A dev team of agents, each in its own git worktree
One AI assistant doing everything has a familiar failure mode: it jumps between the database, the API and the UI in the same context, and by the time it gets to the tests it has forgotten half of what it decided an hour ago. I wanted something closer to how a real team works, so I built an open-source Claude Code plugin that does exactly that: AI Development Team.
The team
You type one command:
/delegate Add user auth with OAuth
and the work flows through six agents, each a Markdown file with its own instructions, tools and limits:
| Agent | Job | Isolation |
|---|---|---|
| user-proxy | Turns the request into clear requirements. Read-only. | plan mode |
| project-manager | Splits the work into tasks and coordinates. | standard |
| backend-developer | APIs and business logic | own worktree |
| database-engineer | Schema, migrations, queries | own worktree |
| frontend-developer | UI, accessibility | own worktree |
| qa-engineer | Tests | own worktree |
Decision 1: isolation beats coordination
The first version had agents writing to the same checkout. They overwrote each other's files and broke each other's builds. The fix was not smarter coordination, it was less sharing: every specialist runs in its own git worktree, with its own branch and working directory. Parallel work stops being a race condition, and merging becomes an explicit, reviewable step with small helper scripts for committing and merging agent branches.
Decision 2: results go up, not sideways
Agents don't message each other or poll files. A subagent finishes and returns its result to its parent; the project manager aggregates and reports back. That keeps the flow easy to follow and easy to debug.
Decision 3: shared knowledge lives in files
What the agents do share is domain knowledge. Each project has a communication/domains/ folder with business rules, schema decisions and API contracts, and every agent reads it before implementing. When the database agent decides a column name, the frontend agent doesn't have to guess.
Decision 4: limits are part of the design
Each agent declares its tools and a maximum number of turns in its frontmatter:
tools: [Read, Write, Edit, Bash]
isolation: worktree
maxTurns: 30
The requirements agent can't write code. Specialists can't run forever. A hook logs every time a subagent finishes, so there's a trail of what ran.
Packaging it as a plugin
It started as a template repo, which meant copying agents into every project and updating them by hand. Now it's a plugin: agents, skills and hooks come from the plugin, and a project only keeps what is specific to it (CLAUDE.md, the PRD and the domain docs). Update the plugin once and every project gets the new agents.
What I learned
Most of the value came from boring constraints: separate working directories, one direction for results, written contracts, and a cap on how long anything runs. The same things that make a human team work.