Introducing the Coordinator

The models deliver faster than I read. The sheer number of generated files makes it hard to follow every step, and anyone who gives up their own oversight at that point notices nothing at first, because the reports still look good and the tests are still green. So for me everything hangs on the functional evidence at the end.

Functional end-to-end tests use predefined tasks to check whether the finished system does what I expect of it. With that evidence in hand I accept code generation by agents as a black box, as long as the functional result can be checked deterministically. The product-level tests during development have their own job alongside that.

As a step in that direction I have added a coordinator to my development cycle. He helps me decide. Behind this sits a common practice: putting models and agents from different vendors on the subtasks they suit.

Updated September 26, 2026: The development flow preserves useful experimental code, limits total repair effort and bases additional checks on risk. Model assignments and the operating experiences described here date from the original version.

What work I hand to the coordinator

From the limits of human sign-off follows the need to pin down more precisely what I still decide myself. As the principal I set the functional goal and say when I accept a result. The coordinator aligns the running work with that.

We test our agentic CLI functionally end to end with Terminal-Bench 2.0. People curated the tasks, each one brings its own execution environment, a hand-written reference solution, and tests that check the result, as the Terminal-Bench paper describes. From that I derived the north star: a generic agentic CLI that works correctly under real model, tool, and failure conditions and proves its results. That is the hard yardstick.

For each self-contained product assignment I appoint a PO, an agent in the role of product owner. Technically he is an AI agent like any other. The role name says what job he has in the development process and which decisions I delegate to him. He carries the assignment through to an independently reviewed result. Three POs work on their own topics at the same time here, and each one answers for his own result.

Within my mandate the PO picks the approach and cuts the work into tasks. He decides which parts belong together functionally and where rework is needed, and he commissions developers and independent reviewers himself. He commissions the isolated experiment within his mandate. Once the plan has passed independent review, he authorises further implementation without asking me every time. What he decided sits in the ticket with its reasoning. I can change it or revoke the mandate.

The mandate itself lives in the repository. It names the product assignment, the permitted decisions, and the limits, for costs and for actions that reach outside, along with the reviews there is no way around and the cases I decide myself. Two things are closed to the PO: signing off his own work and loosening the acceptance criteria on his own authority. I hand him the day-to-day lead of a product assignment. For the product, I am liable.

If one PO needs a building block from another, the two agree directly on what gets delivered and how it is handed over. The supplier answers for his contribution, the recipient for the integration and for the result of his own assignment. Everything else runs on alongside. No PO outranks another. Each looks after one implementation strand with his developers and reviewers.

What he owes, the responsible PO enters in the existing ticket, together with the contributions he expects from others. The general rule for the role sits once in the working instructions and is only applied in the ticket. Whoever owns a topic keeps it. Passing on a subtask or shrinking an implementation step does not release a PO from a promise he has yet to keep.

The coordinator holds a mandate of his own for the questions between these assignments. He watches that responsibilities are unambiguous and that the agreed independent evidence stands behind every completion report. Where it is missing, he keeps the assignment open and sends the PO back to work.

A coordinator who confirms every handover or repeats every review does the work twice. He steps in when the POs cannot settle a conflict on their own. He also handles shared tool and provider problems and merges reviewed changes.

For an assignment I start with one owner of the implementation and an independent review of the result. I call the acceptance agent the Judge. Where a specific risk warrants it, the Judge also acts as an early adversary, checking which faults the planned tests might miss. These two tasks do not automatically require two agents. The reviewer stays independent of the author and follows the model requirements. Additional participants need a specific technical question.

A request to the coordinator names the responsible PO, the open question, and the commit. The existing review report goes with it. Where needed he reads the underlying files and raw logs. An unchanged status report triggers no fresh full review.

What I have not delegated comes to me. For that I need the affected state of the work and the possible consequences of a change. The coordinator puts his recommendation alongside it and names what is still unresolved, so that I can judge a concrete question without digging the whole affair out of the logs.

This agent errs too. So he does not rewrite a negative review verdict into a positive one. If I accept a known risk, my decision stands next to the original verdict. Access locks and cost limits remain in force. Before a release or a default activation I still require a decision paper, as far as I have kept that authority.

Precedents for these agent roles

Agents in such roles are already being studied. Closest to our setup is Effective Strategies for Asynchronous Software Engineering Agents of 23 March 2026. In the CAID procedure described there, a manager agent breaks the work down and assigns it, the developers sit in separate Git worktrees, and afterwards the manager merges their contributions and adjusts the remaining plan. The authors tested this on Commit0 and PaperBench. That is roughly what PO and coordinator do here. One difference stands out: in the main flow the developers review their own changes first. I staff that position with a separate reviewer.

Three further papers describe the same roles from other directions. Coordination Without Judgment, online since 17 July 2026, has agents appear as product owner, scrum master, and developer across 19 simulated scenarios and produce backlogs and sprint plans, though all I can reach of it is the conference abstract. Toward Agentic Software Project Management of 23 January 2026, accepted for the AGENT workshop at ICSE 2026, sketches a coordinating agent with specialised subagents and four operating modes that govern how independently they may act. Software Engineering in the Agent Era of 4 September 2026 separates delegated execution from the authority to accept a residual risk. None of the three has been tested empirically.

I have adopted that last separation. Every role now states explicitly which decisions I give away and which I keep. Our POs are one concrete shape of these approaches, extended by the release after independent plan review and by a coordinator for the questions between assignments.

How I distribute models across the roles

For the coordinator I will from now on pick the newest top model I can get for the job. The POs get a proven model from the generation before last. Development and review run on fast models that edit code and handle tools across several steps. A model change leaves the authority of a role untouched.

With the coordinator the effort pays off, because the hard cases land on him: spotting that two POs describe the same missing interface differently, or judging which parts of a promised feature are still owed after the assignment was cut down. My Codex registrations have GPT-6 Astra there with the reasoning setting xhigh, which governs how much thinking the model is meant to spend. OpenAI lists GPT-6 Astra as its most capable model for complex tasks. What the choice is worth, I see in the coordinator’s results.

A PO works on the same bounded assignment over a long stretch, and for that I would rather keep a proven model, even when a newer generation has appeared in the meantime and looks better on paper. Among my OpenAI assignments GPT-5.6 Sol sits below GPT-6 Astra, at Anthropic I have staffed POs with Claude Opus. “Generation before last” always means the offering of one single vendor. Version numbers from different vendors yield no common ranking.

For developers and Judges I want short feedback loops, but speed only helps if the model also does the job. The developer changes existing code and corrects it against the tests. With the Judge there is the added point that he repeats the required checks himself, for which he has enough context and access to the tools. Where that fails, I take a different review model for that assignment.

What recent research shows about splitting models

I find evidence for this split in work from the ten months between 13 November 2025 and 13 September 2026. The most vivid is the Sakana Fugu technical report of 19 June 2026. In a documented Terminal-Bench 2.1 run, GPT builds a server, then Claude Opus reviews the implementation and finds a false reachability proof, whereupon GPT corrects the work. In other tasks the models swap roles.

The remaining papers supply the measurements. Learning to Orchestrate Agents in Natural Language with the Conductor, first published on 4 December 2025 and accepted for ICLR 2026, distributes subtasks with a trained coordination model across GPT-5, Claude Sonnet 4, and Gemini 2.5 Pro among others. The authors set this mixed pool against a variant that assigns every subtask to GPT-5, and on BigCodeBench and GPQA Diamond the mixed pool does better. Agent-as-a-Router of 22 June 2026 chooses among eight models and improves that choice through a verifier and a memory of earlier assignments. SWE-Router of 30 June 2026 first lets a cheaper model run a few steps and then decides from that trace whether a stronger one takes over, tested on SWE-Bench and SWE-Smith.

I take the deliberate combination of different models to be well supported. My fixed mapping of generations to coordinator, PO, and development is by contrast only one implementation in my own project. The Conductor, for instance, works with a purpose-trained model of seven billion parameters, while my coordinator additionally takes up conflicts between assignments and prepares decisions for me. For that I pick a current top model.

Models in use and how they are reached

The table shows documented assignments from project runs and registered control threads up to 13 September 2026, earlier variants included. It records what has run so far. The new selection rule did not yet apply to all of these assignments, and the sessions did not all run at the same time either.

Claude Code I use with direct access to Anthropic. In Codex a local provider profile determines which vendor the command line addresses: my OpenAI profile calls the GPT models, another connects Codex to OpenRouter, for instance for the model identifier z-ai/glm-5.2, and OpenRouter brokers access to GLM 5.2 from there. The tool is the same in both cases.

Muse adds a further coding agent. I commissioned one developer run through muse exec --provider meta --model muse-spark-1.3 at a high reasoning setting, the model runs at Meta, which describes it for coding and longer agentic tasks. I have never compared these models under equal conditions. A verdict on which one works faster is not mine to give.

Independent review after a model change

One staffing had Claude as PO and planner, Muse Spark as developer, and GLM as Judge through Codex and OpenRouter. Before a substitution the coordinator checks two things: whether independence holds and whether the run fits the released budget.

Claude Opus appears in the table as developer and as Judge, because it took on different assignments. No agent may sign off its own implementation. For the plan gate I additionally require different model families for planning and review, and another version number of the same family is not enough. DeepSeek V4 Flash was an early adversary in the evidence I drew on and never granted a final acceptance.

The review record states which model was called through which provider at which reasoning setting, along with the reviewed commit and the input. I take the logged call for this. What a model says about its own name does not count. Where an alias points at changing versions, I have to look up for the individual run which one it was.

How POs and the coordinator exchange messages

In my earlier attempt with three Claude sessions I watched Claude agents send each other messages. Claude Code offers ListAgents and SendMessage for this, the sessions find each other through their registration and send text over Unix domain sockets. The receiving session reads a delivered message between two tool calls, and if it happens to be idle, the message starts a new turn. Anthropic calls this cross-session messaging.

For our Codex sessions we tied the messages to the working documents in the repository. A PO writes his handover there and sends the recipient only a pointer to it through the queue. A helper of our own nudges idle sessions as soon as something changes. After an interruption the PO still finds his assignment again even when the earlier exchange has long dropped out of his context.

Codex also offers subagents for delegated subtasks. The PO and coordinator sessions are something else, they run longer and each carries its own assignment. We built the message path for these control threads.

State of the work and recipient have to match

For each PO it is recorded which Codex thread performs his role and in which working directory he operates. He is addressed through the thread’s UUID. After a restart I check this mapping, because old paused sessions can still be lying around under the same role name.

The handover sits in the ticket or in the handoff. It names what is finished, plus commit and branch, the review report, and the work still open. The shared coordination register points at it and carries responsibilities and unresolved questions. When something changes, the agents replace the head of the register, and older entries slide below it or into the archive.

Each of these files answers exactly one question. The order sits in the backlog table. How far the work has come sits in the ticket, the permitted scope in the release, and the independent review passes verdict on one specific commit, whose number is in the report. Whoever receives a completion report reads the linked files in the stated version.

With separate Git worktrees this is necessary, because before integration a new handoff note only exists on the sender’s branch, and a file path without branch and commit will send the recipient to the older version sitting in his own directory.

The queue delivers into the existing thread

For an addressed message we use codex queue. As an address the subcommand takes the UUID of the target thread or its exact session name, and which UUID belongs to which role I read off the process list and the rollout files that this very process has open. The entries in angle brackets are placeholders:

codex queue --thread "<recipient UUID>" \
  --message "PO1 to PO2: handover on branch <branch>, commit <sha>. Read <ticket path#section>. Open question: <question>."

PO1 reaches PO2 this way. With an unresolved conflict he addresses the coordinator instead, who answers in the existing thread of the responsible PO. I copy no text between terminals in the process. The queue takes the message, and the already open terminal interface processes it in the original thread as soon as the running turn ends.

There is no shared Codex daemon in the background for this. Queuing happens exclusively through the CLI, and nobody writes into the local queue database.

Reading it is allowed, though, and that has changed the path. At a safe point in its work an agent looks up for itself what the database holds for its own thread identifier, instead of waiting for someone to wake it. It remembers the identifiers of the entries it has already handled, so that a later delivery of the same message triggers no second assignment.

Such a call changes nothing about the recipient’s model and permissions. He carries on with his context and with the child agents he has already commissioned. A message to a PO does not start a second reviewer while the first is still running.

The queue transports text, nothing else. Linked files the recipient reads himself, in the right version, and he checks the message against his permitted assignment. In the log the queue message shows up as a user message, although no human wrote it. No additional human sign-off arises from that.

What the queue cannot steer

On 19 September I had an independent reviewer look into whether a running Codex interface can also be addressed directly, through the process identifier or through the thread. The answer was no. None of the three running processes offered a socket or pointed at a control socket, and a separately running app server was connected to none of these interfaces.

The obvious commands do not help. codex app-server proxy presupposes a control socket that is already running, codex remote-control start explicitly starts a daemon, and codex debug app-server send-message-v2 knows neither a process nor a thread nor a socket selector. The attempt to write straight to the foreground process’s pseudo terminal ended at the operating system with “Permission denied”. This was checked against Codex CLI 0.155.1.

That leaves codex queue as the only supported route. It queues. There is no switch for interrupting, attaching or waking immediately, and a running turn finishes before the message gets its turn.

A helper wakes idle sessions

A local resume helper watches what changes in the repository. A macOS LaunchAgent calls it every five minutes, as long as the machine is awake and the user is logged in. For every registered control thread, the role, the working directory, and the files to watch are on record. Anything explicitly paused is not woken.

It compares fingerprints of the local branch states and of the watched files, among them the working rules, the coordination register, and the tickets of the assignment. If something has changed, it checks whether the thread is currently idle and whether the matching terminal interface is still open, because only that may write into this thread. Where it is closed or the state unclear, the helper waits. Before delivering it also compares model, permissions, and working directory against the register entry.

The wake-up message itself says only: read the current sources, continue the open assignment. A PO then looks at what is pending, the coordinator at a cross-cutting question or a reviewed candidate for integration. A file change yields no new product assignment. If the session finds nothing permissible, it goes on waiting.

Delivery and completion are checked separately

A successful queue call confirms only one thing: the message is queued. How fast an idle session picks it up afterwards I measured once, on 19 September. The running turn ended at 09:02:34.469 UTC, the automatic follow-up turn began four milliseconds later, and at 09:02:34.488 the queued message stood in the thread as user input. No timer, no second controller, no keystroke from me. Before every automatic delivery the helper therefore drops a unique marker and notes the current position in the run log, so that it can later search there for the marker and the matching turn. Only that turn’s start and completion show that the session processed the wake-up message.

Just any completed turn is not enough. Even after the matching turn the functional success is open, and the results and checks from the ticket are what prove it. An assignment can be processed correctly and still end in a waiting state.

On timeout or unclear delivery the helper first reconciles queue and run log and only then decides about resending. A shared lock and at most one open automatic delivery prevent overlapping wake-ups. For the files themselves this lock does not help: before an agent writes there himself, he still checks whether he is responsible, because the helper reserves nothing against manually started work.

As processed the helper records the file state from before the send. If another handover arrives during the turn, it still sees it on the next pass.

The answer goes to the responsible PO

Suppose PO1 has a building block ready that PO2 uses in his assignment. PO1 files the handover with branch, commit, and review report and points PO2 at it, PO2 reads it and checks whether the block meets his requirement. For the promised delivery PO1 remains liable. PO2 demonstrates that it works in his own assignment. A detail conflict the two settle directly, and PO3 carries on with his assignment alongside.

Where the cut of the work is at stake, they send the question to the coordinator. He reads the evidence and records his decision within his mandate. After integration he reports the shared commit to the POs concerned, PO2 takes over that state and checks what has changed at his interface.

Developers and reviewers belong to the PO who commissioned them. The coordinator turns to that PO and does not start his child agents himself. If a control thread is replaced, the open assignment and the steering of the child agents move with it. The old thread is paused.

Register and delivery checking are tools of our own in this setup, and we have to maintain them. An error in the helper can bring the collaboration to a halt, even when all models are reachable and the product code works.

What I am correcting in my earlier assessment

In my assessment of spec-driven development I described end-to-end tests and independent audits as remedies against drift, against specification and code pulling apart, which nobody notices as long as the tests are green. One sentence in it went too far: an executable test does not drift, because it stays red until the code fits. That is not quite right. A test can carry the same wrong assumption as the code and stay green all the same.

Our own product-level tests demonstrated this to us. They produced the expected results themselves. Nothing came out of the product in the process, and the path from input to output went unchecked. After that correction the checks were still missing for whether two compared runs belonged together at all, which model they belonged to, and with which input they had been started. A formally flawless review report thus supported a statement about the wrong run.

The independent reviews found the errors, but only after several rounds of rework, at the end of which we cut down the scope of the implementation to reach a state that could be accepted at all. Then a model provider went down as well. The quota error that was last on the screen explained only part of the delay, the rest went to the review architecture, which we corrected as well.

An ever longer catalogue of small working instructions does not come out of this. When the same problems recur or an assignment stalls, the PO reviews his approach. The coordinator requires a reasoned decision and tracks whether it is actually carried out. What the PO chose sits with its reasoning in the existing ticket.

The functional review lies with the independent reviewer. He has a yardstick of his own and access to the original outputs. Fresh context alone does not protect him from confirming the same error with the same review logic.

The spike before the plan gate

My earlier flow started with a ticket and a feasibility check, then came ever more detailed plans, and whether their checks work at all often only came out in review. A mutation, a deliberately introduced error, then hit an unused code branch or stopped the compiler outright. About the functional check such a red run said nothing.

Work on a new feature begins with a bounded experiment on its own branch. It executes the smallest promised user effect from input to visible result. I have removed the disposal requirement: after reviewing provenance, the diff and affected risks, useful experimental code may become the implementation candidate without a rewrite. Plan review and the required authorisation still precede further implementation. Independent acceptance precedes merging into the main branch. My report on stagnation despite extensive testing explains why I changed this handover.

The attempt follows the input through to the component that consumes the result. Where a stored run record belongs to it, the product code produces it. The test prepares its inputs and the expected target values, and the observed output comes from the product.

For cases involving critical data, permissions or recovery, the developer runs a correct case and introduces a functional fault that fails at the intended test assertion. A valid counter-case still passes. This shows whether the control distinguishes faults or rejects everything. The possible harm determines the negative check. A text correction needs a source and consistency review, without artificial mutations for every table row.

For such risks, the adversary examines the early run using code and raw evidence. The reviewer searches for incorrect executions that the test would accept. If the same independent reviewer later handles acceptance, they use the saved results and review the affected changes again. The candidate report records which critical checks they reproduced themselves.

Where the reviewed values come from

The plan contains the executed checks with their results, plus the functional intent and the reasoning behind the architecture decisions. For the values the verdict hangs on, a provenance table is added: it points at the approved functional definition, names the writing product component and the recipient, lists the permitted deviations, and requires a check with deliberately wrong data.

When comparing a feature switched on and off, both runs get the same task and the same input, all other settings are equal, and only the switch under examination tells them apart. The evidence belongs to its particular attempt, and which review model passed the verdict is stated as well. Swapped evidence gets caught by the check, even when every single file is valid on its own.

A switch can be read correctly and still have no effect later. The product can discard a model response although the call succeeded. That is why the check reaches to the point where the promised effect arises.

I set functional expectations before the agents judge the result. Approved requirements determine what is expected, while code and runtime document what exists. Some acceptance scenarios are withheld from the developer. The developer writes technical tests, whose adequacy the independent reviewer assesses. Shared code for reading a file format is acceptable. The two sides judge functional validity independently.

When the same class of error appears a second time

Automated checks catch lint errors, missing tests and incorrect file references before model review. Their repairs count against the attempt’s total budget, alongside functional reviews, delta checks, tool and environment work, and failed calls. Separating error classes still helps diagnosis. It exempts no work from the limit. A new ticket does not reset the count.

When the same class of error appears again, the PO changes the approach and records why. Before each further run, the PO names a change or a different hypothesis and the observation needed to assess it. Identical repeats need a question about reproducibility or variation. If no knowledge is added or the budget runs out, the PO saves the last useful state and prepares a different approach or expert help. The product assignment stays open. A smaller delivery scope or partial completion requires my explicit approval.

The reviewer checks the entire submitted scope and bundles the corrections. Closed points he reopens when something relevant changes or new evidence speaks against them. An additional report on unchanged code triggers no full repeat.

Carrying on after a provider outage

If the required review fails because a provider quota is exhausted, its verdict reads “inconclusive”. The evidence is then not enough for a decision. Even in a brief progress report I want to tell this state apart from a failed product check.

Before longer review runs the assignment sets the time and cost budget, plus the number of permitted attempts, the review model, and a permitted substitute. An unplanned change requires a decision of its own, not least because it shifts the independence of the model families.

For the resumption the PO secures the reviewed commit and the raw evidence so far and notes which work is still missing. Before the next attempt the old run has to be finished and the code restored after test mutations. Per working area, still only a single agent writes.

If the original reviewer has finished his measurements and only the verdict is missing, he continues there. A new reviewer makes plain which measurements he takes over and which he repeats himself. A short successful model call says nothing about whether the provider will sustain a longer run.

Shared outages the coordinator handles with the POs concerned, and the resumption of individual assignments the respective PO organises himself. That keeps it clear, even with a substitute, who commissions the developer or the reviewer.

When a feature counts as finished

The progress report states which use case works through the intended product path and which previously accepted capabilities remain usable. An initial reference case demonstrates the approach. Completing the story requires all agreed acceptance criteria and the product’s shared quality requirements. Foundation packages alone do not fulfil that promise.

Each PO owns completion of their assignment. The coordinator merges independently reviewed changes and arranges checks of the affected integration. Existing evidence applies only to its code, configuration and reviewed scope. If interfaces, permissions, transactions or the environment change, the reviewer checks the affected assertions again. A new build receives its own provenance and package records.

If a feature is switched off at first, the activation evidence follows. The responsible PO organises the real on/off comparison with matching run records and the independent verdict on the observed effect. What the mandate says decides whether it then runs by default. A set configuration field is not enough for that.

The documentation normally consists of four parts: ticket or specification, implementation and test note, independent review report, and handoff. They sit as sections in the same file, as long as it is recognisable who wrote what. Raw logs and machine-generated run records lie alongside, and the working instructions point at them.

How I will measure the changes

All of this now sits in the working instructions and in the method template. For the running assignments I am keeping the procedure stable and will look at its effect across several completed user assignments. From the corrections so far follows neither a lower error rate nor a lasting gain in speed.

Further general rules I will only make once a shortcoming of the procedure is documented. If an assignment stalls, the responsible PO first investigates the cause: whether he understood the task correctly, whether his technical solution works, whether the model in use is fit for it, or whether he simply lacks the tool. The coordinator demands this clarification and a reasoned change of approach with it. Errors and security problems we keep fixing as soon as they surface.

I record the time to the first complete product path and to the fully accepted feature. The budget includes all work, including failed repairs, provider waiting time and my own interventions. For a comparison, the previous and revised flows should start from the same code and assignment with the same models, budget and independent acceptance.

Lasting progress also means that a demonstrated feature survives later changes. The acceptance and regression tests already planned are meant to show that. If a promised capability is lost again, that setback belongs in the report. A new role description says nothing in itself about whether the product reaches a capability and keeps it.

With the coordinator I watch which requests pile up at him. If routine questions or finished code are waiting there, something is wrong with his remit or his room to decide. For my own sign-offs I still need access to the original evidence.