# Managing a Team of Coding Agents

> Source: https://agilitycms.com/docs/developers/managing-a-team-of-coding-agents

The biggest change AI brings to building Agility sites isn't that code gets written faster. It's that **every developer becomes the manager of a team of agents**. You set the goal, give the agents context and tools, split the work, review what comes back and verify it. The agents do most of the typing: modeling, scaffolding, loading content, checking and writing the docs.

The skills that matter are the ones a good tech lead has always needed: writing a clear brief, cutting work into independent pieces, reviewing fast, and verifying before you trust anything.

This article is part of the [Vibe Coding with Agility](/docs/developers/vibe-coding-with-agility) section. If you haven't set up an agent with Agility yet, start with [Building an Agility Site with AI Coding Tools](/docs/developers/building-sites-with-ai-coding-tools).

## The toolkit

### MCP servers: the agent's hands

An MCP server gives the agent tools for one system. Without them your agent is guessing; with them it's looking.

| Server | What the agent does with it |
| --- | --- |
| [Agility CMS MCP](/docs/developers/agility-cms-mcp-server) | Reads and writes models, containers, content, pages and media; runs workflow; publishes at the level you allow |
| [Agility Knowledgebase MCP](/docs/overview/agility-knowledgebase-mcp-server) | Searches and reads these docs, so the agent cites instead of guessing |
| Next.js DevTools MCP | Reads the running dev server: routes, errors, build state |
| Hosting (for example Vercel) | Deployments, build and runtime logs, environment variables, domains |
| A browser MCP (Claude in Chrome, Chrome DevTools, Playwright) | Checks the live site, preview and Web Studio, and drives web UIs no other server covers. See [Letting Agents Drive the Browser](/docs/developers/letting-agents-drive-the-browser) |
| GitHub | Repos, pull requests, reviews |
| Design (for example Figma) | Reads real tokens, spacing and components so the agent builds from the design |
| Analytics, tickets and your CRM | Experiments and insights; issues and plans; project notes on the deal |

Commit the shared server list to the repo (`.mcp.json` for Claude Code, `.vscode/mcp.json` for VS Code) with **URLs only, never keys**. OAuth servers ask each person to sign in, and the Agility CMS MCP acts only with that person's permissions.

### CLIs: the agent drives these too

An agent is as good at a CLI as you are, and it doesn't forget the flags.

| CLI | Use |
| --- | --- |
| [Agility CLI](/docs/developers/cli-reference) | `agility pull` an instance to JSON (types, diffs, model-drift checks in CI); `agility sync` models and content between instances, then `agility verify`; `agility workflows` for bulk publish or approval |
| `gh` | Create repos, open and review pull requests |
| Hosting CLI (`vercel`, `az`) | Link projects, pull environment variables, deploy, read logs |
| `curl` + `jq` | Prove a publish reached the Fetch API with the live key |

Pin CLI versions in CI (for example `@agility/cli@1.2.1`) so a release can't change behavior under an unattended agent.

## From one agent to a team of specialists

A general agent with good context is useful. A team of specialists, each with a narrow brief and only the tools it needs, is faster and makes fewer mistakes. You build the team from files in the repo:

| File | Role |
| --- | --- |
| `AGENTS.md` | The team handbook: conventions, MCP rules and instance facts. See [Writing an AGENTS.md for Agility Projects](/docs/developers/agents-md-for-agility) |
| `.claude/agents/<name>.md` | Subagents: specialists with their own instructions and tool list |
| `.claude/skills/<name>/SKILL.md` | Skills: step-by-step procedures for jobs you repeat. See [Agility Skills for Your Coding Agent](/docs/developers/agility-skills-for-coding-agents) |
| `.claude/settings.json` | Which tools run without asking, and hooks that run automatically |

A good starting team for an Agility build:

| Specialist | Brief |
| --- | --- |
| **Modeler** | List existing models first. Create or extend models from the requirement. Read every save back and use the real field names |
| **Component builder** | One component per session, from the real model, following the starter's patterns. Register it. The build must pass |
| **Content loader** | Null release and pull dates, small publish batches, content provenance recorded. Never publishes |
| **Verifier** | Checks published content with the Fetch API live key, opens pages in a browser, checks preview and Web Studio. Never writes |
| **Reviewer** | Reviews every pull request against your Agility conventions |

A verifier subagent is short:

```markdown
---
name: verifier
description: Proves that Agility content is really live. Use after any publish.
tools: Bash, Read, mcp__Agility-CMS__get_content_item, mcp__Agility-CMS__get_page
---
You verify; you never write or publish.
For each content ID you're given:
1. Call the Fetch API with the live key and confirm the item and its fields.
2. Open the page URL in a fresh browser session and confirm each component renders.
Report a table: ID, expected, found, pass/fail. "The tool returned 200" is not a pass.
```

Start with a few. Add a specialist when you notice yourself giving the same instructions twice.

## Running agents in parallel

The big win comes from running several agents **at the same time on independent work**.

1. **Model first, alone.** Everything depends on the models, so one agent creates them and you review them.
2. **Then fan out.** Component builders, a content loader and a brand agent can run in parallel because they touch different files and different content.
3. **One Git worktree and branch per agent**, so they don't overwrite each other's files:

```bash
git worktree add ../site-hero -b feat/hero
git worktree add ../site-faq  -b feat/faq
```

4. **Never let two agents write the same content item.** Saves replace the whole item, so the second save silently wipes the first. Give each agent its own containers or pages.
5. **Verify and review.** The verifier checks the published result; the reviewer checks every pull request; you merge.

## Automate what you do on every project

| Job | How |
| --- | --- |
| Pull request review | A review skill, or your agent in CI on every pull request |
| Model drift | `agility pull` models in CI and diff against the committed JSON ([CI/CD guide](/docs/developers/cli-ci-cd-integration-guide)) |
| Sandbox to production | `agility sync` from CI with a committed mappings file, then `agility verify` |
| Smoke test after deploy | A headless agent run with a browser MCP: open key pages and report what didn't render |
| Portfolio status | A scheduled run in your [ops repo](/docs/developers/running-agility-work-from-an-ops-repo) |

## Habits of a good agent manager

1. **Brief like a manager.** Goal, constraints, what done means, and what not to touch.
2. **Read before write.** Every brief starts with "list what exists first". Near-duplicate models are the most common agent mess.
3. **Small, reviewable units.** One feature per session, one pull request per feature.
4. **Verify, don't trust.** Agents report success on calls that did nothing (see [MCP and Agility Gotchas](/docs/developers/vibe-coding-gotchas)). Check the outcome, not the tool's reply.
5. **Capture lessons as files.** When an agent gets something wrong, add the rule to `AGENTS.md` or a skill, and every agent stops making that mistake.
6. **Keep people on judgment calls:** content architecture, scope, anything customer-facing, publishing to production, and what an agent may do in a browser.
7. **Don't let the process get loose.** Fast work tempts you to skip the ticket, the review and the test. Keep all three; agents can do most of the work. A small process agent that checks "every pull request has a test, every ticket has acceptance criteria" helps.

## Related

- [Letting Agents Drive the Browser](/docs/developers/letting-agents-drive-the-browser)
- [Running Agility Work from an Ops Repo](/docs/developers/running-agility-work-from-an-ops-repo)
- [Training Your Team to Build with Agents](/docs/developers/training-your-team-to-build-with-agents)
- [Governing AI Access to Agility CMS](/docs/owners-admins/governing-ai-access)

---

## Related pages

- [Building an Agility Site with AI Coding Tools](https://agilitycms.com/docs/developers/building-sites-with-ai-coding-tools.md)
- [Vibe Coding with Agility](https://agilitycms.com/docs/developers/vibe-coding-with-agility.md)
- [From Brief to Working Site: The Vibe Coding Workflow](https://agilitycms.com/docs/developers/vibe-coding-workflow.md)
- [Writing an AGENTS.md for Agility Projects](https://agilitycms.com/docs/developers/agents-md-for-agility.md)
- [MCP and Agility Gotchas to Know Before You Build](https://agilitycms.com/docs/developers/vibe-coding-gotchas.md)
- [Vibe Coding Playbooks by Use Case](https://agilitycms.com/docs/developers/vibe-coding-playbooks.md)
- [From Proof of Concept to Production](https://agilitycms.com/docs/developers/vibe-coding-to-production.md)
- [Agility Skills for Your Coding Agent](https://agilitycms.com/docs/developers/agility-skills-for-coding-agents.md)
- [Letting Agents Drive the Browser](https://agilitycms.com/docs/developers/letting-agents-drive-the-browser.md)
- [Running Agility Work from an Ops Repo](https://agilitycms.com/docs/developers/running-agility-work-from-an-ops-repo.md)
- [Training Your Team to Build with Agents](https://agilitycms.com/docs/developers/training-your-team-to-build-with-agents.md)

Index of every docs page: https://agilitycms.com/docs/llms.txt