The Inbox Agent: An AI That Triages Your Email and Drafts Your Replies (Without Ever Sending)
Every “AI email” tool hits the same ceiling, and it isn’t the AI - it’s that the tool can only see your inbox. So the best it can do is guess at importance: this sender emails you a lot, this one says “urgent.” It has no idea what actually matters to your business.
The inbox agent I run does. It reads my inbox, sorts it by what matters to me - the people in my world, a real new lead versus noise, the things I actually have to act on today - and drafts replies in my voice. It never sends, deletes, or archives. I press Send.
The reason it works isn’t the email part. It’s that the agent is wired into my whole operating system - my clients, my pipeline, my ideal customer, my tone of voice, my operating principles. It judges mail the way I would, because it can see what’s true about my business. That is the Agent-Staffed Function idea applied to one small surface: one accountable human, one function, an agent that gets its intelligence from being part of the system rather than bolted onto it.
This guide explains what the tool is, how it works, what makes it different, and how to build your own. It assumes you’ve already set up Claude Code - if you haven’t, start with the Claude Code Setup Guide.
Two ways to get it
Want it ready to run? The complete, plug-and-play template is in the Built, Not Hired community. Clone it, type /setup, and you’re triaging in about fifteen minutes - the setup walks the Gmail connection and fills in your context for you. No assembly required. That’s the members’ shortcut.
Want to build your own? This guide walks the whole architecture so you can. It’s the more technical path - expect to be comfortable with an API key and a terminal, and to spend a few hours - but everything you need to understand is here.
Same tool, two doors. The rest of this guide is the build-your-own door.
Part 1: What makes it different
A normal email tool sees an envelope. This agent sees the business behind the envelope. That single difference produces everything else:
- Triage by relationship and intent, not generic “importance.” Mail from a client, a partner, or a deal you’re mid-negotiation with rises to the top with the context attached - “this is the deal at proposal stage.” A first-time, unknown sender who’s actually a real lead gets surfaced too, instead of buried for not being in your contacts yet - because the agent checks them against your ideal-customer definition. Everything else sorts down to “worth a look” and “skimmable.”
- It drafts in your voice, and it’s actually right. Because it can read your tone and your rules, the draft comes back sounding like you, not like a generic assistant - and because it can read the deal’s context, the reply answers the real situation, not a guess from the subject line.
- Drafts only - by construction. There is no “send” in the code. Not “told not to send” - there is literally no code path to send, delete, or archive. The worst case is a draft you don’t like. That’s what lets you hand it a real inbox.
- It judges by your principles automatically. Never fabricate a number, never shorten someone’s name, leave a clear placeholder where a fact is missing - the agent inherits those rules from your system instead of being re-told every time.
The takeaway worth internalizing: the leverage was never the AI. It’s the context you give it.
Part 2: How it works
Three pieces, and the third is where the value lives.
1. The hands - a small script. A program that talks to your email through the official API and can do exactly three things: read a message, classify the inbox, and create a draft. No send, delete, or archive function exists in it. It also tags known service senders (security alerts, payments, anything from a government/tax domain) so those get flagged as action-required.
2. The shared brain - your context. A handful of plain files that describe your business: your clients, your active deals, your partners, your ideal customer, how you write, and your operating principles. This is the unglamorous part, and it’s the part that makes everything else work. A generic tool can’t read these. Yours can.
3. The runbook - the command. A short instruction set (a Claude Code “skill”) that ties it together: run the classifier, read your context files, tier the inbox by relationship and intent, and - when you ask - read a thread and write a draft. Two modes are useful: triage the last couple of days, or triage only what’s new since you last checked (tracked with a tiny timestamp file).
The flow end to end: your inbox → classify + match against your context → a tiered digest of what needs you → (on request) a drafted reply → you press Send. The agent does the volume; you keep the judgment and the final click.
Part 3: Build your own
Here’s the architecture. None of it is exotic; it’s just assembly. (If you’d rather skip the assembly, that’s what the community template is for - see the end.)
1. Connect to your email (the fiddly part). Use your provider’s official API. For Gmail that means a Google Cloud project, the Gmail API enabled, an OAuth consent screen, and a Desktop OAuth client - with a scope that allows reading and creating drafts (gmail.modify), nothing broader. Authorize once in the browser; cache the token locally and let it refresh itself.
2. Build the hands - read, classify, draft. A small script with three commands:
- triage - pull recent mail, and for each message grab the sender, subject, and the inbox category your provider already assigns (real correspondence vs. promotions/social/updates). Run the sender through a short list of service rules (simple pattern matches: your payment processor, your hosting, security alerts, government/tax domains) so non-human mail self-labels.
- read - return the full plain-text body of one message (you always read the real thread before drafting).
- draft - write a reply as a draft into the thread. This is the only mutation. Do not write a send function. Enforce the guardrail in code, not in a prompt - if the capability doesn’t exist, no model mistake and no bad prompt can trigger it.
3. Write your context files. This is the real work and the real payoff. Plain text is fine. At minimum: your clients, your active deals (with stage), your partners, your ideal-customer profile (so the agent can spot a real new lead among strangers), how you write (paste a couple of real emails), and your hard rules. Keep these private - they’re sensitive, and they’re the moat.
4. Wire it into Claude Code as a skill. Write a short runbook that tells the agent the order of operations: load the context files, run triage, tier the results by relationship and intent, surface the two or three things that actually need you, and only draft when you ask. Add the voice and no-fabrication rules so every draft obeys them.
That’s the entire system. The hard parts are the OAuth dance and writing honest context files; everything else is wiring. Budget an afternoon.
Or skip the build
If you want the finished thing - the script, the commands, the fill-in context templates, and a guided /setup that does the Gmail connection and the context interview for you - it’s waiting, ready to run, in the Built, Not Hired community. Members clone it and they’re triaging in fifteen minutes.
Either way, remember the lesson under the tool: the email part is easy. The edge is the context you give it. Build that first - the brain before the inbox - and every agent you add after this one gets smart for free.