A coding agent can finish its turn while the task is still stranded. It changed files, reported success, and left the next developer to reconstruct what it was asked to do, which checks ran, and what still needs a decision.
The useful unit of agent work is a task someone else can continue or reject. Its handoff needs the acceptance contract, the run boundary, evidence, and a named next action.
The agent's chat is a poor task record
Open SWE describes a loop in which a task can enter through an issue, conversation, or schedule, run in a cloud sandbox, produce a PR, and receive follow-up from review or CI. OpenAI's DevDay recap announces reusable cloud environments with shared settings and permissions, along with hosted tool and computer-use capabilities in its Agents API.
In either workflow, work crosses sessions, tools, and people. A chat transcript may explain a decision. It is a bad place to hide the only copy of the task's current state.
Community discussion raises two reasonable questions: where does the work live, and what can someone see when a run stalls? Comments and user reports can prompt a better handoff design. They do not establish that any particular product failed to recover.
Carry four things to the next person
1. An acceptance contract. Record the request and what would count as a finished result. "Improve the release page" is too loose. "Update the hero layout, check the narrow viewport, and prepare the announcement image" gives the reviewer something to inspect. Keep later scope changes visible rather than silently replacing the original request.
2. The run boundary. Record the repo and branch, the environment, the tools and permissions granted, and anything outside scope. Reusable environments can save setup, but a reviewer still needs to know which configuration this run used. Open SWE explicitly distinguishes its cloud sandbox workflow from a local CLI that runs commands as the user; the label "agent" does not tell you the boundary.
3. Evidence tied to each acceptance item. A diff shows what changed. A passing test will not catch a headline wrapping under a button on a narrow screen. A browser preview will not tell you whether CI passed. Link the artifacts and record failed or skipped checks alongside passing ones.
4. A next owner and action. A run can stop at "PR opened," "CI failed," or "needs design review." Name who handles the next step and what they need to decide. Otherwise the agent's final message sounds conclusive while the work sits idle.
Try it on a release-page task
Imagine a request to update a release-page hero and prepare an Instagram announcement. This is a hypothetical acceptance exercise, not a run reported by either vendor.
The page change needs a reviewable diff, a test or build result, and browser previews at the agreed viewport sizes. The announcement needs its own reviewed image export. For that manual publishing step, a reviewer could use Resize Image for Instagram to fit, preview, and export the image for a post or Story. The exported file does not prove the page looks right, and the page preview does not prove the image is ready to publish.
A handoff record for that task could be this small:
Request: Update release-page hero; prepare Instagram announcement image.
Boundary: <repo/branch, environment, allowed tools and permissions>
Outputs: <PR or diff, browser previews, exported image>
Checks: <command or manual check, result, artifact link for each>
Open issue: <failed/skipped check or decision still needed>
Next action: <owner and the specific review or fix>
Fill it with actual links and results as the work happens. If the mobile preview was never opened, write "not checked." If CI failed after the PR, record the failing job and whether the agent is still working on it. A clean record makes uncertainty visible before someone mistakes a confident summary for approval.
A PR is a checkpoint, not a verdict
Open SWE's described PR and review loop gives the next person a concrete place to act, but its repository also says the project is under active development. OpenAI's announcement describes cloud capabilities; it does not establish that every long-running task will resume cleanly or that a PR and CI loop is built into every integration. Neither description is a reliability benchmark.
After the agent stops, another developer should be able to tell what was requested, where the work ran, what was verified, and what to do next without replaying the chat. Code without that record leaves the team to reconstruct the job.
Source notes
- Open SWE README — project workflow, cloud sandbox and local CLI boundary, and active-development caveat.
- OpenAI DevDay 2026 recap — announcement of reusable Codex cloud environments and Agents API capabilities.
- Hacker News DevDay discussion — discussion context about cloud-agent usefulness and product clarity; not product evidence.
- Reddit developer discussion — anecdotal recovery and visibility concerns; specific failure reports are unverified.
Top comments (1)
"The useful unit of agent work is a task someone else can continue or reject" is a good definition. A PR without the acceptance contract forces the reviewer to reverse-engineer what "done" meant.
The evidence part is where I see handoffs fail most: the agent says "tests pass" but not which tests, on which commit, with what output. A cheap rule that fixes most of it is that a claim in the handoff only counts if it links to the artifact: the CI run URL, the command and its exit code, the screenshot of the narrow viewport. Anything without a link reads as "not verified" by default.
How do you handle scope changes mid-run? If the reviewer redirects the task halfway, does the original contract stay visible next to the new one, so the next person can see why the result doesn't match the first request?