Our AI Drafts Every Email and Sends None of Them

Over four months, our company brain surfaced 626 email threads where someone on the team owed a reply. It drafts answers on request, and none of them goes out on the AI’s say-so. Every client email it writes lands in Gmail as a draft, and a person reads it and presses send.

That sounds like the cautious, obvious choice. It took us longer to get there than it should have, and the more interesting lesson came later, from a place where we didn’t have a human in the loop and needed something else.

How the drafting works

At the end of a working day, each founder runs a day-end process (39 runs between June and September, across two founders). It reads the day’s meetings and email, files what matters into the right client folder, creates tasks, and sweeps the inbox for threads where the last message came from someone outside the company and nobody on our side has answered.

For each owed reply, a small agent opens the full thread in its own isolated context, writes a reply that does one specific thing (“confirm receipt and ask for the signed agreement by Friday”), and creates it as a Gmail draft through one shared library. The orchestrator never sees the email body. It gets back a draft ID and a one-line summary.

Two of the drafter’s hard rules matter most here. Drafts only, never send. And never invent a date, a number or a commitment that isn’t in the thread or the instruction it was given.

The rule started in one person’s head

For a while, “never auto-send client email” existed in exactly one place: one person’s private Claude memory. It was a note that one founder’s sessions had learned from feedback. The other founder’s sessions didn’t know it. Neither did the scheduled jobs.

That’s a terrible place for a safety rule. Personal AI memory is great for preferences, like how you like your summaries formatted. It’s a bad home for anything the whole company depends on, because nobody else can see it, review it or notice when it’s missing.

On July 5 we started a decisions log, a single append-only file of company rulings, and this became one of the first entries, logged retroactively from that private memory. It now sits in our ethos file in one line: AI recommends, clients and partners decide. Commands that touch client email print that ruling when it applies, so the rule shows up at the moment it matters instead of living in someone’s recollection.

If your team uses AI tools, go look for this pattern. I’d bet there are rules your company runs on that live in one person’s chat history.

Why drafts, specifically

A sent email can’t be unsent. It goes to someone outside the company, it carries your name, and the recipient will act on whatever it says. Reviewing a draft costs a minute. That asymmetry is the whole argument.

We also run a leak check on every draft before it’s created. It reads the email the way the recipient would and checks seven categories, including other clients’ names, internal pricing, credentials and our negotiating position. The instructions say why plainly: drafts are reviewed by a human anyway, but a clean draft protects the reviewer too. People skim. A reviewer who trusts the system is exactly the reviewer who misses the one sentence that shouldn’t be there.

Some of our commands go further and refuse to create the draft at all. The weekly client update includes a short video, and the template has a placeholder for the link. If the placeholder is still in the text, the command stops and says which project is missing its video. The instruction says it in five words: “never send on a hope.”

Where the human sits matters more than whether there is one

The LinkedIn outreach tooling taught me the most here. It’s split into three separate commands. One writes and edits campaign copy but cannot start a campaign. One starts and pauses campaigns but cannot write copy. One handles replies and can do neither. No single command can both write the words and launch them.

The reason is in the commit message: starting a campaign is a separate invocation “so the person authorising a send is not the person who wrote the copy ninety seconds earlier.” A human in the loop who just wrote the thing they’re approving isn’t much of a check. Putting the approval in a different step, with fresh data pulled from the API, gives the human an actual decision to make.

The write nobody was reviewing

Email is the obvious risk. The incident that taught me more was in task management, where we had decided a human didn’t need to approve each write.

When day-end finds a new task that duplicates an existing one, it merges the new note into the old task instead of creating a second copy. It happens on most runs, and nobody approves each merge. It’s internal, it’s reversible, and putting a human on every one would make the whole process unusable.

During the August 26 run, the deduper transposed two page IDs. A note meant for one task got merged onto a completely unrelated task in a different project. The task tool’s API returned success, because from its point of view nothing was wrong. A valid page got a valid update. It surfaced only when we went back over that run.

We didn’t add a human. We added a check a machine can do reliably: every merge now verifies the target page’s title against the title the deduper expected before writing, and echoes both the ID and the actual title into the log so a wrong target is visible.

That’s the placement principle I use now:

• Irreversible or external (email, campaign launches, anything a client sees): a human approves, in a separate step from whoever wrote it.
• Internal and reversible (task merges, file moves, index rebuilds): no human per action, but a deterministic check on the target before every write, and a log a human can read afterward.

The failure mode I worry about most is the middle ground: a human nominally in the loop on something high-volume, approving by reflex. That’s worse than no human, because everyone believes there’s a check.

What this costs us

Drafts pile up. On a heavy day the drafts folder fills faster than anyone wants to read it, and an unsent draft is still an unanswered email. The system makes replying easier and does nothing about whether anyone actually replies.

Reviewing still takes attention, and a draft that needs context the thread doesn’t have will need real rewriting. I’d rather pay that than find out a client received something nobody on our team read.

If you’re setting this up

Start by finding the rules that live in one person’s AI memory and move them somewhere the whole team, and every automated job, can see. Then sort every write the system makes into the two buckets above. External and irreversible gets a human in a separate step. Internal and reversible gets a deterministic check and a log.

The rest of how we run this is in the pillar post on our company brain, and the decisions log gets its own write-up in Write Down the Rulings. If you want this for your team, with drafts-only email from day one, I build them in 14 days.