Harness Engineering Isn't Dead — It Just Moved
AI agents are getting easier to build. But the interesting part isn't that the harness disappeared — it's that more of the harness is becoming infrastructure.
For a long time, building an AI agent meant building much more than an LLM call.
You needed:
- Tool calling
- Agent loops
- Retries
- Context management
- File handling
- Code execution
- Sandboxing
- State management
- Observability
- Multi-agent orchestration
- Error recovery
In other words, you needed a harness.
Now, things are changing.
On September 10, 2026, OpenAI introduced the Agents API, a public-beta API that provides a managed Codex harness and infrastructure for running cloud agents. OpenAI says the harness manages things such as orchestration, long-running sessions, context management, and recovery, while developers can focus on their agent's tools, knowledge, and workflows.
So is harness engineering dead?
No.
But something important is happening:
Generic harness infrastructure is becoming a managed platform capability.
And that changes what AI developers should spend their time building.
🧠 The simplest explanation
Imagine an LLM is a very intelligent person.
You give it a task:
"Investigate why our API has a high error rate and create a report."
The model can reason.
But reasoning alone isn't enough.
It needs to:
- Inspect logs
- Search files
- Run commands
- Call APIs
- Save intermediate results
- Retry failed operations
- Maintain context
- Possibly delegate work
- Produce the final report
The model is only one component.
Something has to coordinate all of this.
That surrounding system is what we commonly call an agent harness.
A simplified view:
flowchart TD
U[User] --> A[Agent Application]
A --> H[Agent Harness]
H --> M[LLM]
H --> T[Tools]
H --> S[State & Context]
H --> X[Execution Environment]
H --> O[Observability]The important idea is:
An LLM generates decisions. The harness turns those decisions into a reliable workflow.
1. What Exactly Is an Agent Harness?
The term "harness" isn't a single universally standardized component.
Different platforms may use the term differently.
But conceptually, an agent harness is the system around the model that enables an agent to act repeatedly and reliably.
For example:
Model
↓
"I need to inspect app.py"
↓
Harness
↓
File tool
↓
app.py
↓
Harness
↓
Model
↓
"I found the bug"
↓
Harness
↓
Edit file
↓
Run tests
↓
Model
↓
Final response
Without something coordinating those steps, you're mostly dealing with a model that produces outputs.
With a harness, you're building an agentic system.
2. LLM vs Agent
This distinction is extremely important.
An LLM call
A basic application might look like:
response = model.generate(
"Explain this Python function"
)
The flow is basically:
flowchart LR
A[Application] --> B[LLM]
B --> C[Response]Simple.
But now imagine:
"Fix the bug in this repository."
The agent might need to:
Read repository
↓
Find relevant files
↓
Understand code
↓
Edit code
↓
Run tests
↓
Read failures
↓
Modify code again
↓
Run tests again
↓
Produce result
That's no longer one model call.
It's a loop.
3. The Agent Loop
A simplified agent loop looks like this:
flowchart TD
A[Start Task] --> B[Send Context to Model]
B --> C{Model Decision}
C -->|Final Answer| D[Return Result]
C -->|Tool Call| E[Execute Tool]
E --> F[Return Tool Result]
F --> BThe important part is the loop:
Model
↓
Tool
↓
Result
↓
Model
↓
Tool
↓
Result
↓
Model
This is where a lot of the engineering happens.
You have to decide:
- What tools exist?
- Which tools can the model use?
- What arguments are valid?
- How are failures handled?
- How long can execution continue?
- How is context maintained?
- When should the agent stop?
- When should it retry?
- When should a human approve an action?
That's harness engineering.
4. The Old Way: Build Everything Yourself
Imagine you want to build a coding agent.
A simplified architecture could look like this:
flowchart TD
U[User] --> A[Your Application]
A --> H[Your Agent Harness]
H --> M[LLM]
H --> F[File System]
H --> T[Tools]
H --> C[Code Execution]
H --> DB[Database]
H --> L[Logs]
C --> SB[Sandbox]You own almost everything.
You might have to implement:
Agent loop
Retry logic
Tool execution
Tool permissions
Context handling
State
File management
Code execution
Sandbox
Logging
Tracing
Error recovery
At first, this can feel manageable.
Then your agent becomes more capable.
And suddenly your "small AI project" has turned into an infrastructure project.
5. Why Sandboxing Is Hard
This is one of the most important parts.
Suppose your agent can execute code.
The model generates:
import os
os.system("rm -rf important-data")
You obviously don't want arbitrary model-generated code running directly on your production machine.
So you need an isolated environment.
Something like:
flowchart TD
A[Agent] --> B[Sandbox]
B --> C[Files]
B --> D[Processes]
B --> E[Python]
B --> F[Shell]
B --> G[Packages]
B -. Restricted .-> H[Production Systems]Now you need to think about:
- Filesystem isolation
- Network access
- Secrets
- CPU limits
- Memory limits
- Process isolation
- Timeouts
- Cleanup
- Persistence
- Authentication
- Permissions
This is a serious engineering problem.
OpenAI has explicitly described the need for computer environments where agents can work with files, execute code, and persist intermediate results, and has also discussed the security controls required when agents act autonomously.
6. Then Came Agent SDKs
The next abstraction was the Agent SDK.
Instead of manually implementing every part of the agent loop, an SDK could provide abstractions for things like:
Agents
Tools
Handoffs
Tracing
Approvals
Context
Execution
The architecture becomes:
flowchart TD
U[User] --> A[Your Application]
A --> SDK[Agent SDK]
SDK --> M[Model]
SDK --> T[Tools]
SDK --> O[Observability]
SDK --> W[Workflow]This is much better.
But there is still a distinction between:
Using an SDK
and
Using a fully managed agent runtime.
The SDK can simplify your application code while you may still be responsible for running and operating the environment.
OpenAI's April 2026 update to the Agents SDK explicitly described a more capable harness with tools, approvals, tracing, handoffs, resume bookkeeping, and sandbox environments.
7. The Next Step: Managed Agent Infrastructure
Now we reach the interesting part.
Instead of you operating the entire agent runtime, the platform can provide more of it.
The conceptual shift looks like this:
Before
flowchart TD
A[Your App] --> B[Your Harness]
B --> C[Your Sandbox]
B --> D[Your State]
B --> E[Your Observability]
B --> F[Model Provider]With managed agent infrastructure
flowchart TD
A[Your App] --> B[Managed Agent Platform]
B --> C[Agent Harness]
B --> D[Session Management]
B --> E[Context Management]
B --> F[Tool Orchestration]
B --> G[Observability]
B --> H[Recovery]
B --> I[Sandbox]
B --> J[Model]Now you can send a high-level task to the platform.
The platform handles much more of the execution machinery.
8. OpenAI's Agents API
On September 10, 2026, OpenAI announced the Agents API in public beta.
Its core idea is straightforward:
Build and run cloud agents using a managed Codex harness.
OpenAI says it hosts and maintains the harness while developers choose the agent's compute environment.
Those environments can include:
- OpenAI-hosted sandboxes
- Your own infrastructure
- Supported sandbox providers
The API is designed around long-running agent sessions, tool use, context management, recovery, and multi-agent workflows.
This is a significant architectural shift.
9. What OpenAI Is Actually Managing
It's important not to misunderstand this.
The Agents API doesn't mean:
"OpenAI builds your entire application."
Instead, the platform provides infrastructure around the agent.
According to OpenAI, the managed harness includes capabilities around:
- Context management
- Tool orchestration
- Long-running sessions
- Recovery
- Subagents
- Agent coordination
OpenAI also provides hosted sandbox infrastructure where agents can:
- Run code
- Work with files
- Produce artifacts
- Install packages
- Use configured capabilities
Think of it like this:
flowchart TD
A[Your Product] --> B[Agents API]
B --> C[Managed Harness]
B --> D[Model]
B --> E[Session]
B --> F[Context]
B --> G[Tool Orchestration]
B --> H[Sandbox]
A --> I[Your Business Logic]
A --> J[Your Tools]
A --> K[Your Data]
A --> L[Your UX]The platform handles generic agent infrastructure.
You build the thing that makes your agent useful.
10. So... Is Harness Engineering Dead?
No.
This is the biggest misconception.
A better statement is:
Generic harness infrastructure is becoming commoditized and managed.
The harness hasn't disappeared.
It has moved.
Compare this to databases.
You could run PostgreSQL yourself.
Or you could use a managed database service.
The database didn't disappear.
The operational responsibility moved to another layer.
The same idea applies here.
flowchart LR
A[Build Everything Yourself] --> B[Use SDK]
B --> C[Use Managed Agent Runtime]
A --> D[Maximum Control]
C --> E[Maximum Abstraction]11. The Harness Is Moving Up the Stack
Think about the evolution:
ABSTRACTION
↑
Managed Agent Infrastructure
│
Agent SDKs
│
Raw Model APIs
│
HTTP APIs
↓
MORE WORK
Or:
flowchart BT
A[Raw Model API]
B[Agent SDK]
C[Managed Agent Runtime]
D[Your Application]
A --> B
B --> C
C --> DEvery step upward removes some infrastructure work.
But it also introduces trade-offs.
12. What Developers Still Need to Build
This is where things get interesting.
Imagine you're building an AI customer-support agent.
The platform may provide:
Agent runtime
Tool execution
Context management
Sandbox
Tracing
Sessions
Recovery
But it doesn't automatically know your business rules.
For example:
Should this customer receive a $500 refund?
That's your application.
Or:
Is this agent allowed to access the financial database?
That's your authorization system.
Or:
Should an email require human approval?
That's your workflow.
Or:
What information should the agent never reveal?
That's your policy and security layer.
So the architecture becomes:
flowchart TD
U[User] --> A[Your Application]
A --> BL[Business Logic]
A --> AUTH[Authorization]
A --> POL[Policies]
A --> TOOLS[Your Tools]
A --> AG[Managed Agent Runtime]
AG --> H[Harness]
AG --> S[Sandbox]
AG --> CTX[Context]
AG --> OBS[Observability]
AG --> M[Model]The infrastructure is managed.
The product intelligence is still yours.
13. The 80/20 Shift
A useful way to think about this is:
BEFORE
80% infrastructure
20% application
AFTER
20% infrastructure
80% application
These percentages aren't literal benchmarks.
They're a mental model.
The point is that developers can spend less time rebuilding generic agent infrastructure.
Instead, they can focus on:
- Domain-specific tools
- Business workflows
- Data
- User experience
- Permissions
- Evaluations
- Reliability
- Product design
14. But There Is a Trade-Off
Managed infrastructure sounds perfect.
It isn't.
The more you outsource, the less control you have over certain layers.
For example:
Managed Platform
│
├── Convenience
├── Faster development
├── Less infrastructure
└── Less control
You may have questions around:
- Data residency
- Privacy
- Network access
- Vendor lock-in
- Cost
- Custom runtimes
- Debugging
- Performance
- Compliance
- Security boundaries
This is why the ability to choose your execution environment matters.
OpenAI's Agents API allows developers to choose between OpenAI-hosted sandboxes, their own infrastructure, or supported sandbox providers.
So the future isn't necessarily:
"Everyone runs everything on OpenAI."
It can also be:
"The harness and execution environment become separate layers."
15. Harness vs Sandbox
This distinction is extremely important.
They're not the same thing.
Harness
The harness coordinates the agent.
Model
↓
Tool decision
↓
Tool execution
↓
Result
↓
Model
Sandbox
The sandbox provides an environment where the agent can safely execute things.
Files
Processes
Commands
Packages
Runtime
You can therefore have:
flowchart LR
A[Agent Harness] --> B[Sandbox]
A --> C[Model]
A --> D[Tools]
B --> E[Files]
B --> F[Code]And importantly, they don't have to live on the same machine.
OpenAI's Agents SDK documentation describes this separation as useful for isolation, durability, and security.
16. Why This Matters for Security
An agent that can execute code is fundamentally different from a chatbot.
A chatbot might generate:
"Here is a Python script."
An agent might actually execute:
subprocess.run(...)
That changes the threat model.
Now you need to think about:
Agent
│
▼
Tools
│
▼
Permissions
│
▼
Sandbox
│
▼
External Systems
Every arrow is a potential security boundary.
This is why "just give the agent tools" is not a sufficient production architecture.
OpenAI has described the need for explicit boundaries, approval controls, and telemetry when deploying coding agents into real workflows.
17. What Happens to Agent Engineers?
This is perhaps the most interesting career question.
If platforms handle more of the generic harness, does that mean agent engineers become less important?
I don't think so.
Their responsibilities change.
Instead of spending most of their time implementing:
retry()
tool_loop()
context_manager()
sandbox_manager()
they may spend more time on:
agent architecture
tool design
permissions
evaluation
workflow design
memory
reliability
cost optimization
security
domain logic
The abstraction level rises.
18. The New Agent Engineering Stack
A useful model is:
flowchart BT
A[Foundation Models]
B[Agent Runtime]
C[Tools + Sandbox]
D[Application Logic]
E[Product]
A --> B
B --> C
C --> D
D --> EEach layer solves a different problem.
Layer 1 — Models
Reasoning and generation.
Layer 2 — Agent Runtime
Loops, context, orchestration, sessions, recovery.
Layer 3 — Tools & Execution
Files, code execution, APIs, databases, browsers, etc.
Layer 4 — Application Logic
Your business rules and workflows.
Layer 5 — Product
What users actually experience.
The more infrastructure providers manage, the more developers can concentrate on layers 3–5.
19. What About Custom Harnesses?
They aren't going away.
There will always be situations where you need more control.
For example:
Custom planning
Custom memory
Custom routing
Custom model selection
Custom evaluation
Custom security policies
Custom scheduling
Custom orchestration
A managed platform might give you the generic 80%.
Your custom system may implement the remaining 20%.
And sometimes that 20% is the actual competitive advantage.
20. Generic Harness vs Custom Harness
| Problem | Managed Harness | Custom Harness |
|---|---|---|
| Basic agent loop | ✅ | ✅ |
| Tool orchestration | ✅ | ✅ |
| Context management | ✅ | ✅ |
| Long-running sessions | ✅ | ✅ |
| Sandbox infrastructure | Often | ✅ |
| Custom execution | Limited by platform | ✅ |
| Business logic | You build it | You build it |
| Maximum control | ❌ | ✅ |
| Development speed | ✅ | ❌ |
| Infrastructure burden | Lower | Higher |
| Vendor dependency | Higher | Lower |
There isn't a universally correct choice.
It depends on what you're building.
21. Why Codex Is Important to This Story
The Agents API didn't appear out of nowhere.
OpenAI has been building agent infrastructure through Codex.
OpenAI describes the Codex harness as the system responsible for orchestrating interaction between the user, model, and tools.
OpenAI also published its experience with harness engineering after building a software product where Codex generated the code and the team focused heavily on environments, intent, feedback loops, tests, and agent-friendly infrastructure.
This is important because it demonstrates something:
The harness itself can become an engineering product.
And now OpenAI is exposing more of that infrastructure through an API.
22. Harness Engineering Is Actually Becoming MORE Important
Here's the paradox.
We're saying:
"The harness is becoming managed."
But at the same time:
"The harness is becoming more important."
Both can be true.
Why?
Because as agents become more capable, the difference between:
Model alone
and
Model + system
becomes enormous.
OpenAI's own engineering work describes the harness as a critical layer for making agents dependable in production. Its current Codex agent engineering roles explicitly cover harness behavior, sandboxing, orchestration, evaluation, observability, and reliability.
So the harness isn't becoming irrelevant.
It's becoming infrastructure.
23. The Bigger Pattern in Software
This isn't actually new.
Look at the history of software.
Servers
Physical server
↓
Virtual machines
↓
Cloud
↓
Serverless
Databases
Manage database yourself
↓
Managed database
↓
Serverless database
Infrastructure
Hardware
↓
Cloud infrastructure
↓
Managed services
And now:
AI agents
Raw model
↓
Agent SDK
↓
Managed agent runtime
The pattern is:
Infrastructure becomes abstraction.
24. What Developers Should Learn Now
If you're learning AI engineering today, don't focus only on API syntax.
Learn these concepts:
1. Agent loops
Understand:
Model → Tool → Result → Model
2. Tool design
Learn how to give agents reliable tools.
3. Context management
Understand what information the model receives and when.
4. Sandboxing
Understand how code execution should be isolated.
5. Permissions
Never assume the agent should have unlimited access.
6. Observability
You need to know what your agent actually did.
7. Evaluation
A working demo isn't necessarily a reliable agent.
8. Workflow design
Understand when agents should act autonomously and when humans should approve actions.
9. Cost and latency
More reasoning and more tool calls aren't free.
10. System architecture
Most importantly:
Know which layer should own which responsibility.
25. A Practical Mental Model
Whenever you're building an AI agent, ask these questions:
┌────────────────────────────────────┐
│ What does the model decide? │
├────────────────────────────────────┤
│ What does the harness coordinate? │
├────────────────────────────────────┤
│ What does the sandbox execute? │
├────────────────────────────────────┤
│ What do my tools control? │
├────────────────────────────────────┤
│ What does my application own? │
├────────────────────────────────────┤
│ Where are the security boundaries? │
├────────────────────────────────────┤
│ Where is state stored? │
├────────────────────────────────────┤
│ How do I evaluate the agent? │
└────────────────────────────────────┘
If you can answer all of these, you understand the architecture.
26. The Future
I think we're moving toward a world where you won't start every AI project by asking:
"How do I build an agent loop?"
You'll start with:
"What should this agent accomplish?"
Then you'll choose how much infrastructure you want to own.
Something like:
flowchart TD
A[Problem] --> B{How much control?}
B -->|Fastest| C[Managed Agent Runtime]
B -->|More control| D[Agent SDK]
B -->|Maximum control| E[Custom Harness]
C --> F[Application]
D --> F
E --> FThat's much more interesting than simply saying:
"Harness engineering is dead."
Because it isn't.
27. The Final Takeaway
The biggest change isn't:
"Developers don't need harnesses anymore."
It's:
"Developers don't necessarily need to own the generic harness infrastructure anymore."
That's a huge difference.
The future probably looks like:
YOUR PRODUCT
│
▼
YOUR APPLICATION
│
┌─────────┴─────────┐
│ │
Business Logic Custom Workflows
│ │
└─────────┬─────────┘
│
▼
MANAGED AGENT
RUNTIME
│
┌──────────┼──────────┐
│ │ │
Harness Sandbox Tools
│ │ │
└──────────┼──────────┘
│
▼
MODEL
So...
Harness engineering isn't dead.
It is being pushed down the stack.
The generic parts are becoming platforms.
The custom parts are becoming more valuable.
And the job of the AI engineer is slowly moving from:
"How do I make the agent run?"
to:
"How do I make the agent reliably solve the right problem?"
That is a much more interesting engineering problem.
🚀 If You're Building AI Agents
Don't start by writing a giant agent framework.
Start with three questions:
What should the agent do?
Define the actual job.
What does the agent need access to?
Define tools, data, files, and permissions.
What should I own vs. outsource?
Decide whether you need:
Custom harness
↓
Agent SDK
↓
Managed agent runtime
The best architecture is not necessarily the one with the most code.
It's the one where every layer has a clear responsibility.
📚 Further Reading & Sources
OpenAI — Introducing the Agents API
The primary announcement for the managed Codex harness, cloud agents, hosted sandboxes, long-running sessions, and execution environments.
Read the Agents API announcement
OpenAI — Harness Engineering
A detailed look at how OpenAI approached software development around Codex agents and why agent-friendly environments and feedback loops matter.
OpenAI — Unrolling the Codex Agent Loop
A deeper explanation of the agent loop and the role of the Codex harness.
Read Unrolling the Codex Agent Loop
OpenAI — The Next Evolution of the Agents SDK
Useful background on sandbox environments, tools, approvals, tracing, handoffs, and agent execution.
OpenAI — Running Codex Safely
A useful introduction to the security boundaries, approvals, controls, and telemetry required for autonomous agents.
OpenAI — From Model to Agent
Explains why agents need computer environments, execution, intermediate files, and reliable workflow infrastructure.
💬 What do you think?
Do you think managed agent APIs will make custom harnesses obsolete?
Or will the best AI products still require their own orchestration layer?
I'd love to hear your take in the comments.
Top comments (1)
sketchflow.space/app/workspaces/00...