Pantheon P1 Brings AI Agents to Web Building Without Replacing Drupal

Hosting and WebOps company Pantheon unveiled P1 at its inaugural GoLive conference in Miami on 6 October 2026, introducing an AI-native web composition platform that allows developers, editors and AI agents to build and manage websites through shared design and publishing controls. The new platform supports Next.js and React-based experiences while connecting to existing content systems, including Drupal and WordPress. Pantheon announced a limited, paid beta on 8 October, with access subject to review.

Rather than replacing established content management systems, P1 introduces a separate layer for assembling, reviewing and releasing web experiences. Drupal can continue managing structured content, permissions and editorial workflows, while P1 handles visitor-facing presentation and related deployment processes. This division is central to Pantheon's approach as organisations explore how AI agents can participate in website development without bypassing established governance.

Following the launch, The DropTimes received detailed responses from Pantheon through discussions with Christian Yates, the company's senior vice-president of product, design and engineering, and Yulia Popova, its global integrated marketing campaigns lead. The responses addressed P1's architecture, its relationship with Drupal, AI permissions, publishing responsibilities and capabilities available during the beta. Additional materials from the GoLive demonstration illustrated how the platform connects to a Drupal API and uses approved components to construct pages.

Drupal Can Remain the Source of Truth

Organisations using Drupal do not need to migrate their existing content libraries to adopt P1. Pantheon explained that Drupal can remain the canonical repository for articles, structured records and other information, retaining responsibility for how that content is created, edited, reviewed and published. P1 can retrieve the information through APIs and display it through React components within a Next.js application.

The arrangement separates content management from experience composition. Drupal maintains the authoritative record, including its content model and editorial lifecycle, while P1 determines how externally sourced information appears within pages, templates and other visitor-facing elements. The precise integration depends on the available Drupal APIs, authentication arrangements and decisions about which platform owns each type of content.

Pantheon summarised the distinction in its written responses to The DropTimes:

That distinction matters particularly for organisations with extensive structured content. Universities, for example, may maintain course catalogues, staff profiles, programme information and admissions records inside Drupal. Such information can remain in its established content system while P1 supplies the components, layouts and workflows used to present it publicly.

P1 also includes its own content management capabilities, allowing simpler marketing sites to use it without a separate CMS. Pantheon's position is that larger implementations may benefit from retaining specialised content repositories rather than rebuilding their data models within a front-end composition platform.

GoLive Demonstration: Connected P1 to an Existing Drupal API

The relationship between the two platforms was demonstrated at GoLive through a university website scenario. Materials from the keynote showed a course catalogue being retrieved directly from an existing Drupal API rather than copied into P1. Course details, categories and related programme information were supplied by the Drupal endpoint and displayed through a listing component inside P1.

The demonstration went beyond presenting a static catalogue. Editors could open the listing component and select among different data sources, including academic programmes from the external Drupal API and internal content types representing events and counsellors. Changing the selected source updated the listing to accommodate the corresponding data structure.

That example demonstrated P1's ability to consume external structured data within its visual composition environment. It did not establish that Drupal and P1 share a single editorial workflow or that changes made in P1 automatically update Drupal's underlying content records. Pantheon's responses instead describe the systems as maintaining separate responsibilities unless an integration explicitly provides additional operations.

The keynote also demonstrated a university campus page created by P1's embedded AI agent, Zappy. The agent assembled a Montreal campus page from a supplied brief, drawing on an existing component library and media assets. Presenters subsequently showed homepage changes, including new calls to action, and explained how editors could inspect and refine the generated result.

Visual Editing Uses the Same Components as the Published Site

P1's page-building experience is organised around reusable React components governed by an organisation's design system. Developers define the available components and their configuration options, establishing boundaries around what editors and AI agents can assemble or modify. The platform therefore seeks to provide visual editing without allowing every new page to introduce an unrelated design or implementation.

The GoLive demonstration used a component library documented in Storybook, with presenters describing approved component combinations, contrast requirements and other design-system decisions. Those components formed the building blocks of the P1 editing environment. Pantheon also showed how an editor could navigate from a page into its visual editing interface through an on-page control.

A further architectural distinction concerns rendering. According to the demonstration, P1's editor uses the same application code that renders the visitor-facing website, reducing the difference between editing a page and viewing its published appearance. That approach allows developers to maintain their React components directly rather than creating a separate representation of each component solely for an editorial interface.

These controls are intended to support consistency and accessibility, although the use of an approved design system does not independently establish that every assembled page will meet accessibility standards. Content choices, component configuration, integrations and subsequent changes still require appropriate testing and review.

Why Pantheon Built P1 Separately From Drupal

Pantheon developed P1 as a separate system after examining the requirements of collaborative web development involving human contributors and AI agents. The company said its decision was not a judgement that Drupal or WordPress had become unsuitable for structured content management. Instead, P1 was designed for a different set of tasks involving real-time collaboration, asynchronous agent activity and coordinated releases across several kinds of website changes.

Three architectural requirements influenced the decision. The first involved an agent collaboration and orchestration layer capable of supporting multiple participants, long-running operations, streaming interactions and synchronisation across pages and potentially larger groups of sites. The second involved staging and deploying changes to code, content and configuration together. The third placed React components and the front-end design system at the centre of editing and governance.

Pantheon co-founder Josh Koenig expanded on these decisions in a technical explanation published on 16 October 2026. He argued that the asynchronous workload associated with agent orchestration favoured JavaScript, TypeScript and Node.js over extending a conventional PHP-based CMS to perform the same role. He also pointed to the difficulty of coordinating relational database content and application-code changes through one unified release process.

The distinction is an architectural preference for P1 rather than proof that Drupal cannot support AI-assisted workflows. Drupal provides its own content modelling, editorial workflow and extensibility capabilities, while projects such as Drupal Canvas have introduced component-based page building. Pantheon's approach places the composition and agent-orchestration layer outside the existing CMS, allowing that system to retain responsibility for structured content.

Technically, P1 uses Next.js for the visitor-facing application and React for its component model. Pantheon has described a GraphQL-based API backend and identified Puck, an open-source React visual editor, as the foundation of its page-building interface. These choices allow developers to work within the JavaScript ecosystem while using Pantheon's infrastructure to manage collaboration and deployment.

Workstreams Bring Content and Code Into a Shared Release Process

One of P1's principal operational features is Workstreams, a system for organising changes before they reach the live website. A Workstream allows an initiative to progress separately from production while contributors prepare, preview and review the proposed changes. Pantheon intends the model to support coordinated updates across code, content and configuration, rather than requiring teams to manage each category through an unrelated release process.

The concept builds on Pantheon's existing Multidev approach, which gives development branches their own environments for testing and previewing changes. Workstreams extend that principle into a more collaborative process for website teams. Several initiatives can move forward in parallel, with their changes compared against the live experience before approved work is merged and released.

Pantheon's beta release documentation, dated 9 October 2026, confirms support for protected Workstreams, review, merge, publishing and reversion workflows. It also describes the ability to compare proposed work with the live website and retain human approval of consequential updates. The precise behaviour of these operations remains dependent on the capabilities and configuration available within the beta.

For Drupal-backed websites, that release process has a defined boundary. P1 can govern the presentation layer and the changes it owns, but publishing a P1 Workstream does not automatically replace the editorial approvals or revision history associated with Drupal-managed records. Organisations must decide which changes belong in each system and how dependencies between them will be managed.

Zappy and MCP Connect AI Agents to Web Operations

P1 supports AI-assisted work through its embedded agent, Zappy, and through integrations using the Model Context Protocol (MCP). Zappy operates within the platform's editing experience and can help assemble pages, update content, perform localisation and modify approved elements of the visitor-facing interface. External agents can interact with P1 through compatible MCP tools rather than relying exclusively on the visual administration environment.

Pantheon described agents as participants whose actions should be attributable and visible to the wider team. The platform's collaboration model is intended to support human contributors and AI agents working on related tasks without losing track of the resulting changes. Its component restrictions and Workstream processes establish boundaries around the experiences agents are allowed to construct and release.

According to CMSWire's reporting from GoLive, remote agents may operate through an authenticated user context or use an access key associated with a separate agent identity and permissions. The distinction is important because an agent acting under its own identity can potentially be tracked separately from the human who initiated a task. The exact access controls and supported authentication arrangements depend on the relevant P1 capabilities and configuration.

Pantheon has also introduced a separate MCP Server beta for wider platform operations, including access to information about sites, environments, builds and deployment status. That service forwards the authenticated user's Pantheon identity and requires approval for operations that change resources. Its fleet-management tools should not be confused with every capability exposed through P1's own agent-assisted composition workflow.

Drupal retains responsibility for changes to content it owns. An AI agent that merely retrieves information from a Drupal API does not require authority to alter the originating records. Writing changes back to Drupal would require an approved API integration with appropriate authentication, permissions, editorial workflow and revision handling. Pantheon does not describe P1 as a replacement for those Drupal controls.

What Is Available in the P1 Beta?

Pantheon has made P1 available through a limited paid beta for qualified customers and partners. The company describes the product as usable for real production implementations, while cautioning that workflows, capabilities, documentation and recommended implementation patterns may change during development. Registration does not automatically grant access, and selected participants are expected to work closely with the P1 team.

The current beta includes visual component-based page building, reusable templates, AI-assisted editing, protected Workstreams, review and release workflows, and media management. Pantheon additionally confirmed to The DropTimes that real-time collaborative editing, media transformation, page metadata management, localisation, and template and content-type management are included. Zappy and MCP-assisted building are also part of the current offering.

Several governance capabilities are still being developed. Pantheon identified more granular configurable access controls and a pluggable preflight workflow system among the planned additions during the beta period. The latter is intended to support checks before changes are released, potentially incorporating accessibility, performance and Core Web Vitals evaluations.

Some related capabilities already exist elsewhere in Pantheon's products, but their presence does not mean every planned P1 integration is complete. The company has not presented the beta as a finished general-availability release. Organisations evaluating it therefore need to distinguish functionality they can use immediately from the broader operational model Pantheon expects to deliver.

Existing Pantheon Tools Form Part of the Foundation

P1 combines newly developed software with technology Pantheon has built over its years serving Drupal and WordPress customers. Multidev provides the foundation for parallel environments, while Upstreams offer a model for distributing shared code and configuration across groups of websites. Together, these concepts inform Pantheon's plans for governed development and operational consistency across larger website portfolios.

Autopilot, Pantheon's existing automated update and visual regression testing product, provides another foundation for the intended preflight process. Its capabilities can help teams identify unintended changes during updates, although the larger system of automated P1 release checks is still being developed. Pantheon has also identified its Content Publisher, introduced in September 2025, as part of the wider content workflow.

Content Publisher allows authors to prepare material in applications such as Google Docs and Microsoft Word and send it into supported web publishing environments. P1 incorporates this publishing approach, allowing externally authored content to become part of a governed website experience without requiring contributors to manage its visual implementation directly.

Pantheon's managed Next.js hosting and CDN infrastructure provide the delivery foundation for P1 sites. The company also describes a degree of portability: the Next.js application, site content and Puck-based editing functionality can be exported and run elsewhere. The broader Pantheon-managed workflow, including its integrated environments, agent orchestration, operational automation and CDN services, is not included in that export and would require alternatives outside the platform.

Early Customer Migration Offers a Practical Example

An early P1 implementation by Pantheon partner Cellar Door illustrates how the platform may be used beyond controlled demonstrations. The digital agency migrated a sports-technology company's website from WordPress and Elementor to a Next.js-based implementation using P1. The customer maintained an internal design system, but its previous page-building workflow had allowed visual inconsistencies to accumulate across the site.

According to CMSWire's interview with Cellar Door founder Chris Teitzel, the agency first developed a reusable Next.js design system before transferring more than 600 pages to P1. AI-assisted tools, including Claude, supported the migration work. Teitzel said the project took approximately 11 weeks, of which four to five weeks were spent developing the design system.

Teitzel estimated that a similar decoupled Next.js project might have required around six months two years earlier. That comparison represents the agency founder's assessment of one implementation, not an independently established measure of P1's average delivery speed. His account also acknowledged the rough edges associated with adopting the platform during its early development.

The same experience reinforces the difference between simple website composition and complex structured-content requirements. Cellar Door considers P1 capable of performing the CMS role for straightforward marketing websites, while more extensive catalogues may be better maintained in specialised systems. Such implementations can use P1 to combine information from several sources without relocating every underlying record.

What Drupal Teams Need to Consider

For existing Drupal installations, adopting P1 introduces several architectural and operational decisions rather than a mandatory migration path. Teams need to determine which content types remain authoritative in Drupal, which APIs P1 can access, whether those integrations are read-only, and how data changes are reflected in the published experience. Authentication, caching, content synchronisation and error handling will also influence the reliability of integrations.

Publishing governance requires particular attention. Drupal's permissions, moderation states and revision history remain relevant to its canonical content, while P1 provides its own controls for composition and release. The two systems should therefore be evaluated as connected but distinct governance environments, especially when automated agents can initiate changes.

Pantheon's introduction of P1 also extends its role beyond hosting and deployment services into page composition and AI-assisted web operations. That expansion gives Drupal teams another architectural option for delivering visitor-facing experiences, but it also adds a platform boundary that must be managed. The potential advantages of shared components and coordinated releases must be weighed against integration complexity, operational responsibilities and the current beta's incomplete features.

P1's approach is particularly relevant where organisations already have a reliable source of structured content but want additional flexibility in how web experiences are assembled and deployed. Pantheon has demonstrated that Drupal information can be consumed by P1 without wholesale migration, while its beta documentation establishes an initial set of collaborative editing and release capabilities. Broader claims about productivity, governance and automation will require further evidence from production implementations as the platform matures.

Further information about the platform, its available capabilities, and the limited paid beta is available on the Pantheon P1 website.