My Journey Towards Agentic Orchestration

Welcome back to another blog post — and yes, this one is different. For the last few months I've been running every Sitecore Marketplace experiment of mine through a single workspace. The pattern I came to call agentic orchestration: not a sequence of one-off prompts, but a small organisation of AI agents with their own roles, their own contracts, and their own way of handing work between each other. Four production apps shipped. A handful of methodologies crystallised. A bunch of assumptions I started with turned out to be wrong.

This is the honest version of that story. Not a silver-bullet pitch, not a "ten-x your output with AI" listicle — just what I built, what broke, and what I'd carry into the next thing.

AI agents only become productive when you treat them as an organisation, not as a prompt.

If you take one idea away from this post, that's the one. Let me walk you through what it actually looks like when you try.

Where this started

For about a year I was doing what most people do with AI in the IDE: long prompts in chat, the occasional Cursor command, lots of copy-paste between projects. Great for ten-minute tasks. Useless for anything that spanned a week.

The problems were always the same three. The agent was loading too much context — the full brief, my exploratory notes, three Slack threads — and quality was dropping, not climbing. Every project re-invented its own prompts. Lessons from one project never made it into the next until something broke twice. And there was no separation between who was talking and what they were doing — "architect" was a personality I summoned with a prompt, not a role I could hand a different task to.

What I wanted was a workspace where the same set of well-defined agents could be re-invoked with different commands; where each command came with its own input and output contracts; and where the things I learned the hard way on one product would survive into the next without me having to remember them.

The single most important decision turned out to be the simplest. Agent identities describe persona and expertise only. No task instructions, no output formats — just "you are an architect, you reason in consequences, you cite tradeoffs." The actual task is injected by a command at runtime, with a strict input/output contract. Same architect, different jobs, no copy-pasted prompts drifting apart over six months.

Once that separation clicked, everything else fell into place.

What it actually looks like

The workspace runs two parallel pipeline tracks. They share the same agent set — eleven agents in total, with a team lead orchestrating and a source analyst I bring in only when rebuilding an existing product. The rest of this post focuses on one of the two tracks; the other one is worth naming up front so the agent count makes sense.

Research and audits

The first track runs vendor-neutral technology scans, competitor intelligence, and product-management audits of Sitecore reference repos like SitecoreAI Starter and Content SDK. Same agents, different inputs, different outputs — each run produces a merged report rather than shipped code. Useful when I'm comparing platforms or auditing what a customer already runs, but not the focus of this post.

Project development

This is where most of my time goes, and what the rest of this post is actually about. An idea moves through a pipeline of agents, each handing work to the next via a strict input/output contract — three stages, nine commands, one continuous flow:

Two surprises about that pipeline. The first is that nothing forces it to run end-to-end. There's a freeform mode where I describe what I want in plain English and skip the planning entirely — handy for a quick experiment. The same review and test passes still apply. The second is that the most important commands aren't the obvious ones. Code review and the test pass are where the framework earns its keep. They catch things the planning artifacts can't, and they fix most of them themselves before I even look at the diff.

What survived contact with reality

I wrote a lot of principles down. Most turned out to be window dressing once the first real product hit production. A handful actually held up.

Slim context. Each downstream agent runs in its own context with only the inputs it absolutely needs. The implementer doesn't see the full spec or the architecture — it sees a trimmed brief and a checked-off task list. If something is missing, that's a planning gap upstream, not a "load more docs" problem. This is austere. It also dropped my context-bloat regressions to near zero.

The handoff contract. Each task in the breakdown carries a small, mandatory section that captures the architectural boundaries the implementer needs — non-negotiables, decision one-liners, integration contracts, file structure. Blank fields block the handoff. The first time I bypassed it "just to keep things moving," I shipped a UI that rendered an emoji as a giant red bitmap dominating the panel. The boundary I skipped would have caught it. Now nothing ships without it filled.

A single source of truth for artifact paths. Agents read where to find things from one canonical run manifest, not by file-searching. Sounds boring. It's the difference between a reproducible run and a guess.

Smoke gates that can't be silently skipped. "All tests pass" is not enough for a Marketplace app. The real test is whether it renders correctly inside the iframe of a live extension point. The framework records this; a skipped or deferred smoke gets recorded as a warning, never a silent pass. This rule landed after I ran the full pipeline cleanly, every gate green, and watched the first install render visibly broken in production. Mocks are faithful to types. The tenant is faithful to data. Those are not the same artifact.

Skills that announce themselves. For months my repo had a folder I called my skill library. Forty-six markdown fragments, each shaped like a skill, each shipping production apps. The day I tried installing them in a fresh agent session somewhere else, the trick collapsed — the runtime listed nothing. What I had was domain knowledge in costume. The fix was a single-day atomic cutover into a real plugin. Half-migrated would have been worse than not migrated at all.

The four products that tested all of this each taught a different lesson.

Then I tried to ship the next version on top of it.

The lesson that beat all the others

The follow-up extended the version trail with a Compare view: pick two versions, see field-level diffs, drill into a per-component accordion, flip to a side-by-side visual canvas. Three days, thirty-five commits, every test green. The pipeline did everything it was supposed to do.

The first real-tenant smoke surfaced nine findings in one session. The Compare CTA rendered dark text on a purple background. Clicking Compare opened a placeholder body. The page-fields section rendered nothing on success when the field array came back empty. Component rows lost their names because the layout parser returned an empty string and the JavaScript ?? operator passes empty strings through. The Visual tab loaded "Page not found." And four more in the same vein.

Each was a five-to-thirty-line fix. None were architectural. The framework caught architectural drift through structural tests — those held the whole way through. What it didn't catch was the gap between the shape of the data my mocks were returning and the shape of the data the real tenant returns.

That release introduced four new SDK integration surfaces in one shot, and zero real-tenant checkpoints between them. By the time I clicked Compare in the live tenant, four phases worth of unverified divergence had stacked on top of each other.

The cadence that actually works isn't "AI runs the whole pipeline" or "human approves every step." It is:

Autonomous within a phase, hard checkpoint between phases.

Inside a phase, the pipeline runs end-to-end on its own. No micro-confirmations, no babysitting. Between phases, there's a real-tenant install, the F12 console open, a five-minute walkthrough as an actual editor, and screenshots compared against the original mockup. The bugs that mocks cannot reproduce surface here — and they surface in isolation, against a verified prior phase, not stacked on three layers of unchecked drift.

The phasing rule that came out of this is one new SDK integration per phase, not one user-facing feature per phase. Three new integrations in one release is a forcing function for splitting. Each new surface ships against a verified prior phase, or it does not ship.

That's the rule I'd carry to the next agentic project before any other one.

Where I'm going next

A few things I'd tell anyone starting their own version of this, mostly the unglamorous ones. Pick the boring abstractions early — the agent identity / command task separation looks fussy on day one and pays for itself the third time you re-use the same agent for a different job. Make one source of truth from the first commit; adding it later means rewriting every command that hard-coded a path. Treat skills as runtime artifacts, not as prose — if a fresh session can't list them, they're not skills. Mocks are not a substitute for a real tenant. Phase by integration risk, not by feature. That last one is the one I keep re-learning.

And the thing I would not do again: try to autonomously ship a four-integration release end-to-end. The pipeline is genuinely good at running each phase. It is not good at running the whole product on its own — and pretending otherwise costs more time than the checkpoints would have.

Plenty of this will look naive in another six months, and that's fine. The loop's whole job is to keep updating itself. The longer write-ups — the dogfood loop, the skills cutover, the partnership lesson — live as separate pieces in the agentic section of this site if you want to go deeper, with case studies for each of the four shipped apps next door.

If you've built something similar, or are thinking about it, I'd love to hear what you tried and what stuck. The bits that go wrong in your loop are usually the most useful bits in mine.

Until next time — and as always, let me know what you think. Good arguments, awkward questions, and "actually, I think you got that bit backwards" are all welcome.