The Handover Is Where AI-Assisted Work Breaks

When enterprise software vendors discuss "AI handovers," they are almost always referring to customer-service routing: transferring an end-user conversation from an automated chatbot to a human support agent.

This note addresses a completely different engineering reality: technical state handoffs in AI-assisted software development and knowledge work.

If I had to point to the single moment where AI-assisted engineering projects lose the most context, it wouldn't be during the coding session itself. It would be at the handoff — the point where one session ends and another begins, where an AI assistant's context window overflows and work resumes in a clean window, where a human engineer inherits an agent-generated branch, or where autonomous agents attempt to collaborate across tasks.

Work inside an active session tends to feel coherent because the immediate prompt history is in view. Research on human interruptions and context switching (Mark et al., University of California Irvine, ACM CHI) illustrates the cost of reconstructing interrupted work. AI development sessions face a related but distinct challenge: without an accessible record of earlier decisions, a subsequent agent may make assumptions that conflict with the prior work.

Four kinds of technical handoff, 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 complex codebase from a departed colleague. The usual failure is that the departing person's mental model was never written down anywhere durable, 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 project history, and it won't necessarily ask clarifying questions — it will often produce something plausible-looking that quietly violates architecture 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 in conversational prose — which rarely includes the three approaches that were tried and rejected, or the specific reason a seemingly obvious refactoring was deliberately avoided.

AI to AI (agent to agent), across sessions or across different tools, is the newest and least forgiving version of this problem. Research on multi-agent software engineering, including Qian et al.'s ChatDev: Communicative Agents for Software Development (ACL 2024), explores structured communication between specialized development agents. It supports the value of coordination, but does not establish that agent interactions inevitably decay into hallucination loops. There is no shared memory to fall back on unless something outside both sessions holds it.

The Minimum Viable Technical Handoff: What Must Survive Between AI Sessions

Watching enough of these go wrong across daily engineering work, I've settled on five specific artifacts a handoff has to carry at minimum, or the receiving party — human or AI — is working with less than they need and won't know it:

1. The Core Objective (The "Why")

Not the task list — the actual business and architectural goal the task list is in service of. It's surprisingly common for an AI handoff to carry the "what" and drop the "why," and the "why" is what lets the next agent or developer make sound judgment calls when reality doesn't match the prompt exactly.

2. Current State vs. Original Plan

What's actually implemented and verified right now, as distinct from what was originally planned. Plans drift during execution, and a handoff based on the initial prompt rather than current codebase reality sends the next session down a path that has already been partially invalidated.

3. Decisions Made & Rejected Alternatives

Especially the ones that might look, out of context, like an obvious alternative was overlooked. If a simpler approach was deliberately rejected because of a downstream dependency or edge-case failure, that reason must travel with the handoff. Otherwise the next AI session will reasonably try the simpler approach again, burning hours re-discovering why it doesn't work.

4. Known Risks & Protected Invariants

What could break that the receiving session should be watching for — schemas, APIs or files that must not be touched without explicit human review, stated as an explicit boundary rather than left to be rediscovered through broken builds.

5. Unresolved Questions & The Single Next Action

What genuinely hasn't been decided yet, and what the very next concrete step should be. A handoff that ends with "continue the work" puts the entire burden of re-orientation on the receiving agent. A handoff that ends with "run the regression suite on the auth router and review token expiration" lets work resume immediately.

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 coding 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.

Turning handoffs into project infrastructure

This failure pattern is why I stopped treating handoffs as ad-hoc prompt summaries and started treating them as governed project infrastructure.

In VeraKeep, our local-first decision ledger, handoffs are budgeted context packages derived from Markdown records tracked in Git. When moving from Claude to Cursor, or from an architecture session to a test-running agent, the system packages requirements, active architectural decisions, rejected approaches and test results over the Model Context Protocol (MCP). The next session begins with grounded project truth, not a blank slate.

Similarly, our specialist AI skills encode explicit stopping conditions and verification gates so that an agent cannot hand over unverified work without flagging what remains untested. For a deeper analysis of this architectural shift, see my companion essay on why agentic AI has a continuity problem, not an intelligence problem.

The limitation I keep running into

The part I haven't solved cleanly is judging, in the moment, how much detail a given handoff 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 — human or AI — actually processing it before continuing. I don't have a mathematical rule for calibrating that yet — only the practical engineering rule that when in doubt, a structured, checkable record of why decisions were made is the cheapest insurance a software project can buy.