On 10 September 2026 OpenAI released the Agents API in public beta, offering to take over the machinery every team building agents has been maintaining by hand: session state, context compaction, recovery after failures and subagent coordination. For most Hungarian and Central European engineering teams the right move is a narrow, instrumented comparison pilot, because testing costs only the usage it generates while migrating touches the whole agent architecture. Teams without an agent in production have a different job during the beta.
What OpenAI takes over, and what stays with your team
According to the Agents API announcement, a production agent can be created in a single API call: the developer specifies the task, the model (gpt-6-astra in the sample code), the tools and the execution environment. The developer changelog records the same day and names exactly what moves to the vendor: session orchestration, context compaction and recovery. The API automatically compacts earlier context as a session approaches its context limit, so workflows spanning several context windows no longer need home-grown compaction logic.
Multi-agent support splits a task into independent pieces and delegates them to subagents. Each subagent keeps its own context while the main agent coordinates, and concurrency is configurable; the launch example runs at most three concurrent subagents. OpenAI states that the harness is versioned against model launches, so a model upgrade no longer forces the calling team to rewrite its scaffolding.
What stays with the team is still the harder half: tools, internal knowledge, permissions, exception handling and the eval set. We covered that work in our notes on running multi-agent systems in production, and this release does not change it.
The harness is the lock-in, the sandbox is the data question
A CEE buyer should split this launch into two separate decisions. The harness is the surface your code builds on, so that is where vendor lock-in accumulates. The execution environment is independent: the agent can run in an OpenAI-managed sandbox, on your own infrastructure or at a supported provider. OpenAI names nine partners, including Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel, and calls out deployment inside the customer's own VPC.
That split is the real room for manoeuvre. A team can adopt the managed harness while code, files and intermediate artefacts stay in its own environment, which is a materially different risk profile from switching on the hosted sandbox by default. If a customer contract or a tender condition restricts where code may run and where intermediate files may live, sandbox placement is the first question to settle; we set out the criteria in our piece on on-premise versus cloud AI. Neither the announcement nor the changelog entry says anything about EU data residency, GDPR processing terms or AI Act duties, so that part belongs in your own procurement file.
The harness itself is open source: OpenAI says the Agents API is powered by the public Codex harness and that developers can inspect the logic coordinating model calls, tools and context. That helps auditing and exit planning. Readable code does not make the managed service runnable somewhere else.
What the launch did not price
OpenAI states there are no additional fees for using the Agents API and that customers simply pay for the tokens and tools their agents use. That is not the same as cost neutrality. Automatic compaction, tool search and parallel subagents all consume tokens, and every subagent maintains its own context. A managed harness can therefore cut engineering hours and raise the token bill at the same time, which leaves one honest pilot metric: fully loaded cost per completed case.
Run the arithmetic with your own numbers. Suppose a team spends 24 hours a month maintaining its compaction and retry logic, valued at an internal 60 EUR per hour: that is 1,440 EUR a month. Both the 24 hours and the 60 EUR are assumptions, so replace them from your own timesheets and then set the result against the extra token spend. The launch pages publish no worked cost example, no rate limits and no token overhead estimate for compaction, so only measurement closes that gap.
The announcement carries performance figures in exactly one place, and they come from a named customer: the CTO of Ciridae reports an evaluation score moving from 0.71 to 0.85 (roughly a 20 percent relative gain) and a fourfold latency reduction on subagent flows. With no task set, baseline harness or measurement method disclosed, that is one customer's experience rather than a benchmark, and it cannot replace your own A/B test.
Pricing transparency varies by product. The same day, GPT-Live-1 reached general availability with an explicit rate: 0.05 dollars per voice minute, billed per second, with backend model and tool usage charged separately. The Agents API launch publishes no comparable figure. It was one of four product posts dated 10 September, a day after the work-tuned variant of GPT-6 Astra.
If you want measurements behind the choice between your own orchestration and a managed harness, we take agent design, testing and rollout as a project. AI agent development
Who should do what now
| Situation | What to do now | Why |
|---|---|---|
| Agent in production with custom compaction and retry logic | Parallel pilot on one workflow against the managed harness | Most retirable code sits here, and you have a baseline to measure against |
| Want several coordinated subagents but lack engineering capacity | Test the multi-agent setting with up to three concurrent subagents | You skip writing orchestration, while parallel contexts consume extra tokens |
| Prototype only, nothing in production | Build the workflow, the eval set and exception handling first | A first system built on a public beta gets rewritten twice |
| Fixed data placement, sectoral or contractual restriction | Decide and document sandbox placement before the harness question | Execution can stay in your own infrastructure or at a partner provider |
| Delivery tied to an SLA or a public procurement commitment | Wait for general availability, run a closed internal pilot meanwhile | The release is a public beta with no stated GA date or service level |
Decision situations for the OpenAI Agents API public beta, as of 10 September 2026. Source: OpenAI announcement and developer changelog.
What to measure before you migrate
Testing is cheap and migrating is not, so keep the pilot narrow and instrument it properly.
- Pick one real workflow that already has an eval set and error statistics.
- Measure fully loaded cost per completed case rather than tokens per call, and break out the consumption of compaction, tool search and subagents.
- Measure the share of failed or abandoned cases against your own orchestration on the identical input set.
- Keep an abstraction boundary so sessions can be driven by either harness; that is your exit plan.
- Record sandbox placement as a separate documented decision: which files stay there and who can reach them.
- Assign someone to watch harness version changes and define what happens if behaviour shifts at a model launch.
If two or three weeks of piloting show no difference in cost or failure rate, keeping your own orchestration is the thriftier call, and the beta will still be open later.