Every AI workflow has a seam between what the model does and what the human does. The position of that seam is the most consequential design decision in the product, and it is the one most teams do not deliberately make. They inherit a seam from how the model happens to work, and pay for it in trust, accuracy, and adoption.
An inherited seam looks like this: the model returns text, so the product shows text and adds an approve button, and now every task in the product has a review step whether it deserves one or not. Deliberate seam design starts from the task instead: what is the cost of a wrong action here, how reversible is it, and what does this specific user need to see before they extend trust? Different tasks in the same product deserve different seams, and flattening them to one is how products end up simultaneously annoying (approvals on trivia) and alarming (autonomy on stakes).
Three common seam positions
Suggest: the model proposes, the human decides. Highest trust, lowest leverage. Good for novel or high-stakes tasks. Draft: the model executes, the human reviews and edits. Medium trust, medium leverage. Good for repeatable creative tasks. Act: the model does, the human is notified after. Lowest trust to earn, highest leverage. Good only for narrow, reversible, audited tasks.
The draft seam carries a hidden failure mode worth designing against: review fatigue. When drafts are good, approval becomes a reflex within weeks, and a reflexive reviewer is worse than no reviewer, because the product's safety story now depends on attention that no longer exists. Two honest responses: measure real engagement (edit rates, time-on-review), and either promote the task to act with an audit trail, or make the review genuinely lighter by surfacing only what the model is unsure about. A seam whose safety mechanism has quietly died is the worst of both positions.
The trust contract
Users will let the seam shift toward act only after they have watched the model perform reliably at suggest and draft. Move the seam in this order, with this earned trust, or your AI features get turned off by the people you most need to adopt them. Trust is not granted; it is observed.
The observation is measurable, which makes the promotion decision empirical rather than aspirational: acceptance rate at suggest, edit distance at draft, and correction rate after act are the three numbers that describe where the seam has actually been earned, per task and per user. Offering the shift when the numbers support it ("you have sent the last forty drafts unchanged; automate these?") lands as recognition. Offering it before the numbers exist lands as presumption, and presumption is what gets AI features disabled in week one.
How to design the seam visibly
Show the user what stage they are at. Make the action the model is about to take explicit and reversible. Provide an obvious off switch that does not bury them in settings. The seam should feel like a choice, not a default.
Visibility has a second audience: the people around the user. Output that leaves the product (emails, messages, records) should be traceable as machine-drafted-human-approved internally even when it reads seamlessly externally, because the first "did a bot send this?" escalation is answered by an audit trail or by churn. And the off switch is not an admission of weakness; it is the price of the on switch. Users who know they can step back in at any moment extend autonomy far sooner than users who suspect they are locked out of their own loop. The paradox of the seam: the easier it is to pull work back from the model, the more work users hand it.