Multi-session agent orchestration is the new job

OpenAI said the quiet part out loud when the Codex app shipped in early 2026. The hard problem moved from what agents can do to how people direct and supervise them at scale. Claude Code answered with agent view, worktrees, and experimental agent teams. A prettier chat pane would have been feature fluff. The tools are treating orchestration as first-class work.

Typing stopped being the scarce skill#

When a single agent can hold a multi-file change long enough that waiting on generation stops filling the whole day, the math changes. Idle attention becomes inventory.

Practitioners already filled that idle with more agents. Simon Willison describes multiple Claude Code and Codex CLI windows, sometimes in separate directories, for research, small maintenance, and carefully specified work. Rory Bain's write-up for the incident.io team went from zero Claude Code to four or five agents on different features in parallel.

That is a role shift, not a party trick. The human stops being the only typist and becomes the dispatcher of independent tracks. Keep thrashing on keystrokes and the unsupervised queue rots under you.

Free speed, this is not.

What breaks first is not the model#

The failure modes are boring and brutal. They show up before model quality does.

• File collisions. Two writers on one checkout wreck files and context (Sanwald, Claude agent-teams docs).
• Merge debt. Separate branches still collide when the codebase is monolithic (Heeki Park).
• Review ceiling. One human lands one significant change at a time (Willison).
• Attention cost. Multi-session is two meetings next door, and each session is its own context window.

Same checkout, two writers. Lucca Sanwald put it cleanly. If both agents touch the same file, all hell breaks loose, with overwrites and wrecked context. Claude's own agent teams docs warn the same thing in product language. Two teammates on one file leads to overwrites.

Isolation helps write time and fails at merge time. Heeki Park spun up three agent teams on separate issues in a monolithic app and still got a fair amount of merge conflicts, then serial review, merge, and rebase to recover a linear history. Worktrees do not delete integration.

Review is the hard ceiling. Willison's first instinct was correct. Generated code still needs a human, and one person can only land one significant change at a time, which means every extra agent past that budget is not shipping speed so much as a growing stack of nearly-done work that still waits on the same pair of eyes. A pile. That is the same pressure surface as code review becoming the bottleneck, only earlier, at session design time.

Attention is finite too. Sanwald's metaphor sticks. Multi-session feels like moderating two meetings in neighboring rooms, and neither room cares that you are late. Tokens burn just as hard. Each session is its own context window. Claude's teams docs say usage scales with active teammates, and field notes show init context multiplying across lead plus workers.

The steel-man is one good session#

The strongest counter is simple. Most work is not independent. Most people do not need a fleet.

Claude's agent-teams guidance is blunt. For sequential tasks, same-file edits, or high-dependency chains, a single session or subagents is more effective. Subagents stay inside one conversation and report back. That is parallel search and side work, not multi-session orchestration. Confusing the two is how SEO posts sell ten agents to people who needed one clean plan and a nap.

Heeki's field notes land the same place for ordinary issue size. Subagents were enough for most of what he ran. Teams were an experiment, not a daily default. Willison only warmed to parallel work once the extra tracks were low-overhead relative to the primary review load. And the MAST paper is the research spine nobody wants on a marketing slide. Multi-agent gains on popular benchmarks are often minimal, with failure modes that look a lot like org design and verification debt.

So the steel-man is half right. Multi-session is a terrible default for dependent work. It is also a terrible excuse for a fat, always-on instruction dump that every worker reloads. That is the same tax fat instruction files already punish inside a single session.

Where the steel-man fails is the independent case. Research, small maintenance, and fully specified slices free attention while the primary track is reviewing. Vendor products are not building session dashboards for a niche flex. They are building for a job that already exists at the margin.

The job is partition, isolate, and budget review#

If multi-session orchestration is the job, the day is a traffic desk with three verbs. Extra terminals without those verbs just invent more merge and review debt.

1. Partition independent work only. Shared interfaces, migrations, and scope-coupled tracks stay sequential. Write goal, owned files, and forbidden files before spawn.
2. Isolate each writer with its own checkout. Claude worktrees and agent-view background sessions exist so edits never share a working tree.
3. Budget review as the scarce queue. One significant change in flight for landing. Background tracks only when they do not steal that focus.

This site's research workflow often runs that shape. Legwork fans into parallel agents, each on a bounded brief, while judgment stays in one orchestrator context that never lets the workers own the merge desk. That is not a product demo. It is the only way the review budget stays real when three research tracks finish in the same hour.

Spec-first is not ceremony here. It is how Willison's carefully specified work stays cheap to review. Background sessions in agent view move into .claude/worktrees/ before edits for the same reason. Teams that stick with multi-session usually write a worktree helper for the same reason. Friction kills the habit.

Agent view's useful invention is the state board. Needs input. Working. Ready for review. Treat it as a merge desk, deliberately plain, not a vanity wall of green rows.

Handoffs belong on disk. A short task note, a committed plan, an issue body. Anything that survives when the chat row dies. Chat history is a trap if you treat it as team memory. The orchestrator session is for coherence, not for re-deriving every worker's last twenty tool calls.

Hold the title only where independence is real#

Refuse multi-session when the work is a single critical path. Refuse it when two agents would share a file. Refuse it when review capacity is already maxed. You will not outrun a shared critical path by opening more panes. One deep session, or subagents inside it, is the adult move.

Take the title when tasks are independent, isolation is cheap enough, and the review budget still has room for background tracks. That is when multi-session agent orchestration stops being a flex and becomes the job description. Partition the work. Isolate the writers. Keep the merge desk honest, or you ship a second full-time cleanup shift with a cooler name and the same unpaid overtime.

Change the mind for the opposite cases with two receipts. First, a string of independent slices that died in a single-session queue while attention sat idle. Second, a measured review capacity that can absorb one primary track plus low-stakes parallel work without rubber-stamping. Until those show up, the fleet is just more panes, and the real job is still one careful session.