Guildy.ai
Job hunting is no longer a discovery problem. It is an inbox-scale workflow problem. I built Guildy 0→1 to turn recruiter email threads into live interview pipelines and stage-aware prep.
Founder, Product Design, and AI UX (0→1)
2025 — Present
Solo design + AI-assisted development
At a Glance
- -Built a Gmail-native pipeline system that converts recruiting email threads into structured job stages
- -Designed a thread-first detection architecture to reduce missed recruiting updates
- -Shipped as a solo designer using AI-assisted development tools
- -Private beta users replaced manual spreadsheet tracking with Guildy as their source of truth
Overview
Guildy is a Gmail-native intelligence layer for job seekers. It syncs your Gmail, detects recruiting-related email activity, creates and updates pipeline items automatically, surfaces next actions and interview prep, and replaces manual spreadsheet tracking entirely. The core thesis: the inbox is already the source of truth for any active job search. Guildy makes that true structurally, not just philosophically.
The Problem
The High Cost of Lost Context
Noise
Recruiting emails look like generic notifications. ATS confirmations, calendar invites, and actual offer updates all arrive with the same low visual priority. Signal gets lost in volume.
Stale Data
Manual trackers lag behind inbox reality. Status updates happen in email, not in spreadsheets. Most job seekers are days or weeks behind on their own pipeline.
Anxiety
Missing next steps matters more than organizing jobs. The fear is not forgetting a company name—it is missing a scheduling email or forgetting to follow up with a recruiter.
The Solution
A Three-Gate Intelligence Architecture
Guildy runs every incoming email through a layered detection system. Rather than asking the LLM to judge every message from scratch, the architecture separates signal routing from classification—keeping costs down and precision up.
Gate 0 — Thread Inheritance
Once a thread is marked as recruiting-related, all future messages in that thread are automatically flagged. This is the most important rule. Recruiter replies are often short, context-free, and would fail any classifier in isolation. Thread inheritance is what keeps them from being lost.
Gate 1 — Hard Junk Sieve
A blocklist of confirmed non-recruiting senders and patterns. Shipping notifications, password resets, and receipts are filtered before they reach any further logic.
Gate 2 — Warm-Lead Router
A broad, low-bar keyword and pattern match. The goal here is inclusion, not precision. Anything that could plausibly be recruiting-related is routed forward. False positives are acceptable; false negatives are not.
Gate 3 — LLM Classifier
The final gate. The LLM evaluates recruiting relevance, message type (intro, scheduling, rejection, offer), and stage delta. Critically, detection and stage advancement are separate decisions. A message can be recruiting-related without triggering a stage change.
Guildy's Gmail-first recruiting intelligence architecture: thread inheritance, broad routing, and LLM classification.
System Principles
- —Never stop listening to known recruiting threads
- —Prefer over-inclusive routing to avoid missed interviews
- —Separate message detection from stage movement
AI System Design Decisions
Built around the real failure cost
Guildy is intentionally biased toward catching more potentially job-related emails, even if that means a few extra false positives. A false positive is easy to ignore or clean up. Missing a real interview or scheduling email is the bigger failure. The routing and classification logic is designed around that tradeoff.
Internal log for near-misses (Ghost Log)
If an email passes the first routing layer but is not added to the pipeline after classification, it is still logged internally. This Ghost Log is a QA and tuning tool for reviewing edge cases, improving prompts, and refining routing rules over time. It is not a user-facing feature.
Rules first, LLM second
Rules handle broad inbox filtering and route only plausibly relevant emails forward. The LLM handles the harder classification decisions after that first pass. This split keeps the system cheaper and faster, while improving accuracy by reducing noise before the model sees anything.
Designed for ongoing tuning
We can inspect missed cases and use them to improve the rules and prompts. That lets the system get more reliable over time without running the LLM on every email.
What Made This Hard
Linguistic variance: A startup recruiter writing informally and an enterprise ATS sending structured HTML notifications require the same detection system. The vocabulary, tone, and structure vary by two orders of magnitude.
Contextual decay and thread ambiguity: Short follow-up replies contain no stage information on their own. Knowing that a reply belongs to a recruiting thread—and that a previous message set up an interview—requires carrying context across the full thread history.
Product UX
- -Pipeline board + details panel
- -Stage timeline
- -Thread summary
- -Next action
- -Interview prep
- -Manual override
Pipeline board with job details panel
Mobile
Pipeline stages and job details on the go.
Context-aware interview prep tied to the active role.
Impact
- -Replaced spreadsheet tracking for early users
- -Reduced manual status updating to near zero across active pipelines
- -Increased user confidence that they were not missing recruiter updates
- -Established a foundation for interview prep tied to live pipeline context
What I Would Do Next
- -Voice mock interview with scoring and feedback
- -Calendar-aware prep that surfaces automatically before scheduled interviews
- -Stronger handling of edge cases: referrals, cold outreach, multi-recruiter threads
- -Token/referral monetization loop