Imagine a document-processing agent that has updated a test record, written half a report, and then lost its execution environment. You know where its code was running. Do you know which state to resume from—or whether resuming will update the record twice?
That is a hypothetical acceptance test, not a report of a vendor failure. It exposes a question worth answering before a long-running workflow becomes consequential.
Before adopting a managed agent API, map who retains the run’s state, who records its external effects, and who can restore or export its work. Compute placement alone does not answer those questions.
I call this a run-custody map: an operator’s record of responsibility, retained evidence, and recovery paths across a workflow. It is not a product feature or a claim that a particular service lacks controls.
Your sandbox is not the whole run
A sandbox answers where code executes. A useful recovery procedure must also account for what the agent was trying to do, which constraints still apply, which tools already acted, and where its files went.
Consider that interrupted document workflow. The report file might survive while the session’s next-step state does not. Or the session might resume correctly while a tool’s completed write is missing from the latest checkpoint. These are possibilities to test, not assumptions about a managed service.
The distinction matters even when you own the compute. An execution environment under your control does not, by itself, tell you who stores the conversation, controls compaction, or interprets a retry. Conversely, a provider-managed environment can be appropriate when its documented boundaries and observed recovery behavior meet your needs.
The question is not “Do we host it?” It is “Can we account for the work when execution stops?”
Separate the harness from the compute
In its Agents API announcement, OpenAI says it hosts and maintains the agent harness while developers choose the compute environment: an OpenAI-managed sandbox, their own infrastructure, or a sandbox partner. OpenAI’s Agents API overview says the service manages sessions, orchestration, context compaction, and recovery while the application provides tools and chooses its execution environment. Its sandbox guide separately defines the harness as the control plane and the sandbox as the execution plane. The announcement also describes tools and parallel subagents.
Those are attributed product statements, not independent production validation. The useful architectural distinction is that harness operation and compute placement are separate decisions.
There is a good reason to buy a managed harness. Maintaining context management and orchestration yourself is work you may prefer to delegate. A team should not have to own every component merely to understand what happens at its boundaries.
But delegation needs an explicit handoff. If a provider manages compaction, ask how you can check that essential constraints survive. If your team runs the sandbox, ask which files and execution state survive its replacement. If a third party operates a tool, identify who can prove that its write completed.
Our discussion of agent handoffs addresses a related concern: passing work between components needs a check at the boundary. Here, the boundary is between the services responsible for one run.
Build the run-custody map
For each layer, name the accountable party, the evidence retained, and the documented path for recovery or export. Then write an acceptance question you can actually test.
The table below is a worksheet, not a description of OpenAI’s implementation. Fill the owner column with the real team or service in your deployment. Until verified, ownership and behavior remain unknown. Where responsibility crosses organizations, name both sides and the handoff instead of writing “shared.”
| Layer | Custodian to identify | Evidence to retain | Recovery or export path to establish | Acceptance question |
|---|---|---|---|---|
| Session state | Service retaining durable session state; team authorized to retrieve it | Checkpoint reference, task instructions, continuation position | Documented checkpoint retrieval and supported continuation | Can we retrieve the state needed to continue an interrupted test run? |
| Compaction | Harness operator; application owner defining essential constraints | Original constraints and permitted evidence of post-compaction context | Retain authoritative instructions outside a summary; establish a supported way to reapply them | Can we show that required constraints remain effective after compaction, and record what we cannot inspect? |
| Tools | Tool owner; team authorizing calls | Call receipt, operation identifier, external result | Reconcile external state before retry; use documented duplicate protection where available | Can we distinguish an unattempted action from a completed action whose response was lost? |
| Compute | Sandbox operator; team responsible for its lifecycle | Environment configuration and persistence boundaries | Supported replacement procedure and restoration of required dependencies | What remains after disposable compute is replaced? |
| Credentials | Credential issuer; team setting scope and revocation | Scope, expiry, and revocation evidence—not secret values | Revoke test access and issue replacement access through approved custody | Does revocation prevent subsequent protected actions? |
| Artifacts | Storage operator; team responsible for retention | File manifest, versions or checksums, retention policy | Retrieve intermediate and final artifacts independently of a running sandbox | Can we recover the expected files after interruption and verify their contents? |
| Recovery | Workflow owner; service providing continuation | Checkpoint, tool receipts, recovery decision and resulting output | Resume through the documented mechanism, reconciling effects before new writes | Can we continue without silently repeating a completed effect? |
| Export | Service exposing export; receiving team interpreting it | Export inventory, file formats, documented limitations | Retrieve the available state and artifacts; assess what another system can use | What can we take with us, and which execution semantics remain service-specific? |
Two distinctions keep the worksheet honest.
First, observability is not the same as recoverability. A transcript can help explain an action without being sufficient to resume the workflow. Ask for the supported continuation mechanism, not just a readable history.
Second, export is not automatically portable execution. Downloaded messages and files may be useful even when another harness cannot reproduce the original behavior. Treat portability as a separate acceptance test rather than a property implied by an export button.
Compaction deserves the same care. Keeping a summary is not the same acceptance criterion as preserving every constraint relevant to the next action. The related memory-migration discussion is useful when a change in the model also changes how retained information is interpreted.
Interrupt a disposable run before a real one depends on it
Use a workflow you are authorized to test, disposable compute, narrowly scoped test credentials, and reversible or simulated tool effects. Do not discover recovery behavior by interrupting customer work.
For the hypothetical document-processing workflow, the exercise could look like this:
- Define the expected result. Use a small input set and a test destination. Specify the report files, the simulated record update, and a constraint such as “never update a record twice.”
- Establish a checkpoint. Through supported interfaces, record the available session reference, artifact manifest, and tool receipts. Note which information is not exposed rather than inventing a substitute.
- Interrupt execution. Stop or replace the disposable environment using a documented procedure. Record the point of interruption and whether the test tool had already acted.
- Resume and reconcile. Use the supported recovery path. Compare external state with the receipts before permitting a repeated write. Check whether required constraints still govern the continuation.
- Retrieve the result and export. Compare recovered files with the expected manifest. Inspect the available export and identify what is readable, reusable, or dependent on the original service.
- Test revocation separately. Identify the documented revocation window and whether derived tokens need separate revocation. Revoke the scoped test access, then check protected actions through each relevant access path after that window. Confirm denial without exposing credentials in logs or reports.
A successful run through this exercise is evidence about that configuration and interruption point. It is not a general reliability guarantee. Repeat the relevant cases when permissions, tools, persistence settings, or the harness change.
A failure is useful too. If you can retrieve the final report but cannot establish whether an external write completed, you have found a reason to limit write authority until reconciliation is supported. That is a narrower and more actionable conclusion than declaring the whole service unsuitable.
Buy a managed harness, not an unexamined handoff
The goal is to delegate maintenance without guessing where responsibility lands.
For each boundary, make one decision:
- Accept it when documented behavior and observed evidence meet the workflow’s requirements.
- Constrain the workflow when an unresolved boundary is tolerable only with shorter runs, lower permissions, or reversible effects.
- Request missing evidence before putting consequential work behind a recovery assumption you cannot test.
You do not need to self-host everything. You need to know who can recover what—and what your team will do when the answer is incomplete.
Take one candidate workflow, fill in the eight rows, and run the interruption exercise before expanding its permissions or duration. Bring the completed map and test results to the adoption decision.