OpenAI put the Codex harness behind an API. You still have to design the job.
Maestro Brief · Published by Maestro Mojo
Editorial identity incomplete
2026-09-11
Maestro’s take.
OpenAI has turned the machinery behind Codex into a service developers can call.
That is useful. It means less agent plumbing.
It does not mean your product can now manage itself.
TL;DR
The new Agents API can keep a job alive, manage its context, find tools, run code in a sandbox, and coordinate subagents.
You describe the job. OpenAI runs the agent loop.
The big win is not a smarter model. It is less infrastructure for you to build and babysit.
The catch is simple: OpenAI can host the worker. You still own the job description, permissions, budget, evidence, and human approval points.
What changed?
Until now, most teams had three choices.
Use the Responses API and build the agent loop yourself. Use the Agents SDK and run more of that loop in your own application. Or use a finished product such as Codex.
The Agents API adds a fourth option: use Codex-style orchestration inside your own product.
OpenAI says the public beta uses the same open-source harness and infrastructure behind Codex. A session can run for a long time. It can compact old context automatically. It can search for tools only when needed. It can delegate parts of the job to subagents.
The execution environment can be an OpenAI sandbox, your own infrastructure, or a supported sandbox partner.
In plain English: you can stop rebuilding quite so much of the engine room.
The simple comparison
| Tool | What it gives you | What you still run |
|---|---|---|
| Responses API | Models and tool calls | Most of the agent loop |
| Agents SDK | A toolkit for building agent workflows | Your application and workflow runtime |
| Agents API | A hosted, durable agent coordinator | Your product, policy, and business workflow |
| Codex | A finished coding agent | The work you assign and review |
The lines can overlap. The useful question is not which name sounds most agentic. It is how much machinery your team wants to own.
What can developers stop building?
Potentially, a lot of boring plumbing:
- Saving and restoring long-running agent sessions.
- Compacting context before it becomes unmanageable.
- Loading large tool catalogs efficiently.
- Wiring up subagents with separate contexts.
- Maintaining the basic loop that plans, acts, checks, and continues.
That can be a real advantage. Infrastructure work has a habit of disguising itself as product progress.
But do not delete your orchestration code on launch day. The API is in beta. First prove that it handles your real failures, not just the happy demo.
What does it not solve?
It does not decide which work deserves to run.
It does not know which customer data an agent should see. It does not choose when a person must approve an action. It does not define what counts as proof that a job succeeded.
Those are product and control-plane problems.
A system such as Maestro can sit above several workers—including the Agents API, Codex, Claude, or local agents—and coordinate people, tasks, approvals, evidence, and handoffs. The new API could become one execution engine in that system. It does not replace the system around the engine.
That distinction matters. A reliable agent product is not merely a model plus a loop. It is a controlled workflow with a visible owner.
Is it free?
There is no separate fee for the Agents API during the beta, according to OpenAI.
You still pay for model tokens and paid tools. Your sandbox or infrastructure may add cost too.
So the doorway is free. The hallway is metered.
Measure cost per completed job. Token price alone will not tell you whether the system is economical.
DO this
Pick one bounded workflow with an obvious finish line.
For example: inspect a pull request, run the test suite, identify the likely failure, and return evidence. Start with read-only access. Set a time limit and a spending limit. Compare the result with your current implementation.
Keep it only if the hosted loop reduces code and operational work without lowering the success rate.
DO NOT do this
Do not hand a beta agent broad production credentials and ask it to “take care of things.”
Do not replace reliable deterministic code with an agent merely because the API makes agents easier to launch.
Do not call a task successful because the agent produced a confident paragraph. Require tests, logs, links, diffs, or another piece of evidence a person can inspect.
What Maestro users should watch
Watch whether the Agents API reduces the amount of custom orchestration needed for one real workflow.
If it does, let OpenAI own more of the plumbing.
Keep ownership of the permissions, approval points, evidence, and business rules. That is where your product becomes trustworthy—or expensive chaos with a pleasant API.
Sources considered
Source facts are from OpenAI’s own announcements. The product interpretation and recommendations are Maestro’s analysis.