The coding-agent interface is becoming a control plane

OpenAI's Codex app announcement on 2 February describes a macOS interface for managing multiple agents, with built-in worktree support, background automations and a review queue. So the screen you're looking at is now carrying task state, execution state and review state alongside the conversation. I think calling that a control plane is useful, but only if it makes you ask what the interface actually needs to show, because a list of busy agents doesn't tell you much.

Running agents in parallel makes vague instructions worse. Say one agent takes "clean up authentication" and changes request handling, while another, on a separate task, updates account permissions. Each change could be fine by itself and still break when they're combined. So I'd give each agent a short work order: the behaviour you want, what it's allowed to touch, the checks that tell you it's done, and the places where it has to stop and ask. If the objective changes halfway, record that change instead of quietly editing the original request, otherwise the reviewer can't tell which instruction produced the diff sitting in the queue.

A Git worktree gives each agent its own checkout, which stops them overwriting each other's files. It doesn't stop two of them making incompatible decisions about the same shared concept, though, and it doesn't cover things like dev servers, local databases, ports or migrations (two worktrees can still point at the same local service). What I'd want from the interface is each task's base commit, branch, changed files and any overlap with other live tasks. A warning that two running tasks are touching the same module is a lot more use while they're running than after both land in review.

When an agent says it's done, that gives you something to review, and the review item needs enough in it to decide where your attention goes: the objective, base and final revision, a diff summary, commands run and their results, warnings, and anything changed outside the expected scope. I'd link to the full logs rather than putting a tidy agent summary between the reviewer and the evidence. Order matters too. A docs tweak can wait, but a branch that changes a shared interface might invalidate work that's still in progress, so it should be looked at earlier. It should also be easy to reject an exploratory branch, keep what it found and close the worktree without turning every run into a pull request.

Integration is its own step as well. A branch can be right against the commit it started from and wrong against current main, and a green check from an isolated worktree doesn't cover the combination. Update the branch, resolve conflicts with the original objective in view, then run the checks on the integrated tree.

Is the coding-agent interface really becoming a control plane? I think the label only earns its place if the screen shows each agent's work order, where its worktree overlaps with other live tasks, the evidence behind each result and a separate check on the integrated tree. I'd test that by running two genuinely independent tasks and one pair that deliberately overlaps, then seeing whether the overlap shows up before review and whether each result can be reproduced from a clean checkout. If I still need several terminals and private notes to work out what each agent is doing, the interface isn't doing that job yet.