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

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.

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.

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.