WP Suite Content Engine architecture
Agent Composer architecture: governed content operations for existing WordPress sites
The system begins with a site whose design and content model already exist. Composer exposes only the approved content operations to a compatible AI agent, stores validated drafts in WordPress, and leaves publication and any production release to separate human-controlled steps.
SITE-BUILDING BOUNDARY
Agency or builder → theme + patterns + CPTs + editorial rules
↓
CONTENT-OPERATIONS BOUNDARY
Composer Config Set → Site Contract → Page Blueprints
↓
AGENT CONNECTION BOUNDARY
Existing AI agent → direct MCP or optional outbound tunnel
↓
EXECUTION BOUNDARY
Composer validation → assigned Gutenberg draft
↓
RELEASE BOUNDARY
Human review → WordPress publication → optional Static Publisher
Responsibilities and trust boundaries
One narrow path from an approved content model to a reviewable draft
Composer does not design the site, host the model, or expose generic WordPress administration. It translates an authenticated agent request into an operation allowed by the active Config Set, then validates the complete Gutenberg result before saving.
REQUEST FLOW Compatible AI client → authenticated MCP route → Composer ability → active Config Set → page blueprint → approved patterns and provider blocks → validation → draft write PRIVATE CONNECTION FLOW Local or firewall-protected WordPress → outbound Connector tunnel → compatible OpenAI client → same Composer abilities and WordPress authorization IDENTITY AND WRITE BOUNDARY Dedicated WordPress agent user → capability check → assignment separate from authorship → revision + modification tokens → conflict-safe update OPTIONAL PROVIDER FLOW Composer → registered Gatey / Flow / AI-Kit ability → provider materializes and validates its own block → Composer validates the complete draft tree RELEASE FLOW Validated draft → human preview and revision → human WordPress publication → optional manual or scheduled Static Publisher export → S3 / CloudFront + optional Static Site Guardian FAILURE FLOW Missing blueprint, invalid metadata, unavailable provider, or stale revision → validation or concurrency error → no overwrite and no publication
Ownership boundary WordPress stores Config Sets, the Site Contract, blueprints, drafts, supported metadata, assignment state, validation results, and audit information. Model reasoning remains in the selected AI client. Provider data follows each provider’s separate contract. Static Publisher and Static Site Guardian are optional delivery layers; Composer itself does not require AWS.
Activation and operating flow
How an existing site becomes a governed content system
The implementation starts from the finished WordPress site and adds only the contract, connection, and review controls required for repeatable content creation.
- Define the content boundary — Keep the existing site builder, theme, and design process. Map approved post types, templates, reusable patterns, blocks, fields, taxonomies, metadata, and editorial constraints into a Config Set and page blueprints.
- Activate the Composer execution layer — Install Agent Composer, validate and activate the Config Set, and associate a dedicated WordPress agent user with the limited Composer abilities. Agent Canvas may be used as the reference and starter theme, but it is not required.
- Choose the connection path — Connect a compatible client directly through an authenticated MCP route, or use the optional outbound Connector tunnel when WordPress must remain local or behind a firewall. Both paths reach the same governed ability surface.
- Operate review and release separately — The agent creates or updates assigned drafts with optimistic concurrency. Editors preview, revise, and publish in WordPress. If static delivery is enabled, Static Publisher can release the approved state manually or on a schedule, with optional Site Guardian protection.
What runs in each architectural layer
Core WordPress layer
Local, contract-driven responsibilities
- The agency or site owner keeps the theme, patterns, content types, design rules, and editorial policy in WordPress.
- Composer performs capability discovery, blueprint and pattern assembly, block-tree validation, conflict-safe draft writes, preview checks, assignment, and provider delegation.
- WordPress stores the contract, configuration, Gutenberg drafts, supported SEO metadata, revision state, validation receipts, and redacted audit information.
Optional external and delivery layers
Enabled only for the selected workflow
- The chosen AI client performs reasoning and connects through its compatible authenticated MCP path; Composer does not sell or host the model runtime.
- The outbound Connector tunnel is optional for compatible OpenAI clients and private WordPress origins; direct authenticated MCP remains a separate connection option.
- Static Publisher, S3, CloudFront, and Static Site Guardian form an optional production delivery path. Their ownership, AWS cost, protection, and release behavior remain separate from Composer.
Architecture questions
Boundaries to decide before connecting an AI agent
Does Composer take over the agency’s theme or site-building process?
No. The agency or site builder remains responsible for the theme, components, content types, and editorial rules. Composer consumes the active contract and blueprints after those decisions exist. Agent Canvas is only an optional reference and starter implementation.
Does the AI client receive WordPress administrator access?
No. The client reaches named Composer abilities associated with a dedicated WordPress user. Publishing, normal content deletion, plugin and theme management, media upload, site settings, and user administration remain outside the agent execution surface.
Can the WordPress origin remain private?
Yes. A compatible client may use direct authenticated MCP where the route is available. For local or firewall-protected WordPress, the optional outbound Connector tunnel reaches the same Composer server without requiring a public inbound WordPress or MCP endpoint.
Is AWS required, and who releases content to production?
AWS is not required for the core Composer contract and draft lifecycle. Human editors decide whether to publish in WordPress. Static Publisher can optionally export that approved state to an S3 and CloudFront production site, and Static Site Guardian can optionally protect selected delivery paths.
Inspect the complete operating contract
Separate site design, AI-assisted drafting, editorial approval, and production release.
Use Agent Composer as the governed content layer for the compatible AI agent your team already has, while WordPress remains the system of record and every production path stays explicit.