The previous posts are the idea. This one is extra, on why my head goes to Drupal for it, and what I think we should do about that.
None of the idea needs a particular tool. But the obvious next question is what I'd build it on, and the honest answer starts with a bias I'd rather name than hide. I know Drupal. I've worked in it for years and I contribute to it.
When you vibe something, you don't pick the stack. The AI does. The two projects I've looked at were built with different tools and different models, and both ended up with a JavaScript front end with Supabase behind it. That works. But Supabase is a database with some services around it. No content model, no revisions, no editorial workflow, no roles.
Drupal has all of that, and it keeps getting better at it.
So here is the first thing I'd say to anyone building this. Ask the AI to use Drupal as the framework. Point it at the AI module and everything the community has already built around it, and what comes back is a more capable tool than the JavaScript and Supabase flavor you get by default. The front end can still be whatever JavaScript tool you like. Drupal has allowed that for years.
It also has most of the machinery for what I described earlier. It works with Activepieces, n8n and Maestro through the orchestration module, and that integration is being made better every day. So it can sit in a workflow or feed one. You can configure agents through a UI. And it doesn't care much which model is behind it.
That last one is worth a second, because of something from the meetup. People were joking about how hard it is to change your AI backend once you've built on one. Somebody swore his results got worse right after he mentioned he was switching providers. Everyone laughed. Everyone in that room was stuck.
Maybe we should have a Drupal AI the way we have Drupal CMS.
That is why I think Drupal is the answer here. The way the AI work was built in Drupal, it basically masquerades who the backend provider is. And it doesn't stop at the provider. Agents, the context control center, translations, metering, and a long list of things already built and working, none of them tied to whoever is behind the model this month.
And that is where the wish comes in. For Drupal to be the answer the AI gives when somebody asks it to build this, maybe we should have a Drupal AI the way we have Drupal CMS.
Kristof Van Tomme kept saying, at API Days and again at Drupal Pivot, that Drupal is good at native AI applications and could focus there. I tend to agree. Look at what people are doing right now. They're forcing AI onto frameworks that never had it, and building their own connections, their own controls, their own administration. Those are the things Drupal spent years solving.
None of it is finished, and the community says so out loud. The people working on this published their own assessment, and it says plainly that Drupal "still makes agents work too hard to reach the advantage." That's them criticizing their own platform in public.
The same assessment has a line about configuration, which in Drupal means the exported settings that define how a site is built. Content types, permissions, workflows. All the accumulated decisions, saved as data.
"Configuration records what was decided, rarely why."
That's the whole thing I've been trying to say about the hotel. The system holds what was decided. It doesn't hold why. Maybe I'm not the first one to notice.
So it needs work, and the work is happening. Which is fine, because the alternative is worse.
This is the same rule I make my AI follow before it writes anything. Look for prior art. Reuse before you extend, extend before you build, and only build when nothing fits. That rule doesn't stop applying when the thing you're choosing is the foundation. Build your own and you own it forever, every version and every security fix, and you'll spend your time maintaining scaffolding instead of the thing you actually care about.
And there's the part that matters most to me. If a company's operating knowledge belongs to the company, then the layer holding it has to be something they own rather than something they rent. Otherwise you've taken the most valuable thing they have and put it somewhere they can be evicted from.
Open source isn't a preference in that sentence. It's what makes the claim honest.
So this isn't that Drupal is the only answer. There may be other great fits out there, and I hope the people who know them make their case the way I'm making mine. But everything I just walked through, the editorial machinery, the provider masquerading, the ownership, a community maintaining the foundation with you, makes Drupal a really good fit for this. What's missing is making it one of the answers the AI actually gives, and that's work this community knows how to do.
All of this is opinion. It's also a decision, the one I'm making about where my own work goes from here. I could be wrong. I'd rather be wrong on something I chose than right on something the AI picked for me.