What stays yours when the agent harness is managed

The Agents API announcement from OpenAI describes a public beta for agents that can keep working across long sessions, run in managed or partner environments, find tools as they need them and hand work to subagents. That's a lot of runtime engineering a team no longer has to build itself. It also makes it worth writing down which parts the platform now owns and which parts are still yours. The first one that stays yours is the job. "Investigate the issue" is fine for someone who already knows the system and the report you expect. An agent needs the target, the time window, the sources it's allowed to use, where the output goes and when to stop, and if it's allowed to change something, the exact boundary of that change and the evidence you want afterwards.

The environment is still your call even when someone else hosts it. You decide which files go into the session, what can leave and what survives the run. A clean sandbox isolates execution, but it won't tell you whether that customer export should have been in there, so the application has to decide before the task starts and keep enough of the input record to explain it later. I'd build tool access per task too, rather than inheriting whatever the developer who wrote the integration had. Web search, repo access and observability queries are three different trust boundaries, and if the work also needs a deployment tool I'd only add it at the stage that's passed review.

OpenAI says the API can compact earlier context as a session nears its limit and load tool definitions on demand. That helps the harness keep going, but you still need durable state for anything that shouldn't depend on a summary: the approved input version, operation identifiers, external results, review status and open questions. Subagents raise the same issue one level down. The main agent needs to know what each one was asked to do, which tools it got and what came back, otherwise a confident combined answer can hide a branch that failed or never finished.

I'd keep the activity record outside the agent's own final response: session and task IDs, model and harness version, tools granted, important external actions, artefacts produced and the checks run before completion. The agent's summary is useful, but the application should collect the facts about what actually happened. Recovery belongs here as well. A session can stop after an external action succeeds and before its result is stored, or a tool can time out after accepting a request, so the workflow needs states for those uncertain outcomes and a way to reconcile them before another run repeats the action. I'd also set a time or spend limit, keep partial artefacts when it's hit and record a stopped task differently from a failed one, or you'll find out about an open-ended job from the bill.

So what stays yours when the harness is managed? OpenAI's Agents API now runs the sessions, environments, context compaction and subagents, but the job definition, the tools and data each task gets, the durable record and the recovery states are still things your application has to define. I'd test that with one workflow whose result a reviewer can check independently: run it through the managed harness and go through the record without leaning on the final answer. If the reviewer can't see what the agent read, which actions reached external systems, what's still unresolved and where to pick up again, I'd fix that before moving more work onto it.