The question that changed how I talk about AG-UI in Drupal

The argument I went in with

Most AI in Drupal right now lives in a chat popup bolted onto the corner of the page, disconnected from whatever the visitor is actually looking at, and disconnected from the components that make up the page itself. Ask it something about the content in front of you and it answers in a text bubble, next to that content, never inside it.

The talk’s argument was that this is a UI failure, not an AI one. AG-UI, the emerging protocol for connecting an agent’s actions to real interface state, lets an AI response render as an actual component in the content layer instead of a message in a sidebar. Ask for a comparison and get a real comparison table component, built from the same Single Directory Components the rest of the page uses, sitting where a comparison table belongs rather than described in prose inside a chat window. That’s what ai_components is: a set of Drupal components built to be targets for an agent to render into, rather than UI a human assembles by hand.

What landed in the room

The demo landed well. Asking a question and watching a real, styled, on-brand component appear inline is a different experience than reading an AI’s description of what such a component might look like, and DrupalCon Chicago’s crowd is exactly the audience that notices the difference between “the AI described a table” and “the AI rendered one.” That part of the argument, I still believe completely.

The question that stuck with me

During Q&A, someone asked: if an agent can render any component on the page, what stops it from rendering one that breaks the site’s accessibility contract, or inserts a component in a context its design was never meant for. Say a call-to-action component nested three levels inside a body field, where the site’s actual editorial guidelines would never allow that.

I didn’t have a good answer in the room. I said something about component props being constrained by their own schema, which is true and also not the point. A schema constrains what values a prop can take, not whether the component should appear at all in a given context. The honest answer is that the talk had spent most of its time on the capability and very little on the governance problem that capability creates the moment it’s real. An agent choosing to render a component is a structural decision about the page, and Drupal doesn’t currently have a clean way to say “this component is a valid target for an agent in this context” the way it has ways to say what a human editor is allowed to place where.

What I would say differently now

I’d open with the governance question rather than let it arrive as a question I wasn’t ready for. The capability is the easy half: components, schemas, a rendering target for an agent to hit. The half that actually determines whether this is safe to ship on a real higher-ed platform is closer to permissions: which components an agent may render, in which regions, under which conditions, reviewed the same way a new block type or content type would be. ai_components doesn’t solve that yet. It gives you well-formed targets for an agent to render into; it doesn’t yet give you a way to say which of those targets an agent is allowed to choose without a human in the loop.

That’s the actual next piece of work, and it’s a different kind of problem than the demo suggested. Less “can an agent produce a good component” and more “what’s the Drupal-native version of a permission system for structural decisions an agent makes about a page.” I don’t have that built yet. If DrupalCon’s audience is any signal, I’m not the only one who noticed the gap the moment the demo stopped being novel and started being something you’d actually want to run in production.