Coordinator agent pattern: who should run the loop
The coordinator agent pattern split work between a lead agent and workers. When to split, who owns the loop, and what a managed runtime takes.
The coordinator agent pattern splits agent work in two: one agent holds the objective and decides what happens next, while specialised workers execute narrow pieces inside their own context. OpenAI and Cursor both exposed that split on 10 September 2026, and two other runtimes shipped it before them. The harder question is who runs the loop.
That question is an architecture decision, not a procurement one, and it is the one we get asked most often on multi-agent AI engineering work. This post covers when splitting agents earns its cost, what the coordinator is actually responsible for, and what changes when a vendor owns the loop instead of your process.
Four runtimes converged on the same shape
The convergence is the news. The New Stack reported on 25 September 2026 that OpenAI's Agents API and Cursor Projects both launched on 10 September and both split coding work between a coordinator that understands the larger objective and specialised agents that execute individual pieces. Neither invented it. Amazon Bedrock AgentCore reached general availability in October 2025, and Claude Managed Agents entered public beta in April 2026 — the beta header is literally managed-agents-2026-04-01.
The reason given is not elegance. It is accuracy under load.
"An agent with too much context loses accuracy and reliability, and focused work with clearer contexts allows for faster, more accurate iterations," Hilliary Lipsig, a senior principal site reliability engineer at Red Hat, told The New Stack.
Lipsig's point about compaction is the practical version: a large context carries throwaway information alongside the important material, and after a couple of rounds of compaction that throwaway can end up ranked as important, or correct information can be distorted into something incorrect. Teams then go back to managing context by hand. If you have watched an agent confidently contradict a decision it made forty tool calls earlier, that is the mechanism.
The vendors expose it with different vocabulary but the same primitives. OpenAI's Agents API turns it on with a single multi_agent flag and a max_concurrent_subagents limit; the harness supplies the tools to create, message, wait for and interrupt subagents, and you do not declare those tools yourself. AgentCore ships a Harness service described as a managed agent loop invoked with one API call, with each session in an isolated microVM. Anthropic's managed harness handles the loop, tool execution, prompt caching and compaction, and streams results back over server-sent events with history persisted server-side.
When to split agents into subagents, and when to leave them merged
Split when the tasks are genuinely independent and each has a clear question and an expected result. That is not our rule of thumb; it is OpenAI's own guidance, which goes on to say the part most teams skip: keep short tasks and dependent steps in the main agent, and agents that edit the same files must coordinate their changes.
The upside is measurable and so is the bill. Anthropic reported that a Claude Opus 4 lead agent with Claude Sonnet 4 subagents outperformed single-agent Opus 4 by 90.2% on its internal research eval — while noting in the same writeup that multi-agent systems use about 15 times more tokens than a chat interaction, against roughly 4 times for a single agent. That is a deliberate architectural bet, not a free upgrade.
| Work | Split it? | Why |
|---|---|---|
| Review three unrelated documents | Yes | Independent tasks, each with its own question and expected result |
| Investigate several possible causes of one failure | Yes | Parallel investigation; the coordinator judges whether findings are sufficient |
| Three agents editing the same files | No | Concurrent edits produce internally inconsistent work unless they coordinate |
| A short, dependent sequence of steps | No | Keep it in the main agent; the coordination cost buys nothing |
The failure mode when you split badly is specific. The New Stack's example is a migration where one agent changes a database schema while another updates the consuming service against the earlier assumption; the system produces work that is internally inconsistent and passes no single check that would catch it. The International AI Safety Report 2026 is quoted in the same piece warning that interactions between multiple AI agents introduce further risks as errors propagate between systems.
So the honest summary is that splitting work adds token cost, coordination risk and integration risk, and does not by itself guarantee better software. It buys you narrower contexts. Whether that trade is worth it depends on how broad the task actually is — which is why this is an architecture question and not a default.
The coordinator agent pattern is a permissions boundary, not just a scheduler
Once work is divided, the coordinator stops being another coding agent and becomes a control plane. It decides which agent receives which context, which tools, and which authority — and unlike a conventional scheduler it makes probabilistic judgements about whether a worker's result is good enough to proceed on.
The New Stack frames the most important boundary as the distinction between coordination authority and execution authority: a coordinator needs broad visibility to make useful decisions, but broad visibility is not the same as unrestricted control.
"Just like you don't want humans running around with root permissions, you don't want your agents running with them either," Lipsig told The New Stack.
Context routing is where this becomes concrete. Handing every subagent the parent's entire history costs money, adds noise and leaks information that worker had no business seeing. The alternative is an information-flow boundary the coordinator enforces: a database-analysis agent gets schemas and relevant migrations, a security-review agent gets the resulting diff and no deployment credentials. OWASP's Top 10 for Agentic Applications names the failure this prevents — Identity and Privilege Abuse, ASI03.
Two consequences follow for anything you actually operate. First, observability has to be task-level: which agent got the assignment, what context it used, where it ran, and how the coordinator handled failures. Without that provenance you are reconstructing a distributed workflow from fragments, which is the same reason we argue for agent evaluation that will score the trajectory, not the answer. Second, human review belongs around consequential, irreversible transitions — promoting to production, touching sensitive infrastructure — not around every tool call, which destroys the parallelism you paid for.
Who should run the loop: a managed runtime or your own process
All four runtimes give you a coordinator. They differ in where the orchestration boundary sits, and therefore in which infrastructure questions you still have to answer yourself.
| Runtime | What it runs | What stays yours |
|---|---|---|
| OpenAI Agents API | The Codex harness: sessions, orchestration, context compaction, recovery, subagents | Tools, and the execution environment if you set environment.type to self_hosted |
| Claude Managed Agents | The agent loop, tool execution, prompt caching, compaction, SSE streaming, server-side event history | Agent and environment definitions; optionally a self-hosted sandbox for data-residency reasons |
| Bedrock AgentCore | A managed agent loop per session in an isolated microVM, plus Memory, Gateway, Identity, Observability as separate services | Framework and model choice, and which of the modular services you adopt |
OpenAI's split is unusually explicit in the docs: the harness runs the model and tool loop, the environment is where commands run — a remote sandbox, your laptop, a Docker container or a Lambda function — and your application server submits tasks, receives events and handles function tools. Setting environment.type to none is a legitimate configuration for an agent that only calls tools, and it removes the built-in shell and workspace files entirely.
Handing over the loop is not free of operational work, and the durability question is where that shows. Cursor moved its cloud-agent execution loop to Temporal for durable execution and retries, which The New Stack reports now handles 50 million of Cursor's actions a day across 7 million unique workflows and pushed its cloud agents past two nines of reliability. A twenty-minute workflow that modifies a repository is not a disposable computation; if the machine disappears halfway through, restarting from scratch is expensive and potentially unsafe against a changed environment.
That is the real content of "who runs the loop". It is a set of infrastructure decisions — who owns the execution environment, where workflow state persists, how agents are isolated, how credentials are provisioned, what happens when a worker fails, and which actions proceed without human approval. An API leaves more of those to you. An integrated platform answers more of them on your behalf. Neither removes them. We have made the buy the harness or keep yours case separately and will not relitigate it here; the point for architecture is that the coordinator is where every one of those decisions lands.
One constraint worth checking before you commit: The New Stack reports that OpenAI's Agents API currently supports US data residency but not Zero Data Retention, and that choosing a self-hosted sandbox does not make it ZDR-eligible. If your compliance posture requires ZDR, that decides the question for you regardless of architecture.
When a single agent is still the right answer
This is the wrong architecture if your task is narrow. A bug fix in one service, a scoped refactor, a report generated from one data source — none of them benefit from a coordinator, and all of them get slower and dearer with one. Split work inherits every distributed-systems problem you already know: concurrency, shared state, partial failure, ordering. The difference is that the workers are probabilistic.
It is also the wrong architecture if you cannot yet answer what survives a restart. In the systems we build, the durability question tends to surface before the orchestration one, because agents lose more between turns than teams expect — we wrote about what does not carry over between turns for exactly that reason. The same applies to long-running work that has to survive a queue or a scheduler, the shape behind agent orchestration that can simply wait.
The practical next decision, as of September 2026, is narrower than "should we go multi-agent". Take your largest real task, write down which parts are genuinely independent, and count them. If the answer is one, you do not need a coordinator yet. If it is three or more and they touch different files, the split will pay — and then the only remaining question is whether your team already runs durable execution, because if it does not, a managed runtime is answering a problem you would otherwise have to solve first.
Frequently asked questions
A coordinator agent holds the overall objective, breaks it into units of work, assigns each to a specialised worker agent with its own context, and decides whether the returned results are good enough to proceed. It routes context and permissions rather than writing the code itself.
Split agents into subagents when tasks are genuinely independent and each has a clear question and expected result. OpenAI's own guidance is to keep short tasks and dependent steps in the main agent, and to avoid parallel agents editing the same files without coordination.
Sometimes, at a cost. Anthropic reported a Claude Opus 4 lead agent with Sonnet 4 subagents beating single-agent Opus 4 by 90.2% on its internal research eval, while noting multi-agent systems use around 15 times more tokens than a chat interaction.
A managed agent runtime answers durability, isolation, compaction and recovery for you, which matters most if your team does not already run durable execution. Run the loop yourself when you need environment control, specific compliance posture, or inspectable coordinator logic.
A large context carries throwaway information alongside important material. Red Hat's Hilliary Lipsig told The New Stack that compaction can rank that throwaway as important or distort correct information, so accuracy degrades after a few rounds and teams return to managing context by hand.
Worker agents should get the minimum authority their task needs, routed by the coordinator. A database-analysis agent receives schemas and migrations; a security-review agent receives the diff without deployment credentials. OWASP's Top 10 for Agentic Applications names the failure this prevents as Identity and Privilege Abuse, ASI03.
