Claude Code Projects and the rush toward agent teams expose the real bottleneck: coordination. Here is how to run AI agents without creating expensive chaos.

The conversation around AI coding agents has moved on from the single assistant in your editor. This week, the discussion is about agent teams: several agents working on the same outcome, with different roles, shared context and some form of coordination.

That shift is visible in the tools and in the chatter around them. The Verge's AI coverage this week highlighted Projects that let users control a team of Claude Code agents which coordinate with one another. On Hacker News, a September “What are you working on?” thread is full of tools for agent-readable code libraries, sandboxed coding agents and workflows that treat agents as contributors rather than autocomplete. And a September 15 post on X about running several agent harnesses at once drew more than 10,000 views.

The tempting interpretation is that the next productivity leap comes from simply adding agents. It does not. A group of agents without an operating model is not a team. It is parallelized ambiguity: duplicated work, conflicting changes, invented assumptions and a human manager left to reconcile the damage.

The useful question is no longer “which agent writes the best code?” It is: what is the smallest system that lets multiple agents make progress without losing accountability?

More agents multiply coordination costs

A single capable coding agent has a simple shape. Give it a bounded task, relevant files, commands it may run and an acceptance criterion. Inspect the diff. Merge or reject it.

Add a second agent and the hard problems arrive immediately. Which agent owns an interface? Can both change the schema? Where does a decision get recorded? What happens when one agent's implementation invalidates the other agent's assumptions? If an agent is blocked, does it stop, retry, broaden its scope or ask for help?

Humans have accumulated conventions for this over decades: tickets, pull requests, code owners, architecture notes, stand-ups and incident reviews. These are not bureaucracy for its own sake. They are coordination technology. Agent teams need their lighter-weight equivalents.

The practical consequence: do not scale agent count before you can inspect agent work cheaply. If review is already the bottleneck with one agent, a swarm will only produce a larger review queue.

Start with roles, not personalities

“Researcher,” “builder,” “reviewer” and “tester” are useful agent roles because they define outputs. “Senior engineer,” “creative thinker” and “autonomous teammate” are not. They sound productive while leaving the actual contract undefined.

A workable agent role has four parts:

  1. A bounded responsibility. One agent maps the affected code and writes a plan; another implements a named module; another runs tests and looks for regressions. No role owns “make the product better.”
  2. Inputs with provenance. Give the agent repository paths, issue links, API contracts and the current decision record. Do not expect it to reconstruct critical context from a vague prompt.
  3. Explicit authority. State whether it can edit code, create a branch, run migrations, access the network or merely report findings. Permissions should be narrower than the role description.
  4. A verifiable output. A plan, a diff, a test result, a list of unresolved questions. “Done” is not an output.

Give one agent ownership of integration

Parallel implementation creates a shared-resource problem. Somebody has to own the boundary between pieces. In a small workflow, that somebody should be a human. In a larger one, designate an integration agent — but keep the final merge decision with a human until you have strong evidence that the workflow is safe.

The integration owner should not be measured by lines changed or tasks completed. Its job is to identify collisions: incompatible types, overlapping file edits, contradictory assumptions, missing tests and changes that quietly expand the original scope.

Shared context is a product, not a prompt

Most multi-agent failures are described as model failures: an agent “forgot” something, misunderstood a requirement or took the wrong path. Often the underlying problem is that the required information was nowhere durable to be found.

Treat shared context as a maintained product with a small, legible surface area. For a software project, that can be:

  • a concise PROJECT.md explaining architecture, local commands and non-negotiable constraints;
  • an ADR directory for decisions that should not be reopened by every task;
  • issue templates that define acceptance tests and out-of-scope work;
  • a machine-readable task board or status file; and
  • a short handoff format: changed files, commands run, evidence, risks and open questions.

The key is that agents should read the same source of truth rather than pass increasingly distorted summaries between one another. Long conversational handoffs are particularly fragile. Each compression can erase a caveat or turn an unverified assumption into a fact.

Use a control plane, not a group chat

A minimal control plane needs only a few things:

Task states

Every task should have a state such as proposed, planned, in progress, blocked, ready for review, accepted or rejected. Agents should not silently promote their own work from “implemented” to “accepted.”

Immutable evidence

Keep the diff, command output, test results, relevant prompts or task instructions, and the identity of the model/tool version. You do not need to log every token. You do need enough evidence to reproduce a consequential decision.

Hard boundaries outside the model

An agent prompt is not an access-control mechanism. Use separate credentials, branch protections, scoped tokens, sandboxed execution, allowlisted commands and budget limits. The recent Hacker News interest in sandboxed agents is a healthy sign: teams are recognizing that a model's stated intention is not a security boundary.

Escalation by design

Specify when agents must stop: an ambiguous requirement, a production credential, a schema migration, a failing test they cannot explain, a request to broaden permissions, or a conflict with an architecture decision. Escalation is not an agent failure. It is a successful refusal to improvise past authority.

Measure outcomes, not agent activity

Agent teams make it dangerously easy to optimize the wrong metric. Number of tasks completed, tokens consumed, agent hours and pull requests opened all look productive. None tells you whether the team shipped a correct, maintainable result.

Track cycle time from approved task to accepted change; review time per accepted change; regression rate; rollback rate; and the share of tasks that needed human rework. Compare those against your previous workflow. If adding three agents doubles throughput but triples review and rework, you have not gained capacity.

Also track cost at the workflow level. A cheap model that loops for hours, calls tools unnecessarily or produces a hard-to-review patch is not cheap. The relevant unit is cost per accepted outcome.

The next advantage is operational discipline

The excitement around agent teams is justified. Parallel agents can research, implement, test and document work that a single person would otherwise serialize. But the advantage will not go to the company with the largest swarm. It will go to the one that turns agent activity into reliable, reviewable work.

Start small: one planner, one implementer, one reviewer; a written handoff; protected boundaries; and a human responsible for integration. Add autonomy only where your evidence says the system deserves it.

AI agent teams are becoming a real software primitive. They still need the things every effective team needs: clear ownership, shared facts, limits on authority and a way to tell the difference between motion and progress.

Sources