Multi-agent control layers & cockpits

You split a feature across three worktrees. Agent one finishes the upload endpoint, agent two wraps the schema migration, agent three fills in the tests. Every diff is green, every diff is clean, and the integrated branch crashes on a runtime error no single agent ever saw. This is a context collision, and it is the parallel-agent version of a merge conflict — except git never flags it, because no two agents touched the same line.

The canonical case: agent A hardens the auth middleware and renames requireAuth to requireAuthenticatedUser; agent B refactors the user type from { id, email } to { id, identity: { email } }. Both pass their own tests, because each only regenerated the tests inside its scope. Merged, the middleware calls a function that exists but passes a user shape that no longer does, and you get Cannot read properties of undefined (reading 'email'). Neither agent ever ran a build containing both diffs.

Worktrees give isolation, not coordination. The fix is a written context contract handed to every agent, with four load-bearing sections: Scope (the exact files each agent owns; everything else is read-only), Interface boundary (the function signatures, exported types, route paths, and schema shapes that cannot change without a sync step), Shared state (a policy for package.json, tsconfig.json, and the migrations directory — one owner, or no agent edits it), and Merge order (a single line deciding who lands first, chosen by which diffs unblock the others). Then merge as a procedure, not a vibe: review each diff against main, merge in the contracted order, run the full suite after every merge, and reject any diff that crossed its boundary rather than hand-patching it. And skip parallelism below the threshold — work one agent finishes in under two hours, or anything touching build, CI, or deploy, is cheaper done serially.

Running one coding agent is a conversation. Running four is an operations problem. A Claude Code session refactors one repo while a Codex session writes tests in another and two more grind through a migration — and the work stops being about prompts and becomes about coordination: which agent is blocked, which is waiting on you to approve a destructive command, and which quietly went off the rails ten minutes ago.

The failure mode builders describe is the alt-tab tax. Each agent lives in its own terminal, and the terminals do not talk to each other. To answer a basic question — is anything finished, is anything stuck — you cycle through windows, scroll back through output, and try to remember which session was assigned what. A terminal shows you a stream of text, not a status. Four streams give you four times the text and no summary. There is no single place that says: agent A is done, agent B is mid-task, agent C has been waiting eleven minutes for you to approve a file deletion.

Chat is the wrong shape for this. What long-running agent work needs is a status board with plain states — idle, running, blocked, needs review, failed, done — each carrying the project, the agent, the current command, elapsed time, and the next possible action. That turns "babysit the agent or forget it exists" into cheap supervision. The unit of attention is no longer the prompt; it is the fleet. The mature version isn't full autonomy — it's a cockpit where you glance once and see who needs you, instead of reconstructing five sessions from scrollback.

Plan-then-execute agents burn tokens faster than chat assistants because they run several inference passes per turn: one to plan, several to execute, more to self-correct. Done well it's worth it. Done badly you get two failure modes. Under-scoped: you say "fix the auth bug," the agent runs 90 seconds, makes 12 file edits, refactors something unrelated, breaks two tests, and hands you a sprawling diff to undo. Over-budgeted: you say "review this 200-line file and refactor," and four minutes later it has reorganized imports, moved a helper, fixed a README typo, and returned 600 lines across nine files. Both burn tokens for results you can't ship.

The pattern that fixes both is scope → plan → cap → verify:

1. Scope the run first, in three sentences: Goal, Files in scope (max 3–5), Out of scope (an explicit list of what not to touch). Twenty-five tokens of scope saves a 5,000-token over-broad run.
2. Force a plan before code: "Output a numbered plan in 5 lines or fewer. Wait for approval." The plan is cheap (~1K tokens) and lets you redirect before the expensive execution phase.
3. Cap the executor: "Maximum 3 file edits. If you can't finish in 3, stop and explain why." A soft cap makes the agent decide consciously instead of drifting.
4. Verify cheaply: "Run only the tests in auth.test.ts and report failures" — naming which tests avoids a 30–180 second full-suite run and the token cost of digesting its output.

Then run a weekly token-burn audit: pull the last 20 agent runs, bucket by token consumption, and look at the prompts behind the top 20%. They almost always lack a Files-in-scope / Out-of-scope clause. Two situations justify relaxing the discipline — genuinely exploratory tasks, and repo-wide migrations where traversal is the point — but there, set a session token budget instead of a file-count cap.

Multi-agent coding workflows rarely fail because the model is weak. They fail because the handoff is vague. One agent explores, one plans, one writes code, one verifies — and it sounds efficient until the executor starts guessing what the planner meant, or the verifier finds the task quietly changed halfway through. The fix isn't a longer prompt; it's a standard handoff that reads like an execution contract. The executor should read it in under a minute and know four things: what outcome matters, what is in scope, how success is verified, and what must not change. Any missing piece gets filled with assumptions — and that's where the expensive mistakes start.

A complete handoff has these sections:

• Goal — one sentence naming an observable result ("return 400 with password_required when password is missing"), not a topic area.
• Why now — the concrete failure or user-facing consequence, so the task doesn't drift into abstract cleanup.
• Files in scope — the highest-leverage line; naming two exact files bounds the search area, while "the login flow" authorizes a repo walk.
• Out of scope — "no schema changes, no refactors"; this is what stops the helpful side quest.
• Current state — evidence, not theory: what was reproduced, what the stack trace showed, what the tests don't cover.
• Required change — diagnosis turned into concrete actions.
• Verification — operational checks ("run the auth test file; send a login request without a password, expect 400"), not "make sure it works."
• Done criteria — what finished looks like, which is different from what to run: an executor can pass a test while changing five extra files.
• Open questions — the stop-sign section: "if this needs a schema migration, stop and escalate."

Not every task needs the split — skip it when the job is tiny, or when one agent already has all the context. The bar isn't "did the planner think hard," it's "could a different agent execute this cleanly on the first pass."

AI coding sprawl is different from ordinary terminal sprawl because each tool claims its own terminal. Claude Code needs a persistent session, Codex wants its sandbox, and your manual debugging still happens in plain zsh. Multiply by the repos you touch in a day and the tab count doubles. Twelve tabs, three repos, one brain trying to remember which tab belongs where. The symptoms are specific: wrong-repo commands (you git push in the infra terminal thinking you're in the API repo), lost session state (which tab had the bug investigation from twenty minutes ago?), invisible active work (three sessions running — one finished, one looping, one waiting on you, and you can't tell which without clicking through), and context bleed (you paste a stack trace into the wrong agent and it starts "fixing" a repo it shouldn't touch).

Tmux solves naming and layout but not identity — a session named api tells you the repo, not whether the Claude session inside it is still active or what it's working on. The gap is between terminal organization and session awareness. A workflow that holds up today:

1. One tmux session per repo, named after the repo, not the tool. Use windows inside for claude, shell, logs. Never run a coding CLI outside its designated session.
2. Direnv for automatic context — an .envrc per repo sets project env vars, so even a wrong cd swaps your environment to match.
3. Put the session/window name in your prompt ([content-api/claude]) so wrong-repo commands are obvious before you hit enter.
4. Kill idle sessions aggressively — a coding CLI idle for over 30 minutes costs you more as ambiguity than the context you'd lose by restarting it.
5. Keep a session-inventory script that lists every active coding session across repos, and run it before starting new work so you reuse an existing session instead of spawning another.

The real fix is a workspace contract: one lane per repo, strict naming, automatic context, aggressive cleanup. Boring, and the opposite of sprawl.

If you do serious AI-assisted coding you've probably arrived at the multi-tool setup: Codex for autonomous tasks, Claude Code for chatty refactors, the shell for what neither does well, maybe Cursor in another window. Each tool is good at its slice; the cost is at the seams. You hand a half-finished idea from Claude to Codex and Codex has no context. You finish a Codex task and want to review it in Claude, so you paste the diff and re-explain the goal. You become the human switchboard between agents that each forget the decisions the others made.

The bill you actually pay isn't tokens — it's cognitive debt. Every switch is a context reload in your head: re-explain the task, re-establish what the agent already tried, re-find the terminal output that mattered, re-derive a decision you made an hour ago in another window. People split tools for rational reasons (usage limits, pay-as-you-go shocks, instructions that don't stick), but splitting your context across those tools is the mistake.

What's missing is a handoff layer — a shared substrate that carries what survives the tool change: decisions ("we chose approach X"), current state (branch, files being edited, the error under investigation), next steps, recent shell commands and their output, and the active prompt. It's distinct from a long-lived memory vault: the vault answers "what do you know about me?" (slow, standing context like project conventions in CLAUDE.md or AGENTS.md), while the handoff layer answers "what are we doing right now?" (fast, active context). Partial versions already exist — project files, MCP memory servers, manual "here's where I left off" notes — and the shape people keep converging on is one place the context lives that many tools read. Keep the context out of any single tool and the tool-juggling becomes a billing optimization instead of a cognitive tax.

A coding agent can sound completely confident while skipping tests, ignoring style rules, duplicating another agent's work, or carrying hidden context you didn't mean to include. The answer is not a stronger model; it's a workflow that exposes state. AI coding stops feeling magical the first time a generated app has to survive review, testing, handoff, and production — and at that point you need evidence: what changed, why, what was tested, and where the agent may have acted outside its boundary.

The sharpest version of this is the confident hallucination. Builders running agents across Cursor and Claude Code have watched them produce code that calls Stripe and Supabase endpoints that do not exist — the code compiles, the types line up, it reads like something a careful engineer wrote, and it fails only at runtime against the real API, usually well after the agent reported success. When one agent invents an endpoint you catch it because you're watching; when four commit in parallel, the fake call sits undetected while your attention is elsewhere. The compiler won't flag it, so a truth check against the actual API surface has to run on its own.

What review needs is runtime proof, not a polished explanation: active sessions, files touched, commands run, test output, and a link between the final diff and the run that produced it. That trail also catches false progress — an agent looping through the same search, swapping implementations, or claiming a test passed without showing the command. Without it, review turns into archaeology and every handoff becomes a trust exercise. The useful systems won't be the ones that produce the most code; they'll be the ones that leave the best trail: task intent, repo context, edits, tests, failures, retries, and final verification — enough for a developer to resume the work, review another agent, or explain the change later. Trust should be earned before merge time, while the session is still active, not reconstructed after a customer reports the bug.

Auto-approval is convenient right up until it's unclear what the agent can actually do. Remote commands, package installs, file writes, browser actions, and deployment steps carry very different risks, and a chat transcript can't be the only control plane for that action surface. The pattern developers keep rediscovering is that permissions should be designed, not remembered. One builder running multiple Claude Code, Codex, and Cursor sessions ended up writing a watcher just to catch the approval pauses he was missing across windows; another, after a production soft-launch, landed on a set of bounded-autonomy rules that survived real use: agent-as-first-reviewer, generate-then-curate, strict file and command boundaries, and explicit escalation to a human.

Human-in-the-loop doesn't mean stopping every action — that just trains you to click "approve" on autopilot. It means placing review where the cost of being wrong is high: destructive commands, secret handling, production deploys, schema migrations, and anything that mutates state you can't cheaply undo. Useful guardrails are specific. They distinguish read-only inspection from destructive commands, they make the approval decision visible instead of buried in scrollback, and they let a team declare which tools are allowed in a given project and which steps require a human.

The harness around the agent — the MCP servers, hooks, permission boundaries, and review flows people build by hand — is exactly where this lives, and it's increasingly the real product. A dry-run and an approval gate belong to the harness, not to an individual model's good manners, because the model is easier to swap than the operating layer around it. The point isn't to slow the agent down; it's to stop confusing speed with permission.

Route everything through the strongest model and cost becomes unpredictable while feedback slows down. Route everything through the cheapest and the quality failures just move downstream into debugging. Neither extreme is the answer, and the pressure is real: developers describe hitting a plan's ceiling mid-task and reaching for a second tool, getting a surprise pay-as-you-go bill, and trying to stretch a Claude Pro plan across Sonnet for execution, Haiku sub-agents, and Opus for planning with large context windows. One cloud architect testing a planning-heavy model during a production soft-launch found that planning alone burned far more of a five-hour usage window than the actual coding did — and concluded he needed clearer task-to-model routing, not a different subscription.

The practical answer is per-task routing: hard reasoning to a strong model, mechanical edits to a cheap or local one, and the ability to make that choice per task instead of per subscription. But you can only route well if you can see what each agent is doing and what each task is worth. That means cost has to be a first-class signal, not a month-end surprise — elapsed time, tokens, retries, and usage warnings visible while the run is happening, so you can spot a loop before it becomes expensive. A cheaper model repeating the wrong tool calls is still expensive; a stronger model working on stale context still wastes time.

The other half is not paying twice: prompt-cache behavior, aborted requests, and hidden summarization all quietly inflate the bill, so the workflow needs to show where tokens, time, and retries actually went before you can decide whether the model, the prompt, or the context is the real bottleneck.

On a throwaway script the model's habits don't matter; on a 100k+ line commercial codebase they do. Developers running Qwen or other local models on real products describe the same failure: the agent produces working code that ignores the project's layering, invents its own patterns, and quietly re-interprets constraints it agreed to a paragraph earlier. One builder watched Opus and Sonnet both acknowledge a written plan, then reshape the architecture and constraints anyway during implementation. Re-explaining the rules in the prompt every session doesn't hold — the moment the context window rolls, or you hand off from Claude Code to Codex, the rules are gone and the drift starts over.

The fix people converge on isn't a smarter model or a longer prompt; it's a durable, versioned rulebook that gets injected into every agent, every session, on every tool. Concretely: architecture and testing conventions live in reusable skill/rule files (the SKILL.md / AGENTS.md pattern), not in your head. A reviewer pass — often an ensemble of reviewer agents — checks output against those rules before you accept it. And the highest-leverage habit builders report is a ratchet: the first time an agent repeats a mistake, you convert the correction into a written rule so it can't recur, and the rulebook compounds instead of the errors. The model becomes interchangeable underneath a rulebook you own. That discipline also defends against the thing that erodes trust fastest — a tool silently changing behavior between sessions — because your rules and setup are committed artifacts, not something you have to remember and re-type. See also Model routing & AI coding costs for the cost side of the same governed workflow.

Two failure modes show up the moment agents touch a real repo, and both are about input truth rather than output quality. The first is stale reads: an agent pulls a file into context, then you — or another agent, or a git pull — edit that file externally, and the agent keeps reasoning and editing against the version it cached. Its 'fix' is built on code that no longer exists. Builders describe bolting on groundedness audits and evidence citations just to catch when an agent is acting on a file the disk no longer matches. The second is impact blindness: the agent has no durable structural model of the codebase, so on every task it rereads a pile of files and guesses what a change will affect. One developer built a local code graph precisely because the agents kept rereading and mis-estimating blast radius; token-efficient multi-agent workbenches are now shipping the same idea — a persistent map of the repo so agents stop rediscovering structure from scratch each run and stop burning tokens doing it.

The pattern underneath both is that a chat transcript is a poor source of truth about a live codebase. You want the agent — and yourself — reading from something that reflects the current files and the real symbol graph, and you want every change an agent makes to be visible and reversible rather than accepted on faith. In practice that means three things: a real-time view of files instead of a snapshot, real language-level understanding instead of pattern-matching over text, and a per-file record of exactly what each agent touched, so a stale-read mistake surfaces before it reaches review. This is the same territory as Repo understanding & context for coding agents.

The expensive part of multi-agent work isn't any single session; it's the re-assembly tax you pay every time you switch projects. Reopen the repo, spin up the right terminals again, point each agent at the right model, remember that this project runs the cheap model for grunt edits and the flagship for architecture, and go hunting for where the last run actually stopped. Done by hand across a dozen tabs, that setup is both slow and error-prone — the mistakes are wrong-model and wrong-repo, which are exactly the ones that cost tokens or damage.

The reason it's painful is that all of that state lives in your head instead of in the project. Which agents, which windows, which model routing, which trust boundaries, and the run state — none of it is written down anywhere the tool can restore, so every context switch rebuilds it from memory.

The fix is to make the workspace itself the unit of memory. Reopen the project and the terminal layout comes back, the agents come back pointed at the models you chose, and the run state is where you left it. That turns a project switch from a five-minute reconstruction into opening a door — and it removes the class of mistakes that come from rebuilding the setup slightly wrong under time pressure.

Every agent invented its own storage and its own account context, and that's the root of the mess. Claude Code writes JSONL, another tool uses SQLite, a third buries sessions in a hashed temp directory, and each carries its own billing and login. So your actual working history — what you tried, what worked, what you decided — is smeared across four silos in four formats, and none of them can see the others. When a run dies mid-task or you switch tools to dodge a rate limit, you can't pick up where you were; you re-explain from scratch.

Notice what people keep building to cope: TUIs that wrap several agents, VS Code 'rooms,' remote-control layers, governance compilers. They look like different projects but they're reaching for the same missing piece — a control plane that sits above the individual CLIs and keeps one resumable record of the work, independent of which tool happened to produce it.

That's the right altitude for the fix. The history shouldn't belong to Claude Code or to Codex; it should belong to you, span all of them, and be searchable and resumable as a single stream. Once the record lives above the tools instead of inside each one, switching agents stops meaning starting over, and a dead session becomes something you continue rather than something you reconstruct from memory.

Running parallel agents against one working tree is a race condition with a nicer UI. Two agents editing the same files, staging changes, and running builds in the same directory will overwrite each other, corrupt a half-finished refactor, or leave you unable to tell whose change broke the tests. The instinct is to slow everything down with more approval prompts, but that treats a structural problem as a behavioral one. The agents aren't misbehaving; they're sharing a resource that was only ever meant for one writer.

The real fix is isolation. Give each agent its own copy of the code to work in, so its edits, its build artifacts, and its dependency state can't touch anyone else's. On a single repo that means a separate branch and working tree per agent — each one gets the full project, checked out independently, and you merge the results deliberately once you've reviewed them. For work that also touches processes, ports, databases, or system state, a container per agent extends the same idea past the filesystem: the blast radius of any one run is a throwaway environment, not your machine.

Isolation also makes the cockpit legible. When each agent lives in its own space, you can watch them side by side, see which one is stuck, and kill or restart one without disturbing the others. Blocking dangerous commands still matters as a backstop, but it's the floor, not the plan. The plan is that no agent can wreck another's work because no two agents are standing in the same place.

When you're running several agents at once, the mouse quietly becomes the bottleneck — and for anyone managing RSI, an actual health problem. Every context switch is a reach-and-click: find the right terminal, click in, click the tab, click the button. Multiply that by a dozen terminals and a day's worth of switching and you've done thousands of small precise movements a keyboard could have handled without your hand leaving the home row. The productivity cost and the physical cost are the same cost.

The fix is to treat the mouse as optional, not primary. Two capabilities do most of the work. A command palette collapses "where is that and how do I click to it" into type-a-few-letters-and-go — switching terminals, launching an agent, jumping to a project, running an action, all from one prompt without hunting. And fully rebindable shortcuts let you map the moves you make constantly — cycling agents, focusing a pane, sending input — onto keys your fingers already rest near, instead of whatever defaults shipped.

The tell of a genuinely keyboard-first tool is that you can run an entire session with the trackpad untouched, and that the shortcuts are discoverable — a visible guide so you're not memorizing an undocumented map. That combination is what turns "I could technically avoid the mouse" into actually avoiding it, which is the difference that matters when the reason you're avoiding it is pain rather than preference.

Coding agents run long, run unattended, and pause to ask questions — but they're pinned to the machine you launched them on. Screen-share is the usual workaround, and it's the wrong tool: it's laggy, it's mostly read-only, and you can watch a run without really being able to drive it. Worse, you can't pick the session up cleanly on a different device; you're tethered to one desk.

The pain scales with parallel work. You step away, an agent stalls waiting for a yes/no, and you don't notice until you're back at that screen — so a run that could have finished sat idle for an hour. The more agents and the longer the runs, the more of your day is spent physically near the machine just in case.

The fix is to stop treating a session as a window glued to one screen and start treating it as something you reach over the network. You want an addressable terminal you can open, read, and type into from a laptop or a phone — an actual control channel, not a video feed — with the session's state persisted so a reconnect or a device switch resumes exactly where it was instead of starting over. That combination, real remote control plus continuity, is what unpins the work from the desk.

Delegation is where multi-agent workflows get their leverage and lose their visibility. A parent agent spins up subagents to review a diff, run a search, or draft a module, and by default what comes back is a summary the parent chose to surface. The subagent's actual tool calls, its intermediate reasoning, and the raw result it returned are collapsed into a sentence — which is fine until the sentence is wrong. A subagent can report success without running anything, return text that the parent treats as instructions, or quietly do less than it claimed, and none of that shows up if the only artifact is the parent's paraphrase.

The reason this matters more than ordinary agent output is that the parent is now an unreliable narrator for work you did not watch. When you run one agent you can read its stream. When it delegates, you are trusting a compression step you did not author. Debugging a bad result means asking which subagent produced it, what it was actually asked, and what it actually ran — questions a summary cannot answer.

What the layer needs is direct observability:

• A record per subagent — which one ran, what it was delegated, and how long it took — so a stuck or runaway delegate is attributable rather than hidden inside "the agent is working."
• The real return, not the paraphrase. Being able to open a subagent's actual output separates "it did the work" from "it said it did the work."
• The tool calls it made, so you can confirm a claimed test or fetch actually happened.
• A bound on each delegated run, so a subagent that loops does not burn the session unattended.

The goal is not to eliminate delegation; it is to stop treating the subagent boundary as a place where evidence disappears. Once each delegated run leaves its own trail, a fleet of subagents becomes something you can audit instead of something you hope worked.

The loop itself is the right instinct. Self-review is weak — a model grading its own work inherits its own blind spots — and an independent reviewer plus a deliberately adversarial challenger breaks the agreement bias that makes single-agent output feel more finished than it is. People running this pattern for high-stakes work report it catches real defects. The problem is that most people implement it as three chat windows and a human doing fidelity-losing copy-paste between them, which caps how often you'll actually run the loop and leaves no trace of what happened.

Three things fix the transport. First, the roles need to be long-lived sessions sitting side by side — not tabs you re-prompt from scratch — so each keeps its role context across rounds. Second, handoffs should be scoped artifacts, not transcripts: pass the reviewer the diff and the acceptance criteria, not the generator's whole conversation, or the reviewer absorbs the generator's framing and you've rebuilt the agreement bias you were paying to remove. The challenger especially should see the work, not the justification. Third, the loop needs a record — who produced what, who objected, what changed in response — because a review process you can't audit afterward is indistinguishable from one that didn't happen.

One upstream fix matters as much as the loop: package requirements at the right altitude before the generator starts. The expensive failure mode isn't sloppy code — it's clean, reviewable code that builds the wrong thing because the requirements packet was vague, and no reviewer or challenger downstream can catch what was never specified.

This is the scenario that should change how you think about approvals. A session ID is not an execution identity. When a session forks — a resume that didn't cleanly take over, a crashed parent, two clients attached to one history — you can end up with two processes sharing an ID, diverging histories, and overlapping workers writing to the same paths.

The visible branch reporting completion is the dangerous part. Its sibling is still running, so "done" is true of one lineage and false of the system. And a remote approval prompt with no process context is worse still: you are authorising a command without knowing which lineage, which working tree, or which diff it belongs to.

Until harnesses handle this properly:

• Never approve remotely what you can't attribute. If the prompt doesn't tell you the process, project, and branch, deny it. A denied command costs a retry; an approved one on an unknown lineage can cost the repo.
• Bind work to a worktree, not a session. Two processes in one checkout is the corruption path. One agent per worktree makes forking visible as two directories instead of invisible as two PIDs.
• Treat "done" as a claim requiring artefacts. A completion with no diff, no test output, and no commit is a sentence, not a result.
• Check for orphans after any resume. A quick process listing for stray agent processes belongs in your routine the way git status does.
• Keep the local execution record. When a phone prompt appears, the machine should be able to tell you what asked for it.

Generation got fast; reconstruction didn't. The bottleneck in parallel agent work is no longer producing the change, it's rebuilding the intent behind it — what you asked for, which constraint changed halfway through, what you'd already rejected, and how far the review got.

Shell history won't save you, because it records commands, not decisions. Neither will the branch name. What you need is a small amount of state written at the moments when intent exists.

• Write the charter when you create the worktree. Two lines: what this branch is for, and what "done" looks like. If you can't write them, you're not ready to start an agent on it.
• Keep a per-branch progress note the agent updates. Current state, last thing verified, next step, open questions. This is also what makes recovery from a killed terminal or a hit usage limit survivable.
• Record decisions where they happened, not in your head. "We're not using the queue library, we're polling — because X." Six days later this is the difference between resuming and re-deciding.
• Cap parallelism at what you can review. Four agents generating and one human reviewing is a queue with a growing backlog; the code isn't finished until it's been read.
• Make one place the answer to "what is running?" Window-hunting across VS Code, terminals and browser tabs is the tax people describe most, and it's pure overhead.

The artefact that matters isn't the diff. It's the sentence explaining why the diff exists.

Terminal isolation is the real cost of agent-assisted teamwork. The agent has the repo but not the decision; the team has the decision but not the run. One person ends up relaying both directions by hand, and the moment they stop, the agent works from a stale premise.

The pattern that works is to stop treating chat as the record and the terminal as the work. Both are events; the durable thing is the artefact between them.

• Land decisions in the repo. A short decision file per meaningful choice — what was decided, why, what it rules out. Agents read it because it's in the tree; humans read it in review. Chat becomes the discussion, not the memory.
• Make the unit of handoff a task, not a paragraph. A task with a goal, constraints, and an acceptance check can be picked up by an agent, a teammate, or you tomorrow. A pasted chat message can't.
• Attach evidence to the outcome. Files changed, diff, preview URL, what was verified, what's still uncertain. That's what a reviewer needs; without it they re-derive everything.
• Say who approved what. With several agents and several people, "approved by whom, at what state" is the thing that gets lost first and matters most.
• Keep uncertainty explicit. An agent's confident summary hides where it guessed. A note saying "unsure about the migration order" saves a reviewer an hour.

Solo builders hit the same wall with a manager session reviewing a builder session: it works, and it drowns in copy-paste, because the two halves have no shared surface.

The ambition is right and the failure mode is predictable: a private business operating system that lives as prompts scattered across a dozen integrations becomes unobservable long before it becomes powerful. The question isn't whether to combine the tools — it's whether the combination has a control plane or just a lot of wiring.

Overbuilt is constructing the whole platform before proving one path through it works. Efficient is separating durable state and control from the assistants that act on it:

• State outside the prompts. Your business facts, approvals, and audit history live in something you own (your SQLite is fine), not inside a chat or an n8n node that rots.
• Explicit read/write and approval boundaries per integration. Each system declares what it can touch and what needs a human yes. A business brain without approval gates is a liability, not an asset.
• Every integration observable. You can see what each one did, with what inputs, and replay it. Confidence and audit history aren't things you bolt on later; they're the reason to build this at all.
• One thin end-to-end workflow first. Pick a single real business path — order in, decision, action out — and make it work with evidence and approvals before you expand. If one path can't be trusted, ten can't either.

Build the control model first and the platform grows into it. Build the platform first and you get a private brain nobody can audit.

Two orchestration systems isn't inherently wasteful — n8n is good at triggers and plumbing, a coding agent is good at judgment. The waste is that your prompts live inside n8n nodes, where they're invisible to version control, impossible to diff, and quietly drifting from the ones you actually iterate on. That's the part that rots, and it's fixable without collapsing to one tool.

The durable arrangement keeps judgment logic out of the plumbing:

• Prompts and skills as versioned files, not node contents. They belong in your repo where you can diff, review, and roll them back — the same place your code lives. A prompt embedded in a workflow node is a prompt with no history.
• One definition, two triggers. The same prompt/skill should run whether a schedule fired it or you ran it by hand. Maintaining a manual copy and a scheduled copy is how they diverge.
• Record inputs and outputs per run. Which model, which prompt version, what came back — so when article quality drifts you can see which change caused it.
• Clear retry and approval boundaries at the judgment steps, so a bad generation doesn't publish itself.

n8n keeps doing what it's good at. The judgment-heavy prompts move to files where they have a history, and the two systems stop being two competing sources of truth.

Screen scraping a PTY works until it doesn't, and it fails in exactly the ways that matter for orchestration: it infers state from terminal pixels, so a redraw, a resize, or a colour change becomes a false signal. You can't reliably orchestrate what you only observe by parsing output meant for a human. The multiplexer-and-heuristics stack is a workaround for a missing runtime, not the runtime itself.

What background execution actually needs is structure the terminal never provided:

• Stable session IDs. An execution context you address by identity, not by which tmux pane it happens to occupy.
• Machine-readable events, not scraped text. Started, awaiting-input, finished, failed — as events, so control logic doesn't depend on matching a prompt string.
• Explicit lifecycle state and resumable logs. You can see whether a session is running, waiting, or done, and reattach to its full history instead of whatever scrolled past.
• Approvals bound to the exact session. A "yes" applies to the session that asked, not to whichever pane is focused.

Once sessions are first-class objects rather than terminal windows, remote control and multi-session orchestration stop being heuristics and become ordinary reads and writes against known state. The pixels stop being the API.

Agent tooling still assumes one human, one machine, one terminal. That holds until a second person needs to see what's running — then the options collapse to a screen-share (one driver, one spectator, nobody else can act) or a full handoff (the other person rebuilds all the context).

Driving agents in pairs is a different problem from pair programming, because the agent keeps working while you talk:

• Shared visibility of live run state. Both people need to see which agents are running, what each is doing now, and what it just did — without one person narrating.
• Either person can intervene. The value of watching an agent go wrong is catching it in the first minute. If only the laptop owner can type, the observer is decoration.
• Separate lanes, not one contended prompt. Two people typing at one agent produces interleaved instructions and a confused run. New work opens a new lane; the shared thing is the view, not the input box.
• Credentials stay where they are. Neither person should need to buy a second seat or re-authenticate a provider just to observe. The session runs where it runs; access is what's being shared.
• A record that outlives the session. So whoever stepped away can read what happened instead of asking.

The shape that works: treat the agent workspace as a place both people can be present in, with run state as the shared artifact and the terminal as a resource either of you can take. Handing over a machine and handing over context are two different acts, and only one of them should require the other person to be sitting there.

Give the two jobs separate seats. One model generates the change. A separate, deliberately stable orchestrator decides whether it ships — runs the tests, reads the CI evidence, applies the merge policy, quarantines whatever fails. The worker is the variable; the judge is the constant.

This is worth the structure for two distinct reasons.

It makes model comparison mean something. If you swap the coding model and also change the prompt, the branch strategy, and how carefully you happened to review that week, what you have is an anecdote. Holding the evaluation fixed — same task set, same checks, same merge bar — is what turns "this one felt better" into a claim you can act on. The judge doesn't need to be the strongest model you have access to; it needs to be the same one applying the same rules, so the only thing varying is the work being judged.

It removes a conflict of interest. A model that both writes the code and rules on whether it's done will rule that it's done. Separating the seats means the ship decision is made by something with no stake in the diff, reading test output and CI results rather than the author's own summary of them.

The state that makes this reproducible has to live outside the conversation:

• Worktree isolation per worker, so two models attempting the same task don't contend, and each attempt sits on its own branch where you can inspect it independently.
• Append-only run logs — what was attempted, what the checks returned, what was decided. Recoverable after a crash, comparable after the fact.
• The filesystem as the handoff, not a chat thread. A long conversation is a fragile place to keep state; a branch plus a log survives a restart, a model swap, and next month.

The payoff is that "which model should we use for this kind of task" becomes a question with an actual answer, and a crashed run resumes instead of starting over.

You've described the honest version of this, which most parallel-agent advocacy skips: per-command approval doesn't scale, and the middle option — glancing at each one for obvious malice — is the worst of the three. It costs you half your throughput and catches almost nothing, because misguided commands don't look dramatic. A destructive python one-liner reads like every other python one-liner.

Per-command review is simply the wrong unit. What scales:

• Policies instead of prompts. Approve classes of command once — this test runner, this build, reads under this path — and let matching calls run silently. Your approval budget should be spent on things you haven't already decided.
• Risk tiers, with the boundary drawn at reversibility. Reads, local writes, network access, and irreversible operations are four different questions. Bundling them into one Allow dialog is exactly why the dialog stopped carrying information.
• Isolation as the default containment. A per-agent worktree or container makes most approvals unnecessary, because the blast radius is already bounded. Nothing beats not needing the prompt at all.
• Network and credential boundaries set per agent. Your instinct about internet access is the right one — that's the capability that turns a bad command into an unrecoverable one, and it should be off unless the task needs it.
• An audit trail so review happens afterwards, in batch. Reading a hundred commands later, grouped and filtered, is a fundamentally cheaper task than approving them one at a time while blocked.

The goal isn't fewer safeguards. It's moving the decision from per-command to per-policy, so your attention lands on the tier that can actually hurt you.

Worth separating two claims that get marketed together. "Works alongside agents" usually means the app is fast and doesn't fight your workflow — genuinely valuable, and mostly a claim about you. "An agent can use this" is a claim about a machine-readable surface, and far fewer tools have one.

The properties that decide the second:

• State an agent can read without a screenshot. A diff it can enumerate, a file tree it can walk, a terminal buffer it can quote. If the only way to extract the information is a picture of a window, the agent is guessing at your UI — and it will guess confidently.
• Actions with boundaries. Reading a diff and applying it are different permissions. Tools that expose only "do the thing" push you straight back to per-action approval for everything, which is where multi-agent workflows fall over.
• Stable references. A path with line numbers, a commit hash, a task id — something that means the same thing on the next turn. Agents lose more accuracy to ambiguous references than to weak reasoning.
• Evidence that outlives the run. A record of what the tool did, readable afterwards, so the tool's actions are as auditable as the agent's.

Why this matters for ordinary work: the mechanical jobs people most want to hand off — comparing two config versions, checking whether two folders really are identical, walking a merge conflict — are precisely the ones where an agent is useful and where a wrong answer is expensive. Those need a real surface, not a screenshot.

The corollary is worth stating plainly, because it often gets lost in the pitch: a native app that opens instantly and gets out of the way is still the right thing to want. It just isn't the same feature.

"Working" is a UI state, not a measurement. It usually means a promise has not resolved, which is equally true when the model is thinking and when a file watcher is blocked on a network mount and will never return. From the outside those are identical, and no amount of restarting separates them — which is why the empty-project case is so disorienting. There is nothing to be slow about, so the hang is structural rather than computational.

Evidence is what separates them, and there are only a few places to get it:

• Phase. Indexing, waiting on the model, running a tool, waiting for approval. A spinner that names its phase turns "stuck" into "stuck on what", which is most of the diagnosis.
• Subprocess activity. Is there a child process, and is it consuming CPU or blocked? A shell command waiting on a prompt you cannot see is the most common single cause, and it stays invisible unless something surfaces the process.
• Filesystem scope. Agents that scan a tree walk whatever they are pointed at — a synced folder, a network volume, a home directory containing a cloud mount. An empty project inside a watched parent is not empty from the scanner's point of view.
• Permission state. On macOS, first access to a protected location blocks on a consent dialog that can appear behind another window, or not appear at all. The process is not hung; it is waiting for you.
• A timeout. Every external call needs one. Unbounded waiting is a design decision and it is the wrong one — a failure after ninety seconds is more useful than a spinner forever.

Practical order: look for a child process, then what path it is touching, then permissions. If the tool cannot tell you any of that, the tool is the problem rather than the model.