Bound Claude Code Agent Teams

Claude Code agent teams work best when each agent has a bounded job, a declared tool budget, and a review receipt before code lands. Treat Claude Code subagents like temporary teammates, not background magic.

An agent team is a set of specialized agent sessions working on separate parts of one engineering task, then handing evidence back to a human reviewer. In Claude Code, Anthropic's coding agent, that means the team convention matters more than the prompt: who may touch which files, which MCP servers are allowed, which checks prove the work, and where the handoff lives.

This guide is for teams turning Claude agents into a repeatable Claude Code workflow, not a one-off experiment. For the broader convention set, keep this next to the related training topic.

Split the work by ownership, not by vibes

Give each agent a scope that maps to a real repo boundary. In a payments change, one agent can own apps/api/payments/**, another can own apps/web/billing/**, and a third can inspect tests and migrations without editing production code.

This matters because parallel work fails when two agents share the same fuzzy goal. “Improve checkout” is too wide. “Update the payment intent retry path and prove idempotency tests still pass” is reviewable.

The trap is creating too many agents too early. Start with two: one implementation agent and one review agent. Add more only when the repo already has clean seams, such as packages, services, or worktrees.

Route every agent through one slash command

Use a slash command as the launch point for Claude Code agent teams. The command should collect the ticket, affected paths, allowed MCP servers, expected checks, and handoff location before any agent starts editing.

For example, a repo might use /agent-team/payments-change for changes that touch payment code. The command asks for a Jira ticket, creates a branch naming convention, starts an implementation subagent, and reserves a review subagent for evidence gathering.

This keeps the workflow teachable in a Claude Code training session. The command becomes the team’s front door, while CLAUDE.md stays small and durable: repo rules, architecture constraints, and escalation rules only.

The trap is hiding policy inside a long prompt. If the rule must survive the current chat, put it in the command, hook, permission setting, skill, or repository memory where the team can review it.

Give MCP tools a job description

MCP is the integration layer that lets Claude Code connect to external systems such as GitHub, Slack, issue trackers, document stores, databases, and private knowledge bases. For agent teams, MCP access should be narrower than a human’s access, not broader.

A useful pattern is read-first permissions. Let an implementation agent read GitHub issues and docs, but block production database writes. Let a review agent read CI and pull request metadata, but avoid write access unless the review command explicitly needs it.

Here is the kind of MCP permission note that belongs in the slash-command workflow or team runbook:

The trap is granting one “agent team” identity access to everything. Shared credentials make debugging and auditing worse. If your enterprise setup supports managed MCP configuration, use that to make the safe path the default.

Require a handoff before review

Do not review an agent team by replaying the whole chat. Ask for a short handoff receipt that says what changed, what was not touched, what evidence was collected, and where the reviewer should look first.

This is where hooks help. A pre-commit or pre-tool hook can remind the agent when it crosses a boundary, while a stop hook can require the handoff receipt before the session ends. Keep hooks boring: they should enforce the shape of the work, not become a second policy engine.

The trap is accepting “looks good” as evidence. A reviewer needs file paths, commands, failing checks, skipped checks, and open risks. That is true whether the work came from one Claude session or several claude code agent teams running in parallel.

Paste this operating checklist

Use this as the first convention. It is intentionally small. Put it next to the slash command or team runbook, then link to it from your Claude Code workshop materials.

# Agent Team Operating Checklist

Use this checklist before starting a multi-agent Claude Code task.

## Task shape
- [ ] One ticket or issue is named.
- [ ] The owner states the user-facing change in one sentence.
- [ ] The work is split by repo boundary, package, service, or worktree.
- [ ] No two agents own the same editable path.

## Agent roster
- [ ] Implementer scope: ______________________________
- [ ] Reviewer scope: _________________________________
- [ ] Researcher or test-only scope, if needed: _________
- [ ] Each agent has a stop condition.

## Tool boundaries
- [ ] MCP servers are listed by agent role.
- [ ] Write access is granted only to the implementer.
- [ ] Production data access is blocked unless explicitly approved.
- [ ] External tickets, docs, and CI are read-only for reviewer agents.

## Repo rules
- [ ] CLAUDE.md has only durable repo rules, not task prompts.
- [ ] Any Claude skill used by the team is named here: _________
- [ ] The slash command used to launch the workflow is: _________

## Review evidence
- [ ] Changed paths are listed.
- [ ] Commands run are listed with pass/fail status.
- [ ] Skipped checks are explained.
- [ ] Risks and follow-up work are named.
- [ ] A human reviewer signs off before merge.

Adoption should be lightweight. One engineer proposes the checklist in a pull request, one maintainer reviews the repo boundaries, and one security-minded reviewer checks the MCP permissions. Store it where the workflow lives: a slash-command folder, an internal runbook, or the repo’s team conventions docs.

The enforcement rule is simple: no handoff receipt, no merge. If that feels heavy, apply it only to multi-agent changes or code that touches money, auth, privacy, deployments, or data migrations.

For a team rollout plan around this kind of convention, see Adopt Claude Code as a Team.

Best ways to use this research

• Best for: Claude Code teams that want agent teams without losing ownership boundaries.
• Best first artifact: The agent team operating checklist above, especially the tool boundary and review evidence blocks.
• Best comparison angle: Compare one implementer plus one reviewer agent against a single unbounded agent, then keep the version that leaves clearer evidence.

Common questions

• How should we use agent teams in Claude Code?

  Use agent teams in Claude Code for work that has clean boundaries: separate packages, services, worktrees, or review roles. A good starter shape is two agents: one implements and one reviews evidence. Avoid splitting a small bug fix into five agents; coordination cost will erase the benefit.

• Are Claude Code subagents the same as human code owners?

  No. Claude Code subagents are task-scoped workers, while human code owners remain accountable for the merge. Use code ownership to set agent boundaries, but keep approval human. The review receipt should name the human reviewer, changed paths, commands run, and skipped checks.

• Where do CLAUDE.md, skills, and slash commands fit?

  Use CLAUDE.md for durable repository memory, skills for reusable capabilities, and slash commands for repeatable workflows. For this convention, the slash command launches the agent team, a Claude skill can package domain knowledge, and CLAUDE.md should stay concise so it does not become a task script.

• Do we need the Claude Code Agent SDK for this?

  Not at first. The Claude Code Agent SDK is useful when you are building custom automation around agents, but a team convention can start with subagents, permissions, hooks, and a slash command. Reach for the SDK after the manual workflow is stable enough to encode.

• What is the biggest risk with Claude agents and MCP?

  The biggest risk is over-broad tool access. A reviewer agent rarely needs write access, and a researcher agent usually needs only read access to docs and issues. Write down the MCP permission table before running the workflow, especially in Claude Code enterprise environments.

Further reading

• Claude Code - getting started
• Claude Code - skills
• Claude Code - hooks
• Claude Code - permissions
• Model Context Protocol - specification
• Anthropic - Claude Code product page
• GitHub - anthropics/skills

Start with one bounded run

Pick one real ticket with two clean repo boundaries, run the checklist, and keep the handoff receipt in the pull request. After one week, delete any rule nobody used and promote the one that made review easier.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.