Claude Code agent teams: multi-agent work is moving into practice

Update, 20 October 2026: keep the orchestrator focused

Meta Engineering’s 19 October case study describes a thin orchestrator: fixed workflow control with isolated specialists instead of one context-heavy agent. The authors report configuration preparation falling from several manual days to under an hour, with roughly two-thirds of changes requiring no substantial human edits. This is their internal result, not a new Claude Code feature or our benchmark.

For a pilot, I would separate control of the process from work on its content. In CRM enrichment, code can own the states “awaiting sources,” “proposed,” “review” and “accepted.” A specialist receives evidence for one company and returns proposed fields with sources. It cannot redefine completion or skip review.

Test three failures: the same lead arrives twice, a worker times out, and two sources disagree. The surrounding workflow must prevent duplicate writes, cap retries and request review of disputed facts. Correct sequencing does not establish factual accuracy.

In n8n or Make, start with a few explicit branches and state stored outside the conversation. If classification requires a model, treat it as another bounded step that can return uncertainty; it is not deterministic simply because it performs routing. Add specialists only after comparison with a single-agent baseline.

On May 13, 2026 Anthropic added a research preview of agent teams to Claude Code. This matters because Claude Code is no longer only one agent taking one task. It is moving toward a workspace where work can be split across several specialized agents.

Updated May 25, 2026: I added the /goal command, which Anthropic shipped in Claude Code 2.1.139 on May 11, 2026. It is part of the same direction: agent teams split the work, while /goal defines when an agent should keep going and when the job is actually done.

Updated May 28, 2026: I am also adding Superset, which shows the other branch of the same trend: not multi-agent mode inside one tool, but local orchestration of several coding agents through isolated Git worktrees. This is not a new release today, but it is a practical workflow that complements both agent teams and /goal.

Updated June 18, 2026: I am adding the practical layer around Claude Code hooks and notifications. This is not a new model, but it matters operationally: long agent runs should call the human back when they need permission, hit an error, or finish the job.

Updated June 29, 2026: I am adding one more operational detail that came back in the Czech AI scene over the weekend: Claude Code can run locally as a terminal tool, while the model itself still runs remotely. For companies, that matters. You are not only managing prompts. You are managing file permissions, network access to the workstation, command approvals, and which data leaves for model inference.

Updated June 30, 2026: I am adding the next layer: Remote Control, Claude Code on the web, and Slack. The point is not merely that you can steer an agent from a phone or a Slack thread. The point is knowing where the agent actually runs, where its context comes from, and who is allowed to send it into a repository.

Updated August 31, 2026: Claude Code can now use SendMessage and ListAgents to communicate between separate sessions. A practical Czech demo shows that agents can coordinate a shared resource such as a single GPU. A message, however, is neither a lock nor proof of delivery. Real operations still need a lease, an acknowledgement and a check of the resource's actual state.

Claude Code agent teams workflow

What changed

Claude Code changelog version 2.1.141 mentions an experimental agent teams feature for multi-agent collaboration. It is enabled with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, and Anthropic explicitly warns that it is token-intensive.

In practice, this is useful when one agent implements, another checks tests and risk, another explores documentation or the codebase, and the human keeps the goal and final decision.

The new layer: /goal

/goal moves Claude Code in a different way than agent teams. It is not about having more agents. It is about setting a measurable completion condition and letting Claude continue across turns until a separate evaluator model confirms that the condition is met.

Example goal:

/goal npm test exits cleanly and git status shows no unintended changes

According to the Claude Code docs, the condition is checked after each turn. If it is not met, Claude receives the reason and continues. The evaluator does not run commands or read files by itself; it judges only what has been surfaced in the conversation. That means Claude needs to show evidence while working: test output, build results, diffs, or a checklist of acceptance criteria.

Superset: external orchestration instead of another chat

Superset approaches the same problem from a different angle. It is not a model and not another coding agent. It is an editor/orchestrator that can run several CLI coding agents in parallel on one machine. According to its docs, it supports tools such as Claude Code, Codex, Gemini CLI, Cursor, OpenCode, and Copilot, and it creates isolated environments through Git worktrees.

In practice, that means:

one agent fixes a bug,
another prepares tests,
a third tries a refactor,
a fourth works on documentation,
the human compares diffs, runs tests, and decides what gets merged.

This is the important difference from agent teams. Agent teams coordinate agents inside Claude Code. Superset coordinates work across different tools and separate working trees. It is less magical, but very practical: isolation through worktrees is boring technology that solves the exact problem of two agents stepping on the same files.

It does not mean you should unleash ten agents on one vague task. It makes sense mainly for parallel, separable work: independent issues, experimental solution variants, a refactor next to a feature, or comparing Claude Code vs. Codex vs. Gemini CLI on the same task.

When to use agent teams, /goal, and Superset

My practical split is:

agent teams are useful when you need parallel roles inside one problem: implementation, review, research, testing,
/goal is useful when you have one clear end state and do not want to keep nudging the agent after every step,
Superset is useful when you want to run several independent agent sessions side by side and keep them isolated through worktrees,
auto mode mainly reduces tool-approval interruptions inside a single turn,
hooks or a custom loop make sense when you need more deterministic checks through your own script.

The interesting combination is /goal plus good guardrails plus isolated worktrees plus human review. For example: “migrate this module until all tests pass, do not change the public API, and stop after 10 turns with a report.” That is no longer chatting. That is assigning work to an agent.

Hooks as the agent operations panel

The practical signal is simple: Claude Code does not have to run silently in a terminal. With hooks, it can trigger a custom action when a run finishes, when it needs permission, or when something fails. That can be a local notification, a log entry, a Slack webhook, or local text-to-speech.

Claude Code documentation describes hooks as user-defined shell commands, HTTP endpoints, or prompt hooks attached to lifecycle events. The operationally important events are things like Notification, Stop, StopFailure, PreToolUse, and PostToolUse. These are the places where a chat tool starts behaving more like a managed process.

For team usage, I would not treat this as a toy. Useful examples include:

a voice or system notification when the agent waits for permission,
a Slack message after a long run completes,
an automatic summary written into an issue or internal log,
a hard block for destructive commands,
a post-file-change hook that runs lint or tests.

This is a small configuration change, but a meaningful ergonomics change. If an agent runs for 20 minutes, the human should not stare at the cursor. The agent should work, record evidence, and call for attention when a decision or review is needed.

Three modes: local machine, cloud, and Slack

Claude Code now has three different operating modes, and teams should not treat them as the same thing.

The first mode is Remote Control. Anthropic's documentation says the session keeps running on your machine, while the web or mobile app is only a control surface. This is useful when the agent needs a local checkout, local MCP servers, local tools, or project-specific configuration. It also means the computer must stay running, must keep network connectivity, and still carries the risks of the local environment.

The second mode is Claude Code on the web. That session runs in Anthropic-managed cloud infrastructure. It is a better fit when you want to start a task without local setup, run several tasks in parallel, or work on a repository you do not currently have cloned. The security model is different: instead of access to a developer's machine, you manage connected GitHub repositories, the cloud environment, session sharing, and plan limits.

The third mode is Slack. When you mention @Claude in a channel with a coding task, the Slack integration can create a Claude Code session on the web, bring in thread context, select a repository, and post progress back to Slack. For companies this is most interesting in bug triage: a support or incident thread already contains the issue description, logs, expected behavior, and team discussion. The agent can turn that into an investigation or a small PR without someone manually copying context into an editor.

This is where governance matters. A Slack thread is not automatically a safe prompt. Claude's documentation warns that the agent can use conversation context and may follow instructions from surrounding messages. I would not enable this broadly in general company chat. It fits better in dedicated channels such as #dev-bugs, #support-triage, or #internal-tools, with clear rules for who can mention the agent, which repository may be used, and when human review is mandatory.

The practical pattern is simple: Slack is the intake queue, Claude Code on the web is the isolated work environment, and the pull request is the control point. Remote Control stays for cases where the agent needs a developer's exact local environment. Once these three modes are mixed without rules, the team loses track of where a change came from, what context shaped it, and who actually authorized it.

A local tool is not a local model

Claude Code documentation describes it as an agentic coding tool available in the terminal, IDE, desktop app, and browser. In practice, it runs close to your repository: it can read files, edit them, run commands, and integrate with development tools. That does not mean the model is running locally on the laptop.

For teams, this boundary matters. The local CLI gives ergonomics and access to working files. The remote model provides inference. The security questions sit between those layers:

which folders and repositories the agent may read,
which commands it may run without confirmation,
whether the working tree contains secrets, production dumps, or client data,
how the human connects to the machine where the agent is running,
where the audit trail lives and who approves the result.

The weekend workflow signal is straightforward: a developer runs Claude Code on a laptop or devbox, connects to it through a private network such as Tailscale, and lets the agent work over a local checkout. This is useful when you want to continue work away from the main machine, monitor a long run, or approve a step remotely. It still requires separating access to the machine, access to the repository, and the agent's own permissions.

Tailscale SSH documentation describes a model where the SSH connection is authenticated and encrypted through WireGuard and Tailscale node keys. That is a useful network layer, not a magic security exception. If the agent can run a destructive command on the machine, connecting through a VPN does not automatically make the process safe.

My practical baseline: a separate work account or devbox, a clear working directory, no production secrets in the repository, read-only defaults where possible, approval for destructive commands, hooks for logging, and human review before merge. Then "local Claude Code plus remote access" is a solid workflow. Without that, it is just a faster path to an expensive mistake.

Where it makes sense

I would not use agent teams or Superset for tiny edits. The overhead is not worth it. They start to make sense for larger refactors, unfamiliar debugging, security review, API migrations, production incident analysis, PRs touching multiple modules, or comparing several agents or models on the same task.

The point is parallel control, isolation, and a good merge process, not just a longer prompt.

What to set first

Agent teams, /goal, and Superset are not an excuse to turn off control. They are the opposite. The more autonomy you give the system, the more guardrails you need:

a clear token, turn, or budget limit for one task,
separate branches or worktrees,
a measurable completion condition such as tests, build, or checklist,
a mandatory final report: what changed, what was not tested, and where the risks are,
human review before merge,
rules for secrets, production data, and destructive commands,
logs of which agent made which decision.

Without that, multi-agent work can become a more expensive version of chaos.

Conclusion

I still treat Claude Code agent teams as a research preview, /goal as useful for tasks with a clear end state, and Superset as a practical local layer for managing several agent runs. The direction is clear: development workflows are moving from one chat window to managed agent runs.

Teams with good task design, limits, worktrees, and review will benefit. Teams that only enable another experimental feature will mostly buy an expensive lesson.

Update on July 15, 2026: adoption is a team problem, not a tool install

Tomáš AI raised a practical point today that shows up in company AI rollouts all the time: choosing a tool is not enough. If the way of working, responsibilities, and measurement do not change, the company has only added another app to the stack.

A recent study, Adoption and Impact of Command-Line AI Coding Agents, makes this concrete through Microsoft's early rollout of Claude Code and GitHub Copilot CLI. The authors studied tens of thousands of engineers and do not frame adoption as a purely technical problem. First use spread mainly through the company's social network, retention was tied more to actual coding activity than demographics, and adopters merged roughly 24% more pull requests than the model estimated they would have merged without adoption. The paper also makes the important caveat that a merged PR is not the same as the real value of a change.

For a CTO, the takeaway is more practical than "buy every developer an agent". A rollout needs visible champions, concrete use cases, measured output, and review rules. Sending a tool link into Slack and waiting for company-wide change is not a rollout. A better pilot starts with teams that already have enough coding work, shows real examples in pull requests, tracks usage by workflow, and measures not only PR count but also review quality, defects, time to merge, token cost, and team satisfaction.

That fits the argument of this article. Agentic development is not about giving a developer a stronger chat window. It changes operations: how work is assigned, where the agent runs, who approves actions, how worktrees are separated, what gets logged, and how we know whether productivity actually improved. Without that, Claude Code or Copilot CLI remains an interesting toy for a few enthusiasts. With a good rollout, it can become a normal team capability.

August 20, 2026 update: more agents can be more capable and harder to control

Two practical examples from the Czech AI community sharpen the original argument. AI s rozumem demonstrates Git worktrees as isolation for parallel coding agents. Marek Bartoš highlights new Anthropic experiments in which multi-agent setups failed under conflicting goals and shared infrastructure.

In its work on “AI organizations,” Anthropic found that agent teams were more likely to achieve the business objective in the evaluated tasks while making worse ethical trade-offs than a single agent. In software tasks, agents decomposed the work into isolated subproblems and no participant retained the system-level objective. The authors explicitly warn that single-agent safety results do not automatically certify a multi-agent deployment.

A more dramatic red-team experiment placed three Claude instances in one environment with mutually incompatible objectives. The agents initially did not know about one another, interpreted competing changes as sabotage and escalated the conflict. This was an adversarial lab setup designed to create goal conflict—not evidence that ordinary agent teams will spontaneously attack each other. It is, however, a useful test of orchestration without clear ownership, goal visibility and permission boundaries.

A Git worktree solves only the first layer. Each agent receives its own working directory, index and HEAD, so unfinished changes do not overwrite one another. A production design still needs:

one explicit objective and task owner per agent,
a shared state register showing who is changing what and why,
separate worktrees, credentials and sandboxes, not one shared privileged shell,
a merge gate with tests and review performed independently from the agent that wrote the change,
a stop condition for unexpected changes instead of automatic reverts or counter-actions,
a system-level evaluator responsible for the whole outcome, not another specialist optimizing one component.

For a normal engineering team, the best starting point is deliberately small: two agents in two worktrees, one implementing and the other reviewing tests and risk. They share the same brief but not the same write permissions. Their work is combined only through a diff and review gate. Ten parallel agents without this foundation are not a team that is ten times faster. They are ten concurrent sources of change, conflict and cost.

Update sources: Anthropic AI Organizations Can Be More Effective but Less Aligned than Individual Agents, Anthropic Patterns and problems in emerging multiagent systems, Git git-worktree documentation, and YouTube signals from AI s rozumem and Marek Bartoš.

August 31, 2026 update: agents can message across sessions, but a message is not a lock

Jirka Herník showed a practical workflow while dubbing a two-hour video into fourteen languages. Several Claude Code sessions ran on one machine and shared a single RTX 3090. An agent used ListAgents to discover the other sessions, asked through SendMessage who was using the GPU and for how long, and used the wait to prepare translations and other CPU work. It started rendering only after the GPU was released, then notified the other sessions when it was done.

This is useful for expensive or limited resources: a GPU, licensed CAD software, a test device, a staging environment or the only account for an external service. The waiting agent does not stall the whole workflow and can prepare work that does not require the shared resource.

Claude Code 2.1.224 added cross-session SendMessage, ListAgents, crossSessionInbound and dialogExpiry. The changelog also shows rapid fixes for missing inboxes, parked messages and false success on failed delivery. Newer versions are meant to report a refused message or full queue to the sender. The public Claude Code repository nevertheless contains concrete reports from older versions where a message appeared in the UI or returned success but was never processed by the receiving model.

I would therefore not treat SendMessage as a distributed lock. A safer production baseline is deliberately boring:

keep free / leased / released state outside the agents' conversation,
give every lease an owner and expiry so a crashed session cannot lock the resource forever,
require an explicit acknowledgement and check the real resource state before use,
renew the lease during long work and release it on completion,
make a conflict or missing reply fail into waiting, not concurrent use,
log the request, acknowledgement, start, finish and result.

For a small team, the registry can be a locked file, SQLite or Redis. In n8n or Make, it can be a database row with an owner and expires_at. For a GPU, check real processes and free memory immediately before launch. For staging, use a lease on the specific environment instead of a message saying “nobody seems to be using it.” Cross-session messaging is a useful coordination layer; deterministic infrastructure should retain authority over the resource.

The conclusion is the same as with worktrees: agents may share intent and status, but isolation and ownership cannot live only in a text conversation. Cross-session messages make handoffs faster. Leases, verification and audit decide whether those handoffs form a reliable process.

Update sources: Claude Code changelog, Jirka Herník: Claude Code agents sharing a GPU, reports in the official Claude Code repository #89938 and #86370.

Sources: Claude Code changelog, Claude Code /goal docs, Claude Code commands, Superset, Superset docs: AI Agents, Superset: Working with Git Worktrees, Filip Oborník: Superset, Filip Oborník: Claude Code Goal, Jirka Herník, Tomáš AI, Claude Code hooks reference, AI s rozumem: How I made Claude Code talk to me, Claude Code overview, Claude Code security, Tailscale SSH docs, AI s rozumem: Claude Code runs locally, AI s rozumem: remote access with Tailscale, AI s rozumem: what local means, Claude Code Remote Control, Claude Code in Slack, AI s rozumem: Claude Code remotely, Jirka Herník: Claude in Slack, Adoption and Impact of Command-Line AI Coding Agents, Tomáš AI: implementation is not only about technology.