The shape
The system produces a draft (a reply, a summary, a report, a first version of a document) and a person edits it and sends it. The system never sends anything.
This is the highest value-to-risk ratio in the whole subject and it is consistently underrated because it looks unambitious. It removes the expensive part of the work, which is the blank page, while leaving accountability exactly where it was. The failure mode is a bad draft that somebody deletes, which costs thirty seconds.
For most organisations, most of the time, this is the right shape, and the argument for anything more autonomous should have to beat it explicitly.
Where the draft appears decides whether it is used
More projects die here than on quality. A draft that appears in the reply box the person is already typing into gets used. A draft that lives in another tab, behind a login, requiring a copy and a paste, does not, no matter how good it is.
Three requirements that sound like polish and are actually the product:
- In place. In the email client’s reply field, in the document, in the ticket’s response box.
- Fast enough. Under about three seconds or people start typing instead. Stream the tokens; a draft appearing progressively feels immediate at the same total latency.
- Editable text, not a conversation. People want to fix a sentence, not negotiate with a chat window about fixing a sentence.
The metric is what happens to the draft
Track, for every draft: sent unchanged, lightly edited, heavily rewritten, or discarded. This is free instrumentation and far better evidence than a satisfaction survey.
A high discard rate is the loudest signal you will get and it is usually specific: one category of request the drafts get wrong, or a tone that does not fit. A high unchanged-send rate looks like success and deserves suspicion, which brings us to the real risk.
Automation bias
When a fluent, confident draft is put in front of a reviewer, approval rates rise for content the reviewer would not have produced themselves, including content that is wrong. This effect is well documented in aviation and in clinical decision support, where people accept an automated recommendation over their own contrary judgement; the direction of the finding is robust, though the size varies substantially by task, expertise and how the interface is designed.
The mechanism is worth holding onto: reviewing is cognitively cheaper than composing, and a well-formed draft supplies a reason to stop thinking. Fluency is not a signal of correctness, but it reads like one.
So design the interface to keep the reviewer working:
- Show the sources inline. Every factual claim carries the record it came from, as a link the reviewer can open. Checking a fact against a source is a task; reading a paragraph is a glance.
- Highlight what needs verifying. Mark the numbers, dates, names and commitments in the draft. The reviewer’s attention goes where you point it.
- Do not display a confidence score. A number the model generated will be treated as evidence it is not.
- Leave gaps deliberately. A draft with
[confirm delivery date]in it cannot be sent without a human having done something. This is crude and it works better than any amount of instruction.
Voice comes from examples
Never describe the tone with adjectives. Give the model six of this person’s or this team’s actual past replies, and say to match them. “Professional but warm” produces the same anodyne register for everyone; six real replies produce something a colleague recognises.
Keep those examples in a file the team can edit themselves. Being able to fix the voice without asking an engineer is what makes a drafting tool feel like theirs.
Where the line is
The moment the system sends without a person, it stops being this pattern and becomes something with an entirely different risk profile: one where a wrong draft reaches a customer, a regulator or a supplier with your organisation’s name on it. Auto-send is a decision to take, deliberately, for a narrow category, with a limit and an audit trail. It is not an incremental improvement to a drafting tool, and treating it as one is how teams ship something they never agreed to.
Every lesson here is open. Your progress is recorded once you pass the Context Engineering exam.
Check your understanding
A drafting tool for support replies is measured as a success: 71 per cent of drafts are sent with no edits. Why should that number worry the team as much as reassure them?
Pick the one you would defend. Your answer stays private.
Stuck on something?Ask Mai, your AI tutor
