Your Coding Agent Hit Its Usage Limit Mid-Task. Who Owns the Next Move?

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:

1. Agent A is assigned a scoped fix.
2. Agent A prepares a change and starts a write.
3. Its session ends before a reliable success receipt is recorded.
4. Agent B starts with a summary: "The change is probably done. Please continue."
5. 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:

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.