Building the Agentic Web with Adobe Experience Manager

For years, we built websites for two audiences: people and search engine crawlers. That equation just added a third player, and it's changing faster than most teams have caught up to. AI agents are now browsing on behalf of users, researching products, comparing options, and even completing purchases without a human ever loading a page in a browser. Traffic to US retail sites from generative AI sources jumped 770% year-over-year, and that number is only going up.

This is what people mean by the "agentic web." It's not a rebrand of AI search. It's a shift in who or what is actually reading your content, and Adobe Experience Manager has been rebuilding itself around that shift: less a content management system, more what Adobe calls a brand experience management system, built to serve human visitors and autonomous agents from the same source of truth.

Here's what that actually looks like under the hood, and what it means if you're the one building on AEM.

What "Agentic Web" Means for Developers

Before getting into AEM's specific tooling, it helps to be clear on what's different:

• Agents don't render pages the way browsers do, they consume structured data, so content that's only meaningful visually (a clever layout, a subtle animation) is invisible to them.
• Discoverability now depends on machine-readable structure, not just SEO metadata.
• The same content fragment might get served to a human on a marketing page, a chatbot answering a support question, and a shopping agent comparing products, all from one model.
• Governance matters more, not less, because agents can act at a speed and scale no human review process was designed for.

In short: content modeling stops being a backend concern and becomes the whole game.

The MCP Server: How Agents Actually Talk to AEM

Adobe built a unified MCP (Model Context Protocol) server for AEM as a Cloud Service, which is the connective tissue between AI agents and your instance. Instead of an agent calling raw APIs, it talks to AEM through a standardized protocol that any MCP-compatible client can use Claude, ChatGPT, Cursor, your own internal tools.

What that server actually exposes:

• Content operations - create, read, update, and delete pages and content fragments, search and import assets, manage metadata, and generate image renditions on the fly with Dynamic Media.
• Experience governance - check content against brand rules and pull governance configurations before anything ships.
• Cloud Manager access - manage programs and environments, trigger deployment pipelines, all through natural language.
• Migration support - surface Best Practices Analyzer findings when moving from AEM 6.x to Cloud Service.

The part developers should care about most: none of this bypasses your permission model. An agent can only do what the authenticated user could already do. It's a new interface to AEM, not a new set of privileges.

Five Native Agents, Not One Generic Assistant

Rather than shipping a single do-everything AI layer, Adobe split agentic capability into purpose-built agents inside AEM:

• Production Agent - turns content creation and updates that used to take weeks into a matter of hours.
• Governance Agent - checks compliance and brand policy automatically instead of relying on manual audit cycles.
• Discovery Agent - lets people (and other agents) search approved content in plain language instead of hunting through folders.
• Development Agent - speeds up code review, debugging, and deployment tuning for the engineering side of the house.
• Content Optimization Agent - reshapes content for different channels and formats without a human redoing the work each time.

Together, these are meant to work as a closed loop, content gets produced, checked, discovered, and adapted without constant manual handoffs, while still staying inside brand and governance boundaries.

What Actually Changes for Developers Building on AEM

None of this is really about writing less code. It's about designing systems differently:

• Content fragment models need to be clean and well-structured, because an agent's understanding of your content is only as good as the schema behind it.
• Governance rules have to be defined explicitly, since an agent will follow them literally there's no "common sense" fallback.
• Testing now includes agent workflows, not just human user flows, does the Discovery Agent actually surface the right content for a given query?
• Permissions and access design carry more weight, because agents inherit exactly what the authenticated identity is allowed to do.
• Documentation and content structure decisions made early save real pain later, since retrofitting unstructured content for agent consumption is a much bigger job than modeling it correctly from day one.

Getting Started Without Overhauling Everything

You don't need to rebuild your AEM instance to start adapting to this. A few practical starting points:

• Audit your existing content fragment models for structure and consistency before layering agents on top.
• Set up the MCP server in a sandbox environment and test a few real workflows before rolling it out broadly.
• Start with one native agent, Discovery or Production are usually the easiest wins rather than turning everything on at once.
• Involve whoever owns brand governance early, since the Governance Agent is only as good as the rules it's given.
• Keep an eye on how agents are actually querying and using your content once this is live, and adjust the model based on real behavior, not assumptions.

Where This Is Heading

The agentic web isn't a future scenario, it's already showing up in referral traffic and in how products get discovered before a human ever visits a site. AEM's move toward native agents and a standardized MCP interface is Adobe's answer to a question every content platform is going to have to answer: how do you stay useful when the reader might not be human.

For developers, this isn't really about learning a new framework. It's about treating content structure, governance, and permissions as first-class design decisions instead of implementation details. The teams that get this right now will have a real head start once agentic traffic stops being a growing slice of the pie and starts being the default.

If you're figuring out what agent-ready content architecture looks like for your own AEM implementation, that's exactly the kind of thing worth thinking through before you're retrofitting it under pressure.

Written by

Vandit Shah

AEM Certified Developer

I’m Vandit Shah, an Adobe Certified AEM Developer at Arroact Technologies. I work with Adobe Experience Manager to build structured, scalable digital experiences that are both efficient to manage and consistent across channels. 

Alongside AEM, I focus on N&N Automation to streamline repetitive processes and improve how teams handle content and workflows. I’m interested in finding practical ways to reduce manual effort while keeping systems reliable and easy to maintain. 

My approach is straightforward - understand the requirement clearly, build with clean structure, and make sure the solution works smoothly in real-world use. I enjoy working on projects where thoughtful implementation can simplify complexity and create lasting value for both teams and end users.