OpenAI Open-Sources Codex's Core Agent Harness Framework: Easily Bring Agents into Your Own Business Systems

Why a model alone doesn't make a real agent

A simple model call is easy: ask a question, get an answer. But when the task shifts from "answer" to "accomplish," the gaps become obvious.

The model needs to know which object it's handling, remember what it has already done, read files or logs or business records, call external tools, switch course after failures, and distinguish between actions it can execute automatically and those that require a waiting period for human approval. For tasks that stretch over tens of minutes or multiple sessions, it also has to compress old context without discarding critical early judgments.

Agent Harness is the execution system that tracks progress, orchestrates tools, enforces permissions, and keeps the task moving.

The most direct question about why Harness matters: how much difference does the same model show when run with a different execution setup? OpenAI offered a striking—and easily misused—number.

On the ARC-AGI-3 public benchmark, an agent must observe, experiment, and infer rules in an unfamiliar interactive environment, making it crucial to preserve prior reasoning and action history. With GPT-5.6 Sol using the official general-purpose Harness from ARC-AGI-3, the RHAE (Relative Human Action Efficiency) score was 13.3%. After switching to retaining reasoning state and using compaction—compressing old context into a usable summary rather than simply dropping the oldest entries—the RHAE rose to 38.3%, while output tokens dropped to about one-sixth.

The mechanism is not mysterious. Discarding reasoning is like making the agent re-learn the game with every step; rolling truncation gradually erases earlier observations and actions. Retaining reasoning lets plans carry forward, while context compaction keeps the agent's core knowledge intact over long tasks instead of simply forgetting the oldest information.

But these results are tied to a specific model, a specific public benchmark, and a specific metric. They don't translate into "every agent gets three times better when you plug in Codex." They demonstrate that the architecture around the model also shapes how much of the model's capability actually surfaces.

We have a separate deep dive on the full 13.3%→38.3% experiment:

Related readingTwo API settings, not a new model: OpenAI reports GPT-5.6 Sol jumping from 13.3% to 38.3% on ARC-AGI-3The model stayed the same; the harness did not—retained private reasoning plus compaction instead of deletion cut output tokens per game to about one-sixth.→

What each of the three layers does when you integrate a business system

Once you understand Harness as the operational scaffolding, the practical question becomes: when you integrate Codex into a product, what do the host application, the Codex app-server, and MCP each handle?

The architecture cleanly divides responsibilities into three layers.

Three layers, not a hierarchy — three kinds of ownership

Keep business logic in the app, let Codex run the agent loop, and route trusted reads and writes back through MCP

Host app Owns the business context and final control

Current object · Page state · Business rules · Human approval

↓ Object, context, and constraints ↑ Progress, events, and approval requests

Codex app-server Maintains the agent's runtime lifecycle

Threads and turns · Reasoning loop · Sandbox · Streaming events

↓ Tool calls ↑ Trusted results

App-owned MCP Turns proprietary systems into controllable tools

Trusted data · Query tools · Business actions · Permission boundaries

Execute after approval and write back

Publisher's original architecture diagram

The first layer is the host application—your existing logistics dashboard, ticket system, or tax software. It defines which alert, ticket, or order the user selected, what state the current page shows, what actions the business allows, and which steps require human consent.

The second layer is the Codex app-server. It takes that context, saves the task state, drives the agent's continued tool use, and keeps execution within sandbox and approval rules. The product can also observe the process, interrupt at any time, and respond to approval requests.

The third layer is the application's own MCP service—think of it as a set of business interfaces built specifically for the agent. MCP is not the business database itself; the agent uses it to read authoritative records and to request business actions like rebooking, creating tickets, or updating status. Those actions only take effect when the host application's rules and approval conditions are satisfied.

The results then flow back into the original product interface. The agent's conclusions land in the formal business system, which remains the final record and control center.

This division resolves three things that often blur together in agent products:

• Codex drives the task forward;
• MCP hands Codex trusted data and controlled actions;
• The host application tells both what matters, what's allowed, and where the final result should land.

From one-off tasks to product features: choosing your integration approach

Most tasks don't need the app-server. You can remember the three approaches in one line: use codex exec for scripts or background jobs, the SDK for calls from business code, and the app-server when you're building the agent as a product feature.

codex exec fits well-defined one-off tasks like reviewing code in an automated check, periodically cleaning up records, or batch-processing a set of inputs in the background. It can return either the final text or structured output that a program can continue processing. The lifecycle is simple: start, run, finish.

Codex SDK suits cases where business code launches and manages Codex tasks directly. The application can start new tasks and also resume or recover prior work—without the product team having to deal with app-server's low-level protocols.

Codex app-server is for building the agent directly as a product feature. The application can maintain long-running tasks, watch execution in real time, interrupt at will, provide tools on the fly, and handle approval requests when Codex asks.

Don't think of these as "basic, medium, and premium" tiers. Choose based on three questions: Does the task need ongoing state? Does the product need to observe and intervene during execution? Does the agent need to complete consequential business actions within the user's current interface?

If you're just running a one-time background analysis, jumping straight to the app-server only adds integration cost. Conversely, if the agent will live permanently in an operations dashboard, a single codex exec command can't realistically handle sessions, approvals, and UI synchronization.

Choosing the layer is purely an implementation decision. The bigger product question is: where should these capabilities ultimately appear? The answer isn't necessarily a new chat box.

Embedding an agent doesn't mean adding another chat box

Product teams now face the question: where does the AI live? OpenAI's answer is to put the agent where the work already happens, not to bolt a generic chat box onto every piece of software.

A generic chat window that sits apart from the business system has no access to current context, so it pushes all the work of organizing the situation onto the user: please translate the order you're working on, the page state, the business rules, and your objective into a fresh prompt.

The user has to restate which record they're viewing, copy the dashboard status into the model, and guess whether the model's advice is based on the latest data. After the model responds, the user still has to toggle back to the business system to act. Context, analysis, and action get scattered across two places, and important boundaries can easily get lost in copy-paste.

Side by side, the difference isn't whether the model can answer. It's who assembles the context, where the business boundaries come from, and where the final result lands.

That's why dashboards, ticket pages, tax forms, and security event queues don't lose their value when AI arrives. They already gather the objects, states, evidence, and buttons needed to do the work. The natural place for an agent is inside those interfaces, using the context that already exists—sparing users the job of recreating the scene from a blank input box.

Chat isn't going away. Open-ended exploration, vague questions, and ad hoc analysis still belong in a conversation. What deserves to go is the idea that a generic chat box should be the only form an agent product can take.

Relay demo: how an AI completes a task in a logistics dashboard

Relay runs on synthetic seed data, not a real customer system. It takes the three-layer division of labor and the integration approaches described above and turns them into a complete logistics operation.

Start from a business object, not from a blank input box

Read, judge, request, execute, and write back — all within the original workflow

01Select an exception shipment

The dispatcher picks a real work object first.

→

02Inject page context

Route, promised time, shipment value, and the exception all enter the task.

→

03MCP reads current records

Codex pulls trusted operational state.

→

04Investigate and compare options

Analysis can run automatically.

↘

Human control point05Human approves critical writes

Stop when rebooking, record changes, or fees come up.

→

06Execute approved actions

Only run changes that were explicitly allowed.

→

07Write back and refresh business state

Results re-enter system records and the UI.

Relay official demo UI

The dispatcher doesn't start from a blank prompt like "help me analyze shipping delays." Instead, they select a shipment in the exceptions queue, then click "Investigate Delay" or "Compare Remediation Options." That click alone delivers the business object and user intent; the page continues to offer visible context like route, promised time, shipment value, and the current exception.

Codex then reads current operational records through Relay's MCP tools, determines where the problem is, and compares available options. The analysis runs automatically; but if the next step involves rebooking, changing a business record, or incurring costs, the system pauses and asks the dispatcher to approve. Once approved and executed, the changes re-enter the logistics records and the business view refreshes.

The whole loop compresses into seven steps:

Select object → Inject context → Query authoritative data → Investigate and compare → Human approval → Execute business action → Refresh official records

What this adds beyond "a chat box with a few tools" is precisely the product design: when to deliver context automatically, which tools are available, which actions have consequences, and where a human should take back control of the decision.

The pattern is already spreading across domains. GitHub and JetBrains are putting Codex into existing IDE workflows; Cisco uses the Codex SDK in the App Builder within Cloud Control; Thrive Holdings, Crete, and OpenAI have connected Codex to tax preparation and practitioner feedback loops.

The tax preparation pilot involving Thrive Holdings, Crete, and OpenAI processed 7,000 tax returns, with partners reporting about a one-third reduction in preparation time. That number isn't from an independent third-party evaluation, but it shows a second layer of value from workflow embedding: the agent doesn't just complete a single task. It reads production records, absorbs expert corrections, builds evaluation tasks, and feeds the next round of product improvements.

Setting the record straight: what's open and what isn't

There's one more boundary that's easy to misread: the Harness being embeddable doesn't mean the entire Codex platform is freely self-hostable. The official open-source boundary is narrower than that.

Developers get an agent execution foundation they can inspect, modify, and integrate into their products, plus entry points ranging from one-off tasks to deep product integrations. What they don't get is an open-source implementation of the models or the cloud services.

More importantly, Harness doesn't generate the business domain for product teams. Which records are authoritative, which tools can be called, which actions require approval, and how results are written back into existing systems—all of that still has to be defined by the host application.

In short, OpenAI saves developers a substantial amount of work in building the agent execution foundation, but the business product still needs to be built by the team itself. The real gap comes down to understanding the business, and whether you can wire data, tools, permissions, and human judgment into a reliable workflow that lets AI actually finish the job inside existing systems.

Further reading: Harness engineering's twelve principles of practice.

Related readingTwelve rules of harness engineering from a Google staff engineerA year of practice distilled into a workflow: lock your chosen model and agents in place, change nothing, and adjust only the context and tools around them.→