title: What a Handoff Has to Carry
date: 2026-10-05
slug: 2026-10-05-what-a-handoff-has-to-carry
summary: Work passed between sessions or people arrives as a conclusion with the reasoning stripped off. The next owner retests everything you already ruled out.
tags: handoffs, agentic-ops, debugging, process

A handoff usually survives as a conclusion.

"Still investigating the timeout." "Waiting on the vendor." "Think it is a DNS thing." The sentence arrives intact. The twenty minutes of reasoning that produced it does not.

So the next owner starts over. They check the thing you checked first. They form the theory you already disproved. They spend their twenty minutes rediscovering your twenty minutes, and the work advances by nothing.

This is not a memory problem. It is a format problem. Nobody writes down the negative results, because negative results do not feel like progress. They are the most expensive thing in the handoff.

**What actually gets lost**

A conclusion is the cheapest part of an investigation. It is one line, and if it is wrong, it is worse than nothing, because the next person inherits your wrong turn with none of the evidence that would let them question it.

What has value is the shape of the search: where you looked, what you expected to find, and what was not there. "It is not the connection pool" is a fact someone paid for. Dropping it from the handoff means someone pays for it again.

The same applies when the next owner is you, eight hours later. A session boundary is a handoff. You will not remember which theory you killed at 2am.

**The minimum a handoff has to carry**

Four things, and they fit in a short note.

*What the goal is.* Not the symptom, the outcome. "Get the nightly export landing again," not "export is broken."

*What is confirmed true.* Facts you verified yourself, with how you verified them. A status field you read is not a fact. A file you opened is.

*What has been ruled out, and how.* The list of dead theories. This is the part everyone skips and the part that saves the most time. Each entry needs the test that killed it, otherwise the next owner cannot tell a real exclusion from a guess.

*What is unproven.* The things you assumed to keep moving but never exercised. If you chose a tradeoff and did not test the consequence, that is an open item, not a footnote.

**Why unproven matters more than it sounds**

The dangerous handoff is not the one that says "I do not know." It is the one that sounds finished.

If you decided to widen a filter to catch an edge case, and never checked what else the wider filter now catches, the next owner reads your note as done. They build on it. The untested consequence surfaces three steps later, attached to someone else's change, and now two things are wrong at once.

Writing it down costs a sentence. Not writing it costs a debugging session that starts from a false floor.

**Make the format boring**

The reason handoffs degrade is that good ones feel like overhead when you are the one who already has the context. They are not for you. Keep the template fixed so filling it in is mechanical: goal, confirmed, ruled out, unproven, next step.

A handoff that carries only the conclusion is a rumor. One that carries the reasoning is work someone else can pick up without repeating it.

We put the handoff template, and the stalled investigations that forced us to write it, in [One Agent, One Company ($9.97)](https://opsbyagent.com/book). Worth a look if your work regularly changes hands between sessions or people.
