Suggest, Draft, or Act: Choosing the Interaction Shape

Suggest, Draft, or Act: Choosing the Interaction Shape is the decision that constrains every other decision in this book. The three shapes differ in who holds the decision, and because of that they differ in what an undo must cover, how fast the answer has to arrive, how much human review the feature consumes and what a single interaction costs.

Key takeaways

• The shape is a product decision about who holds the decision, not a UI preference. Suggest leaves it with the user, draft splits it, act takes it.
• Each shape commits you to a different bill of engineering. Choosing act commits you to reversibility, abstention, monitoring and a cost ceiling, all at once.
• Latency tolerance rises as you climb. A suggestion competes with the user's own typing, while an autonomous action can take a minute nobody is watching.
• Review load is the resource that runs out first. Draft consumes human attention per interaction, so a drafting feature at scale is a staffing decision.
• Shape is per action, not per product. One feature routinely suggests some things, drafts others and acts on the trivial remainder.

Read this after Chapter 2's gates, which decide which shapes are even available, and before Chapter 4, which builds the reversibility that act depends on. The organisational version of the same argument, where review becomes the constraint, is Agents That Finish.

Two teams build the same email feature. One ships a button that proposes three replies. The other ships a system that answers routine mail on its own.

Same model, same prompt, same corpus. The first team's remaining work is a dropdown and some telemetry.

The second team's remaining work is an audit log, an undo, a confidence threshold, an escalation path, a rate limit, a cost alarm and a policy about which mail is routine. None of that is optional, and none of it was in the estimate.

The shape is about who holds the decision

Strip away the interface and each shape is an answer to one question. When the model has produced something, who decides whether it happens.

Suggest leaves the decision entirely with the user. The system offers an option, the user takes it or ignores it, and the default outcome if the user does nothing is that nothing happens. The system's output is an opinion.

Draft moves the work to the machine and keeps the decision with the human. The system produces something substantially complete, the human inspects and commits it, and the default outcome if the human does nothing is still that nothing happens.

Act takes both. The system produces and commits, the human is informed rather than consulted, and the default outcome if nobody intervenes is that it happened.

That last clause is the whole distinction, and it is worth stating as a test. Ask what happens when everybody is busy and nobody looks. Under suggest and draft, nothing. Under act, everything.

What each shape commits you to

The bill of engineering differs sharply, and reading the table before building is cheaper than discovering it during hardening.

Two rows deserve attention because they are where estimates go wrong.

The undo row scales badly. Under draft, the only thing to reverse is a commit the human just made, which is one operation and usually one record. Under act, the undo has to cover everything the system did without asking, including effects that left your boundary, such as a sent email or a posted webhook, and those are not reversible by rolling back a transaction.

The review row is the one that decides whether the feature survives contact with volume. A drafting feature consumes a bounded amount of human attention per interaction, which is fine at a hundred a day and a hiring plan at ten thousand. That arithmetic belongs in the design, not in a later conversation with operations.

Latency tolerance rises as you climb

Each shape sits in a different part of the user's attention, which is what makes the latency budget differ by orders of magnitude rather than by percentages.

A suggestion competes with the user doing it themselves. If the user can type the thing faster than the suggestion appears, the suggestion is noise, so the budget is well under a second and streaming does not help, because a half-arrived suggestion is not usable.

A draft is requested deliberately, so the user is willing to wait and to watch. Several seconds is acceptable, streaming genuinely helps because partial output is readable, and the perceived-speed techniques in Chapter 8 apply here more than anywhere else.

An action nobody is watching has almost no latency constraint, and that is a resource worth spending. Time buys verification, a second opinion, a slower and better model, and a retry on a failed check. That is the shape's main advantage. An autonomous feature that answers in 400 milliseconds has usually spent its main advantage on nothing.

Choose by cost of wrongness and reviewability

Chapter 2's gates said which shapes are permitted. Two further factors pick among them.

The cost of a wrong answer at the point it lands sets the ceiling. Where that cost is high and irreversible, act is unavailable regardless of accuracy, because accuracy is a rate and a rate is not a guarantee. Where the cost is trivial and self-correcting, draft is often wasteful, since you are spending scarce human attention protecting against a cheap mistake.

Reviewability sets the floor from the other direction. Draft only works if a human can actually check the output in a sensible amount of time, which is a property of the output format. A one-line classification is reviewable. A four-paragraph analysis of a document the reviewer has not read is not reviewable, so shipping it as a draft produces the appearance of oversight and none of the substance.

That failure has a name worth using in reviews: rubber-stamp drafting. It is worse than act, because it carries the review cost without the review benefit and it moves accountability onto a person who was never in a position to judge.

Shape is per action, not per product

The instinct is to pick one shape for the feature, and mixing them within a feature is usually the better design.

Consider inbox triage. Labelling a message is trivially reversible and checkable, so the system acts. Drafting a reply is reversible until it is sent, so the system drafts and the human commits. Issuing a refund inside that same conversation is irreversible, so the system suggests it and a human performs it.

One feature, three shapes. Each is chosen by the cost of getting that action wrong. The user experiences one coherent assistant, and the architecture underneath is honest about which parts it is allowed to decide.

The practical artifact is a short table listing every action the feature can take, its shape, and its reason. That document settles arguments quickly, it is what a security or compliance reviewer wants to see, and it is the input to the routing decisions in Chapter 6.

Moving up the ladder has to be earned

Products drift upward, from suggest to draft to act, and the drift is usually driven by enthusiasm rather than evidence.

The move that should require evidence is any promotion of an action from a shape where a human decides to one where the system does. What counts as evidence is a measured accuracy on that specific action, on data from real traffic rather than a curated sample, along with a demonstrated undo and a monitor that would catch a regression.

Building that apparatus is the subject of a companion volume, and the evaluation argument is that the gate has to be able to say no. Without one, promotion happens because a demo went well in a meeting, which is the mechanism behind a large share of the integration failures MIT's Project NANDA report describes when it puts about 95% of enterprise pilots at no measurable P&L impact.

Demotion deserves the same formality. It almost never gets it. Write down, at design time, what would move an action back down the ladder, because deciding that during an incident means deciding it under pressure with an audience.

A worked example, composited and labelled

The details are composited from ordinary product shapes rather than one system, and the shape is exact.

A recruiting product wants AI screening. The first proposal is autonomous: read each application, score it, reject the bottom half, advance the top ten per cent.

Run the analysis. The cost of a wrong rejection is high, borne by someone outside the company, invisible to the company, and irreversible in practice because the candidate is gone. So act is unavailable for rejection. The measured accuracy does not change that.

The shipped design splits by action. Extracting structured fields from a CV is verifiable and reversible, so the system acts. Summarising relevant experience is drafted, with every claim linked to the line of the CV it came from, which makes it reviewable in seconds. Ranking is a suggestion, presented as an ordering a recruiter can reorder, with the reason shown. Rejection is a human action the system never takes, though it may flag missing hard requirements as a checkable fact.

The feature saves most of the time the original proposal promised. It does so without ever putting an irreversible decision about a person inside a component that is wrong at some rate.

The objection: suggest is a cop-out

The objection is that suggestion-shaped features are timid, that they leave the work with the user, and that the value is in automation. Half of that is correct.

It is true that suggest captures the least value per interaction, and true that a product which only ever suggests is leaving efficiency on the table. Where the objection fails is in treating the ladder as a measure of ambition rather than a consequence of the cost of being wrong.

The pragmatic sequence answers most of it. Ship at the shape the evidence supports, instrument the acceptance rate, and use that measurement as the case for promotion. A feature whose suggestions are accepted 92% of the time has an argument for becoming a draft. A feature whose drafts are committed unedited 97% of the time has an argument for acting on the subset where that holds.

That sequence also produces the evaluation data the promotion needs, so shipping low is how you earn the right to ship high. Starting at act, by contrast, means the first real measurement of accuracy arrives as a customer complaint.

Chapter summary

The three shapes are answers to one question, which is who decides whether the model's output happens: suggest leaves it with the user, draft moves the work to the machine and keeps the decision with a human, and act takes both, and the test that separates them is what occurs when everybody is busy and nobody looks, which under act is everything. Each shape carries a different bill of engineering, and two rows dominate: the undo, which under draft covers one commit and under act covers every effect including those that left your boundary, and the review load, which under draft is a bounded amount of human attention per interaction and therefore a staffing decision at volume. Latency tolerance rises by orders of magnitude as you climb, since a suggestion competes with the user's own typing and must be sub-second, a draft is awaited and can stream, and an unattended action has time to spend on verification, a second opinion or a retry, which most autonomous features fail to spend. Among permitted shapes, the cost of a wrong answer sets the ceiling and reviewability sets the floor, and shipping unreviewable output as a draft produces rubber-stamp drafting, which is worse than acting because it carries the review cost without the benefit and moves accountability onto someone who could not judge. Shape belongs to the action rather than the product, so one feature may act on labelling, draft a reply and merely suggest a refund, recorded in a short table of action, shape and reason. And upward promotion needs measured accuracy on real traffic, a demonstrated undo and a monitor, with the demotion trigger written down at design time rather than decided during an incident.

Act depends entirely on being able to take something back, and most products have far less of that ability than their teams believe. Chapter 4 is Designing Reversibility Into the Product, which treats undo as a feature to be built rather than a property to be assumed.