Long-Running Agents: What OpenAI's Agents API Update Changes

OpenAI shipped a batch of updates to its Agents API this week, and almost all of them target one problem: keeping long-running agents on track once a task outlasts a single prompt. According to AICoder's write-up, the release adds background compaction, an Auto Review step that checks commands before they run, experimental time awareness and the ability to change an agent's tools mid-session.

None of this is flashy, and that's the point. Agents that run for an hour or a day fail in boring ways: they forget the goal, run something they shouldn't, or burn time on a dead end.

TL;DR#

• OpenAI's Agents API (public beta since September) now supports async context compaction, with Auto Review, time limits and mid-session tool changes reported alongside it.
• These features target the real failure modes of long-running agents: lost context, risky actions and runaway tasks.
• Platform features help, but your own harness (progress files, checkpoints, approval gates) still decides whether an agent is safe to run on business data.

What OpenAI actually shipped#

OpenAI introduced the Agents API in public beta on September 10, 2026, describing it as the same harness and infrastructure that powers Codex, offered through an API. There's no extra fee: you pay for the tokens and tools your agents use. Sessions already compacted older context automatically as they neared the limit.

This week's additions, as reported by AICoder from a post shared by OpenAI's developer account:

One caveat: AICoder notes the official changelog hadn't listed these items yet, and OpenAI hasn't shared latency or cost numbers. Treat the details as early.

Why long-running agents break#

A long-running agent has to carry a goal across dozens or hundreds of steps, often across several context windows. Anthropic's engineering team put the core problem well in its post on effective harnesses for long-running agents: each new session "begins with no memory of what came before."

Context compaction helps, but it's lossy#

Context compaction is the standard fix. When the window fills up, the agent summarises what happened so far and keeps going. The catch is that summaries drift. Anthropic found that "compaction isn't sufficient" on its own, because it "doesn't always pass perfectly clear instructions to the next agent." Addy Osmani describes the same decay: the original goal gets summarised, then re-summarised, and loses fidelity.

Agents declare victory too early#

The second failure is overconfidence. Anthropic saw agents try to one-shot an entire app, and later agents "see that progress had been made, and declare the job done." Osmani is blunter: "Models reliably skew positive when they grade their own work."

Actions compound#

A wrong answer in a chat costs you a re-prompt. A wrong command in step 40 of a reconciliation job can write bad data into your ERP, and step 41 builds on it. Pre-execution review exists because the cost of a bad action grows with how long the agent has been running unsupervised.

The technical trade-offs of OpenAI's approach#

Async vs blocking compaction. Background compaction keeps the agent moving, which matters for latency-sensitive work. The trade-off is that the agent may act on a context that's mid-summary. For anything touching money or customer records, blocking compaction is the calmer default. The SDK change lets you pick either mode.

Auto Review vs your own approval gates. A model reviewing another model's commands is a useful filter, not a guarantee. It catches the obviously destructive stuff. It doesn't know that refunds over $500 need a manager, or that one supplier's invoices always get a second look. Business rules still belong in your code.

Time awareness vs hard limits. An instruction to "timebox to 10 minutes" relies on the model honouring it. A hard timeout in your orchestration layer doesn't. Use both: the soft limit to change the agent's behaviour, the hard one to protect your bill.

Mid-session tool changes. This is the sleeper feature. It means you can start an agent with read-only tools and only grant write access once it has produced a plan someone approved. That's least-privilege access, applied over time.

A sensible agent harness ends up looking something like this:

trigger -> plan (read-only tools)
        -> human approves plan
        -> grant write tools for this task only
        -> execute step -> checkpoint -> progress file
              ^                             |
              |---- compaction / resume ----|
        -> independent verify -> log -> done

What this means for businesses running agents#

The real question is what work you can now hand to an agent that runs for hours rather than seconds. Good candidates share three traits: the work is multi-step, it touches several systems, and it's currently done by someone copying data between tabs. Think month-end reconciliation across Stripe and your accounting tool, catalogue cleanup across a few thousand Shopify SKUs, or working through a backlog of support tickets that each need a lookup in two systems.

The platform features lower the cost of building these agents. They don't remove the need for an agent harness, the scaffolding around the model that holds state, enforces rules and records what happened. Anthropic's own fix wasn't a smarter model. It was structure: work on "only one feature at a time," commit progress with descriptive messages, and keep a progress file the next session can read. That pattern transfers directly to business processes: one invoice batch, one customer segment, one SKU range at a time.

There's also a vendor question. Building directly on one provider's harness is fast, but your progress files, checkpoints and approval logic are the parts you'll want to keep if you switch models next year. Keep them in your own code.

How to get started: a practical checklist#

1. Write the done-condition first. Osmani's advice is to define it before the agent starts. "Reconcile all October payouts and flag mismatches over $5" beats "clean up payouts."
2. Break work into small, resumable units. Each one should be safe to retry.
3. Keep state outside the model. Use a progress file, database table or ticket comment. As Osmani puts it, "the agent itself is amnesiac, but the filesystem isn't."
4. Start with read-only tools. Grant write access only after a plan is approved, using mid-session tool updates if you're on OpenAI's platform.
5. Put business rules in code, not prompts. Auto Review is a backstop. Thresholds and approval rules belong in your orchestration layer.
6. Set hard time and spend limits. Treat the model's time awareness as a hint, not a control.
7. Verify with something other than the agent. A separate check, a test or a person should confirm the work before it counts as done.
8. Log every action. You'll need it for debugging and audits.

How MagicMakers Lab approaches this#

Most of our agentic development work is less about picking a model and more about building the harness around it: scoped tools, human approval gates and decision logs, so a long job can pause, resume and explain itself. It's the same discipline behind Framico, where 200+ orders a day now ship with zero manual steps. The platform features in this release make that kind of build faster, but the guardrails are still yours to design.

Key takeaways#

• OpenAI's Agents API now targets long-running work directly, with async compaction confirmed and Auto Review, time awareness and mid-session tool changes reported.
• Context compaction keeps agents going but loses detail over time, so durable state has to live outside the model.
• Auto Review and time limits are useful backstops, not replacements for business rules and hard limits in your own code.
• Mid-session tool updates make least-privilege workflows practical: plan read-only, then grant write access after approval.
• The best first agents handle multi-step, cross-system work that people currently do by hand.

FAQ#

What are long-running agents?#

Long-running agents are AI agents that work on one goal across many steps, often for hours or days and across several context windows. Unlike a chatbot that answers once, they plan, call tools, save progress and resume after interruptions. They suit multi-step business work such as reconciliation, data cleanup or ticket triage, as long as state and approvals are handled outside the model.

What is context compaction in AI agents?#

Context compaction is how an agent keeps working when its context window fills up. The system summarises older conversation and tool output into a shorter form and continues with that summary. It keeps sessions alive, but summaries lose detail over time, so important facts like the goal, progress and decisions should also be saved somewhere durable, such as a progress file or database.

What is an agent harness?#

An agent harness is the code and infrastructure around a model that turns it into a working agent. It manages tools, memory, context, permissions, retries, logging and checkpoints. The model decides what to do next, while the harness decides what the agent is allowed to do, records what happened, and lets the work resume safely after a failure or handoff.

Is OpenAI's Agents API ready for production?#

The Agents API is still in public beta, and OpenAI says it will iterate quickly before general availability. Some of this week's features are experimental or not yet in the official changelog. It's reasonable for pilots and internal workflows, but production use on business-critical data should include your own approval gates, hard limits and logging rather than relying on platform defaults alone.

If you've got a multi-step process that eats hours of someone's week and you're wondering whether an agent could run it safely, we're happy to look at it with you and give you an honest answer. Book a free audit.

Sources#

• OpenAI Agents API: Auto Review, Async Compaction, Time Awareness (AICoder)
• Introducing the Agents API (OpenAI)
• feat(api): add agent context compaction settings (openai-java PR #1304)
• Effective harnesses for long-running agents (Anthropic)
• Long-running Agents (Addy Osmani)