The coding agent was making progress. Then it hit a usage limit.
You switch to another agent so the task can continue. Sensible enough.
But consider the last operation before the interruption:
Did the file write finish? Was the review still current? Does the next agent have the same authority?
"Continue where it left off" sounds like one instruction. In practice, it can hide several independent decisions.
A plausible failure sequence
Consider a fictional coding task:
- Agent A is assigned a scoped fix.
- Agent A prepares a change and starts a write.
- Its session ends before a reliable success receipt is recorded.
- Agent B starts with a summary: "The change is probably done. Please continue."
- Agent B retries or moves to review.
We now have at least three unknowns: whether the original write persisted, whether Agent B can act within the current scope, and whether the review covers the current subject.
Depending on the tool, blindly retrying an uncertain action can duplicate an effect. Blindly declaring success can leave the work incomplete.
Neither choice deserves to be made from a conversational summary alone.
Five questions at the handoff
I would want the handoff record to answer these:
| Question | Minimum useful record |
|---|---|
| What is the task now? | Current task ID, exact objective, allowed scope, and acceptance criteria |
| Who takes over? | Declared role, plus authenticated runtime identity and effective permissions |
| What was last confirmed? | Exact commit/artifact or observable tool receipt |
| What remains unknown? | A named unresolved item, for example "whether the last write persisted" |
| What is permitted next? | Fresh authority check, current review/approval binding, and retry decision if needed |
That last row is easy to skip. Recording uncertainty and authorizing a retry are different operations.
What a declaration checker can catch
In Agent Role Contracts (ARC), we published a guide to rechecking tasks when agents switch.
It distinguishes five cases with concrete checks:
- Same declared role, new runtime instance: recheck the current task and scope. A change of instance alone does not establish a new declared role.
- Different declared role: check whether the handoff follows the allowed route.
-
Task scope changed: recheck it against the current role authority; an out-of-scope request produces
TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY. -
Task or action changed after review: the old binding can fail with
G1_SUBJECT_MISMATCH. -
Previous outcome uncertain: record a blocked handoff with the unknown explicitly unresolved; claiming completion with unresolved work is rejected as
HANDOFF_COMPLETE_UNRESOLVED.
The guide is backed by fictional fixture tests. Those tests establish declaration behavior under the tested cases. They do not observe a real filesystem write or provider delivery.
For a repository that already has ARC declarations, the sequence looks like this (paths are examples; use your own task files):
# Record and validate the declared handoff.
node bin/agent-role-contracts.mjs handoff \
--bundle .arc/bundle.json --task .arc/task.json \
--handoff .arc/handoff.json --format text
# Recheck the task before another agent works on it.
node bin/agent-role-contracts.mjs explain \
--bundle .arc/bundle.json --task .arc/task.json \
--format text
If the task, policy, or action changed, recompute its subject and bind any required new review and approval. The runtime must separately authenticate Agent B, verify actual permissions, inspect real effects, and decide whether a retry is safe.
The rule I'd like teams to debate
My candidate rule is:
Every interrupted agent task should preserve the last confirmed effect and a list of unknowns. A successor should recheck current authority before any consequential action. Unknown outcomes should remain explicit until evidence resolves them.
This adds some bookkeeping. It may also prevent the much more expensive work of investigating an accidental duplicate or a falsely completed task.
Some runtimes already offer durable, idempotent operations and strong recovery records. For them, this may be unnecessary duplication. That comparison matters.
When a coding agent hits a usage limit or crashes halfway through a task, what do you let the next agent do automatically?
Resume reading? Edit code? Re-run a tool call? Retry an external side effect? Where do you require human review or an external receipt?
I'd like to hear a concrete rule that has survived a real interruption.
Disclosure: I maintain ARC at Netsujo. The handoff cases discussed here are declaration-level test scenarios; actual execution effects and runtime identity require separate verification. Agent-switch guide.
Top comments (12)
The handoff summary saying "probably done" is the dangerous line, because it turns an unknown into a belief that Agent B inherits without checking. The cheapest guard seems to be making B's first step a read of the actual state, the file and its hash, before it decides whether to retry or review. Authority is the harder unknown, since a fresh session can easily carry broader permissions than the scoped one it replaces. Would you have the receipt record the scope as well as the result, so B can show it isn't widening it?
Yes, Gautam. I think the receipt should bind both the observed result and the authorized scope. That's an important addition.
I'd structure the handoff evidence around five elements:
The critical rule would be:
Agent B's effective authority for the resumed operation must remain within the currently approved scope. Any expansion requires fresh authorization.
There's also an important distinction between recording authority and enforcing it. A receipt can preserve what was authorized, but the runtime must independently check B's actual permissions and constrain consequential actions. A declaration alone cannot prove runtime enforcement.
That's precisely the boundary we're exploring with ARC and Agent OS.
I'd like to turn your suggestion into a reproducible handoff test: Agent A starts with a restricted write scope, the session ends, and Agent B resumes with broader credentials. The test should reject any attempt to exercise the additional authority without fresh approval, even if the artifact hash matches.
Thanks for raising this. It sharpens the handoff contract considerably.
Five elements is a clean structure, and binding the authorized scope next to the observed result means a reviewer can check both in one place. The part I'd watch is the policy version, since a handoff read later should be judged against the policy that was live when the action ran. Would the receipt store the policy itself or only a reference to it?
Great question, Gautam. I'd use a hybrid approach: bind the receipt to an immutable policy snapshot, rather than embedding the full policy in every receipt or relying on a mutable reference.
The receipt should include the policy ID, exact revision, canonical content digest, and a content-addressed reference to the archived policy snapshot. The host must preserve the snapshot and the evidence of which policy and approval were actually applied.
I'd also separate two decisions:
A valid historical receipt must not automatically authorize future actions after the policy changes.
If the original policy snapshot cannot be retrieved or its digest doesn't match, historical verification should remain unresolved rather than silently falling back to today's policy.
For ARC, this would make a useful negative test: preserve the artifact hash, change the policy between sessions, and verify that the successor cannot reuse stale approval.
Would you favor a shared immutable policy archive, or self-contained policy snapshots for portability?
The distinction between recording uncertainty and authorizing a retry is the key one. I would add a cheap reconciliation step before any successor acts: inspect the current artifact, compare it with the last confirmed receipt, then decide whether a retry is even meaningful. That turns “continue” from a conversational instruction into an explicit state transition.
Thanks, Alex. I agree that the successor should begin with a read-only reconciliation step: inspect the current target state, compare it with the last confirmed receipt, and explicitly decide whether the outcome is confirmed, still unknown, or eligible for a retry.
An artifact match alone may not establish whether an external side effect occurred, so reconciliation, current authority, and retry authorization should remain separate decisions. I'd make that transition explicit in the handoff record.
Exactly. The reconciliation step needs to preserve the difference between evidence of a side effect and authorization to issue a new one. A handoff record that names the target, last known receipt, authority scope, and explicit retry decision gives the successor a safe stopping point instead of turning uncertainty into an automatic resend.
Agreed, Alex. I think this distinction should become an executable handoff contract.
One particularly important failure case is when the original action succeeded but the receipt was lost. The successor must not interpret missing evidence as permission to repeat the action.
I'd separate three things explicitly:
If the outcome remains UNKNOWN, the successor should preserve that uncertainty and stop before any non-idempotent retry.
This would also make a useful acceptance test for ARC and Agent OS: a handoff is safe only when uncertainty cannot silently become execution authority.
Thanks for sharpening this boundary.
Resume reading, but no edits until someone has run git status and git diff and can account for every change in the tree. One of my reviewer agents had planted a bug in a production file on purpose, to prove a test could fail, and then hit the account's session limit. The bug stayed in the file, and the failure notice said nothing about the tree. Every task on that branch committed by explicit path, so the next agent to touch that file would have committed the bug as its own work. The orchestrator reverted it and confirmed the tree was clean before reading any report.
Thanks for the concrete incident, Jackson. It shows why committing by explicit path is not sufficient to establish a safe handoff: an intentional test mutation can remain in the working tree and be inherited by the next agent.
I'd make
git statusandgit diffagainst the last trusted revision mandatory before resuming writes. Every unexpected change should be accounted for, reverted, or explicitly accepted. Your orchestrator's revert and clean-tree verification are the meaningful recovery evidence. The usage-limit notice alone cannot establish workspace safety.My rule is: the next agent can read, but it cannot edit or re-run anything with a side effect until a human has checked what actually landed. I run git status and git diff first, and I treat anything described as probably done as not done. For the small tools I work on, a duplicated effect — a double write, a repeated action — is usually harder to unwind than just redoing the step cleanly, so I would rather lose a little progress than trust a summary. Resume reading is fine; claiming the last step finished is not.
Steven, that's a sensible safety rule. I especially agree that "probably done" is not evidence of completion.
One distinction I'd add: an uncertain outcome should remain UNKNOWN, rather than automatically being treated as not executed. If a remote write succeeded but its acknowledgement was lost, blindly retrying could produce exactly the duplicate effect you're trying to avoid.
git statusandgit diffare useful first checks, but they cannot establish whether an external API call, payment, or message actually took effect.In our Agent OS work, we're aiming for evidence-based autonomous recovery: the successor checks the current workspace, authority, operation identity, and independently observed destination state before taking consequential action. Unresolved effects remain on hold.
Human review remains essential when authoritative evidence is unavailable or a new approval is required.
I'm curious: would you trust independently verified receiver-side evidence and idempotency guarantees to replace the human check for some low-risk operations? Or would you keep the human gate for every side-effecting handoff?