The Handoff Problem
Most days I have more than one coding agent working on the same codebase. Something that used to take me a week of calendar time can show up as a finished branch by the end of an afternoon.
The expensive part starts after the branch lands, when the next person (or the next agent) has to pick it up and figure out what was decided and why.
Someone writes a ticket in Linear or Jira. An agent, or a person running one, picks it up. Somewhere in the middle of that session a real decision gets made: drop a feature to hit the date, handle one customer differently from the rest, change how the product behaves because the old way was wrong. That decision happens inside a model session, or in a Slack thread, or in someone’s head while they’re reading the output. The ticket was written before any of it, and almost nobody goes back to update it.
So the system of record is out of date by design. The next person gets a closed ticket and the code, but not what they need to start: what was decided, what’s still blocked, and who owns the next step.
Faros AI studied more than 10,000 developers in their 2025 AI Productivity Paradox report . On teams with high AI adoption, developers completed 21% more tasks and merged 98% more pull requests. Those pull requests got 154% bigger, and the time spent reviewing them went up 91%. Faros found no significant link between AI adoption and improvement at the company level, and their read is that something downstream is absorbing the value the tools create. Bigger changes take longer to read, so review time alone doesn’t prove much. The company-level result matters more. Somewhere between the agent and the business the gains are disappearing, and handoffs are one place I’d look first.
With people, this cost was always there, it was just spread out and slow. Someone would ask a question in the hallway, or remember the meeting where it was decided. Agents make it sharper, because an agent starts every session with only what it’s handed and doesn’t remember yesterday. It has whatever you hand it, and if you hand it the repository and a ticket, it has to rediscover everything else.
Two researchers, Dipesh KC and Anjila Budathoki, tested this in a paper published this summer called Handoff Debt . They stopped coding agents partway through a standard set of software tasks and had a fresh agent finish the work. When the fresh agent got a note describing what had been done so far, it needed a median of 20 to 59% fewer steps and 42 to 63% fewer prompt tokens than one that only had the code to go on. That’s agents, not whole organizations, so I wouldn’t stretch it too far. Starting from the code alone is measurably expensive, and you pay it every time someone new picks the work up.
The obvious answer is to have someone write the decision down. A person usually won’t. Going back to record it is the step that gets skipped when things are moving fast. An agent will, if you ask it to. Where does it write it? Each agent keeps notes in its own place, on one person’s machine, in one tool’s memory. You can tell it to update the ticket or the PR instead, and that helps, but those end up spread across hundreds of closed items, and nothing pulls the relevant ones into the next session before it starts. The next person on the team, running a different agent, never sees them. A decision only helps the next person if it lands somewhere they and their agent read before they start, and almost no team has that place.
That’s the reason I’m building Scout at Cascade. It’s one shared record that every agent reads when a session starts and writes to as it works, so context moves between developers and agents instead of staying with whoever made the call. We’re building Scout with Scout: the team tracks the work in Linear, and the context (what we decided, what changed, what we learned) goes into Scout, where every session starts.
You don’t need any tool to find out whether you have this problem, though. Take the last branch an agent built on your team and hand it to the person who’s going to pick it up next. Ask them to write down the three most important decisions behind it without asking anyone, then check what they wrote against what actually happened. Whatever they missed is what your team pays to rediscover every time that work changes hands.