The Handover Is Where AI-Assisted Work Breaks

If I had to point to the single moment where AI-assisted projects lose the most context, it wouldn't be during the work itself. It would be at the handover — the point where one session ends and another begins, where one tool's context window fills up and work continues in a fresh one, or where a human picks up something an AI assistant was working on, or vice versa. Work inside a session tends to be coherent, because everything relevant is still in view. The handover is where coherence has to survive a gap, and gaps are exactly where things get dropped.

Four kinds of handover, and why they're not the same problem

Human to human is the handover we're most practiced at, because it's the oldest kind, and even so it goes wrong constantly — ask anyone who's inherited a codebase from a departed colleague. The usual failure is that the departing person's mental model was never written down anywhere, so what gets handed over is the code, not the reasoning behind it.

Human to AI is deceptively easy to get catastrophically wrong, because the model will confidently proceed on incomplete context rather than visibly stall the way a confused human colleague might. Hand an AI assistant a task without the relevant history, and it won't necessarily ask the clarifying questions a cautious human would — it'll often just produce something plausible-looking that quietly misses constraints nobody told it about.

AI to human fails in the opposite direction. A session ends, a person picks up the thread, and the summary they're working from is whatever the AI happened to surface — which might not include the three approaches that were tried and rejected, or the specific reason a seemingly obvious simplification was deliberately avoided.

AI to AI, across sessions or across different tools, is the newest and least forgiving version of this problem. There's no shared memory to fall back on unless something outside both sessions holds it, and each fresh session starts from something closer to zero than most people initially expect.

What actually needs to survive the gap

Watching enough of these go wrong, I've settled on five things a handover has to carry, at minimum, or the receiving party — human or AI — is working with less than they need and won't necessarily know it:

The objective. Not the task list — the actual goal the task list is in service of. It's surprisingly common for a handover to carry the "what" and drop the "why," and the "why" is what lets the receiving party make good judgment calls when reality doesn't match the plan exactly.

Current state. What's actually true right now, as distinct from what was originally planned. Plans drift during execution, and a handover based on the original plan rather than the current reality sends the next person down a path that's already been partially invalidated.

Decisions made. Especially the ones that might look, out of context, like an obvious alternative was overlooked. If a simpler approach was deliberately rejected for a specific reason, that reason has to travel with the handover, or the next person — reasonably — tries the simpler approach again and burns the same time re-discovering why it doesn't work.

Known risks. What could go wrong that the receiving party should be watching for, stated explicitly rather than left to be rediscovered the hard way.

Unresolved questions and the next action. What genuinely hasn't been decided yet, and what the very next concrete step should be. A handover that ends with "continue the work" rather than a specific next action puts the burden of re-orientation entirely on the receiving party.

The specific failure that made this concrete for me

The version of this problem that sharpened my thinking most wasn't a human-to-human handover — it was AI to AI, across two different tools used on the same task a day apart. The first tool had spent a session exploring an approach to a feature, ruled it out for a specific reason involving a downstream dependency, and implemented a different approach instead. The session ended. The next day, a different tool picked up related work on the same feature, with no visibility into the previous session's reasoning — only the code that resulted from it.

That second tool, working from the code alone, proposed refactoring toward the exact approach the first tool had already tried and specifically rejected. Nothing was recorded anywhere that said "this was considered and here's why it doesn't work" — the rejection lived only in the first session's now-closed context. The human overseeing both had to notice the proposal looked familiar, dig back through the first session's history to confirm it really was the same rejected approach, and explain the downstream dependency problem a second time. Multiply that by every handover on a project with several contributors, human and AI, and the cost stops being a minor annoyance and starts being a real tax on how fast work can actually move.

Why this list is a floor, not a ceiling

I want to be clear that this is a minimum, not a complete specification. A handover that carries these five things is usable. It isn't necessarily complete, and for genuinely complex work, more context will always help. But I've found that teams — and AI-assisted workflows — tend to either carry far too little (a one-line "pick up where I left off") or attempt to carry everything (a sprawling document nobody actually reads before continuing). The five-part minimum is meant to be small enough to actually get written and read every time, which matters more than being exhaustive.

The limitation I keep running into

The part I haven't solved cleanly is judging, in the moment, how much detail a given handover actually needs. A trivial continuation might genuinely need only the "next action" line; a complex, judgment-heavy handover might need considerably more than the five-part minimum to avoid genuinely losing something important. Writing too little risks the exact context loss this whole approach exists to prevent. Writing too much risks nobody actually reading it carefully, which has the same practical effect. I don't have a reliable rule for calibrating that yet — only the general instinct that when in doubt, a slightly-too-thorough handover is the safer failure mode, because the cost of over-explaining is a few minutes of a reader's attention, and the cost of under-explaining is a repeated mistake.