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 section. If you haven't set up an agent with Agility yet, start with Building an Agility Site 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	Reads and writes models, containers, content, pages and media; runs workflow; publishes at the level you allow
Agility Knowledgebase MCP	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
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	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
.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
.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:

---
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:

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)
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

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). 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
• Running Agility Work from an Ops Repo
• Training Your Team to Build with Agents
• Governing AI Access to Agility CMS