.png "Your DXP was built for humans. What about AI agents?")
One thing AXP can do is give AI agents a different representation of a webpage. Instead of sending all the JavaScript, tracking, interactive components and other browser-oriented complexity that we normally deliver to a human visitor, AXP can serve clean, server-rendered HTML without a JavaScript dependency. Dynamic components can also be simplified or restructured so their information is easier for an AI agent to consume.
I really like that idea. Especially for large enterprise websites, where you might have years of technology decisions behind you, multiple platforms, JavaScript-heavy applications and perhaps no headless architecture yet. Then putting an intelligent delivery layer in front of what already exists would be a very pragmatic solution. You can improve what agents receive without rebuilding your entire website.
But while listening to the webinar, it also made me think about the other side of this problem. If I were designing a headless DXP from scratch today, would I still want to add another platform dependency to transform my pages? Or should the frontend be able to serve AI agents properly from the start?
We designed our digital experiences for humans
For years, most of our assumptions have been relatively simple. Someone opens a browser, requests a page and then interacts with the experience we have carefully designed for them. You can see that assumption almost everywhere in modern websites.
We use JavaScript to provide interaction. We hide information behind tabs and accordions, just to create a seamless experience. We use carousels to fit multiple products into a limited amount of space. We personalise components, run experiments, add tracking and keep making the frontend experience more sophisticated. There is nothing wrong with that. All of those things can provide real value to a human visitor. But AI agents have very different needs.
It doesn't need an accordion to save screen space. It doesn't care about the animation between two slides in a carousel. It doesn't need a fancy menu to figure out where to click next in the same way a person does. It can do without all those fancy experiences that we keep adding to make our customers happy.
What it does need is access to the information, plus enough structure and context to understand what that information actually means. And that is becoming more relevant. In July 2026, Cloudflare reported that automated bot traffic had surpassed human activity and was generating roughly 57% of all web requests. That includes far more than AI agents, so we shouldn't translate that number into "57% AI traffic". However, it does show that websites increasingly have machine consumers next to human ones. If that continues, our DXP architectures probably need to start acknowledging it as well.
Smaller HTML is not the actual goal
It is tempting to reduce this whole problem to something like "remove JavaScript for AI". I don't think that goes far enough.
A small HTML document isn't automatically a useful document. Imagine an accordion containing important information, where only the first panel is available unless someone interacts with it. Removing the JavaScript does not suddenly make that page agent-friendly. It might actually make part of the content impossible to access. So the goal shouldn't simply be to create less HTML or remove more JavaScript. The goal should be to give an AI bot access to the better meaning of the content on the page. While removing all the fancy experience that the bot is not interested in.
Take a product carousel with five products. A human visitor might see one product at a time and click or swipe through them. An agent doesn't need that interaction. Its representation could simply expose all five products as a semantic list.
An accordion could become a series of headings and sections. Tabs could become sequential content. A complex comparison experience could expose the comparison data without requiring the interaction around it.
At the same time, a normal content block with a heading and a few paragraphs probably doesn't need any special treatment at all. That is important, because I don't think the solution is to build an alternative version of every component. We only need to look at the places where the human experience gets in the way of accessing the information.
Headless gives us an interesting opportunity
This is where I think headless architectures become interesting. A typical implementation might have a CMS such as Sitecore or Storyblok providing structured content to a Next.js frontend. That frontend already knows what the content is, which components need to be rendered and what those components are supposed to represent. In other words, we have a lot of knowledge available before everything is turned into the human experience.
An external agent-experience layer works from the other direction. It receives the finished website and transforms it back into something that is more suitable for machines. Scrunch describes AXP as sitting at the CDN layer, detecting AI traffic and serving an optimised version while leaving the normal human website unchanged.
For existing websites, I think that makes a lot of sense. It allows you to retrofit agent support onto an architecture that wasn't designed for it. For a new headless architecture, however, I think we should at least ask whether some of that responsibility could live closer to the frontend.
Instead of thinking only in this direction: structured content → human experience → machine-friendly transformation
we could start thinking about: structured content → representation appropriate for the consumer
That might sound like I am proposing two websites, but that is exactly what I would try to avoid.
For me, this would be one of the most important architectural constraints.
The CMS remains the single source of truth.
I would not start by letting an AI representation invent additional content, generate new claims or maintain its own AI-specific editorial version of a page. The moment we do that, we are introducing another publishing channel, with a whole lot of maintenance nightmares. And for a large organisation, that will create a lot of questions very quickly.
Which version is correct? Who approves the AI-specific text? Does it go through the same compliance process? What happens with translations? And how do we make sure the human and agent versions don't slowly start drifting apart?
I would start much simpler.
Same content. Same permissions. Different representation.
The agent representation can reorganise existing content, expose information that was hidden behind interaction, improve its semantic structure and remove unnecessary browser machinery. But the underlying facts and access boundaries remain the same. This also makes the architecture much easier to test. We can automatically compare the human and agent representations and check whether meaningful content, links, media references or other context has disappeared.
Remove the chrome, not the context
Once you start looking at a page this way, there is quite a lot that an agent probably doesn't need. It is unlikely to benefit much from our account menu, cookie interface, animated navigation, tracking scripts or a footer with dozens of repetitive navigation links. Removing those things isn't only about creating cleaner HTML. It could also reduce the work performed by backend services and lower the amount of data transferred for machine traffic. But we have to be careful not to remove useful context at the same time.
Breadcrumbs, for example, can tell an agent where information sits inside a site hierarchy. Brand and site identity still matter. Relevant related links can describe relationships between information. Canonical information, language information and structured data should remain available as well.
I would also keep references to meaningful images. The consumer can decide whether it wants to retrieve and interpret the actual image. The same applies to video. We don't have to send an entire interactive video player just to communicate that a relevant video exists.
So for me the principle is quite simple: Remove interaction and presentation noise, but preserve meaning and context.
Keep the agent experience stable
There is another difference between human and agent experiences that I think can work in our favour. Our human websites are increasingly dynamic. We personalise content, run A/B tests and adapt experiences based on previous behaviour or other information we have about the visitor. For the first generation of an agent representation, I would probably do almost the opposite. I would keep it boring. Make it canonical, public, deterministic and highly cacheable. No personalisation, no experimentation, no user-specific state.
If the underlying content in the CMS doesn't change, the agent should ideally receive the same representation every time. That gives us something we can properly test, cache and reason about. I would also initially keep traditional search crawlers on the rendering path that we already know. Scrunch takes a similar approach with AXP and states that Googlebot and Bingbot are not routed through its agent experience, while real-time AI retrieval agents are. In the future, there might be reasons to give search engines a similar optimised representation. For existing organic search performance is simply too important to include casually in the first experiment. Don't try to fix something that isn't broken.
Make it measurable
This is also where I think we have to be careful with the claims we make. Removing JavaScript doesn't prove that ChatGPT will suddenly cite your website more often. Better semantic HTML doesn't automatically mean better visibility in Gemini either. Generative systems are probabilistic, and there are many factors outside our own website that influence the answers they produce. But there are things we can measure.
Can we remove the client-side runtime without losing meaningful content? Can we expose information that was previously hidden behind interaction? Is the resulting structure easier for a machine to understand? Is the output stable? Is the payload smaller than the normal human version? Those are concrete engineering outcomes. From there, we can start observing what actually happens and keep improving it.
.png "Baseline. Optimize. Observe. Repeat.")
For me, that is a much more useful approach than pretending we already know exactly how every AI agent wants to consume the web.
Start putting this in your proposals
I don't think we should wait until all standards and best practices around this have settled. If I were proposing a new headless DXP implementation today, I would already make agent readiness part of the architecture discussion. That doesn't mean promising a second rendering implementation for every component. It doesn't mean putting generative AI directly into the live request path. And it certainly doesn't mean building a second website specifically for bots.
It simply means acknowledging that the browser is no longer the only consumer we have to think about. We should identify experiences where human interaction hides information. We should think about what a canonical machine representation could look like. We should keep the CMS in control of the content. And we should design the frontend in such a way that this capability can evolve when agent behaviour and web standards change.
AI-assisted development is here to stay; using it makes this more interesting. Writing and maintaining an alternative representation for the small number of components that actually need one is becoming cheaper. Personally, I would much rather use AI to help developers create and test deterministic rendering code than use generative AI to rewrite approved brand content on every request.
Scrunch AXP was what triggered this thought process for me, and I still think its approach makes a lot of sense, especially when you have to make an existing enterprise landscape more agent-ready without rebuilding it. But when we are designing a new headless architecture, we have the opportunity to think about this earlier. Maybe supporting both humans and machines should simply become another responsibility we expect from the frontend. I have started calling that capability agent rendering.
In the next article, I will go deeper into what an agent-rendering architecture could actually look like. Where should consumer detection happen? How can components provide another representation without doubling the maintenance? How should we handle caching and testing? And where could emerging capabilities such as Markdown content negotiation fit into the picture? Because if AI agents are becoming another consumer of our digital experiences, the question is no longer only whether they can access our websites.
The more interesting question is what experience we choose to give them.