Section 14 · Part three
Agentic web development
More go-to-market work lands on the website than anywhere else. It is where you are found by search engines and AI assistants, where paid traffic arrives, where the storefront takes the order and where the concierge answers at midnight. An autonomous GTM operation therefore needs an agent that can build and run the web surface, not merely post to it.
More go-to-market work lands on the website than anywhere else, so the agent needs the whole website, not just a way to post to it. Every write is routed by its risk across three servers over one capability registry, which turns trust into a routing decision. Capability accrues to the architecture rather than to a vendor’s roadmap.
The pattern does not depend on any particular web platform. It depends on three properties of whichever platform you run: an extension ecosystem large enough that the capability an agent needs already exists, a machine-readable registry in which extensions declare what they can do, and a bridge from that registry to MCP. Any platform with those three properties can carry the pattern. Today’s implementation is one such platform, named in the callouts, and a future edition may name another without changing a word of this section.
14.1The problem is trust, not connectivity
Connecting an agent to a content management system is easy, and that is where most agentic-website demonstrations stop. What an autonomous operation needs is calibrated trust: before every write, the agent must know whether the change can be previewed, reversed, audited and approved. A homepage edit, a bulk catalog update and an extension upgrade carry very different risks, and an architecture that treats them the same is either too timid to be useful or too bold to be safe.
The architecture resolves this by making trust a routing decision. Writes are routed by their risk to the surface that can govern that risk, which is why the web surface is built from more than one server.
Current implementation
WordPress: an ecosystem of more than 74,000 plugins; an abilities registry in core since version 6.9, in which any plugin declares what it can do; and, since October 7, 2026, an official MCP Adapter plugin from the core AI team bridging that registry to MCP. The platform standardized on the pattern this architecture had been built on two assessment cycles earlier.
14.2The three-pillar pattern
The web surface is three cooperating MCP servers, each installed as an ordinary extension of the platform, each reading from the same capability registry, and each tuned to a different level of trust. The governed change platform is where anything irreversible goes: it previews, snapshots, approves and design-checks before it writes. The broad bridge exposes the widest set of capabilities, including whole-content editing, the full commerce toolset and whatever other extensions have registered. The ground-truth layer is the escape hatch for whatever the other two did not anticipate: direct code execution to diagnose root causes, secure upload links for images and files, and storage on the site for the agent’s own memory and skills.
The routing doctrine follows from the trust levels. Unguarded bulk reads and whole-content editing go through the bridge, where breadth matters. Anything irreversible goes through the governed platform, where reversibility matters. Diagnosis goes to ground truth. Our own assessment put the principle plainly: the stack can do more than it can be trusted to police, and the routing table is what closes the gap.
14.3Capability accrues to the architecture
Because all three pillars read the same registry, any extension that registers its abilities enriches every pillar at once, with no integration work by anyone. We have watched this happen three times. The commerce platform’s own registrations surfaced as a 47-tool set in the bridge; no release of the bridge added them, the registry did. A forms extension surfaced 35 form-management abilities the same way. On a lab site running a learning-management extension, 81 course, lesson and enrollment abilities appeared, and nobody wrote a line of integration code to make it so.
This is the composable property the architecture is named for, observed at the level of a single plane. Install a well-behaved extension for a vertical, and the agent inherits the vertical. Two of our sites expose different tool counts for exactly one reason: they carry different extensions that register their abilities. The architecture is the constant and the registry is the variable. Commerce and learning management are not two integrations but two instances of one extension rule; events, memberships, bookings and donations will be next.
14.4Knowledge that travels with the site
The governed platform stores the agent’s skills, memory and playbooks on the site itself. Any agent session that connects, from any project or framework, receives the current operating doctrine automatically. Operational knowledge lives in the managed asset rather than in a runbook that goes stale on someone’s laptop. We maintain it in three tiers, site, project and practice, with the most specific tier winning.
14.5Design governance as a first-class capability
An agent that can edit a page can also make it ugly, off-brand or unreadable, and will do so confidently. The governed platform treats design as something to be checked, not hoped for. Named design directions are imported from a design system expressed as reusable values for color, type and spacing. Every page-builder write is checked against them twice, once by rule and once on the rendered page, catching off-palette color, poor contrast, broken type scale, a banner that does not fit the screen, filler copy and the generic look an unguided model defaults to. Signed preview links let a reviewer see a change before it goes live, the screen in its seeing role from Section 12, and approval loops carry sign-off through to publication.
14.6Commerce on the same surface
Commerce is where the pattern proves itself, because it improved between our assessments without anyone building anything. Catalog operations arrive from the registry: products, variations, orders, refunds, customers, coupons, shipping, tax and reporting. Governed storefront writes arrive from the governed platform, including the only checkout-layout editor on any pillar, with snapshots and dry runs. The same trust routing applies to commerce without modification: fast, unguarded bulk catalog work where speed matters, and snapshotted, approval-gated writes where revenue is at stake.
Three agentic commerce patterns are worth naming. Pre-filled cart links let a piece of content deep-link into a populated cart, so “configure this room” becomes a click. AI product-feed configuration and a catalog AI-readiness score keep the storefront legible to the shopping assistants your buyers increasingly use. And an agent-orders report attributes orders to AI-agent referrals, which closes the attribution loop an autonomous operation needs.
For technical evaluators
Governed writes carry an idempotency call id, before-and-after snapshots and a deterministic dry-run fingerprint that is provably identical to the real write’s. Deletion is trash-not-delete. Plan mode previews predicted effects; guarded plugin updates roll back automatically on a failed health check; misbehaving plugins can be quarantined. The bridge, by contrast, leaves no audit row on template writes and takes no snapshots, which is exactly why writes are routed by risk rather than by convenience.
The stack has completed three full measurement cycles, absorbed 22 governed-platform releases in one nine-day window, and executed a real eight-plugin update cycle through its own guarded-update tooling on October 4, 2026, in ascending risk order, with every health verdict green.
Current implementation
Pillars: Respira for WordPress 9.1.23 as the governed change platform (364 tools); Easy MCP AI 2.0.1 as the broad bridge (714 tools, including 106 Novamira abilities reached through the bridge); Novamira 1.12.7 with Pro 1.11.0 as the ground-truth layer. 1,184 agent-reachable tools in total, measured October 5, 2026.
Platform: WordPress 7.x with WooCommerce and a block theme on a commodity Apache/PHP 8.3 host. WooCommerce adds a 47-tool set through the registry and 110 governed tools through the Respira add-on; Masteriyo LMS adds 81 abilities on the lab site. Agent Zero is the operating agent.
14.7Residual risks, stated plainly
Three risks remain. The first is concentration: the governed platform is the only source of snapshots and rollback, so the safety of the whole surface depends on one vendor’s plugin. The second is specification volatility. MCP shipped a revision on July 28, 2026 that broke compatibility, which is why, in today’s implementation, the platform’s core team ships its MCP bridge as an extension rather than in core. The third is drift between assessments, mitigated by a snapshot-before-update rule and scheduled re-assessment.
That official bridge deserves one more comment. It ships three default tools and server plumbing, and replaces none of the governance, breadth or ground-truth layers; the pillars’ value sits where core is not going. We treat it as a watch item, to be re-evaluated at its 1.0 release.
Give the agent the whole website, but route every write by its risk. Three servers over one capability registry turn trust into a routing decision, and capability accrues to the architecture rather than to a vendor’s roadmap.
Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §14. revworx.ai/architecture/14