The Four Handovers

When a team designs an intelligent feature, the debate usually sounds like an interface debate. Should it be a panel? A button? A suggestion that appears in place? Should it work quietly in the background and show you what it did?

Those sound like layout questions. They are one question wearing four disguises: how much of the work is the product taking - and how much is the user keeping?

Everything else is downstream of that answer. The layout, the copy, the onboarding, the failure design - all of it follows from where the work is split. Teams that argue about the surface first end up shipping a contract nobody read, including them.

Classic software had clean contracts, and we stopped noticing them. A spreadsheet takes the arithmetic and leaves you the meaning. A search box takes the looking and leaves you the choosing. A compiler takes the translation and leaves you the intent. Nobody reads these contracts because nobody needs to: the tool's abilities drew the boundary, and the boundary never moved.

Intelligent products broke that stability. For the first time, the product could take more - it can propose, choose, perform, even check its own work. The boundary is no longer set by what the software can do. It is set by what its designers decide it should do. Which means every intelligent interface is now an authored contract, whether or not anyone authored it deliberately.

The interfaces that feel wrong are usually the ones whose contract was never written. The product took responsibilities nobody agreed to hand it - or refused ones the user was ready to give.

Any job a product might help with splits into four responsibilities. Someone notices that the work needs doing. Someone chooses what to do, among the ways it could be done. Someone performs it. And someone answers for it being right.

Initiate. Decide. Act. Verify.

Take something unglamorous: an overflowing queue of customer messages. Noticing that a message needs an answer is initiate. Choosing what the answer should say - refund, apology, escalation - is decide. Writing and sending it is act. Standing behind it when the customer replies is verify. A product can hold any subset of those four, and each subset is a completely different product. The same model, the same capability, four different contracts - and the user experiences the contract, not the capability.

Every interface posture is an assignment of those four responsibilities between the user and the product. Four postures cover almost everything teams actually ship - and seeing them side by side says more than any definition.

Read the map row by row and it looks like a story of the product steadily taking over. Read it column by column and a more interesting pattern appears: the responsibilities do not move together.

Acting moves first. We hand over execution easily, because executed work is cheap to inspect and easy to redo. Deciding moves next, and already the handover is harder - a decision embeds values, and the user wants to see a track record before letting go. Initiating moves late: a product that starts work on its own has entered territory most users guard closely, because attention is the one budget nobody gets back. And verifying barely moves at all. Even under a standing mandate, the user keeps the audit. Answering for the result is the responsibility users release last - and never completely.

This is why "we automated it end to end" so often lands badly. End to end describes the work. It says nothing about the risk - and the risk is the part the user still holds.

The most damaging posture on the map is not too much ambition or too little. It is the lopsided contract: the product initiates, decides and acts - then hands the user a pile of finished work and, with it, the entire responsibility for checking it.

Call it the verification dump. It has a distinctive signature: the product's output grows at machine speed while the user's capacity to check it stays stubbornly human. The contract quietly inverts. The user ends up working for the product - auditing on a schedule they never agreed to, at a volume they cannot sustain. On paper the feature is saving time. In practice the user is drowning in review, or has silently stopped reviewing - which means verification was never handed over at all. It was abandoned, and nobody is holding it.

The dump rarely looks like malice. It looks like momentum - more drafts, more answers, more code, with review left as an exercise for the reader. Scale the work without scaling the checking, and the contract breaks in the user's hands.

A product that takes the act responsibility owes the user one of three things in return. Keep the output at a scale a human can actually check. Carry part of verification itself - its own checks, its confidence, its sources, the reasons a result deserves belief. Or make skipped review recoverable, so the cost of trusting wrongly stays small. An interface that offers none of the three has not taken work from the user. It has taken credit and left liability.

The move down the map is often described as the product asking less of the user. That is not what happens. The asks change shape.

An outcome contract does not shrink the user's job. It promotes it. The user stops operating and starts governing: framing goals well, drawing boundaries before the work starts, judging exceptions, and auditing at a rhythm they choose. That is different work - often harder work, and almost always more valuable work. Products that pretend the user's work disappeared leave their users unequipped for the job they actually received. The honest ones teach it: they make goals easy to state well, boundaries easy to draw, exceptions impossible to miss.

This reframing also explains a pattern most teams meet eventually: the expert user who resists the smarter interface. They are not resisting help. They are declining a contract whose terms they cannot see - being asked to give up operating, which they have mastered, for governing, which the product has not taught. Meet them at the contract: show the boundaries, surface the exceptions, and let them keep the parts of the work that were never a burden to begin with.

The postures are not maturity stages, and the map is not a roadmap. Nothing about a product's ambition entitles it to the next row.

A handover follows demonstrated performance in front of the person handing over. A product earns Decide by proposing well, visibly, at Draft. It earns Initiate by deciding well inside a mandate the user drew. Each row is an act of permission - and permission is granted on evidence, per job, not per product. The same product might hold a standing mandate for tidying its own internal queues while remaining a draftsman for anything that leaves the building under the user's name.

Some jobs will never advance, and should not. Where a wrong result is expensive, invisible until too late, or harder to check than to produce, the ceiling is low - and that ceiling is a property of the job, not a failure of the product. Deciding to stay at Draft forever is a design decision of exactly the same dignity as deciding to advance.

What counts as evidence matters as much as the order. A track record the user never sees earns nothing: the product may be right constantly, but if being right is invisible, no handover follows. This is why the map rewards interfaces that show their work even when they do not have to - every visible good decision is a quiet application for the next responsibility.

The practical discipline is short. For each job the product touches, write the contract down: which of the four responsibilities the product holds today, which one it is asking for next, and what evidence the user has seen that it deserves it. A contract that cannot be written in three sentences is not a design - it is an accident waiting for its first incident.

Then make the posture legible in the interface itself. The user should never have to infer whether they are looking at a proposal or a done deed, whether the product will wait or proceed, whether anyone has checked this or they are the check.

Legibility is not decoration on the contract. It is what makes the next handover possible. A user who can see what the product decided - and what it would have decided - extends responsibility willingly. A user who has to guess extends nothing, and quietly takes the whole job back.

Interfaces used to describe what software could do. For intelligent products, they describe what the product has taken on - which makes the interface a promise, made in public, kept or broken in front of the person who matters most.

Keep the promise smaller than the capability, and keep it. Products earn a place in someone's work the way anyone does: by holding exactly the responsibility they were given, and asking - visibly - before taking more.