Beyond Content Generation: Architecting Safe AI Agents for Sitecore

AI Is Moving Beyond Content Generation

Over the past few years, I've spent a lot of time exploring how AI can improve the way we build software. Part of that has involved helping engineering teams adopt new tools and approaches, but I've also made it a priority to get hands-on with these technologies myself. With how quickly things are changing, I've found that the best way to understand what these tools can do, and where they fall short, is to actually use them.

Like many developers, my early experiences with AI focused primarily on code generation. Tools like GitHub Copilot and ChatGPT helped accelerate everyday development tasks, but there was still considerable effort involved in providing the right context. AI could generate code without necessarily understanding the project, its requirements, or the decisions behind them.

That began to change with more sophisticated coding agents and the introduction of the Model Context Protocol (MCP). By connecting AI tools to systems like Figma, Atlassian, and Sitecore, we could provide access to design specifications, project requirements, and content structures rather than relying entirely on manually supplied context.

More recently, we've seen another shift toward agentic solutions capable of interacting directly with these platforms. Instead of simply recommending changes, agents can increasingly perform operations and coordinate workflows across connected systems.

Having worked on both sides of AI adoption, as an engineer experimenting with these tools and a technical leader helping teams incorporate them into their workflows, I've found that each advancement brings new opportunities to rethink how we approach familiar challenges.

Sitecore's recent expansion of its MCP and Agent API capabilities is a good example of this evolution, opening up new possibilities for how we interact with and manage content across the platform.

What Sitecore's New Capabilities Enable

In October 2026, Sitecore expanded its Marketer MCP and Agent API capabilities to support additional content-management operations. These include adding, moving, and removing page components, identifying content dependencies, and managing content through agent-driven workflows.

Programmatically managing content in Sitecore isn't anything new. Developers have been building integrations and automating these operations through APIs for years. What's different is how these capabilities are becoming accessible to AI applications. Sitecore's Agent API exposes operations through REST endpoints, while its Marketer MCP server builds on those APIs to make supported functionality available to AI tools through a standardized interface.

This opens the door to workflows that go beyond predefined automation. An agent can interpret a request, gather relevant context, and determine which operations are needed to accomplish a goal.

Consider a marketing team that wants to reposition a call-to-action component on a landing page. An AI agent could inspect the page structure, identify the component, check for dependencies or active experiments, and prepare the requested change. What might otherwise involve several manual steps could become a coordinated workflow driven by a simple request.

Sitecore has incorporated safeguards into some of these operations, including protections related to content references and active experiments. However, those protections can't necessarily account for every business requirement or architectural consideration.

The opportunity extends beyond automating individual tasks. We can begin designing workflows that understand the relationships between content, components, and the broader digital experience.

The Challenges of Agentic Content Operations

Giving an AI agent access to tools that modify content is relatively straightforward. Ensuring those changes are appropriate and aligned with business requirements is another matter.

I've encountered similar challenges while incorporating AI into development workflows. On one project, our team was building a feature where AI-generated code introduced functionality that wasn't part of the original requirements. The implementation appeared reasonable, but the AI had made assumptions based on common patterns associated with the feature. We caught the discrepancy while reviewing automated tests and Storybook stories, before it reached a deployed environment.

That experience reinforced something I've emphasized when helping teams adopt AI-assisted development: a technically valid solution isn't necessarily the right solution.

Now consider an AI agent tasked with improving a Sitecore landing page. It might determine that moving a call-to-action component would improve the experience, but does it understand the reasoning behind the existing layout? Is the component part of an active experiment? Could the change affect other pages or conflict with established design standards?

Platform-level safeguards can address some of these concerns, but they can't anticipate every business rule, design decision, or organizational process.

There's also the question of autonomy. Retrieving content and recommending changes carries a different level of risk than modifying shared components or publishing directly to production.

I don't think the answer is to unnecessarily restrict what agents can accomplish. Instead, we need to apply the same engineering discipline we've established around traditional development and content-management processes.

Architecting Responsible AI Workflows

When designing agentic workflows, I would organize the architecture around three primary responsibilities: context, controlled execution, and validation.

These aren't necessarily separate services or components. They're responsibilities that should be accounted for regardless of the tools or frameworks used.

Context: Understanding Before Acting

Before modifying a Sitecore page, an agent needs enough context to understand what it's changing and why.

That might include the page structure, content relationships, active experiments, design guidelines, or requirements from connected project-management systems.

The goal isn't to provide unrestricted access to every available system. It's to make the information relevant to the task accessible so the agent can make informed decisions.

Controlled Execution: Establishing Boundaries

Once an agent proposes an operation, the application needs to determine whether it should be executed.

Not every action requires the same level of oversight. Creating an unpublished draft is different from modifying shared content or publishing changes to production.

I would introduce a policy layer that evaluates operations against permissions, business rules, and risk levels. Lower-risk actions might execute automatically, while more consequential changes require approval.

These controls should be enforced through application logic and API permissions rather than relying entirely on instructions provided to the AI model.

Validation: Confirming the Intended Outcome

A successful API response doesn't necessarily mean the intended result was achieved.

After executing an operation, the workflow should verify the resulting state. For Sitecore, that could involve checking component placement, validating content relationships, or confirming that the page structure remains intact.

Depending on the complexity of the change, additional checks might include accessibility testing, design-system validation, or visual regression testing.

We also need to account for failures. Sitecore's Agent API already provides operation tracking and rollback capabilities through its Jobs API, which can support recovery when something goes wrong. Our orchestration layer should build on those protections, particularly when a workflow spans multiple operations or external systems.

Bringing It Together

The architecture doesn't need to be overly complicated. A lightweight orchestration application may be sufficient for many use cases, provided it establishes clear boundaries between what an agent proposes, what it's authorized to execute, and how the results are verified.

Putting the Architecture into Practice

Let's revisit the landing page example. A marketer wants to move a call-to-action component higher on the page to improve its visibility.

An agent connected to Sitecore could retrieve the page structure, identify the component, and check for dependencies or active experiments. It could then prepare a proposed modification for evaluation before executing anything.

An intermediate operation plan might look something like this:

{
  "operation": "move_component",
  "target": {
    "pageId": "landing-page-123",
    "componentId": "cta-component-456"
  },
  "destination": {
    "placeholder": "main",
    "position": 1
  },
  "expectedPageVersion": "v12",
  "riskLevel": "moderate",
  "requiresApproval": true,
  "status": "pending"
}

This is an illustrative orchestration contract, not an official Sitecore API schema.

There are a few important details here.

expectedPageVersion represents an optimistic concurrency check. Before execution, the application would compare the expected page state against its current state to detect changes made since the plan was created. Ideally, this would be enforced atomically by the underlying API. Otherwise, additional safeguards may be needed to prevent changes between validation and execution.

riskLevel represents a classification assigned by the governance layer rather than relying solely on the AI model's assessment.

requiresApproval is determined by application policy, ensuring that approval requirements aren't left to the agent's discretion.

Only after these conditions are satisfied would the application invoke the appropriate Sitecore operation.

Following execution, the workflow could retrieve the updated page structure and verify that the component was moved to the intended location.

But what happens if another content author modifies the page between planning and execution?

Rather than executing an outdated plan, the application should recognize that the underlying context has changed and reevaluate the operation.

This is an important distinction between connecting an AI agent to an API and building a reliable integration around it. We're accounting for the same challenges found in traditional software development, including concurrent modifications, stale data, and unexpected failures.

The approach could extend beyond repositioning components to content updates, page creation, campaign preparation, and other content-management activities. The complexity may vary, but the architectural principles remain consistent.

Looking Ahead

As AI continues to evolve, I expect more platforms will introduce capabilities that allow agents to interact directly with their systems. Sitecore's recent updates are a good example of that direction, with opportunities to move beyond AI-assisted content creation toward more connected and automated workflows.

One thing I've come to appreciate while helping engineering teams adopt AI is that the technology often evolves faster than the processes surrounding it. New capabilities can improve productivity, but realizing those benefits requires more than simply making the tools available.

The architectural considerations we've explored aren't necessarily new. Authorization, validation, observability, and recovery have always been important parts of building reliable software. What's changing is how we apply those principles when AI agents begin performing operations previously handled directly by developers or content authors.

I see this as an opportunity to rethink familiar workflows while building on established engineering practices. The goal shouldn't be to automate everything simply because we can, but to identify where agentic capabilities provide meaningful value and implement them in ways that make sense for the organizations using them.