Over the past two years, Pantheon has been quietly building a product for the AI Era of the web. We didn’t want to rush this or take the task lightly. “Don’t just sprinkle AI on it” has been a non-negotiable in our product strategy, and I’m confident it was the right line to hold.
This week, at our GoLive user conference, we unveiled what we’ve been cooking.
The centerpiece is the AI-native web composition layer we call P1. It helps teams and agents manage content, but it’s not a CMS. It’s what we think you need to succeed in a “post-CMS” world. I don’t mean that in the sense that CMSs don’t exist or don’t matter, but now that AI can translate across systems so effectively, the particular technology matters much less than that a source of truth exists, that the information is organized and of high quality.
P1 in a Nutshell
Here are a few features that we’re most excited to ship, the things that I believe truly set P1 apart.
Visual editor governed by components
The surface of P1 is a page-building interface that enables site editors to assemble pages from React components. That’s table stakes. What makes P1 special is that these components are governed by a design system, and the components themselves govern what is editable by humans or AI. If you have a Storybook, you can start building real websites with P1 with no extra effort.
Multiplayer mode for Humans and Agents
P1 is built with the assumption that sites will be worked on by multiple people simultaneously, and that AI agents should be part of this team, not siloed assistants hiding behind a human. So we have built-in real-time collaboration for the whole team, including identity management for any AI players in the mix — whether that’s our first-party agent we call “Zappy,” or your Claude — so that there’s always full visibility and accountability into who changed what.
Workflow for Code, Content, and Config, all together
With P1, we had the opportunity to rethink the architecture such that we can now allow customers to develop, preview, and most crucially deploy changes that cut across code, content, and config changes in a unified workflow. Branch and merge for the whole site. It’s insanely cool.
These capabilities all build upon one another to deliver AI Era speed, without loss of control. Component governance makes AI safe to use in production; bringing agents into the workflow directly and accountably demystifies who is doing what; the ability to work on small or sweeping changes in a workstream — while still deploying with one click of a button — lets teams get everyone on board before they go live.
Why not build on an existing CMS?
Given our history of helping Enterprise teams make the most of WordPress and Drupal, one common question I get when showing Pantheon’s P1 to customers, partners, or community members is why we didn’t build it on top of an existing open-source CMS? They both have great page builders in Gutenberg and Canvas, and there’s a lot of existing open-source technology we could leverage, and that’s our heritage, right?
Believe me, we thought about it. A lot. And our conclusion was we shouldn’t.
Part of the answer is where in the stack P1 sits. It lives on the front end. Spoiler alert: P1 sites are built in Next.js. That doesn’t mean WordPress or Drupal exit the picture; in fact, we’re already seeing instances of customers pulling content from them as backends to power pages that have their end-user-facing layouts managed via P1. Existing CMSs have a long-term future managing libraries of content, but our feeling was that wasn’t where it made sense to invest in a system to manage the visitor experience.
But the bigger reason we had to start fresh is that P1 is so much more than a page builder. It’s simply not feasible to create what we have created on a 20+-year-old foundation. That’s not a knock on existing workhorse technologies; it’s just acknowledging the technical capabilities and limitations of the LAMP stack vs. our vision for what web building has become in the AI Era.
More Than a Pagebuilder: an Opinionated AI-Native Web Composition Layer
P1 lets non-technical users intuitively create web pages, but that’s not what makes it special. The pagebuilder UX is just another open-source project (which, incidentally, is also how we stay true to our value of avoiding vendor lock-in for customers; more on that later). It’s certainly a nice user interface, but the ability to drag-and-drop blocks around is table stakes at this point. It’s commodified.
What makes P1 unique is the opinions and insights we’ve built into and around that “no code” composition interface. This is why we had to update:
- In modern parlance, P1 is an AI harness, something that’s not reasonable or responsible to build out at scale within the confines of any LAMP stack application.
- Staging and merging updates to site content alongside code changes required moving beyond traditional relational database architecture.
- Building around design systems and ensuring a first-class frontend developer experience meant going natively JavaScript was no-brainer.
While workarounds exist for every technical limitation, when we objectively thought about the “best tool for the job” across these three load-bearing capabilities, every signal pointed in the direction of building fresh on a modern stack. So that’s what we did.
As with our overall approach to AI, I’m confident this was the correct decision. But it’s worth taking a few moments to unpack each of these things, not just in terms of what we’ve built, but also why and how.
Agentic Orchestration and Real-Time Collaboration
P1 doesn’t just embed a chatbot to help with site administration. It’s an AI harness for doing the work of building and maintaining websites, a multiplayer collaboration canvas for an agentically augmented team. Both from within the UI and “outside-in” via MCP, the system is designed for AI to pick up and run tasks in parallel with humans, with transparency and accountability into who did what at each step of the process.
One of our strongly held opinions is that the utility of AI hits a low ceiling when it’s siloed into the role of an individual personal assistant. Teams need visibility into what was AI-generated vs. human-made, and they need the ability to work collaboratively in real-time rather than having everyone go off to ask their own chat to help out with an individual task.
All of that adds up to P1 managing a lot of work farmed out to models in parallel. There are a lot of great things about PHP, but some of the design tradeoffs that make it so killer at high-throughput web transactions also mean it’s a poor technical fit for this kind of agentic workload, which demands long-running asynchronous threads and streaming inputs and outputs.
The control plane for agentic processes is super important, as Dries Buytaert wrote about last year, and while it’s true that you can make your PHP application serve this role, as Acquia’s Martin Anderson-Klutz described, it’s never going to be scalable or reliable due to a lack of asynchronous I/O.
As I’m sure someone will point out, streaming/async PHP is technically possible. Fibers were introduced in PHP 8.1, but not widely implemented. More importantly, neither WordPress nor Drupal is designed to work that way.
Conversely, JavaScript/TypeScript and Node.js are natively async. They have a vast and growing ecosystem of open-source libraries and projects for building and orchestrating agents. Add in the fact that “real-time multiplayer” is table stakes for any productivity tool these days, and the way that’s done is based on JS, and the decision was clear.
Staging and Merging for Code and Content
One of the holy grails of web operations is to develop, stage, and deploy a wide-ranging set of changes for a site without having to call for a content freeze in production. Big releases take time to set up, let alone to get sign-off for, and it’s anywhere from extremely painful to completely unacceptable for a website that matters to not post anything for an hour, let alone days or weeks.
Well-resourced teams have historically gotten through this challenge with carefully crafted implementations and release processes. Painstaking setup, custom scripts, meticulous attention to data structure, often still requiring a lengthy (and therefore off-hours) maintenance window for deployment. It’s doable, but it’s expensive and risky, and even under the best circumstances it’s… annoying.
With P1, we realized we had a chance to solve this as a core part of the system. Building on our historical expertise in multi-environment management and the branching and merging of code, we’ve created a system where content+code staging “just works” across any aspect of the site. For industry veterans, this part of the demo feels fully magical, but we think that within a few years this will be a basic expectation, as will having the ability to track all changes and revert to any point in time (à la “time machine”) instead of nightly DB backups as an option to restore.
Beyond the big launch use-case, this kind of staging is the required backbone for a high-quality automated testing regime. This is how you ensure that every change is production-ready, and how you can bring agents into the production workflow without losing accountability.
Achieving this required us to break with the traditional RDBMS approach that established CMSs have used since the LAMP stack first became a thing. Building on a different set of assumptions opens new possibilities, and DB tech has come a long way over the past two decades. Another data point in favor of starting fresh.
Front End is First-Class, and Components are King
As we studied how the modern AI-era web was being built, we developed a very strong opinion that the most important unit to prioritize was the frontend component. By that we mean the individual block or box of content that a human reads as a whole thing, and no coincidence the unit at which it makes sense for people (or agents) to edit.
At the same time, the recipe for success for organizations needing to govern even a modestly complex surface area was becoming clearer. Even pre-AI, design systems were significantly improving the work of building and managing fleets of sites, apps, experiences, etc. Today they are the indispensable artifact for governing brand, accessibility, and quality at scale, for making every site part of one system.
We built P1 around the core opinion that such a component library (aka design system) is the foundation for everything. It describes the blocks that human users or agents can build with, what is permissible to change and configure, and can be used not only to drive adherence to standards, but also to manage change as standards naturally evolve over time.
Along with that, we wanted to make sure that in P1 the creativity of frontend developers to build rich interactive and evocative experiences was unfettered. While both WordPress and Drupal have made moves towards React-based block models in Gutenberg and Canvas, they still force a kludgy experience on frontend devs because ultimately their JavaScript components are getting embedded inside a PHP application vs. running natively the way they would expect.
With P1, if you have a Storybook, you are minutes away from using that to build websites. The front-end components directly drive the back-end editorial UI. No translation needed.
We also still support custom functionality. The frontend framework for P1 sites is native Next.js, with Pantheon CI/CD; so you can have your dev team (or coding agents) do integration or UX work that’s beyond the reach of component assembly, but with a first-class DevOps pipeline.
Likewise, the API backend is well-documented, curated, and scalable GraphQL. These are the tools of the modern trade.
True to our Open Source Roots
Another question I get asked a lot is, “So you’re pivoting from open source and towards a proprietary SaaS tool?” And the answer to that is a firm “no.” While we’ve done a lot of incredible things to make P1 a unique and awesome tool, we’re also staying true to our historical approach to ownership. The code, content, and data for every site on Pantheon belong to you, and if you want to run it somewhere else, that’s easily done.
As I mentioned in the intro, the basic page builder in P1 is based on an open-source project called Puck, and as I just explained, the end-user-facing front end is just another Next.js site. These export cleanly from the platform (along with all the content) and can be self-hosted or set up on a number of other platforms.
What doesn’t export is all the workflow, but that’s nothing new. Historically speaking, you’re free to take your Drupal or WordPress site from Pantheon to any other platform, but MultiDev only exists with us. Upstreams are a part of our dashboard now. Our long-beloved CLI (and freshly launched REST API and MCP endpoints) are obviously attached to the platform. The tightly-integrated CDN isn’t something you can export, for obvious reasons.
Same story with P1: sites can be exported and run elsewhere for free, in every sense of free software, including the ability to continue editing content with Puck. But you won’t have multiple environments, and the workflow layer for AI agents will need replacing, as will the process for flowing changes from a component library, automatically testing changes before they go live, time-machine, and the rest of what we provide as a wrapper around the actual live-site experience itself. Oh, and the CDN/WAF security layer is still tightly integrated, naturally.
There’s also a material role for existing open-source CMSs to play in many P1 implementations. As I said, P1 isn’t really a CMS in the classic sense: while it has a data model that understands content types and templates, we’ve focused on the work of managing components and component-based experiences. A lot of people need a robust, canonical, structured content library as part of their solution, and P1 doesn’t pretend to be the best tool for that particular job.
What P1 does have is an awesome data-integration layer for people to connect to the systems where they already manage repositories of posts or traditional databases of information that need to surface on the web. P1 is the layer where people and agents work together to ship fast and ship right. We fully expect that larger implementations may include a traditional CMS (or three) to manage larger libraries of structured information that are canonically stored elsewhere.
Those could include a Shopify API endpoint for the product catalog, or a Google Sheet containing a staff directory/bios, or an existing WordPress or Drupal instance where existing content is built and maintained. We’re already seeing several interesting permutations playing out with our charter customer cohort, and look forward to building more integrations and tooling as use-cases come up.
Standardize to Modernize
The AI Era of the Web demands we move forward. Expectations have changed. The way we do the work has changed. The external threat environment has changed. The old ways no longer serve us.
But change isn’t easy, and the web isn’t a greenfield unless you’re a brand-new startup. Most organizations have a few decades, if not more, of heritage in their online presence. It’s difficult bordering on irresponsible (if not impossible) to make a single decision to go all-in on any particular technology.
Our alignment has always been to the craft, the mission, the work that needs doing, over and above any codebase. What we offer the market is the ability to leverage the best of what AI has to offer in terms of automation and efficiency, across the best of what open source has to offer in terms of web frameworks.
We’ve also always been opinionated, and that’s not going to change. We vertically integrate the mission-critical components, reducing the seams that create integration, ownership, security, and support burden.
We’ve always known multi-site was a kludge. We have workflows that have been proven bulletproof over 16 years in the business. Our way works: a perfect launch, every time. We’re taking that confidence into the next era of the web.
With P1, we have a winning recipe for organizations with the most demanding use cases, but also for anyone who is trying to figure out how AI becomes a real value-add to their team, or who just wants to get the most out of modern web development in multiplayer mode.
If you want to know more and join us on this journey, sign up for the beta and help us build what’s next.
