The AI-Ready CMS, Compared: What WordPress, Drupal, and Adobe Actually Built

For the first time, the AI-in-the-CMS conversation can be had with shipped software instead of roadmaps. All three major approaches are now real, purchasable, and different enough to compare properly.

WordPress 7.0 ships a standard AI API for the editor. It also ships an Abilities registry that tells outside systems, agents included, what a site can do. Drupal’s AI Initiative has delivered provider-agnostic agents into core workflows, with the code open to inspection. Adobe’s agents orchestrate inside the Experience Cloud, coordinated and managed as a suite.

Three architectures, three philosophies. We are not going to declare a winner. After twenty years of refereeing platform fights, we know the winner always depends on the buyer. What we can do is sharpen the questions that actually decide it.

The four questions that decide it

How does it integrate? WordPress gives you open, documented interfaces anyone can build against. Drupal gives you open internals your team can read, extend, and self-host. Adobe gives you rich coordination inside its walls, with managed connectors pointing out. Whether you value openness or coherence more depends entirely on how many other systems your AI future runs through.

Can you govern it? This is the real differentiator now. Adobe’s governance is the most productized: brand rules and audit trails as features you configure. Drupal’s is the easiest to verify. When the agent code is open, ‘what exactly can this thing do?’ has a checkable answer. In regulated sectors, that matters a lot. WordPress’s governance is solid but depends heavily on how carefully you configure it.

Whose lock-in can you live with? There is no dependency-free position in this era, only choices about its shape. Drupal lets you swap model vendors or self-host. WordPress lets you choose providers behind one API. Adobe manages the models for you, indemnified and theirs. Pick the exit costs you can actually afford.

What does it really cost? The suite’s premium against the open stack’s staffing needs. The review capacity that every agent deployment quietly demands. And the readiness work that every one of these architectures assumes and none of them includes.

Two evaluations from this quarter

The questions land better with examples, so here are two recent ones, anonymized.

A regional health system, heavily audited and compliance-driven, ran this comparison in the spring. Provider control mattered most to them, so clinical-adjacent workloads could run on approved or self-hosted models. Verifiable agent behavior mattered nearly as much, because their auditors ask for evidence, not assurances. The open stack won in the compliance review before anyone opened a feature matrix.

A multi-brand consumer company weighed the same questions and went the other way. They were already deep in the Experience Cloud, with a staffed operations team. One coordinated orchestration, one vendor accountable for it, brand governance enforced as product. They renewed into the suite with clear eyes about the gravity that comes with it.

Same quarter, same shipped field, opposite decisions. Both right. The same criteria led each organization to its own answer.

What all three still need from you

Here is what the vendor comparisons leave out. All three platforms assume work on your side. None of them includes it.

They all assume structured, governed content. An agent working from well-organized content can do useful things. An agent working from fifteen years of messy pages produces confident nonsense at scale.

They all assume someone owns the configuration. Permissions, logging, and review gates ship as settings. Unless a named person owns those settings, they drift toward the vendor’s defaults.

And they all assume review capacity. Every agent deployment we have watched converts a doing problem into a checking problem. The platforms generate more findings, more drafts, and more proposed changes than most teams can review. If the business case does not include reviewer time, it is wrong. On all three platforms, by roughly the same amount.

How to run your own version

Start with an honest read of your content operations. Well-governed, structured content gives any of these platforms something to work with. Sediment gets automated into more sediment, expensively, on all three.

Then weight the four questions by your actual situation. Compliance-heavy organizations should weight verifiability and provider control. Organizations consolidating on one experience stack should price the suite’s coherence honestly against its exit costs. Organizations whose AI plans run through many systems should weight the open interfaces.

And keep the oldest rule in platform selection: requirements first, demos second. The demos will keep converging. The governance setups are splitting apart right now. They are much harder to change later. That is where this decision will really be made. AI capability in a CMS is a governed-infrastructure question now, not a checkbox. Buy accordingly.