I've been tinkering with a personal project — a CMS migration from Sitecore to AEM. Dozens of page templates, hundreds of components, a live site that the result needs to match exactly.

My setup was solid: a single Claude Code session with my starter prompt, a set of .md files tracking decisions and progress. Claude remembered everything across sessions. No context rot.

But every time Claude finished a component — a hero banner, a navigation tree, a content card — I'd pull up the original Sitecore site and start comparing. Does the spacing match? Did we miss the mobile breakpoint? Are the AEM dialog fields capturing everything the Sitecore component exposed?

I was spending more time validating than building. And I was becoming the bottleneck.

The job I didn't sign up for

In a single-agent setup, the AI does the implementation and the human does everything else: reviewing output, catching regressions, comparing against requirements. For this migration, that meant Claude writes AEM components, I compare them to the Sitecore original. Claude was fast. I was the slow part.

And every time I found a discrepancy and asked Claude to fix it, that correction round-trip polluted its context. Implementation conversations tangled with validation concerns. Both got worse.

That's when I realized I was doing the validator's job. Not because I wanted to, but because there was no validator.

Enter agent teams

Claude Code's experimental agent teams feature lets you spawn specialized sub-agents from a lead session, each with their own context and file permissions. I redesigned the starter prompt around three roles:

The Lead never writes code. It maintains the project files, coordinates work, and triages issues. Separating coordination from implementation keeps its context clean — not drowning in HTL template syntax while tracking project-level progress.

The Builder owns all code files — HTL templates, Sling Models, clientlibs, Maven configuration. It gets atomic tasks: "implement the Hero Banner component per MIGRATION-MAP.md." Focused context, focused output.

The Validator has read-only code access. Its job is what I was doing manually: compare the Builder's output against the original Sitecore site, check visual fidelity, content mapping completeness, responsive behavior. Findings go into VALIDATION.md with severity ratings. Critical issues go straight to the Builder.

The key addition: MIGRATION-MAP.md, a structured component-by-component mapping that both agents reference as their work queue. The Lead updates it as components move from planned to built to validated.

What actually changed

The obvious win is parallel work. The Validator checks the last component while the Builder works on the next. No more serialized bottleneck with me in the middle.

But the real change is in my role. The Lead now asks me things like "the Validator found 12 discrepancies on the product listing page — 3 critical, 9 minor. The critical ones are content mapping gaps. Should the Builder fix all of them before moving to the next template?" That's a stakeholder question. In the single-agent setup, there was no validator generating those findings — I was doing that myself.

I went from pixel-comparing CSS spacing to making prioritization calls. From validator to stakeholder.

What it doesn't solve

The Validator catches structural and content issues well but struggles with subtle visual fidelity — things like "this padding feels different" that need human judgment. And coordination overhead is real: the Lead occasionally assigns work that conflicts with what the Builder is mid-way through. These are new problems. But they're better problems than being the bottleneck on every component.

The deeper implications — how this changes the context management architecture, and what it means for token costs — are topics for follow-up posts. For now, the practical takeaway is simpler: if you're spending more time reviewing AI output than doing your actual job, you might be doing work that should belong to another agent.