The Missing Check in Agent Handoffs

A coding agent finishes its assignment. The tests pass. The completion message is clean. The orchestrator immediately starts the next agent.

Then the workflow stops.

The second agent expected a patch on the correct branch, a decision record for one unresolved tradeoff, and a reproducible test command. It inherited a green status instead. The first agent may have completed its task correctly, but the handoff still failed.

That distinction matters as agent workflows become longer and more autonomous:

Completion belongs to the worker. Compatibility belongs to the boundary.

Most orchestration systems are much better at recording the first than proving the second. They know a worker returned success. They do not necessarily know whether the state it left behind is valid, sufficient, and safe for the next worker to use.

A handoff therefore needs two checks: evidence that the predecessor finished, and evidence that the successor can begin.

The operating read

• Worker completion proves only the exit side of a handoff.
• Successor entry conditions must be declared before the transition is evaluated.
• Inherited state should be checked before the successor spends tokens, time, or side effects.
• Repair is a bounded, authorized stage with its own receipt and mandatory revalidation.
• Worker, handoff, and repair outcomes should be measured separately.

The false finish line

A worker-level success signal answers a narrow question: did this worker satisfy its assigned task contract?

It does not answer several boundary questions:

• Is the expected artifact present?
• Is it the right version and format?
• Does it include the context the successor requires?
• Did the predecessor leave residue that conflicts with the next operation?
• Can the successor act without guessing, repeating work, or causing an unsafe side effect?

Those are not cosmetic details in a handoff packet. They determine whether the next stage is admissible at all.

The common mistake is to let worker_success = true directly trigger the successor. That collapses two different properties into one status. A better system treats predecessor exit and successor entry as separate sides of the same boundary.

A transition problem from robotics

A useful version of this problem appears in robotics research, where state compatibility is physical and difficult to ignore.

In the August 17, 2026 arXiv v1 preprint Don't Drop the BATON: Long-Horizon Robot Manipulation via Agentic Subtask Exploration and Transition-aware Memory, Bingxin Xu, Yuzhang Shang, and Emilio Ferrara study long-horizon robot manipulation. Their BATON system uses an LLM agent to orchestrate frozen vision-language-action primitives and related mechanisms.

The paper identifies a transition failure that should sound familiar to workflow operators: one subtask can succeed yet leave the scene in a state the following subtask cannot use. The predecessor has an exit, but that exit does not automatically satisfy the successor's entry condition.

The authors introduce three transition mechanisms inside BATON's robotics architecture:

• Invocation transitions check scene readiness before a contact-rich primitive is invoked.
• Handoff transitions record a successor entry condition and restore the scene when predecessor residue has disturbed it.
• Lookahead transitions let a following subtask's requirements influence how the current subtask is performed, favoring an outcome the successor can inherit.

On RoboMemArena, the authors report a 57.7% task success rate and a 78.8% cumulative success rate. Those results are 11.6 and 14.9 percentage points above their strongest reported comparison system, respectively.

Those are the authors' results within their robot-manipulation evaluation. The paper is an arXiv v1 preprint, not evidence that the same gains transfer to software-agent workflows. It does not independently validate the contract I propose below.

The software analogy has a boundary

The useful analogy is narrower than “robotics solved agent handoffs.” It did not.

The transferable question is this:

What if transition success is a property of the boundary, not a side effect of predecessor completion?

In software work, the inherited state may be a branch, schema, browser session, deployment artifact, research packet, approval record, or combination of several things. None of those need to be physically misplaced to become unusable. A version mismatch, missing provenance record, unresolved decision, stale environment, or incorrectly shaped artifact can be enough.

The operating lesson I would test is to define the successor's entry conditions before execution, validate actual inherited state against them, and refuse to start the successor merely because the preceding worker returned success.

That leads to a two-sided handoff contract.

The Two-Sided Handoff Contract

For software-agent workflows, my proposed contract has five fields. This is an operator synthesis, not a framework proposed or validated by the BATON authors.

1. exit_evidence

What proves the predecessor completed its assigned work, and what exact state did it produce?

A status label is weak evidence. Prefer references to inspectable results: an artifact identity, commit, test result, API response, decision record, or other output appropriate to the task.

2. successor_entry_conditions

What must be true before the next worker can begin safely and usefully?

Declare these conditions before evaluating the transition. Give the contract a stable version or equivalent reference. If the rules can be silently weakened after seeing the output, the gate is theater.

3. inherited_state_check

Does the actual inherited state satisfy every required entry condition?

This is the missing check. It compares evidence from the predecessor's real output with the successor's declared requirements. Its outcome should be explicit: compatible, repairable under existing policy, or rejected.

4. repair_receipt

If inherited state was incompatible, what changed, why was that change allowed, and what evidence shows the corrected state now passes?

A repair receipt does not grant repair authority. It records a bounded normalization already permitted by a predeclared policy. A boundary might be allowed to regenerate an index, normalize a known schema field, or restore a documented workspace state. It should not make an unapproved product decision, rewrite source material, or broaden its own permissions just to turn the check green.

After any repair, run the inherited-state check again. If the needed mutation falls outside the declared repair policy, reject or escalate the transition.

5. successor_admission

What evidence allowed the successor to proceed?

Admission should reference the passing compatibility check and, when applicable, the repair receipt. A queued, assigned, or attempted successor is not an admitted successor. Admission happens only after the boundary passes.

A compact representation looks like this:

Contract field	Example evidence
exit_evidence	Patch identity and passing test result
successor_entry_conditions	Expected base, decision record, reproducible checks
inherited_state_check	A passing boundary-check record
repair_receipt	applied: false, or an authorized change plus revalidation evidence
successor_admission	Admission linked to the passing boundary check

The identifiers and evidence shapes will vary by system. The important design choice is that completion evidence and admission evidence are not the same field.

A concrete software-agent handoff

Consider a hypothetical coding workflow with a builder followed by a reviewer.

The builder's task contract says: implement a change and make the relevant tests pass. It does both. Worker success is true.

The reviewer, however, has declared three entry conditions:

1. The patch must apply to the expected base revision.
2. The builder must record the reasoning behind any changed public behavior.
3. The test command must be reproducible in the review environment.

The inherited-state check finds that the patch and tests are valid, but the decision record is absent. The boundary has no authority to invent that reasoning. This is not a repairable formatting defect. It rejects the transition and asks the builder for the missing artifact.

That outcome is more accurate than either alternative. Starting the reviewer would force it to guess. Marking the builder's entire implementation as failed would erase the fact that its code and tests were correct.

The worker succeeded. The handoff did not. The receipt tells the operator exactly where to intervene.

Now change the defect: the decision record exists, but its filename uses an older allowed convention. If a predeclared policy permits that normalization, the boundary can rename or index it, issue a repair receipt, revalidate the entry conditions, and then admit the reviewer.

That is repair success. It is not retroactive proof that the original handoff was compatible.

Measure the boundary separately

Once the contract is explicit, the metrics become clearer. Track at least three outcomes:

• Worker success: Did the predecessor satisfy its own task contract?
• Handoff success: Did inherited state satisfy the successor's declared entry conditions on first evaluation?
• Repair success: When an authorized repair was attempted, did the corrected state pass revalidation?

I would also keep four distinct receipts:

Receipt	What it establishes
Completion	The predecessor finished and produced specific state
Compatibility	That state passed explicit successor entry conditions
Repair	An authorized correction occurred and passed revalidation
Admission	The successor was allowed to begin after the gate passed

This separation prevents a deceptive aggregate. High worker success does not rule out repeatedly unusable transitions. Frequent successful repairs look healthy until the repair rate exposes a brittle upstream contract.

The point is not to maximize the number of receipts. It is to preserve enough evidence to answer the operational question: did the worker fail, did the boundary fail, or did a known repair safely bridge the two?

What to implement next

Pick one agent-to-agent transition in a real workflow. Do not redesign the whole orchestration layer.

1. Write the successor's entry conditions before the predecessor runs.
2. Identify the evidence that proves predecessor completion.
3. Add a boundary check that compares actual inherited state with those entry conditions.
4. Predeclare any narrow repair classes the boundary may perform.
5. Require revalidation and a repair receipt after a mutation.
6. Admit the successor only from a passing compatibility result.
7. Record worker, handoff, and repair outcomes separately.

Then inspect the failures. If worker success stays high while handoff success is low, the problem is not necessarily agent capability. Your workers may be completing valid local tasks inside a system with undefined boundaries.

A predecessor saying “done” is useful. It is not a baton in the successor's hand.