The fleet: several agents, orchestration and background work

Sooner or later a single agent runs into two limits: the context window and time. A long search fills up the context; a large migration takes hours. A fleet is several agents working in parallel, each in its own area of responsibility. Claude Code has five ways to do this. Below they go from simple to complex, with equivalents in Codex, Cursor and GitHub.

#Level 1. Subagents: context isolation

A subagent is a helper inside your session with its own context window, its own system prompt, its own tools and permissions. It handles a side task and returns the result. The built-in Explore, for example, searches the code with read-only permissions, and the search results don't end up in the main conversation.

When you need it: the task produces a lot of noise (logs, search results, file contents) that you won't need later; separate permissions are required; the work is self-contained and boils down to a result. How to define your own subagent is covered in the third post.

In Codex, custom agents are defined in .codex/agents/*.toml, and the number of concurrent threads is limited by agents.max_concurrent_threads_per_session in config.toml.

#Level 2. Parallel sessions in git worktrees

When you run several tasks at once yourself, the main danger is two agents editing the same files. A git worktree gives each session a separate copy of the repository:

claude --worktree feature-auth
# creates .claude/worktrees/feature-auth/ on the worktree-feature-auth branch

You can give a subagent its own worktree with the isolation: worktree field. If changes remain in the worktree, Claude Code asks on exit whether to keep it or remove it.

For a single large change there is the built-in /batch skill: it splits the change across 5–30 subagents, each in its own worktree.

#Level 3. Background and cloud agents

A background session keeps working while you are busy with something else. In Claude Code, the screen with all background sessions opens with the claude agents command (agent view, research preview): you can see the state of each one and which of them needs your answer. The /tasks command shows everything running in the background of the current session.

A cloud agent goes further: it runs in a separate VM and keeps going even when your computer is off.

• Claude Code: cloud sessions at claude.ai/code or via claude --cloud; /teleport pulls a cloud session into your local terminal.
• Cursor: Cloud Agents in isolated VMs; you can run as many as you like in parallel, from the desktop app, the web, Slack or a @cursor comment on GitHub.
• GitHub: Copilot cloud agent: you assign an issue to Copilot, the agent works in an environment based on GitHub Actions and prepares changes in a branch.
• CI: Claude Code GitHub Actions responds to @claude in issues and PRs; claude -p and codex exec fit into any pipeline.

#Level 4. Agent teams

An agent team is several independent sessions coordinated by a lead: a shared task list and direct messages between members. Unlike subagents, each member has its own context, and you can talk to any of them directly. In Claude Code, agent teams are experimental and off by default. An important detail from the documentation: team members are not isolated in worktrees, so you need to divide the work so that each member has its own files.

#Level 5. Script-driven orchestration

When a task outgrows a handful of subagents (an audit of the whole codebase, a migration of 500 files, cross-checking a piece of research), it is easier to keep the plan in a script than in the model's decisions at each step. In Claude Code these are dynamic workflows: a script that launches many subagents, reconciles their results, and can be rerun.

#Pattern: orchestrator and workers

Almost any fleet follows the orchestrator and workers pattern from Building effective agents: a lead model breaks down the task, hands out the parts and combines the results. Anthropic described in detail how it built a research system on this pattern:

• a lead agent on Claude Opus 4 with subagents on Claude Sonnet 4 outperformed a single Opus 4 by 90.2% on an internal evaluation;
• agents use about 4 times more tokens than chat, a multi-agent system about 15 times;
• the lead needs detailed subtask descriptions, otherwise workers duplicate work or leave gaps;
• it pays to build scaling rules into the tasks: one worker for a simple question, more for a complex one.

And the main limitation: the setup is a poor fit for tasks where all agents need shared context and there are many dependencies. According to the authors, this applies to most programming tasks. So in code, a fleet works when the task is split in advance into independent pieces: API, UI, tests, each in its own branch.

#Verification: the author doesn't accept their own work

The more agents you have, the less you see yourself. Hence the rules from the Claude Code best practices:

• An independent reviewer. A reviewer subagent or a workflow that tries to refute the result. The agent that did the work shouldn't evaluate it.
• A deterministic gate. A Stop hook runs the tests and doesn't let the agent end its turn until they pass.
• Evidence, not words. Test output, the command and its result, a screenshot.

#Long tasks: memory outside the context

A fleet often works longer than a single context window. In Effective harnesses for long-running agents, Anthropic describes a technique: the first, initializer agent prepares the environment: an init.sh script, a claude-progress.txt progress file, a JSON list of features with “passing” and “failing” statuses, and an initial commit. Each subsequent session takes one feature, finishes it, verifies it (including through a browser) and leaves the environment clean. This guards against two typical failures: the agent tries to do everything at once, or declares victory too early.

#Where to start

1. A researcher subagent (read-only) and a reviewer subagent already make a small fleet.
2. Two parallel sessions in different worktrees on independent tasks.
3. A cloud or CI agent for recurring tasks with a clear check: dependency updates, triaging new bugs.
4. Agent teams and orchestration, once the previous levels work reliably and you have the budget.

This is the last post in the series. All of its terms are collected in the glossary.