Handoffs: fewer people, more machine boundaries
Lean thinking taught us that every handoff is waste. Agentic teams have fewer human handoffs and considerably more boundaries, and the new ones fail differently: silently, plausibly and at speed.
Trace a feature through a conventional team and count the transitions. A product manager writes a requirement and passes it to a designer. The designer produces a flow and passes it to an engineer. The engineer implements and passes it to a reviewer. The reviewer approves and it passes to QA. QA passes it to release. Release passes it to operations. Six or seven handoffs, each one a point where context is compressed, transmitted, and partially reconstructed by someone who was not present for the original decision.
Lean thinking has been telling us for forty years that this is where the waste is. Not in the work, in the queues and the transitions between the work. Every handoff has a wait time, an information loss, and a risk of misunderstanding. The entire cross-functional team movement, the whole “you build it, you run it” argument, DevOps as a discipline: all of it is fundamentally an argument for removing handoffs by putting the capabilities in one place.
So here is the appealing story about agents: they collapse the handoffs. One person, holding product intent, working with agents that implement and test and document, ships the whole thing. Six transitions become one. Enormous win.
The appealing story is about half right, and the half that is wrong is the half that will hurt you.
Handoffs did not disappear, they changed species
What actually happens is that human-to-human handoffs are replaced by human-to-agent and agent-to-agent boundaries, and the count often goes up, not down. A single feature might now cross: human intent to specification, specification to planning agent, planning agent to implementation agent, implementation to test generation, tests to CI, CI to review sampling, review to merge policy, merge to deployment automation, deployment to monitoring. Nine boundaries where there were six.
They are faster. They have essentially zero queue time, which was a large fraction of the cost of the old kind. That is a real and substantial win and I do not want to minimise it.
But they are not free, and the way they fail is worse in one specific respect. A human handoff fails loudly. The designer looks at the requirement and says “wait, what happens if the user has two accounts?” The QA engineer says “this does not match what the ticket asked for.” Human recipients of a handoff are active interpreters who push back when the input is bad. That pushback is not a bug in the process, it is the primary error-detection mechanism in the entire system, and it is almost entirely undocumented because nobody thinks of “asking a clarifying question” as a control.
An agent boundary fails silently. Ambiguous input does not produce a question. It produces a confident, plausible, wrong output that passes to the next boundary, which also does not ask, and so on. The error propagates at full speed through every subsequent stage, gaining apparent legitimacy at each one, because by stage four it is no longer an ambiguity, it is an established fact in the codebase with tests around it.
That is the core asymmetry. Human handoffs are slow with built-in error detection. Machine handoffs are fast with built-in error amplification. Any process design that swaps one for the other without adding explicit detection is trading latency for correctness without noticing it made the trade.
Human handoff
- Queue time measured in days
- Recipient reads it and asks a question
- Ambiguity surfaces as a conversation
- Fails loudly, at the boundary
- Slow, with error detection built in
Machine boundary
- Essentially zero queue time
- Recipient never asks anything
- Ambiguity resolved silently by guessing
- Fails quietly, three boundaries downstream
- Fast, with error amplification built in
Where the boundaries actually are now
It helps to name them, because they are less obvious than the old ones and they get designed by default rather than on purpose.
Intent to specification. The highest-consequence boundary in an agentic team, and the least instrumented. A human holds a fuzzy sense of what should exist and converts it into criteria. Everything downstream inherits whatever was lost or invented here. There is no automated check on this transition at all, which is why the previous pieces in this series keep circling back to specification quality.
Specification to implementation. Nominally checked, since the acceptance criteria give you something to evaluate against. But the check verifies the implementation against the criteria, not the criteria against the intent, so an error introduced at the previous boundary passes through this one with a green tick.
Change to change. The one people miss entirely. When several agents produce changes in parallel against the same codebase, each is individually correct with respect to its own specification, and their interaction is nobody’s responsibility. This is a handoff in the sense that matters (context has to travel between two pieces of work) and there is usually no mechanism for it whatsoever. Two changes that each add a caching layer, or that each modify the same configuration in compatible-looking ways, or that each assume they are the only writer to a table.
Implementation to operations. Something is running in production that no human designed in detail. When it behaves strangely at 4am, the person on call is doing archaeology on code they have never read, written by a system that is not available to explain itself. The handoff to operations used to carry a human who remembered writing it. Now it carries a diff.
Session to session. Even within a single agent’s work, context does not persist the way a human’s does. A developer who returns to a feature after a week retains a mental model. A new session starts from whatever is written down. This makes written context load-bearing in a way it never was, and it means undocumented decisions do not merely become hard to recall, they cease to exist.
Designing the boundaries deliberately
Three things seem to matter more than the rest.
Make the interface explicit and checkable. Every boundary should have a stated contract, and the contract should be verifiable. Specification to implementation has acceptance criteria. Implementation to review has evidence of checks. Change to deployment has a rollback path. Where you cannot state what a good handoff looks like, you have an undesigned boundary, and undesigned boundaries are where the silent failures live.
Add back the clarifying question. The most valuable behaviour of a human recipient was refusing to proceed on ambiguous input. That behaviour can be partially reconstructed: agents can be instructed to flag ambiguity rather than resolve it, and a specification review step can ask explicitly whether the criteria are decidable. Neither is as good as a skeptical colleague. Both are much better than nothing, and the difference between “resolve ambiguity plausibly” and “surface ambiguity for a human” is one of the highest-return configuration decisions available.
Make context travel as an artefact rather than as memory. If session-to-session continuity is thin, then decisions have to be written down at the moment they are made, in a place the next reader will look. Architectural decision records, previously a discipline that good teams maintained and everyone else intended to, become structurally necessary rather than virtuous. The undocumented rationale does not degrade gracefully any more; it evaporates.
The human boundaries that remain are more important, not less
A counterintuitive consequence. Because there are fewer human-to-human handoffs, the ones that remain carry much more weight and deserve more investment rather than less.
The product-to-specification conversation now determines the fate of a large volume of work rather than a single ticket. Getting it wrong used to be caught by an engineer three days later. Now it produces eleven changes before anyone notices.
The reviewer-to-author conversation still exists and is now a conversation with a person who may not have written the code they are defending. That is a strange and under-examined dynamic. The author is accountable for a change they specified and sampled but did not compose, and the review conversation has to be about intent and judgement rather than about craft, or it becomes a discussion nobody can meaningfully have.
The engineer-to-operations relationship becomes more critical because the runtime behaviour is less predictable from first principles. Observability stops being a nice practice and becomes the only way anyone knows what the system does.
The pattern: fewer handoffs, each one carrying more consequence. That is an argument for making them better, not for celebrating that there are fewer.
The parallelism problem deserves its own attention
I want to dwell on the change-to-change boundary because it is the one I think is most under-appreciated.
Human teams naturally limited parallel work in the same area, because a person can only hold one thing at a time, because they talk to each other, and because merge conflicts are annoying enough to create social pressure toward coordination. Those limits were accidental and they were doing real work.
Remove them and you can have six changes in flight touching overlapping code, each passing its own tests, each merged in an order nobody chose deliberately. The conflicts that a version control system detects are the easy case. The ones it does not detect (semantic conflicts, where both changes merge cleanly and the combined behaviour is wrong) are the expensive case, and they scale with the square of parallelism rather than linearly.
The mitigations are unsatisfying but real: limit concurrent work per area of the codebase, integrate frequently rather than accumulating long-lived branches, invest in integration tests specifically at the seams where parallel work lands, and treat any area with high parallel change rate as a candidate for better module boundaries. None of them is clever. All of them are the kind of thing teams skip because the failure is intermittent and hard to attribute.
Human teams limited parallel work in the same area without ever deciding to. A person holds one thing at a time, they talk to each other, and merge conflicts are annoying enough to avoid.
Those limiters were accidental, and agents remove all three. Six changes in flight over overlapping code, each passing its own tests, merged in an order nobody chose.
Where this breaks down
Where the argument is weaker than it sounds.
I may be overstating human error detection. The clarifying question is real, but so is the engineer who receives an ambiguous ticket at 4pm on Friday, makes a guess, and ships it. Human handoffs failed silently all the time. The requirements-to-implementation gap has been the industry’s most reliable source of defects for its entire history, and it was staffed entirely by humans who could have asked. The honest version of my claim: humans asked sometimes, and sometimes is more than never, and the difference matters at volume. It is not the difference between a reliable process and an unreliable one.
Fewer handoffs is still a genuine win and I have spent this piece qualifying it. Queue time was an enormous fraction of lead time in conventional processes, often the majority of it. Agent boundaries have essentially none. If I have made the new boundaries sound worse than the old ones on balance, that is wrong. They are better on latency by an order of magnitude and worse on error detection, and for most teams the aggregate is clearly positive. The point is to notice the specific thing that got worse and address it, not to conclude the trade was bad.
Explicit contracts at every boundary is a lot of process. Taken to its conclusion, this piece asks for stated, checkable interfaces at nine transitions, which is a heavier process than most teams run today and a hard sell for anything but the largest organisations. In practice you can afford to instrument two or three boundaries properly. Choose the ones where errors are most expensive to detect late, which is almost always intent-to-specification and change-to-change.
Written context has a decay problem of its own. I have argued that decisions must be written down because they no longer live in anyone’s head. Written decisions go stale, and a stale architectural decision record is arguably more dangerous than none, because it is confidently wrong about the current system. Trading tacit knowledge for documented knowledge trades one failure mode for another, and the documented one at least fails visibly, but do not mistake it for a solution.
And the small-team case may not apply at all. Much of this assumes enough people and enough parallel work for boundaries to be a real problem. A two-person team working with agents on a codebase they both know well has approximately none of these issues, because the context genuinely does live in two heads that talk constantly. Structure has costs, and small teams are usually better off paying the cost of occasional confusion than the cost of nine contracts.
The takeaway
Agents remove human handoffs and add machine ones, often more of them. The new boundaries are dramatically faster and lose the error detection that human recipients provided for free by asking questions, so errors propagate silently and gain legitimacy as they go.
The response is to design the boundaries rather than let them accrete: explicit checkable contracts where errors are most expensive, ambiguity surfaced rather than resolved, and context that travels as a written artefact rather than as memory. Plus deliberate attention to the boundary nobody owns, which is the interaction between changes happening in parallel.
That last point about context travelling as an artefact leads somewhere specific. If the tacit knowledge is gone and the written record is what remains, then documentation stops being a hygiene task and becomes infrastructure. The next piece is about what happens when documentation can regenerate itself from the code, and why that is a smaller victory than it first appears.