The coding-agent interface is becoming a control plane

Parallel agents, isolated worktrees and queued review change the developer’s role from typing every change to supervising work in motion. The difficult part is setting boundaries, spotting drift early and keeping enough evidence to understand each result before integration. OpenAI's Codex app announcement on 2 February describes a macOS interface for managing multiple agents, built-in worktree support, background automations and a review queue. Those features put orchestration into the everyday developer interface. The screen is carrying task state, execution state and review state alongside the conversation. Calling that interface a control plane is useful if it makes the operating requirements concrete. A list of busy agents is only the beginning. Parallel execution magnifies vague instructions. One agent interpreting "clean up authentication" may change request handling while another updates account permissions under a separate task. Both changes can be reasonable alone and incompatible together. A work order should state the intended behaviour, permitted scope and observable acceptance checks. Name files or modules when the boundary is known. Identify dependencies and protected areas where the agent must stop and ask. Include the command that tests the result, but do not confuse a passing command with complete acceptance.

The interface should keep that work order visible beside the running session. If the objective changes, record the change rather than silently editing the original request. A reviewer needs to know which instruction produced the diff now waiting in the queue. Some work should remain serial. If one change defines an interface that the next change consumes, running both at once creates guesses on each branch. Parallel work is most useful where tasks can complete against a stable shared base. A Git worktree gives each agent a separate checkout and protects the working directories from overwriting one another. That is a sound execution boundary. It does not stop two agents making incompatible choices about a shared concept. The control plane needs to show each task's base commit, branch or worktree, changed files and relationship to other active tasks. A warning that two live tasks touch the same module is more useful while they are running than after both enter review. Isolation also extends beyond tracked files. Agents may start development servers, create databases, bind ports, write caches or run migrations. Separate worktrees can still point at the same local service. The task configuration should either allocate those resources per run or make shared dependencies read-only.

Before dispatching several agents, check the repository instructions and test setup from a clean checkout. If an agent must rely on untracked configuration or a developer's existing database, the isolated branch may produce evidence that nobody else can reproduce. An agent returning "done" creates a review item, not a finished change. The review queue should carry enough information for a developer to decide where to spend attention. At minimum, keep the objective, base revision, final revision, diff summary, commands run, results, unresolved warnings and any changes outside the expected scope. Link to full logs rather than placing a polished agent summary between the reviewer and the evidence. Queue order matters once several tasks finish together. A small documentation change can wait. A branch that alters a shared interface may invalidate work still in motion and should be reviewed earlier. Tasks with failed checks or unexpected scope should be separated from clean candidates so they do not become ordinary backlog noise. The interface should also support rejection without ceremony. An exploratory branch may answer a design question without being suitable for integration. Keep its useful finding, close the worktree and avoid turning every completed run into a pull request.

Watching every command defeats much of the reason to delegate. Waiting for the final result leaves drift too long to grow. The useful middle ground is a small number of meaningful signals while work is running. A visible plan gives the developer an early chance to correct a mistaken interpretation. Changed-file updates can reveal a scope breach. Test failures, repeated retries and requests for broader permissions are worth surfacing immediately. Ordinary reads and successful local commands can remain in the log. Intervention should preserve the history. When a developer redirects a task, the record should show the previous plan, the instruction that changed it and the work already performed. Otherwise the final explanation tends to make a messy run look linear, which is unhelpful when a later defect needs investigation. Set simple stop conditions before execution. An agent should pause when it needs a production credential, encounters an undocumented migration, would alter a public contract, or cannot run the required verification. The exact list depends on the repository. It belongs in the work order, not in the reviewer's memory. A branch can be correct against its starting commit and wrong against current main. Integration should therefore be treated as another execution stage with its own status and evidence.

Update the branch, resolve conflicts with the original objective in view, then run the relevant checks on the integrated tree. If several agent branches depend on one another, record their order. A green check from an isolated worktree does not cover the combination. The reviewer should be able to trace an integrated change back to its work order and session. That connection matters when several agents produced similar diffs or when a person amended the branch after the agent stopped. A practical starting interface can be modest. Show active tasks, their boundaries, current plans, changed files, significant alerts and review-ready evidence. Add explicit controls to pause, redirect, reject and integrate. Then run two genuinely independent tasks and one deliberately overlapping pair. Check whether the interface makes the overlap obvious before review, whether each result can be reproduced, and whether the integrated tests run against the actual combined state. If a developer still needs several terminals and private notes to work out what each agent is doing, the control plane has not yet captured the work it claims to supervise.