AI-Powered Stack — Working with AI as your Sitecore BA, architect, and PM

1. Summarize the approach in 2-3 sentences
2. Define the content architecture:
   • What content types live in XM Cloud vs Content Hub vs external systems
   • Template hierarchy strategy (inheritance, shared templates)
   • SCS module boundaries (what gets serialized where)
3. Define the delivery architecture:
   • Experience Edge query patterns (layout queries vs item queries)
   • Caching strategy (ISR intervals, on-demand revalidation, Edge caching)
   • Preview vs delivery endpoint usage
4. Define the personalization approach (if applicable):
   • Rule-based (XM Cloud embedded) vs CDP-driven
   • Where personalization decisions happen (Edge, server, client)
5. Identify integration points:
   • How each Sitecore product connects
   • External system integration patterns
6. Assess trade-offs:
   • Pros (what this optimizes for)
   • Cons (what you sacrifice)
   • Cost implications (licensing, infrastructure, maintenance)
7. Flag Sitecore-specific risks:
   • Serialization complexity
   • Edge rate limits and mitigation
   • Preview API limitations (not for production traffic)
   • Content Hub sync timing (if applicable)

<output_format>

Option 1: [Descriptive name]

Summary

[2-3 sentence overview]

Content Architecture

SCS Module Strategy:

• Foundation/[Module]: [What it contains]
• Feature/[Module]: [What it contains]
• Project/[Site]: [What it contains]

Delivery Architecture

[Simple ASCII or description of request flow]
User → CDN → Next.js (Vercel/Node) → Experience Edge → [Response]

Caching Strategy:

Personalization Approach

[Description or “Not applicable”]

Integration Points

Trade-offs

Pros:

• [Benefit 1]
• [Benefit 2]

Cons:

• [Limitation 1]
• [Limitation 2]

Cost Considerations:

• [Licensing, infrastructure, or operational cost notes]

Sitecore-Specific Risks

[Repeat for Options 2 and 3] </output_format>

Architect workflow: component and data design

Goal: Translate IA and requirements into content models, components, and data flows that are realistic for XM Cloud and composable Sitecore.

Steps:

1. Start from your component matrix.
   Use the output of your “Code Generation” series: the Playwright crawl, matrix, and components/*.md specs.

2. Model content types.
   Ask your agent to propose:

   • templates and content types in XM Cloud (or in Content Hub, if content is shared across channels),
   • field definitions and constraints,
   • relationships between entities (for example articles, authors, categories, products).

3. Validate against Sitecore docs.
   Cross-check:

   • whether your templates align with component usage patterns in XM Cloud components docs,
   • whether Experience Edge queries will be efficient for your access patterns,
   • whether personalization rules have the data they need.

4. Document data flows.
   Ask an agent to draw sequence diagrams (in Mermaid or similar) for:

   • page render in preview vs delivery,
   • personalization decision flows,
   • integrations (for example XM Cloud → Connect → Salesforce).

Output: Content models, component designs, and data-flow diagrams in docs/architecture/.

Prompt for component/template design:

<context>
You are a Sitecore XM Cloud content architect designing templates and components for a headless implementation. You understand:
- XM Cloud template inheritance and standard values
- Content SDK field types and GraphQL schema generation
- Experience Editor / Pages authoring experience
- BYOC (Bring Your Own Components) registration patterns
- Rendering parameters vs datasource approaches
</context>

<task>
Design XM Cloud templates, field definitions, and component mappings based on the provided component matrix.
</task>

<component_matrix>
[Paste component list with fields, or reference the component specs folder]
</component_matrix>

<instructions>
1. **Design template hierarchy:**
   - Identify shared base templates (reduce field duplication)
   - Define page templates vs component/datasource templates
   - Plan standard values and insert options

2. **Define field specifications:**
   - Map each component field to a Sitecore field type
   - Include validation rules and help text for authors
   - Consider source fields for Droplists/Multilists

3. **Separate rendering parameters from datasource fields:**
   - Rendering parameters: display options, layout choices (no content value)
   - Datasource fields: actual content that varies per instance

4. **Design placeholder structure:**
   - Define placeholder names and allowed renderings
   - Plan nested placeholder patterns for complex layouts

5. **Optimize for GraphQL:**
   - Avoid deeply nested templates that complicate queries
   - Consider field naming for clean GraphQL schema
</instructions>

<output_format>
## Template Hierarchy

### Base Templates
| Template Name | Path | Purpose | Inherited By |
|---------------|------|---------|--------------|
| _ContentBase | /Foundation/Content | Common fields (Title, Description) | All content templates |
| _MediaBase | /Foundation/Media | Image, Video fields | Media-rich components |

### Page Templates
| Template Name | Path | Base Templates | Insert Options |
|---------------|------|----------------|----------------|
| HomePage | /Project/[Site]/Pages | _ContentBase, _SEO | HeroBanner, ContentBlock |

### Component Templates (Datasources)
| Template Name | Path | Base Templates | Used By Rendering |
|---------------|------|----------------|-------------------|
| AccordionItem | /Project/[Site]/Components | _ContentBase | Accordion |

## Field Definitions

### [Component Name] Template
| Field Name | Display Name | Type | Source | Required | Help Text |
|------------|--------------|------|--------|----------|-----------|
| Title | Title | Single-Line Text | - | Yes | "Main heading (50 chars max)" |
| Body | Body Content | Rich Text | - | No | "Supports links and lists" |
| Theme | Background Theme | Droplist | /Content/Lookups/Themes | No | "Visual style variant" |

**Standard Values:**
- Theme: "Default"

## Rendering Parameters vs Datasource

| Field | Location | Rationale |
|-------|----------|-----------|
| BackgroundColor | Rendering Parameter | Display option, not content |
| Title | Datasource | Actual content, varies per use |
| MaxItems | Rendering Parameter | Layout control |

## Placeholder Structure

main-content ├── hero (allowed: HeroBanner, VideoHero) ├── body-content (allowed: ContentBlock, Accordion, CardGrid) │ └── card-grid-items (allowed: Card) [nested] └── cta-section (allowed: CTABanner)

## GraphQL Considerations
- [Notes on query patterns, fragment reuse, etc.]
</output_format>

<quality_checks>
- Every component from the matrix has a corresponding template
- Field types are appropriate for Content SDK serialization
- Author-facing names are clear and consistent
- No orphan templates (all are used by at least one rendering)
</quality_checks>

Architect workflow: decision records and technical debt management

Goal: Track why you made certain decisions and when to revisit them.

Steps:

1. Adopt a decision note template.
   Add docs/adr/template.md with:

   • context, decision, alternatives, consequences, review date.

2. Use AI to draft decision notes.
   For each significant choice (for example Experience Edge strategy, serialization layout, hosting model), ask an agent to generate a draft ADR from your architecture vision and notes. You edit and approve it.

3. Tag decisions with revisit triggers.
   Ask the agent to propose revisit triggers (for example “traffic increases 10×,” “Content Hub DAM is introduced,” “Search quotas change”) and include them in the ADR.

4. Periodically review decision notes with AI assistance.
   Once per quarter or per big release, ask an agent to:

   • scan ADRs,
   • compare them against current metrics and constraints,
   • propose which decisions may need revisiting.

Output: A decision log that actually gets maintained. AI makes drafting fast enough that I don’t skip it.

Prompt for ADR drafting:

<context>
You are a technical writer documenting architecture decisions for a Sitecore XM Cloud project. ADRs will be reviewed by:
- Future developers who need to understand why choices were made
- Architects evaluating whether to revisit decisions
- Stakeholders assessing technical debt and risks
</context>

<task>
Draft a complete Architecture Decision Record based on the provided decision context.
</task>

<decision_input>
**Problem:** [What problem or question triggered this decision]
**Decision:** [What we chose to do]
**Alternatives considered:** [Other options we evaluated]
**Key constraints:** [What limited our options - budget, timeline, team skills, licensing]
</decision_input>

<instructions>
1. Frame the context so someone unfamiliar with the project understands the problem
2. Explain the decision with enough detail to reproduce the reasoning
3. Document alternatives honestly - why they were rejected, not just that they were
4. Be specific about consequences - both positive outcomes and new constraints/risks
5. Define concrete, measurable revisit triggers
</instructions>

<output_format>
# ADR-[NNN]: [Concise decision title]

**Status:** Proposed | Accepted | Superseded | Deprecated
**Date:** [YYYY-MM-DD]
**Deciders:** [Names/roles involved]
**Technical area:** [Content architecture | Delivery | Integration | Infrastructure | Security]

## Context

[2-3 paragraphs explaining:]
- What problem or opportunity prompted this decision
- What constraints shaped our options (timeline, budget, team, licensing)
- What requirements or goals this decision must satisfy

### Sitecore-Specific Context
[If applicable: relevant XM Cloud capabilities, limitations, or patterns that influenced the decision]

## Decision

**We will:** [Clear statement of what we're doing]

**Rationale:**
1. [Primary reason - most important factor]
2. [Secondary reason]
3. [Additional supporting factors]

### Implementation Notes
- [Key implementation details]
- [Configuration or setup required]
- [Dependencies on other decisions]

## Alternatives Considered

### Alternative 1: [Name]
- **Description:** [What this option would have meant]
- **Pros:** [Benefits]
- **Cons:** [Drawbacks]
- **Rejection reason:** [Why we didn't choose this]

### Alternative 2: [Name]
[Same structure]

## Consequences

### Positive
- [Benefit 1 - be specific]
- [Benefit 2]

### Negative
- [Trade-off or limitation 1]
- [New constraint introduced]

### Neutral
- [Changes that are neither good nor bad, just different]

## Risks

| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| [Risk description] | Low/Medium/High | Low/Medium/High | [How we'll address it] |

## Revisit Triggers

This decision should be reconsidered if:
- [ ] [Concrete, measurable condition, e.g., "Monthly page views exceed 10M"]
- [ ] [Scope change, e.g., "Content Hub CMP is added to the project"]
- [ ] [Technology change, e.g., "Sitecore releases a native solution for X"]
- [ ] [Time-based, e.g., "12 months after go-live for performance review"]

## Related Decisions
- ADR-[NNN]: [Related decision title] - [How they relate]

## References
- [Link to relevant Sitecore documentation]
- [Link to internal design docs or RFCs]
</output_format>

<quality_checks>
- Context is understandable without prior project knowledge
- Decision rationale is traceable to stated constraints
- Alternatives are fairly represented (not straw men)
- Revisit triggers are specific and measurable
</quality_checks>

Project manager: keeping things visible

PM work is often just communication and bookkeeping—roadmaps, status updates, risk logs, retros. None of it is hard, but it eats time. AI handles the repetitive synthesis so I can focus on the conversations that actually move things forward.

PM workflow: delivery model and roadmap

Goal: Choose a delivery model (phased releases, parallel tracks, etc.) and keep a clear roadmap aligned to capacity.

Steps:

1. Feed the agent delivery constraints.
   I provide:

   • team composition and capacity,
   • timelines and key milestones,
   • dependency constraints (for example content readiness, external systems).

2. Ask for delivery scenarios.
   I ask for 2–3 delivery models (for example “MVP, then composable add‑ons,” “journey‑by‑journey rollout”) with pros/cons, emphasizing Sitecore‑specific risks: content migration, personalization ramp‑up, search tuning, etc.

3. Turn the chosen model into a roadmap.
   I have the agent:

   • map epics to releases,
   • highlight cross-team dependencies,
   • suggest buffer and risk mitigation activities (for example early content modeling, early search setup).

4. Export a shareable roadmap.
   Together we generate:

   • a Markdown roadmap (committed to git),
   • a slide for stakeholders (for example a simple swim-lane diagram).

Output:
An AI-assisted but human-curated roadmap that is consistent with architecture, requirements, and team capacity.

PM workflow: RAID logs and risk intelligence

Goal: Keep risks, assumptions, issues, and dependencies visible and actionable.

Steps:

1. Create a structured RAID log.
   I maintain docs/raid/raid_log.md with sections for risks, assumptions, issues, and dependencies.

2. Use AI to ingest meeting notes.
   After key meetings, I paste notes or transcripts into my PM agent and ask:

   • “Extract new risks, assumptions, issues, and dependencies,”
   • “Suggest owners and due dates where obvious.”

3. Ask for risk heatmaps.
   Have the agent summarize RAID entries as:

   • a prioritised risk list (impact vs likelihood),
   • visual-friendly bullets for stakeholder updates.

4. Tie RAID items to work.
   I ask the agent to suggest which epics/stories should mitigate a given risk and convert those suggestions into backlog items or checklists.

Output: A living RAID log that stays current without manual retyping.

Prompt for RAID extraction:

<context>
You are a project manager analyzing meeting notes for a Sitecore XM Cloud implementation. You understand common XM Cloud project risks including:
- Content migration complexity and timing
- Experience Edge rate limits and caching strategies
- Serialization conflicts in multi-developer environments
- Third-party integration dependencies (CDP, Search, Content Hub)
- Author training and adoption challenges
</context>

<task>
Extract and categorize RAID items (Risks, Assumptions, Issues, Dependencies) from the provided meeting notes.
</task>

<meeting_notes>
[Paste meeting notes, transcript, or summary here]
</meeting_notes>

<instructions>
1. **Identify Risks** — potential problems that haven't happened yet
   - Consider technical, organizational, timeline, and budget risks
   - Flag XM Cloud-specific risks (Edge limits, preview API constraints, SCS conflicts)

2. **Surface Assumptions** — things we're treating as true without verification
   - Challenge assumptions that could derail the project if wrong
   - Note which assumptions need validation and by whom

3. **Capture Issues** — problems that already exist and need resolution
   - Distinguish blockers (stopping work) from impediments (slowing work)
   - Note any workarounds currently in place

4. **Map Dependencies** — external factors we're waiting on
   - Include both upstream (we need X) and downstream (Y needs us)
   - Note expected resolution dates if mentioned
</instructions>

<output_format>
## RAID Log Update — [Meeting Date]

### New Risks
| ID | Risk Description | Category | Likelihood | Impact | Owner | Mitigation | Due |
|----|------------------|----------|------------|--------|-------|------------|-----|
| R-[NNN] | [One sentence describing what might go wrong] | [Technical / Timeline / Budget / Resource / External] | H/M/L | H/M/L | [Name/Role] | [Proposed mitigation action] | [Date] |

**Sitecore-Specific Risks Flagged:**
- [Any risks related to XM Cloud, Edge, Content Hub, etc.]

### New Assumptions
| ID | Assumption | Category | Impact if Wrong | Needs Validation By | Status |
|----|------------|----------|-----------------|---------------------|--------|
| A-[NNN] | [What we're assuming] | [Technical / Business / Resource] | [What happens if false] | [Who should verify] | Unvalidated / Validated / Invalid |

### New Issues
| ID | Issue Description | Severity | Blocker? | Current Workaround | Owner | Target Resolution |
|----|-------------------|----------|----------|-------------------|-------|-------------------|
| I-[NNN] | [What's wrong now] | High/Med/Low | Yes/No | [If any] | [Name] | [Date] |

### New Dependencies
| ID | We Need | From | For (Epic/Story) | Expected Date | Status | Escalation Path |
|----|---------|------|------------------|---------------|--------|-----------------|
| D-[NNN] | [What we need] | [Team/System/Person] | [What it unblocks] | [When expected] | Pending/At Risk/Resolved | [Who to escalate to] |

### Recommended Actions
1. [Immediate action needed]
2. [Follow-up for next meeting]
3. [Escalation if required]

### Items Requiring Stakeholder Decision
- [Any items that need client or leadership input]
</output_format>

<quality_checks>
- Each item has a clear, actionable description (not vague)
- Owners are assigned where identifiable from context
- Impact ratings are justified by project context
- No duplicate items (check existing RAID log)
- Sitecore-specific concerns are explicitly called out
</quality_checks>

PM workflow: status, stakeholder updates, and retros

Goal: Spend less time manually writing updates and more time resolving real issues.

Steps:

1. Automate status rollups.
   I provide:

   • ALM exports (sprint board, burndown, cycle time),
   • RAID log,
   • the roadmap.
     Ask the agent to generate:
   • a weekly internal status (for the team),
   • an executive summary (1–2 slides, non-technical language).

2. Drive better retrospectives.
   After each sprint, I give the agent:

   • completed work,
   • incidents,
   • cycle-time metrics,
   • key decisions and changes.
     Ask it to propose:
   • themes for “what went well / what to improve,”
   • 3–5 concrete improvement actions,
   • owners and suggested timings.

3. Keep the loop closed.
   At the start of the next sprint, I revisit the previous retro actions with an agent and confirm status. This ensures improvements actually happen.

Output: Consistent status updates and better retros with less manual effort.

Prompt for status rollup:

<context>
You are a project manager creating status updates for a Sitecore XM Cloud implementation. You understand:
- XM Cloud delivery phases (content modeling, component development, integration, UAT)
- Common stakeholder concerns (timeline, budget, quality, adoption)
- Technical milestones (Edge connectivity, content migration, personalization setup)
</context>

<task>
Generate a weekly status update with both internal (team) and external (stakeholder) versions.
</task>

<inputs>
**Sprint Board Status:**
[Paste or describe: completed items, in-progress items, blocked items]

**RAID Log Updates:**
[New risks, resolved issues, changed assumptions, dependency status]

**Key Decisions This Week:**
[Architecture decisions, scope changes, process changes]

**Metrics (if available):**
[Velocity, burndown, cycle time, defect count]

**Upcoming Milestones:**
[Next major deliverables and dates]
</inputs>

<instructions>
1. **Analyze sprint progress** — what moved, what's stuck, why
2. **Highlight blockers** — distinguish team-solvable from escalation-needed
3. **Connect to milestones** — is the current pace on track for upcoming dates?
4. **Surface decisions** — what was decided and what still needs decision
5. **Identify escalations** — anything executives need to know or act on
</instructions>

<output_format>
---
## Internal Status (Team)

### Sprint [N] Progress — Week of [Date]

**Overall Health:** 🟢 On Track | 🟡 At Risk | 🔴 Off Track

#### Completed This Week
| Story/Task | Points | Notes |
|------------|--------|-------|
| [ID]: [Title] | [N] | [Any relevant context] |

#### In Progress
| Story/Task | Points | % Complete | Owner | Blocker? |
|------------|--------|------------|-------|----------|
| [ID]: [Title] | [N] | [%] | [Name] | [None / Description] |

#### Blocked
| Story/Task | Blocked By | Impact | Resolution Path | ETA |
|------------|------------|--------|-----------------|-----|
| [ID]: [Title] | [What's blocking] | [What can't proceed] | [How we'll unblock] | [Date] |

#### XM Cloud-Specific Progress
- **Content Modeling:** [Status — % templates complete, serialization stable?]
- **Component Development:** [Status — Storybook coverage, BYOC registration]
- **Edge Integration:** [Status — Preview/Delivery endpoints, caching strategy]
- **Content Migration:** [Status — if applicable]

#### RAID Updates
- **New Risks:** [Brief list or "None"]
- **Resolved Issues:** [Brief list or "None"]
- **Dependencies Changed:** [Brief list or "None"]

#### Decisions Made
1. [Decision and rationale summary]

#### Decisions Needed
1. [Decision needed, who needs to make it, deadline]

#### Technical Debt / Cleanup
- [Any debt incurred this sprint]

---
## Executive Summary (Stakeholders)

### Project Status — [Date]

**Overall:** 🟢 On Track | 🟡 At Risk | 🔴 Off Track

**Progress Highlights:**
- ✅ [Major accomplishment 1 — business language]
- ✅ [Major accomplishment 2]
- 🔄 [What's actively being worked on]

**Milestone Update:**
| Milestone | Target Date | Status | Confidence |
|-----------|-------------|--------|------------|
| [Milestone name] | [Date] | On Track / At Risk / Complete | High / Medium / Low |

**Attention Needed:**
- ⚠️ [Any item requiring stakeholder awareness or action]

**Key Metrics:**
- Sprint velocity: [N] points (target: [N])
- Defects: [N] open ([+/-N] from last week)

**Budget/Timeline Impact:** [None / Description of any changes]

**Next Week Focus:**
1. [Priority 1]
2. [Priority 2]
</output_format>

<escalation_criteria>
Flag for escalation if:
- Blocker persists > 3 days without resolution path
- Milestone confidence drops to "Low"
- Scope change impacts budget or timeline
- External dependency misses committed date
- Technical risk could impact go-live
</escalation_criteria>

Governance: keeping it useful

A few practices that keep AI helpful rather than chaotic:

• Single source of truth in git.
  Requirements, architecture, prompts, and checklists live beside code. ALM tools and docs can be regenerated from this source.

• Explicit “do not change” rules.
  Maintain AGENTS.md and similar files explaining what agents may touch (Markdown docs, specs, tests) and what they must not change directly (secrets, environment configs, serialized items).

• Citations required.
  For anything related to Sitecore behavior, require agents to cite official docs or a project RAG source. If a suggestion has no citation, treat it as speculative.

• Human sign-off for decisions. Epics, architectures, roadmaps, and risks are always reviewed before they become canonical. AI drafts; I approve.

These patterns work for me. Your mileage may vary—AI tooling changes fast, and what works today might look different in six months. The underlying idea (delegate repetitive synthesis, keep humans on decisions) should hold up longer than any specific tool.

Useful links

• Sitecore XM Cloud docs: https://doc.sitecore.com/xm-cloud
• Sitecore Developer Portal (XM Cloud, CDP, Search, etc.): https://developers.sitecore.com/docs
• Sitecore Content SDK docs: https://doc.sitecore.com/xmc/en/developers/content-sdk/index-en.html
• Sitecore Search docs: https://doc.sitecore.com/search/en/developers/search-developer-guide/index-en.html
• Sitecore CDP docs: https://doc.sitecore.com/cdp
• Sitecore Personalize docs: https://doc.sitecore.com/personalize
• Sitecore Content Hub docs: https://doc.sitecore.com/ch/en/index-en.html
• Next.js docs: https://nextjs.org/docs
• Azure OpenAI “On your data” overview: https://learn.microsoft.com/azure/ai-services/openai/how-to/use-your-data

Related posts in the AI-Powered Stack series:

• AI-Powered Stack — Series overview and roadmap
• AI-Powered Stack — My Sitecore delivery stack for 2025
• AI-Powered Stack — From Blank Page to Signed SOW
• AI‑Powered Stack — From Signed SOW to Sprint One
• AI-Powered Stack — Sprint zero for XM Cloud with agentic AI