A useful agent demo does not answer the control-plane question
The common story is that once an agent can use tools, browse a UI, or work inside a sandbox, broader autonomy is mostly a prompt and model choice away. The operational reality is harder. OpenAI’s current Agents SDK guidance says the SDK track is the fit when your server owns orchestration, tool execution, state, and approvals. That is not a minor implementation detail. It means the first architecture decision is not the agent persona. It is which runtime owns the workflow once the system can affect production work.
Trusted runtime is where orchestration, approvals, and recovery belong
OpenAI’s sandbox guidance makes the split explicit: the harness is the control plane around the model, while compute is the execution plane where files, commands, mounted data, ports, and snapshots live. The same guidance says keeping those boundaries separate lets applications keep auth, billing, audit logs, human review, recovery state, and other sensitive control-plane work in trusted infrastructure. That is the production pattern serious teams need. If orchestration and model-directed execution collapse into the same boundary, convenience goes up for a prototype and governance gets weaker for a real system.
Sandboxes and computer-use harnesses still matter, but as execution surfaces
None of this argues against sandboxed execution or browser automation. It argues against letting them become the implicit control plane. OpenAI’s tools guidance says shell, apply-patch, and computer-use harnesses should stay in your runtime even when the SDK models the tool decision. Its computer-use guide goes further: if a team already has Playwright, Selenium, VNC, or MCP-based automation with action execution, observability, retries, and domain guardrails, that harness can stay in place as a normal tool interface. In practice, the sandbox or UI harness should do the work, while the trusted runtime decides when work is allowed, what it can touch, and how the run is traced.
Validation has to sit next to the side effect
OpenAI’s guardrails guidance is equally direct: approvals are the human-in-the-loop path for tool calls, and workflow boundaries matter because agent-level guardrails do not run everywhere. Tool guardrails only run on the tools they are attached to, which means validation has to sit next to the tool that creates the side effect rather than living only in a high-level system prompt. NIST’s AI RMF reinforces the operating-model side of the same point by calling for documented roles, executive responsibility for deployment risk, ongoing monitoring, change management, and explicit human-AI oversight responsibilities. A trusted runtime is where those responsibilities become enforceable instead of aspirational.
The executive move is a two-plane runtime diagram, not another agent bake-off
The practical next step is simple enough to fit in one review meeting. Draw two boxes for one real workflow: trusted runtime and isolated compute. Then label where orchestration, approvals, secrets, trace storage, recovery state, tool validation, and post-deployment monitoring live. If the team cannot do that cleanly, it is not ready for more agents, more browser automation, or a bigger workflow surface. It is still missing the control boundary that makes those capabilities governable when the model is wrong, the UI changes, or a production action needs to be reconstructed after the fact.
Key takeaways
- Keep orchestration, approvals, secrets, tracing, and recovery in a trusted runtime you control.
- Use sandboxes and UI harnesses as execution planes with narrow credentials, not as the hidden control plane.
- Require one two-plane boundary diagram per production workflow before expanding agent autonomy.