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 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 and the Agility Knowledgebase MCP.
• 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 and Page Models.
• Hands-on: run the Next.js starter 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).
• 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.
• 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 works well). Publish it, have a verifier prove it with the live key, and time publish to live.
• Read twice: MCP and Agility 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.
• Automation: model-drift checks and instance sync with the Agility CLI in CI, review on every pull request, smoke tests after deploy.
• Across projects: 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.

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.
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
• Managing a Team of Coding Agents
• Running Agility Work from an Ops Repo
• Training guide