Suppose you ask a coding agent to fix the error state on a signup form. It changes the component, starts a test, and the session drops. When you reconnect, the chat offers a confident recap. The repository, meanwhile, has uncommitted changes and no clear answer about which checks finished.
That recap is useful context. It cannot tell you whether the code in front of you is the code that was checked.
We give agents elaborate starts: better prompts, more context, a cleaner plan. I want an equally boring plan for when a run cuts out. Someone has to decide what to do with the code already on disk.
Give the run a boundary before it starts
For the signup form example, I would write down the task in terms a reviewer can check later:
- Starting commit and allowed files.
- Expected behavior: show the server's validation message beside the field; keep the existing success state intact.
- Checks to run, including the relevant form tests and a manual pass through the error state.
- Actions that still need a person, such as approving a wider change or merging the result.
This is a proposed working contract. A practitioner account of AI coding makes a similar case for bounded tasks, phased execution, tests, and reading the diff instead of relying on the agent's summary. The written boundary lets you spot drift after a break.
The starting commit matters here. If the working tree already had unrelated edits, a later diff is harder to interpret. Record that fact at the start, or use a clean branch or worktree for the task.
Reconnect to the work, then inspect it
First establish whether the agent's response is still active, stopped, or complete. Do not infer that from a chat message that may have arrived before the interruption.
Then look at the repository. For a Git project, git status --short, the unstaged diff, and git diff --cached answer more than a prose recap. Which files changed? Is there a half-written test? Did the agent touch a file outside the agreed scope? If a check ran, keep its command, result, and the code state it checked. A passing test from before the last edit is old evidence.
BetterC0de describes a beta workspace that places project files, terminals, browser previews, and Git review surfaces near agent activity. Microsoft's Foundry Toolkit has stop and reconnect controls for active hosted-agent responses. They address different parts of an interrupted run; the sources do not describe an integration between them. You still have to verify the code you are about to keep.
In the signup form scenario, a preview might still show the earlier build while the working tree contains a newer edit. Check the state behind the preview before treating it as evidence. The same applies to a test result: it belongs to the version that actually ran.
Make one of three decisions
Resume when the original task still fits, the agent's state is known, and the changed files and check results line up with the current code. Give the agent the unresolved step and the relevant failure output. Avoid asking it to reconstruct the whole run from memory.
Repair when the scope is intact but a specific check failed or an edit is plainly incomplete. A failing form test with a known error is repairable. Inspect the patch after the fix and rerun the affected checks against that patch.
Restart when you cannot explain the working tree, the task crossed its boundary, or the agent no longer has enough context to continue responsibly. Preserve any useful notes and test output, then begin again from a known base. If you have to guess which edits belong to this run, another agent pass will make the patch harder to review.
These are operator choices, not reliability guarantees. A green unit test covers what that test asserts. Sensitive behavior still needs the review appropriate to the change.
The handoff is part of the task
A run may stop without leaving a clean finish line. Before anyone continues, they should be able to name the task boundary, identify the code under review, and say which checks apply to that code.
If those pieces line up, continue. If one is missing, repair the evidence or restart the work. A plausible chat recap is the start of inspection, not approval to keep going.
Source notes
- AI coding workflow account — practitioner advice on bounded work, phased execution, tests, diff review, and clean resets; not independent performance evidence.
- BetterC0de README — beta workspace description and its files, terminals, preview, and Git review surfaces.
- Microsoft Foundry Toolkit release notes — hosted-agent follow-up, stop, and reconnect controls in the v1.6.14 notes.
Top comments (0)