Agents API Hosts Codex Orchestration for Production Incident Investigations

? charlie-guo presents the Agents API as a division of responsibility for long-running production agents. OpenAI operates the hosted Codex harness—handling orchestration, sessions, and context management—while builders retain control over the agent’s instructions, its tools and data access, and the environment in which it executes.

That distinction addresses the work surrounding a capable model: connecting tools, tracking progress, managing context, and securing and maintaining the infrastructure around the agent. An application sends work to the harness, which manages the agent lifecycle and connects it to a sandbox. The builder can focus on defining what the agent should do and what it is permitted to use rather than building and maintaining that harness.

The workflow is illustrated through a fictional commerce-service incident involving Northstar’s checkout system. An agent is asked to investigate checkout errors following a deployment. Its session is configured with a model, instructions, tools, an execution environment, and multi-agent orchestration enabled for up to two concurrent subagents.

The agent needs observability data, recent code changes, and the team’s outage-handling instructions. Tools are supplied through capability directories: Datadog provides MCP tools, GitHub provides skills and MCP tools, and a skills directory supplies the investigation runbook. The runbook directs the agent to find a likely cause, explain customer impact, and prepare an on-call handoff—but to gather evidence before recommending a change.

Its constraints are as important as its objective. The example instructs the agent to use UTC, keep production and staging evidence separate, verify service names in the data, and treat a deployment near an error spike as a lead rather than proof of causation. Those instructions distinguish a plausible operational explanation from a supported recommendation.

The builder also chooses the execution environment. The API supports an OpenAI-hosted sandbox identified by an environment template, as well as self-hosted configurations using a workspace directory—whether in a third-party sandbox or the builder’s own infrastructure. In each case, the configuration identifies the capability directories available to the agent.

A production investigation may return more logs than can fit in a model’s context window. Programmatic tool calling is intended to let an agent process and filter those results in code before returning the relevant information to the model.

In the example, 5,000 log records include checkout UPSTREAM_TIMEOUT errors. A direct get_logs() call would place 170,126 tool-result tokens into model context. Filtering records in code for checkout entries at error level instead returns a compact result: 5,000 records scanned and 42 matched, at 11 tool-result tokens.

Rather than passing raw operational data through context, the model receives the relevant subset and a summary, leaving more of the context window for the information needed to reason about the problem.

For work that can proceed independently, the lead agent can delegate tasks through multi-agent orchestration. In the demonstration, one subagent reviews recent code changes while another analyzes telemetry. The code review finds that the upstream timeout fell from 2,000 milliseconds to 200 milliseconds. Telemetry finds 42 errors beginning after deployment and an upstream p95 latency of 380 milliseconds. The lead agent combines those findings: the new timeout is below the observed upstream latency.

? charlie-guo identifies compaction as a separate mechanism for sustaining a long-running single-agent session. Instead of retaining all prior work in active context, the model receives a summary of completed work and can continue its investigation from that accumulated state.

? charlie-guo describes the intended output as a shareable report for an on-call team: a likely root cause, supporting evidence, and suggested next steps in one file. In the fictional checkout example, the report assesses the errors as consistent with Deployment 1842 reducing the upstream timeout from 2,000 milliseconds to 200 milliseconds while observed upstream p95 latency was 380 milliseconds. It assigns moderate confidence because the timing and failure mechanism agree, but says a controlled mitigation and recovery check are still needed.

The report preserves the basis and limits of that conclusion. It records a deployment followed by timeout failures, identifies 42 checkout error records among 5,000 scanned logs, and notes that the log export and telemetry snapshot cover different time windows—so the log count is not a true error-rate denominator. It also states that no production change has been executed.

The agent can gather and organize evidence, identify uncertainty, and propose a response, but the on-call engineer retains the mitigation decision. The example recommends first confirming the deployed configuration and any overrides, then approving either restoration of the prior timeout or a rollback of the deployment, with a rollback plan for the chosen action.