Bohea

AI extrapolates fluency. I extrapolate emotion.

8 Aug 2026

I use AI to draft client correspondence, and I don't forward what it writes. The popular division of labour — the AI handles the technical part, the human handles the human part — is backwards, and I think it's going to be the thing that catches a lot of people out. AI and people fail in opposite directions. That's not a weakness of either; it's the reason the pair works.

How I WorkAI & JudgmentClient CommunicationReview

Two failure modes, opposite by nature

Watch either side long enough and the pattern is stable. Both failures are extrapolation — filling a gap with something plausible — but they fill different gaps.

  The AI Me
Fails by Fluency extrapolation. Writing a completed tense for something that never happened. Inventing a duration on someone else's behalf. Producing a comparison that quietly steps on a named person's work — because the sentence flowed that way. Emotion extrapolation. Reading enthusiasm as impatience, a delay as going cold, an escalation as a power grab. Filling silence with the worst story that fits it.
How the other side corrects it Every "has / will / should" gets checked back against the code and the record before it goes out. Evidence before action: go re-read the actual thread, line by line, before responding to a feeling.

In practice both columns fire regularly, and both catch real damage. I've caught drafts claiming work was already done that wasn't, tripled time estimates offered on someone else's behalf, and sentences that read as a swipe at a colleague who would have been on that email. Going the other way, I've been talked out of responding to a client's silence as if it were displeasure — and been shown, by going back through the thread, that every part of my read was contradicted by what was actually written.

One detail matters more than the rest: the AI had the entire context and still missed things. The sentence that stepped on a colleague was written with every relevant file in the window. So the review layer isn't there because one side is under-informed — it's there because every single layer has its own blind spot, and the only reliable fix for a blind spot is a second layer that is blind somewhere else.

The reading time is the product, not a tax

Spending two hours understanding a draft I could have forwarded in five minutes looks like waste until you ask what the client is buying. They're buying a person who will put their name on the result. You cannot stand behind something you didn't understand. When they call tomorrow and ask what a particular margin figure means, answering fluently is the deliverable — and you can only do that because of those two hours.

And it capitalizes. Understanding a mechanism once puts it in your head permanently; the next letter that touches it costs nothing. The cost curve for a given client falls on its own as templates and shared shorthand accumulate — so don't estimate the steady state from what a phase boundary costs.

Here's the part I'd bet on: in two years the market will be full of people forwarding AI drafts. They will fail in exactly the ways in the AI column above — the invented completion, the borrowed estimate, the sentence that steps on someone. Not because their model was worse, but because a forwarder has no second layer. The protocol is the moat, and it's an unusually cheap one.

Tiered review: spend where the stakes are

Reviewing everything at full depth doesn't scale and isn't necessary. Three tiers, chosen by what the letter can cost you:

The restatement test in tier A does most of the work. It's not a proxy for understanding — it is understanding, and it's the only one of the three checks that can't be faked by skimming.

What the AI owes the review

The pair only works if the reviewing side knows where to aim. So every draft comes with a review-focus list attached: the two or three places the AI is least sure about, the complete list of commitments the draft makes, and every sentence that names a person or carries a tone. That single habit cut my review time by roughly a third without reducing what I caught — because the time now lands where the density is.

The rule I'd keep if I could keep only one

Every "X should happen" must have had X actually happen once first. Checklists, protocols, promised behaviours — all of them get written after the thing has been done at least once, never before. Written the other way round they read exactly the same, and they're fiction. This is the same discipline as the rest of my work: don't automate a flow you haven't run by hand many times, and don't claim a result you haven't measured.

Written from how I actually run client correspondence — this note is itself a product of the pair described in it, and the draft it started from had three commitments in it I had to go and verify. No specific client, project or person is described.

Related: the same "make it structural, don't rely on anyone being careful" instinct, applied to a machine — I use AI heavily. The machine still can't hurt you.; and to money — Governing AI agents that touch money. On keeping the communication overhead low in the first place: One email per milestone.

If a machine you build needs an interface, a device connection, or data that has to land somewhere else, tell me what it's costing you now. You'll get an honest read on whether it's solvable, and usually something running to look at. Start here →

← All notes