fidzu : php

For most of the web's history, we have designed digital experiences around a simple assumption: a person will visit our website. That person might arrive through a search engine, follow a campaign link, scan a QR code, or maybe even type the URL into their browser.

AI is changing that... dramatically and rapidly!

People are now asking AI assistants to research products, compare services, explain policies, recommend suppliers and complete tasks on their behalf. Sometimes, they might not even consciously choose AI and are simply guided by seemingly familiar tools like Google 'AI Overviews'. Either way, instead of visiting ten websites, a customer may ask one assistant to gather the relevant information and present a recommendation.

In the near future, that AI assistant could be doing more than reading a web page: checking product availability, requesting information, preparing an application, arranging an appointment or even completing a transaction.

Your next website visitor may not be a person at all, but an AI agent acting on their behalf, which raises a serious question:

Can AI systems understand our organisation, trust our information and interact with our services safely?

Getting to know your new audience

To be useful, AI assistants need to find the right information, understand its meaning and decide whether it is current and trustworthy.

A prospective student asking an assistant to compare courses across several universities, a buyer requesting a shortlist of products that meet detailed technical, ethical and budget requirements - both are now part of your website's audience.

While human visitors use navigation, page layouts, graphic cues and calls to action, AI systems depend more heavily on structured information, descriptive metadata, clear relationships and reliable access to data.

Your web pages may look perfectly clear to a person but remain ambiguous to a machine. For example, a human might understand from the design that one contact address is intended for media enquiries, and another is for customer enquiries, but an AI assistant may not interpret it correctly unless it's represented clearly in the underlying content structure.

The content management decisions you make today will shape how accurately they are represented by AI tomorrow.

Being visible is not the same as being understood

Many organisations are currently focused on whether their content appears in AI-generated answers. That is important, but visibility is only one part of the problem.

An AI system also needs to understand:

• What the organisation offers
• Which information is authoritative
• When the information was last reviewed
• Which products, services or locations it relates to
• Whether regional or language differences apply
• What actions can be taken
• Which information is public and which is restricted

Without this context, AI assistants may rely on outdated pages, confuse similar services or combine information that was never intended to be used together.

Preparing for AI visitors therefore requires more than content. It requires a well-structured and reliably governed source of truth.

Drupal gives content meaning

Drupal treats content as structured information rather than a collection of web pages. A university course, for example, could have defined fields for qualification, fees and application route, rather than burying them in a block of text. That structure is what makes the same content usable well beyond a single page.

For a human visitor, Drupal assembles that information into an attractive and accessible page. For an AI visitor, the same structure makes the information easier to identify, compare and reuse.

You don't need to maintain one version of content for people and another for machines because Drupal allows the same governed content to serve websites, applications, search services and AI agents.

Drupal can become the trusted source behind AI answers

AI systems are powerful, but they are only as dependable as the information and context available to them. The idea of autonomous agents can quickly become uncomfortable when governance is treated as an afterthought: what happens if an agent uses sensitive information, makes an unsuitable change, or you simply can't tell why an action occurred?

Drupal can provide a controlled source of organisational knowledge. Its content model, taxonomy and relationship system describe what information means, not simply where it appears on a page, helping an AI assistant distinguish a current policy from an archived one, or a general contact address from a specialist enquiry route.

The Drupal AI ecosystem is developing capabilities to support this level of governance, including guardrails for requests and responses, observability and activity logging, controlled access to organisational context, provider-independent integrations, and human review and approval workflows.

This is especially valuable for large or complex digital estates, where information is created by multiple departments across different languages and regions.Drupal's advanced AI implementation and integration does not negate all risk from AI usage, but it does give you a stronger foundation for identifying and managing it

Put simply, AI makes content governance essential to digital communication.

Hi, I'm a machine, please can I come in?

Making content understandable is the first step. The next is enabling controlled action

Giving an AI agent access to your digital platform creates an obvious concern: what will it be allowed to see and do?

Drupal has long supported detailed roles and permissions, allowing different users to view, edit, approve or publish specific types of content.

The same principle can be applied to AI visitors. A useful agent may need to inspect content, search records, or carry out an action, but it should never gain unrestricted access to your systems, or expose private content simply because that content exists in the same system. It should only be able to access the information and tools permitted for the person, service or task it represents.

The Drupal AI Initiative organises this work through two connected areas:

• Inside AI, which brings AI assistance into Drupal for editors, marketers and site builders
• Outside AI, which enables external AI agents and tools to connect to and act on Drupal

This changes the role of the content management system from being a 'human experience engine' to being a governed platform through which people, applications and AI agents can understand and interact with your organisation.

Design for people, prepare for agents

Human visitors are not disappearing. People will continue to value clear information, strong design, accessible services and experiences that feel relevant and trustworthy. However, they will increasingly use AI to navigate and make sense of the vast amount of information available to them.

AI readiness can look like a technology challenge, but an AI system cannot reliably represent your brand if the underlying content is fragmented, duplicated or poorly structured.

The organisations that adapt successfully will not choose between human-centred design and machine-readable content. They will build digital platforms that support both by creating information people can understand, data machines can interpret and processes agents can interact with safely.

Your next website visitor might not be human - will your digital platform know exactly how to help them?

Try Drupal today!

Article by: Martin Anderson-Clutz. Originally posted on the Acquia blog.

Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.

Back in March, at EvolveDigital in Toronto, I ran into Preston So. He mentioned that the team behind Decoupled Days was looking for speakers, and that this year the event would be in Montréal. I was interested right away. Drupal Canvas is the most compelling answer I have seen to a problem that has followed decoupled architectures for years, and I wanted that message to reach beyond the Drupal faithful - out to the practitioners who live and breathe headless every day.

The talk I ended up giving was not really about a content management system at all. It was about how Drupal has quietly become something else: a governed harness for artificial intelligence. Here is the argument I made, the demo that seemed to land hardest with the room, and why I think 2026 is the year the trade-offs of going headless finally stop being trade-offs.

Drupal Was Decoupled Before Decoupled Was Cool

Drupal did not arrive late to the headless conversation. Far from it. The community committed to an API-first architecture roughly a decade ago, and a vibrant subcommunity has been refining decoupled patterns ever since. That work produced a spectrum of delivery models rather than a single one: traditional, where Drupal renders everything; progressively decoupled, where a JavaScript front end takes over the parts of the page that benefit from it while editorial preview stays intact; and fully decoupled, where Drupal is a pure API feeding any number of channels.

That range matters, because it means Drupal has never been only a content API. It owns content, delivery, and governance at the same time. The headless-native platforms compete on one of those axes. Drupal competes on all three.

The Headless Bargain, and Why 2026 Voids It

When organizations adopted front-end frameworks like Next.js and Astro, most of them accepted what I think of as the headless bargain. They gained fast front ends and their choice of framework, and in exchange they gave up live visual editing, layout control, and real-time editorial preview. Editors went from composing pages to filling in form fields blind and filing tickets for changes they used to make themselves.

The industry tried to patch around this - bespoke preview services, visual editors bolted onto the front end, what amounted to Storybook pressed into service as a content tool. None of it fully closed the gap.

Drupal Canvas, which shipped as the default editing experience in Drupal CMS 2.0, closes it a different way. It delivers a true-to-life editing workspace where content creators edit layouts live in the browser, and the site still ships as a high-performance decoupled front end. The CMS stopped being the bottleneck and became the conductor. You keep Next.js or Astro, and you get the editorial experience back.

The Bigger Shift: The CMS Became a Harness

Something larger is happening underneath all of this. For most of the last two decades, the job of a CMS was to model content and publish it to channels. Through 2024 and 2025, artificial intelligence showed up inside these platforms as a feature - an assist button in a text box that summarized a paragraph or suggested tags when a human clicked it.

By 2026, that framing is obsolete. Artificial intelligence has become infrastructure rather than an accessory: autonomous agents that run scheduled jobs, batch operations, and real-time triggers. Analysts have adopted new vocabulary to match, from agentic experience platforms to AI-ready content management. Three capabilities now separate a platform that is serious about this from one that is not: the Model Context Protocol (MCP), which lets external agents query and update content through one standard interface; autonomous agents that behave like digital teammates; and answer engine optimization, which structures content so it surfaces accurately inside tools like ChatGPT and Perplexity.

And the whole category is converging on the same destination. Headless-native platforms like Sanity, Contentstack, and Storyblok others are all racing to add agents, automation, and AI-assisted authoring. When everyone is heading for the same place, the differentiator is no longer whether a platform has AI. It is how that AI is governed and orchestrated.

So What Is an AI Harness?

Even the most capable models today are prone to hallucination, blind to context they are not explicitly given, and easy to push outside the bounds of what an organization would allow. That is why almost no one uses a raw model directly. They use a harness: the code around the model that improves the quality, safety, and reliability of what comes back. A harness augments the query, enforces guardrails on input and output, and adds tools that give the model real capabilities.

Think of your AI model as the engine: the part that makes your reasoning system go. The harness is the vehicle built around it: the controls that point it in the right direction, change gears when the situation calls for it, and bring it to a stop when needed.

If you list what a good AI harness needs - structured content the model can reason over, access control, deterministic workflows, versioned and reviewable configuration, and centralized governance - Drupal has shipped every one of those for years, for reasons that had nothing to do with AI. The model at the center is a commodity. It is swappable, replaceable, and never the true value driver. Everything Drupal wraps around it is the durable part.

Which leads to the line I kept coming back to: what drives the value of intelligent systems is your schema, not your prompt. Prompts are transient. Typed fields, entity relationships, and taxonomy give a model unambiguous ground truth instead of prose it has to guess at. And the same JSON:API structure that feeds your decoupled front end is exactly what an external agent inspects and reasons over. Drupal orchestrates the content and context; the external model supplies the intelligence. That division of labor ages far better than trying to build models in-house.

Where You Actually See It Work

Everything above is architecture. The demo is where it becomes visible, and it is the part of the talk the audience responded to most.

I had set up a demo environment for a fictional company called Inspace. Ahead of time, I populated the Context Control Center with the things a real brand would have on hand: a brand guide, a tone of voice, documentation for a component library I had programmatically migrated from Drupal's Mercury design system into Code Components and synced into Astro, and a set of context items describing a new "Executive Suites" offering that Inspace was preparing to launch.

Then, live, I created a new page in Canvas, opened Canvas AI, and gave it one sentence: generate a landing page for the new Executive Suites offering. It went to work, and while it did, I took questions from the audience. A couple of minutes later it had assembled a full landing page out of real components, populated with relevant, on-brand content. To make the point that a human stays in the loop, I dropped an image from the media library into the hero component and published. Then I switched to the Astro app, navigated to the same path, and there was the identical page - every decision the human and the model had made, rendered by the decoupled front end. A complete landing page, start to finish, in a couple of minutes.

The second beat pushed further. The marketing team wants a brand-new component: a call to action for a waitlist. I asked Canvas AI to build a full-width announcement banner with an announcement pill, a headline, a supporting line, and a primary call to action. After a short pause, the component appeared in the Canvas interface - colors on brand, formatting consistent with the rest of the library - with its code fully visible and editable and a live preview I could resize to check different breakpoints. I noted that in the real world you might refine the code yourself or ask Canvas AI to iterate, then saved it to the library, dragged it into the Executive Suites page, and published.

When I reloaded the Astro app, it threw a fatal error, exactly as I had planned. The layout now referenced a component the front end did not know about. One npx canvas push from the command line synced the components, a refresh brought the page back, and the new banner rendered cleanly in the Astro layout. That deliberate stumble made the architecture legible: content edits flow to the front end instantly, but new component code is a real, versioned artifact that moves through a real workflow.

I closed the demo by going back to the Context Control Center, because that is the intelligence that made the rest possible. This is what AI prompt grounding looks like in practice: before a single token is generated, each request is automatically supplied with the brand voice, domain knowledge, and guardrails relevant to the task at hand. Some context items are global and travel with every request. Others are scoped specifically to working in Canvas. Others still apply only to content about the Executive Suites program. All of them were assembled automatically behind those short prompts - which is why one sentence was enough to get on-brand, relevant output. I finished on the form for managing a single context item, showing the range of ways its use can be scoped and restricted. Compliance before generation, not review after.

Why Enterprises Can Trust It

For regulated and enterprise teams, governance is where this stops being a demo and starts being a decision. Drupal is model-agnostic by design: dozens of providers sit behind one abstraction layer, spanning cloud services like OpenAI, Anthropic, and Gemini as well as self-hosted options like Ollama and Mistral for data sovereignty. Swapping providers is a configuration change, not a rewrite of your schemas or your logic.

Agents act inside Drupal's existing permission model which includes the Access Policy API, so the access logic that already governs your people governs your agents too - no separate guardrail layer to maintain. Deterministic orchestration through the Event-Condition-Action (ECA) or FlowDrop frameworks handle rules-based logic that costs no tokens and never hallucinates, which is a useful reminder that the cheapest, most reliable AI call is often the one you do not make. And because that orchestration lives inside the platform as native state machines - ECA for event-driven rules, Maestro for durable, multi-step approvals - stateful business logic runs where the content lives, rather than being stitched together from external webhooks, serverless functions, and third-party glue code. Guardrails filter sensitive data before it leaves the server, and metering tracks token spend by user and role so finance can see what AI actually costs.

An Honest Read

It doesn't serve anyone to pretend one side wins everything, and I said so in Montréal. The headless-native platforms lead on real things: faster time to value, a cleaner developer experience, and more polished agentic tooling in market today. If those are your priorities right now, they are genuine strengths.

Where Drupal leads is open source with no lock-in and dozens of documented APIs, model-agnostic freedom, deep governance and orchestration, and fit for enterprise, multi-brand, and regulated environments. It is also worth remembering the shape of the thing behind it: an open ecosystem moves at the speed of everyone who needs it to, while a single-vendor roadmap moves at the speed of one company's priorities.

The Takeaway

The way I put it at the end of the talk: we gave up the editorial experience to go headless, and in 2026 we stopped having to. The original headless win is now additive with the editorial win, not traded against it. One structured content model can serve four consumers at once - a decoupled front end, editors in Canvas, internal AI agents, and the wider martech stack over MCP.

Drupal is not a CMS with AI features bolted on. It is a governed AI harness that happens to have been building the right foundations for 20 years. If you want to see it for yourself, start with Drupal CMS 2.0 and Canvas, then explore the AI, context, and MCP modules. For teams that would rather not set up and host Drupal themselves, Acquia Source CMS offers a fully managed on-ramp to the same platform. And if you are ready to help shape where this goes, the Drupal AI Initiative is where the work is happening.

Making that case in Montréal was a highlight of my year. If you were in the room, thank you - the questions were sharp, and a few of them changed how I will explain this next time. If you were not, come find me, and we can pick up where the talk left off.