OpenAI and Cursor put a coordinator agent over coding subagents on the same day

A single coding agent runs one loop. It reads the repository, picks a next step, calls a tool, checks the result and goes around again ^[13]. Everything it touches lands in one context. A large migration means learning an unfamiliar codebase, tracing dependencies, changing schemas, updating services, rewriting tests and editing deployment config. One agent has to carry what it learned at each stage into the next ^[15].

Compaction is where that loop degrades. Hilliary Lipsig, a senior principal site reliability engineer at Red Hat who leads the Azure Red Hat OpenShift SRE teams ^[8], said a large context "also includes a lot of throwaway information" ^[5]. "Through compaction, that information can inadvertently end up ranked as important and incorrectly influence what your agent does," Lipsig told The New Stack ^[5]. "Either way, after a couple of rounds of compaction, developers are seeing accuracy degrade and are starting to manage context once again manually," Lipsig said ^[5].

The context-rot study The New Stack cites tested models including Claude Opus 4.6, GPT-5.4 and Gemini 3.1 Pro ^[9]. Its range of 2 to 30 times more misses puts a factor of 15 between the low end and the high end ^[10]. For the result to apply to a given team, its sessions have to run toward 800,000 tokens before the risky step, and its risky steps have to look like the ones in the test ^[9].

The coordinator split goes after both limits. Each worker gets a narrow context. Database analysis, documentation and test discovery can run side by side, where a single agent would run them one after another ^[11]. Lipsig said the convergence reflects that "an agent with too much context loses accuracy and reliability, and focused work with clearer contexts allows for faster, more accurate iterations" ^[14].

Lipsig compared the pattern to the orchestration problem that led to Kubernetes. "These multi-agent workflows are the same concept, just in a new part of the technical stack," Lipsig said ^[7]. In that description, "the orchestrator can act as a source of truth," with the orchestrator "ideally enforcing guardrails, recovering from any failure states, and intelligently routing work to the most efficient target agent" ^[6].

The operative word there is "ideally." In this design the guardrails, recovery and routing live in the coordinator, so whoever operates the coordinator operates them. The New Stack's headline says OpenAI and Cursor disagree on exactly that: who runs it ^[12]. The two products sit at different points in the stack ^[3], and OpenAI describes its sessions as managed ^[1]. The coverage does not say where either coordinator keeps its plan and task state, whether that state can be exported, or what either costs.

In my context, a team that already runs its own CI and policy checks, I'd take the coordinator whose state I can read and move, and accept a rougher setup to get it. I'd expect the coordinator to be the hardest piece to replace later, because it holds the plan and the recovery path.