DEV Community: Santiago yie

Is Drupal Still a CMS? Its New Role in the Agentic Stack

Santiago yie — Wed, 19 Aug 2026 22:15:40 +0000

For most of its history, Drupal has been easy to describe: a CMS, or for developers, a content management framework.

That is still true. But in 2026, it is becoming incomplete.

Through projects such as AI Search, AI Agents, Tool API, and MCP Server, Drupal can now participate in RAG pipelines, expose application capabilities as tools, and allow external AI agents to interact with a site.

What makes this interesting is not that Drupal suddenly "has AI."

It is that much of the architecture agents need was already there.

Drupal already had the hard part

A mature Drupal application already knows how to represent structured entities, relationships, permissions, revisions, workflows, configuration, APIs, and services.

Drupal doesn't just store documents. It stores structured domain knowledge together with rules governing what can be done with it.

In the emerging agentic stack, that maps surprisingly well to three concepts: context, skills, and tools.

Drupal content can become context. AI Search can retrieve relevant entities through semantic search and feed them into RAG pipelines.

Drupal capabilities can become tools. Tool API can expose operations such as:

search_content(query)
create_article(data)
publish_content(entity_id)
create_taxonomy_term(vocabulary, name)

And higher-level combinations of tools, instructions, and domain rules can become something closer to skills: reusable capabilities for operating a particular Drupal application.

But there is another piece: the harness.

Drupal doesn't have to be the agent

This distinction matters.

An agent is more than an LLM with access to some tools.

The harness is the runtime around the model: the system that decides what context to provide, which tools are available, how many steps the agent can take, how failures are handled, when human approval is required, and when execution should stop.

That harness might live in an external coding agent, an automation platform, or a custom agent built with something like LangGraph.

Drupal can sit underneath it:

             Agent Harness
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    Context     Skills      Tools
       │          │          │
       └──────────┼──────────┘
                  ↓
                 MCP
                  ↓
                Drupal
          ┌───────┼────────┐
          ↓       ↓        ↓
       Content  Actions  Permissions

This is where Drupal's role becomes more interesting.

Drupal does not need to replace the agent framework.

It can become the governed environment the agent operates against.

From CMS to context engine

Drupal's AI Search project integrates embeddings and vector search with Search API.

A Drupal site can therefore expose its structured content as semantic context:

Drupal entities
      ↓
Search API
      ↓
chunking + embeddings
      ↓
vector database
      ↓
semantic retrieval
      ↓
agent context

For organizations whose authoritative information already lives in Drupal, this removes an awkward duplication.

Instead of maintaining Drupal as the CMS and building an entirely separate knowledge system for AI, Drupal itself can participate in the retrieval architecture.

From APIs to agent skills

The other direction is action.

Tool API allows Drupal operations to be represented as structured capabilities. MCP Server can then expose those capabilities to external MCP-compatible agents.

An external agent could discover that a Drupal application provides tools for searching content, managing taxonomy, creating drafts, or triggering workflows.

The harness decides when to use them.

Drupal decides whether the operation is allowed.

That separation is important.

Giving an LLM unrestricted database access is easy. Giving an agent a small set of explicit, permission-aware capabilities is much safer.

And this is where some of Drupal's old complexity suddenly becomes valuable.

Entities, permissions, revisions, moderation, workflows, plugins, and configuration were originally designed to control what humans could do.

Now the same architecture can help control what agents can do.

So, what is Drupal now?

Drupal is still a CMS.

It is not suddenly a replacement for LangGraph, an agent runtime, or a general-purpose Agent SDK.

A more useful description is that Drupal is becoming a possible application and governance layer in the agentic stack:

Drupal entities     → context
AI Search           → retrieval
Tool API            → tools
Domain workflows    → skills
Permissions         → governance
MCP                 → interoperability
External runtime    → harness

That distinction matters.

Humans see pages, fields, forms, and workflows.

Applications see APIs.

LLMs see context.

Agents see tools and skills.

The harness sees an environment it can operate.

Drupal spent more than two decades building systems for structured knowledge, permissions, workflows, and controlled operations. AI agents now need many of those same things.

So perhaps the interesting question is no longer:

"Is Drupal still a CMS?"

It is:

"Could a CMS become the governed application layer behind AI agents?"

Drupal is starting to make a surprisingly strong case that it can.

I rewrote my AI-agent tool from Bash to Python. That was the easy doubt.

Santiago yie — Thu, 16 Jul 2026 18:27:14 +0000

There are, conservatively, nine thousand tools for running AI agents across your projects. This is number nine thousand and one. I know. Stay a second anyway.

Eighteen years of backend work, most of it PHP, most of it through agencies — which is a polite way of saying I've spent my career as a line item in someone else's staffing spreadsheet. Several projects at once, different clients, different timezones, "resource" being the official word for what I am on a good invoicing day. So when AI agents got good enough to do real work, I didn't wonder whether one could write code. I wondered how I'd wrangle a whole fleet of them across projects — which, I eventually noticed, is me trying to become the manager of a little spreadsheet of resources, after eighteen years of being one. The snake found its tail. I built it anyway.

Docket, then: a control plane for running OpenClaw agents across projects, made with heavy AI assistance on purpose — the point was to close my own gaps, not to prove I could type from memory. It started as a Bash CLI; it's now a tested Python package. On GitHub, beta, link at the bottom. This is me thinking out loud in public, not selling you anything.

And somewhere in that rewrite, the doubt everyone expected me to have — is Bash the right language? — died, and a worse one took its place. That worse one is what this piece is actually about. Let me get there honestly.

What I aimed for, not what I mastered

I want to say this before the vocabulary makes me sound like I know more than I do. I did not sit down understanding context isolation, or git worktrees per agent, or anti-corruption layers. I sat down wanting clean, stable, maintainable, tested code — and I steered an AI toward that shape until it held together.

The shape is real. My grip on every part of it is not the same.

What the shape does, plainly: OpenClaw is a local-first agent daemon, great at running one agent. Run a fleet and you hit problems it doesn't solve. Docket runs pods — a Lead that owns context and talks to me but never touches code, an Implementer that does, optionally a Reviewer and Tester. Each project is walled off from the others. Each agent has a hard spend cap that pauses it when the money runs out. Nothing risky happens without an approval gate.

That's the honest brochure. It reads like a product. Hold onto that feeling.

Doubt 1: is a control plane the right thing for one person?

I answered the Bash question by leaving Bash — no types, error handling by discipline, testing as a craft. Python gave me a safety net Bash structurally can't.

But what I built is Kubernetes-shaped thinking for a fleet of mostly-me. The people who build this shape are solving real multi-tenant problems. I'm one guy with a handful of projects; I could probably survive on a shell script and some discipline.

So did the problem need a control plane, or is building a control plane just how you learn control planes? I keep reaching for the flattering answer. I've stopped trusting myself when I do.

Doubt 2: is there a use case, when first-party tools are this good?

If Claude Code, Codex, and Antigravity all ship great orchestration, who needs mine? Nobody who lives inside one vendor. Each is a walled garden — Codex to GPT, Claude Code to Claude, Antigravity to Gemini. None will happily run a mixed fleet where the Tester is on a cheap model, the Implementer on Sonnet, and the Lead on a free tier, under one budget and one policy.

That's the niche. Whether anyone's standing in it is another matter. The story only gets compelling for a team with governance and audit needs — the exact kind of org I'm not, shipping alone. "A real use case" and "a use case with real people in it" turn out to be different claims.

Doubt 3: the tests I trust and the tests I can't write

The deterministic half is genuinely covered — config, isolation, cost math, gate logic, pinned against the old Bash behavior so the rewrite couldn't quietly change meaning. Coming from PHPUnit, that part was easy.

The other half: the thing dispatches LLM-driven agents, and LLMs don't return the same answer twice. A unit test works because f(2) is always 4. A Lead → Implementer → Reviewer → Tester run has no such guarantee. Testing that properly — eval harnesses, judge models, regression across the whole pipeline — is a second project the size of the first, and I haven't built it.

The tested half is the half I know how to be proud of. The untested half is the half that decides whether the thing actually works.

Doubt 4: should this be public at all?

Against: chasing a fast-moving daemon is brutal maintenance, I'm adjacent to three of the best-funded eng orgs alive, and a repo with one contributor is a diary with a license file.

For: nothing forced me to understand a feature like having to defend it in public and write down where it isn't true yet.

So it stays open — not because I'm sure, but because the reasons for it are ones I believe on good days, and the reasons against are ones I believe at 2am. I ship on the good-day logic and try not to check the star count.

The doubt the other four stand on

I built this with heavy AI assistance, on purpose. So some fraction of what I call understanding is really me having supervised a machine that already understood — well enough to review it, argue with it, throw out the wrong versions. That's not nothing; reviewing well might be the skill now. But it isn't the same weight as the PHP that lives in my hands, and I can't always find the line.

I'm writing this with the same kind of help. Somewhere in here is a sentence I'd have phrased worse alone, and I've lost the ability to point at it. An essay about not knowing what I learned, co-written with the thing I learned it from. Sit with that. I'm trying to.

Would I bet my career on Docket becoming the standard? No. Would I build it again? Yes — mostly because I still don't know what I learned, and the only way I can think to find out is to build the next one with less help, and see what falls over.

So here's the door. If you run OpenClaw fleets and this problem is already yours — the mixed-vendor mess, the budget that quietly runs away from you — come look, and come break it. I'd rather hear where it falls over from you than find out alone at 2am. The repo's below.

Docket is open source (Apache 2.0, beta) at github.com/yielab/docket. Independent project, not affiliated with OpenClaw or the OpenClaw Foundation.

The AI Agent Solved Drupal's Easy Problem. Nobody Asked About the Hard One.

Santiago yie — Tue, 14 Jul 2026 13:50:48 +0000

Drupal now has an AI agent that builds your site by chat. Type a sentence, it wires up a field, spins up a content type, configures a view. Stuff that used to eat an entire afternoon of clicking through admin screens now happens in a chat bubble.

Very slick. Very "the future is here."

It also requires PHP 8.1.

The version number is the whole story

That requirement is Drupal's extremely polite way of saying: this feature is not for you, specifically, if the institution you work with is still running software from the Obama administration. Drupal 7 shipped in 2011. PHP 8.1 didn't show up for another decade. If you've spent any time around government, nonprofit, or higher-ed Drupal installs, you already know exactly which sites that excludes — and it's not a small number.

So there's an immediate, practical split: newer Drupal 10/11 sites on modern PHP get a genuinely useful productivity tool. Everyone still running Drupal 7 or an early 8, which in my experience is a lot of institutions, gets nothing from this except one more reason the upgrade gap keeps widening.

What the agent is actually good at

Here's the part worth sitting with, though. The agent is genuinely good at the part of Drupal work that was always the boring part — field wiring, content type scaffolding, boilerplate views. That's real. I'm not being sarcastic about the "slick" part.

Which leaves the developer doing migration work holding exactly the part that was never really teachable: the instinct for which piece of a fifteen-year-old install is load-bearing, and which is scar tissue nobody removed. That instinct comes from having broken things on production sites, or from having read someone else's undocumented hook_update_N() at 2am and had to reverse-engineer why it exists.

Either that's the most secure seat in the room right now — the work an agent can't touch yet — or it's the last seat left before the room empties out entirely. Hard to tell which, from inside it.

The decision that got harder, not easier

Meanwhile the institutions I work with aren't just choosing between Drupal versions anymore, which is its own quiet shift. Migrate to 10 or 11, sure. But also: stay in the Drupal family at all, or take the "rip it out" option and leave for WordPress, or go static, or hand the whole thing to a headless setup an AI agent can plausibly assemble.

And underneath that, a second question nobody used to ask out loud: pay the traditional agency's markup, or hire a handful of contractors directly and coordinate it yourself, now that an AI assistant can plausibly do the project-management glue work an agency used to justify its cut with.

More options, more tools, more paths that technically work. And somehow the actual decision is harder to make than when there was just one obvious next version to upgrade to.

Dries Buytaert — Drupal's founder — ran an experiment recently asking an AI coding agent to recommend a CMS stack for a typical institutional project. Drupal's structured content model and explicit APIs should be exactly what an agent wants. But the agent flagged something it called "session-time risk" — too much friction in the first hour of getting a working, verifiable site up. Capability wasn't the blocker. The first-session experience was. That's a strange new axis to be judged on, and it's not one any of us were optimizing for a few years ago.

I don't know if that's a Drupal problem specifically, or just what "too much change, arriving all at once" does to any institution — regardless of which CMS, or which staffing model, happens to be running underneath it.

Curious whether other people doing long-running CMS/migration work — Drupal, WordPress, whatever — are seeing the same shift: not "will AI replace X," but "the menu of options got long enough that choosing well is now the hard part." What does that look like from inside a WordPress shop, or an agency that isn't CMS-specific at all?

My roommate partied all night in Rio. I ended up building local-first JS on the stairs.

Santiago yie — Tue, 30 Jun 2026 19:10:40 +0000

2012, Rio de Janeiro, Carnival week. I was playing digital nomad before that was a phrase anyone used — staying in a rented room, splitting it with a roommate who was still asleep at noon because the whole night had been spent out celebrating. Couldn't work inside without waking him up, so I took the laptop out to the staircase of the building instead. Client was in Bogotá: an equipment rental company whose reps needed to build quotes on the spot at venues with no WiFi. So the catalog, the pricing logic, the whole quote state lived in the browser — no server round-trip per calculation, just local storage doing the persistence. Local-first before "local-first" was a name anyone used for it. App itself was hosted on Heroku for whenever a connection did show up.

Samba through the wall the whole time. Carnival two blocks away. I tested it with my own WiFi off to make sure it actually held up with zero connection, then sent the client setup instructions for their reps and called it done.

Looking back, I'm not sure how much of that was a real engineering challenge and how much was just the tools of the time being clunky for something that's almost trivial now — local-first patterns are basically a checkbox in a lot of frameworks today, and I genuinely don't know if an agent would've had this solved in twenty minutes flat. Maybe the staircase was the hard part, not the code.

Anyone else have a "the deadline did not care what was happening outside" story?