We Don't Build the Website — What CMS Development Taught Me About Designing Agent Teams

The Penny Drop

I've been a CMS developer for the majority of my career. Sitecore, specifically. And if you've spent any time in that world, you've heard the line — probably from me — that we don't build the website. We build the components. We build the configuration. We build the experience that lets the content author build the website.

If you've worked around me, it's something you have probably heard my say before. It's one of those truths that sounds obvious once you hear it, and then shapes how you think about everything.

Tonight, deep into planning the third rebuild of my own Agent Management Studio, that same truth hit me from a direction I wasn't expecting.

Here's the irony. I literally just wrote a post about Sub-Agents vs Personas vs Skills — mapping agent patterns to OOP concepts, explaining how skills are like enterprise helper classes, how sub-agents are like separate classes with single responsibilities. I understood the technology. I could diagram it, explain it, write code examples for it.

But understanding the technology and understanding what it means for design are two completely different things. The penny didn't drop until I was deep in the planning for my third engine rebuild, wondering why my agents kept drifting, why token costs were climbing, and why something felt architecturally wrong despite following the patterns I'd just written about.

The answer was sitting in my own career experience the whole time.

What CMS Developers Actually Build

If you're not from the CMS world, here's the quick version.

In Sitecore, when a client says "build me a homepage," I don't open a blank page and start typing headlines. Instead, I think about the content author. What do they need to see in the page editor? What fields make sense to them — heading text, background image, CTA button label, CTA link URL? How should the component preview so they can trust what they're building? Where should the guardrails sit so they can move fast without breaking brand standards?

I build a Hero Banner component, but the component isn't the point. The point is the experience the content author has when they use it. A marketer who's never touched code opens the page editor, drags the Hero Banner onto the homepage, types "Spring Sale — 40% Off Everything," picks a lifestyle image from the media library, sets the CTA to /shop/sale, and hits publish. That workflow should feel effortless. That's what I'm actually designing.

They built the homepage. I tailored the experience that made it possible.

This distinction runs deeper than it sounds. The end user — the person who visits the website — matters, of course. The text needs to render at the right size, the image needs to load at the right resolution, the button needs to navigate correctly. But the end user is a step removed from me. I build in capabilities and gates to ensure their requirements are met, but my primary design surface is the content author's workflow. How efficient is their process? How intuitive are the configuration points? How hard is it for them to make a mistake?

You could have twenty different homepages built from the same components. Different headlines, different images, different layouts. The components don't change. The authoring experience doesn't change. Only the content does. That's the whole point.

The Same Pattern, Different Domain

The Agent Management Studio I've been planning doesn't build applications. It shapes the working experience of the agents — the specialist knowledge they carry, the cognitive posture they adopt, the quality standards they're held to, and the skills they can pick up on demand. It designs the workflow they move through: human gates, resolver chains, verification phases. Everything is oriented around one question: what does the orchestrator need to work effectively?

Then the agents go and build the application.

Read that again. The studio is to the agents what Sitecore is to the content author. One layer tailors the experience. The next layer does the work.

When a content author drags a Hero Banner onto a page, they don't think about the React component behind it. They think about headlines and images. When an agent picks up a work item, it doesn't think about how its context was assembled. It thinks about the brief, the acceptance criteria, and the code.

The developer's job — my job — was never to build the page. It was to make the content author's working experience so well-designed that they could build confidently and efficiently. The agent designer's job is the same: make the capability surface — skills, workflows, constraints — so well-designed that the orchestrator can deploy agents effectively without micromanaging every interaction.

Where I Went Wrong: Skills Baked Into Agents

This is the part where I have to be honest about what I built.

My sub-agents are powerful. They're full of context. I built them that way on purpose. Each one can research a codebase, verify against acceptance criteria, commit code to a repository, and work items off a Jira board. They are capable agents.

But those capabilities are baked in. Each agent carries its skills in its own specialist context, permanently loaded, always present.

Think of it like building a Sitecore component where the Hero Banner also contains the image optimisation logic, the analytics tracking script, the A/B testing engine, and the caching strategy. All embedded in one rendering. It works. It's powerful. But the moment you need image optimisation in the Card component too, you duplicate the logic. When the caching strategy needs to change, you change it in every component that embedded it. And every component is now heavier than it needs to be, even when it's not using half of what it carries.

That's exactly what my agents looked like. frontend-dev knew how to commit code. content-writer also knew how to commit code. Both carried that knowledge in their specialist context, permanently loaded whether they needed it or not. The same logic, duplicated across agents. Different phrasings of the same instructions, slowly drifting apart as each agent's context evolved independently.

Duplication. Drift risk. Token cost. The same problems I'd solve in a Sitecore project without thinking twice.

The Right Way: Composable Skills

In a mature Sitecore build, you don't embed image optimisation in every component. You extract it into a shared rendering extension — a pipeline processor that runs on every image request regardless of which component produced it. You extract caching into its own processor. You extract analytics into a page-level wrapper. Components stay focused on what they render. Shared concerns live in shared infrastructure.

The agent equivalent is composable skills.

Extract "commit code" into a skill file. Extract "search Jira backlog" into a skill. Extract "run verification against acceptance criteria" into a skill. Each skill is defined once, tested once, maintained in one place.

The agent keeps its ability — domain expertise, specialist knowledge, quality standards. That's what makes a frontend-dev different from a security-audit. But skills are loaded on demand, like Neo downloading kung fu in The Matrix. The agent doesn't permanently carry every capability it might ever need. It picks up the skill when the current task requires it, and it drops it when the task is done.

BEFORE: Agent = Specialist Knowledge + Embedded Skills (bloated, duplicated)
AFTER:  Agent = Specialist Knowledge + Ability to invoke Skills (lean, composable)

The impact is significant across three dimensions:

Less drift. A skill is defined once and used by every agent that needs it. When you update the "commit code" skill, every agent gets the update. No more divergence between how frontend-dev commits and how content-writer commits.

Fewer hallucinations. Agents carry less permanent context, so there's less noise competing for attention during any given task. A frontend-dev working on a React component doesn't need Jira integration instructions cluttering its context window. It loads the Jira skill only when the workflow reaches the point where it needs to interact with the board.

Lower token costs. Skills load only when needed, not on every invocation. If a work item doesn't touch the backlog, no agent pays the token cost of carrying backlog instructions. Context stays lean and relevant to the task at hand.

Thinking about skills this way also changes how you see parallelism. When skills are independent, well-separated units — proper OO boundaries rather than tangled embedded logic — the orchestrator can swarm. Multiple agents can pick up different skills and run concurrently without stepping on each other. That's not a feature you build. It's a property that emerges from designing the capability surface correctly.

Hooks: The Workflow Gates

Skills define what agents can do. But there's a second design surface that's just as important: where the workflow pauses and checks.

In Sitecore, this is workflow approval states. A content author writes a page, but it doesn't go live immediately. It moves through Draft → Awaiting Approval → Published. An editor reviews it. A compliance check runs. The workflow gates exist because even well-designed components can be assembled incorrectly — wrong tone, outdated pricing, broken links. The gates catch what the components can't prevent.

Agent workflows need the same thing. In my delivery engine, these are hooks — human gates and verification phases that pause execution at critical transitions. After the brief is written, a human reviews it before planning begins. After the plan is approved, execution proceeds. After execution completes, a verification phase checks the output against acceptance criteria before anything is marked done.

Skills are what agents can do. Hooks are when the workflow stops and asks whether they should. And the design insight is the same: you're not designing what the agent produces. You're designing the transitions between phases. Where does the workflow pause? What gets checked? Who has authority to approve? These questions matter more than any individual agent's capability, because a brilliant agent with no workflow gates is just a faster way to ship mistakes.

The Real Lesson

I literally wrote a post last week mapping agent patterns to OOP concepts. I could diagram skills, explain sub-agents, describe composable architectures. I understood the technology.

But understanding a technology and understanding what it means for how you design — those are different skills entirely. The first is knowledge. The second is recognition. Knowledge says "composable skills exist and here's how they work." Recognition says "wait — that's the same problem I solved in Sitecore ten years ago, and I've been ignoring my own solution."

The gap isn't technical. It's the distance between knowing a pattern exists and seeing where it applies in your own work. I had all the pieces. I'd written about them. I just hadn't connected them to the thing I was actually planning.

That's the real lesson of CMS development, and it transfers directly to agent design: you're never building the thing. You're designing the experience for the thing that builds the thing. In Sitecore, I think from the content author's perspective — what do they need, how do they work, what makes them efficient? For agents, the question is the same: what does the orchestrator need? What capabilities should be available? What workflow makes it effective? The moment I stopped thinking about assembling a team and started thinking about designing the capability surface, everything clicked.

Years of Sitecore taught me that. Three planned rebuilds of an agent engine made me finally hear it.