# Training Your Team to Build with Agents

> Source: https://agilitycms.com/docs/developers/training-your-team-to-build-with-agents

This is the learning path we use when we train partner and customer development teams on AI-assisted Agility development. Each level teaches the Agility skills for that level **and** the next step in managing agents. Start at the level that fits each person, and have them skim the levels below.

This article is part of the [Vibe Coding with Agility](/docs/developers/vibe-coding-with-agility) section.

## Before anyone starts

Everyone, at every level, needs:

- Node 20 or later, Git, and an editor.
- An AI coding agent (we use Claude Code) connected to the [Agility CMS MCP](/docs/developers/agility-cms-mcp-server) and the [Agility Knowledgebase MCP](/docs/overview/agility-knowledgebase-mcp-server).
- A training instance, and a login with **Editor-level** rights so nobody publishes by accident.

Check the setup with one prompt: *"List the component models in my Agility instance, then search the Agility docs for how ContentZone works."* Both answers must come from tool calls.

## The path

| Level | Who | Agent skill | They leave able to |
| --- | --- | --- | --- |
| 1. New developers | Early-career, or new to headless CMS and Next.js | **One agent as a pair:** brief it, read its work, verify it | Run the starter, explain how a URL becomes a page, make a safe change with an agent |
| 2. New to Agility | Working web developers new to Agility | **A small team:** specialists, skills and a verifier, one feature per session | Model, build, register, publish and prove live a component |
| 3. Experienced | Senior developers and leads | **Running the team:** parallel agents, automation, scheduled jobs | Run a build from brief to handoff with agents, and make the architecture calls |

### Level 1: one agent as a pair

- **Concepts:** content models and items, components, page models and zones, the sitemap, and Staging versus Published. See [Component Models](/docs/developers/component-models) and [Page Models](/docs/developers/page-models).
- **Hands-on:** run the [Next.js starter](/docs/developers/building-sites-with-ai-coding-tools) and follow one URL from the catch-all route, to the page template, to the component registry, to a component.
- **Agent habits:** brief with a goal, constraints and "done when"; make it read the model before it writes; read every diff; run the build. At this level, **agents never publish or delete**.
- **The lesson to land:** `npm run dev` shows Staging content. Working locally proves nothing about what's live.

### Level 2: a small team

- **Concepts:** the data layer and cache tags, the publish webhook, preview, and modeling ([Map Your Design System to Component Models](/docs/developers/design-system-to-component-models)).
- **Agent habits:** an `AGENTS.md` with instance facts; specialists for modeling, building and verifying; a review skill on every pull request. See [Managing a Team of Coding Agents](/docs/developers/managing-a-team-of-coding-agents).
- **Design inputs:** give the agent the best design you have. A Figma file through the Figma MCP works best; screenshots or the client's current site work with more iteration. Review the first component closely before it builds the rest.
- **Lab:** build a component end to end ([the testimonials example](/docs/developers/building-sites-with-ai-coding-tools#step-4-model-a-new-component-end-to-end) works well). Publish it, have a verifier prove it with the live key, and time publish to live.
- **Read twice:** [MCP and Agility Gotchas](/docs/developers/vibe-coding-gotchas).

### Level 3: running the team

- **Parallel work:** models first and alone, then component builders and content loaders in separate worktrees. Never two agents on the same content item.
- **The gaps:** UI-only jobs go to an agent with a browser, inside a scope a person sets. See [Letting Agents Drive the Browser](/docs/developers/letting-agents-drive-the-browser).
- **Automation:** model-drift checks and instance sync with the [Agility CLI](/docs/developers/cli-reference) in CI, review on every pull request, smoke tests after deploy.
- **Across projects:** an [ops repo](/docs/developers/running-agility-work-from-an-ops-repo) and a weekly sweep.
- **Scope:** ask "what can we ship tomorrow?", not "how long will this take?". Cut phase one to fit, ship it, show it, iterate. See [From Proof of Concept to Production](/docs/developers/vibe-coding-to-production).

## Before you hand AI to a client

The question we hear most from agencies: "What stops a client's AI from publishing everything, or deleting a bunch of content?" The answer is the workflow and the roles, not the AI.

1. **Map the real content workflow.** Who writes, who reviews, who publishes? Many instances only have "admin" and "not admin" in practice. That isn't enough once agents are involved.
2. **Set up roles to match.** Agents sign in as a user with Editor-level rights or below. **People stay the final gate on publishing.** See [Governing AI Access to Agility CMS](/docs/owners-admins/governing-ai-access).
3. **Turn on approval workflow** for the containers that matter.
4. **Explain the safety net.** Saving never publishes. Until someone publishes, nothing an agent did is live.
5. **Warn about media.** Uploading an asset makes it available immediately; media has no Staging step the way content does.
6. **Assess regulated clients first.** For finance, healthcare and government, agree in writing which instances, actions and data an agent may touch before anyone connects an MCP server.

## "Content change or code change?"

Clients often ask whether something can be done in Agility or needs a release. An agent connected to the CMS sees the content, but not your code, your architecture, or scripts injected through a tag manager or straight into content. It can answer if the project repo tells it:

- An `AGENTS.md` with instance facts and a short **architecture note**: what renders what, which fields drive which behavior, and what's injected from outside the CMS.
- **Decision records**: a few lines each on why things are the way they are, written by the agent as the work happens.
- For legacy projects with thin documentation, have an agent draft the architecture note from the repo and its history, then correct it.

## Keep the process

When work gets this fast, it's tempting to skip the ticket, the review and the test. Keep all three; agents can do most of the work. Every change goes through a pull request, CI runs the build and tests, and a small process agent can flag what's missing.

## Related

- [Vibe Coding with Agility](/docs/developers/vibe-coding-with-agility)
- [Managing a Team of Coding Agents](/docs/developers/managing-a-team-of-coding-agents)
- [Running Agility Work from an Ops Repo](/docs/developers/running-agility-work-from-an-ops-repo)
- [Training guide](/docs/training-guide)

---

## 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)
- [Managing a Team of Coding Agents](https://agilitycms.com/docs/developers/managing-a-team-of-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)

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