AI-Powered Stack — Series overview and roadmap

The AI-Powered Stack theme is where I step back from individual tools and look at the whole delivery system I use for Sitecore XM Cloud projects. The lens is simple: how can a single architect, plus a small bench of AI agents, behave like a full team without cutting corners on quality, governance, or security?

Instead of chasing “AI that does everything,” this series focuses on repeatable patterns:

agents as narrow specialists backed by a project knowledge base,
humans owning decisions, reviews, and scope,
and everything important landing in git as Markdown, specs, decision notes, and runbooks.

In this article I summarize the themes covered by the AI-Powered Stack posts and how they fit together:

If the AI Code Generation series is about turning matrices and Figma files into components and heads, AI-Powered Stack is about the people, tools, and workflows that surround that pipeline.

Why “AI-powered” is a delivery pattern, not a product

On real XM Cloud engagements, “AI-powered” usually means:

I have more work than a single human can comfortably handle,
the client still expects solid architecture, documentation, and governance,
and I need a way to keep context and quality while delegating repetitive work.

The posts in this theme share a few beliefs:

Ground agents in real context.
A project knowledge base built with retrieval-augmented generation (RAG)—using tools like NotebookLM or Azure OpenAI On Your Data—plus official Sitecore docs keeps answers anchored in reality.
Treat agents like junior specialists.
Give them clear roles—business analyst, architect, project manager, coder, QA—and judge them by their drafts. You own the final call.
Make everything inspectable.
Requirements, decision notes, risk and dependency logs, and prompts live in the repo. If an agent did something important, there is a file and a diff you can review.
Prefer pipelines over heroics.
The stack should make it easier to repeat good decisions than to improvise clever one-offs.

With that lens in mind, here is how the posts in this theme fit together.

My Sitecore delivery stack for 2025

Reference: AI-Powered Stack — My Sitecore delivery stack for 2025
Focus: tools, services, and patterns that make the rest of the series possible.

This post is the inventory and wiring diagram for the whole stack:

planning and reasoning tools like ChatGPT Pro, Claude Code, and NotebookLM,
delivery basics like XM Cloud, Experience Edge, Content SDK, Search JS SDK, and Content Hub,
glue and governance: Azure OpenAI On Your Data, RBAC, VNETs, and prompt hygiene,
and practical choices like IDEs, terminals, and MCP-style integrations.

If you read only one AI-Powered Stack article before a project, make it this one. It answers:

which agents I keep open every day and why,
how I connect them to Sitecore’s official docs instead of random blog posts,
and how I keep cost, privacy, and RBAC sane as a company of one.

The rest of the theme assumes this stack exists and is configured: agents wired to a shared knowledge base, basic XM Cloud docs indexed, and a repo that can hold prompts and artifacts.

From Blank Page to Signed SOW

Reference: AI-Powered Stack — From Blank Page to Signed SOW
Focus: going from scattered inputs to a signed Statement of Work (SOW) with AI as a junior architect/PM, not a one-click generator.

This post is the pre-sales and discovery playbook:

how I centralize RFPs, transcripts, legacy docs, and code into a “project brain” backed by that knowledge base,
how I use agents to draft requirements, solution shapes, diagrams, and options,
how I structure estimates, risk logs, and commercial scenarios,
and how I co-author the actual SOW text while keeping scope, assumptions, and risk under human control.

If you want to see concrete prompts for “blank page → architecture → plan → SOW,” this is the deep dive. It pairs directly with the next post.

From Signed SOW to Sprint One

Reference: AI‑Powered Stack — From Signed SOW to Sprint One
Focus: what happens the day after the SOW is signed.

Where the previous post stops at the signature, this one starts right after it and shows how I use agents to:

stand up a delivery workspace (contracts, discovery, solution, planning folders),
translate SOW scope and architecture into epics, stories, and swim lanes,
prepare Jira/Azure DevOps boards, backlogs, and risk logs,
and line up environments, access, and keys so Sprint 1 is not blocked by basic setup.

I treat it as an AI-assisted Sprint Zero runbook focused on moving from paper plan to a ready-to-run backlog and team runway.

Sprint zero for XM Cloud with agentic AI

Reference: AI-Powered Stack — Sprint zero for XM Cloud with agentic AI
Focus: a concrete Sprint Zero cadence for XM Cloud, from brief to signed scope.

Sprint Zero is where I use agents the most aggressively and also the most carefully. The post breaks that into stages:

Capture the brief and build a ground-truth workspace.
NotebookLM and Azure OpenAI On Your Data ingest RFPs, notes, and legacy docs so everyone—humans and agents—pulls from the same facts.
Recon the current estate.
Playwright crawlers plus analysis prompts produce annotated sitemaps and early component matrices that will later feed the Code Generation theme.
Convert recon into information architecture (site structure) and requirements.
BA-style agents turn crawl data into component specs, site-structure diagrams, and epic lists with acceptance criteria, all checked against XM Cloud docs.
Shape the backlog and delivery model.
Agents draft stories, estimates, and risk logs; I tune them to match real capacity and risk.
Lock down environments, keys, and serialization.
Architect and DevOps prompts propose Experience Edge usage patterns, SCS module layouts, and CLI runbooks, always citing Sitecore guidance.
Price, package, and hand off.
Estimator prompts combine size and risk into a forecast; NotebookLM and others assemble executive decks and scope appendices.

By the end of Sprint Zero, I expect to have:

a populated backlog tied to a clear information architecture,
initial component specs and a crawl-backed view of the legacy site,
environment and serialization decisions that delivery can trust,
and a knowledge base that new teammates can query on day one.

This post is the bridge between AI-Powered Stack and AI Code Generation: it turns discovery into the inputs that the code-generation pipeline needs.

Working with AI as your Sitecore BA, architect, and PM

Reference: AI-Powered Stack — Working with AI as your Sitecore BA, architect, and PM
Focus: role-specific workflows once the project is underway.

On most XM Cloud projects I am asked to be BA, architect, and PM at once. This post breaks down how I use agents to support each role without blurring responsibilities:

BA workflows:
- turn messy inputs into structured requirements and discovery questions,
- keep a living taxonomy of personas, journeys, and content types,
- generate epics and stories with clear acceptance criteria,
- and maintain requirement diffs as the scope evolves.
Architect workflows:
- draft architecture options grounded in XM Cloud and composable constraints,
- model content and components that are realistic for Experience Edge and Content SDK,
- maintain decision notes with revisit triggers,
- and document data flows and integration patterns.
PM workflows:
- propose delivery models and roadmaps that fit team capacity,
- keep risk logs current by mining meeting notes and ALM data,
- generate status updates and retro inputs without manual retyping.

The throughline is governance:

everything lands in git (requirements, decision notes, risk logs, prompts),
agents must provide citations for platform behavior,
and humans sign off on anything that changes scope, architecture, or risk.

If the Sprint Zero post is about how to start, this one is about how to keep going without letting AI or scope drift take over.

Fast POCs from prompt to XM Cloud components

Reference: AI-Powered Stack — Fast POCs from prompt to XM Cloud components
Focus: showing value quickly without creating throwaway prototypes.

Stakeholders often want to see XM Cloud, Experience Edge, and new UX in action in the first week. This post explains how I let agents help with that while still aiming for production-grade foundations:

Frame the POC clearly.
Agents draft a one-pager with objective, scope, success criteria, and keep-vs-throwaway rules so everyone knows what the POC is for.
Use XM Cloud-compatible starters.
Coding agents scaffold Next.js App Router + Content SDK + Storybook projects that follow Sitecore’s guidance instead of one-off demos.
Treat wireframes, flows, and copy as artifacts.
Design and writing agents generate and refine UX and content drafts stored in docs/pocs/, not just in someone’s head.
Go from wireframes to XM Cloud-ready components.
Agents help define component specs, generate Storybook components, and hook a subset up to Experience Edge Preview so authors see real content.
Capture decisions and hardening plans.
Decision notes describe which choices are safe to keep and which are POC shortcuts; agents propose hardening backlogs and minimal CI pipelines.

The outcome is that POCs:

are fast enough to unblock decisions,
are close enough to the target architecture to reuse,
and come with documentation that makes promotion or archiving deliberate, not accidental.

How the AI-Powered Stack theme fits into the bigger picture

The AI-Powered Stack theme sits before and around the more technical themes:

It feeds the AI Code Generation series with component matrices, specs, and repos ready for agents to scaffold code.
It gives the AI Workflows theme the raw material (taxonomies, briefs, content models) that editorial and DAM copilots need.
It sets expectations for Integrations work by documenting environments, keys, and guardrails up front.

You can think of it as the operating system for AI on a Sitecore project:

which agents you use,
how they see project context,
how you keep their work grounded and auditable,
and how you move from “AI experiment” to “standard delivery practice.”