Agentic WordPress: governed content publishing with human approval

Governed publishing keeps release authority outside the agent

Agentic WordPress can describe two different things: an agent producing a page draft and an agent changing a public site. The release boundary separates them. A draft can be revised without affecting visitors, while publication changes the public record and needs a named decision.

On mercury.digital, the publishing workflow reserves the public action for a person. The agent works through a release session that can create and update drafts, run checks and assemble release evidence. Publishing is a human-run operation by design. The same boundary applies to an unpublish or a change to site-side PHP: a person runs it.

For the broader offer, see Agentic WordPress. For the choice between adding agents and replacing the CMS, see Agentic WordPress vs a CMS migration.

The release path on our own site

This is the process evidenced in Mercury’s agentic WordPress systems document and its release guide. It describes our own WordPress operation, not a promise that every engagement has the same monitoring or governance scope.

Stage	What happens	Where human authority sits
Scope	The publishing work has an accepted work order, target pages and acceptance checks	Josh accepts the work; acceptance does not authorize publication
Baseline	The release session reads current statuses, document hashes and other expected state before writing	Unexpected drift stops the write rather than overwriting a newer edit
Draft	Governed copy compiles into WordPress drafts; link, structure and other pre-publish checks run	Creating or changing a draft has its own approval boundary
Preview	The reviewer inspects the rendered draft in wp-admin, with screenshots captured for the release evidence	Josh reviews the draft before anything goes public
Publish	A self-checking release routine verifies the expected drafts and publishes them	A human runs the release operation
Readback	The public result is checked against the intended state, including links and relevant metadata	A failed check stops the sequence and invokes recovery
Rollback	A pre-change backup or snapshot provides the restoration path	The recovery action restores the known prior state rather than improvising one

This path uses specific draft-creation and draft-update tokens. Those tokens do not grant publication authority. The human publish step remains distinct from the agent’s ability to prepare the release.

A preview is the review surface

A reviewer needs to inspect the page as a visitor will receive it, not just the source text. The release flow includes a wp-admin preview and full-page screenshots before publish. The review covers the visible page as well as structural checks on status, slug, fields and metadata.

The read-before-update check matters for the same reason. A person may edit a draft in WordPress after the agent compiled it. A later readback and diff against the current state prevents a blind save from restoring the older copy. The release session has to notice that change before it writes.

Backups and readback belong to the same control

A backup says what can be restored. Readback tests what actually changed. One without the other leaves either an untested release or a known failure without a prepared recovery.

In the documented release-swap process, backups come first, followed by a drift check against the expected state. Changes run one at a time with pre-checks and readback diffs. Failure in a public check restores that post from its backup and stops the sequence.

Recovery can also mean restoring a prior layout snapshot or returning a faulty live page to draft, depending on what changed. The important operating point is that the recovery route is selected before the release and tied to the artifact being changed.

What this does not claim

This is evidence from Mercury’s own release process, with a human deciding every release. It does not establish compatibility with every WordPress theme, builder or plugin combination. The systems document identifies the proven stack as Cornerstone, Yoast, ACF and Code Snippets on our hosting, and calls for a separate test before broader compatibility claims.

It also does not describe always-on monitoring, continuous remediation or an agent applying maintenance on its own. Those claims need their own run evidence and agreed scope. Here the subject is one bounded path from governed draft to approved public page, with backup and recovery ready.

Approval gates explains the general distinction between a gate, a later review and an exception escalation. The WordPress Abilities API guide covers the separate question of which actions a site exposes to an agent and under which permissions.

Where this fits with related articles

See the Guides hub and the live marketing ops AI employee use case for adjacent operating models.

The operational distinction between drafting and acting also runs through AI employee vs chatbot vs RPA and what an AI readiness audit for operations should include. The latter can establish the first release scope, owner and acceptance checks before a build.

For the financial case rather than the release mechanics, see The business case for WordPress AI integration.

An AI Opportunity Audit can map the first publishing workflow, its reviewer, permitted actions and recovery requirements. Book an Audit to scope that work.

FAQ

How do you keep a human in the loop when AI agents publish to a WordPress site?

Keep consequential publish actions behind a named reviewer’s approval. The agent prepares the draft and checks; a person decides what goes live. See approval gates.

What does governed content publishing look like on an agentic WordPress stack?

Agents prepare and check changes on the current CMS. A person approves each release. Evidence, acceptance checks and a fallback stay visible. See Agentic WordPress vs a CMS migration.

When should a marketing team add AI agents to WordPress instead of migrating CMS?

When the constraint is publishing capacity and governance on the CMS you already run, not a platform rewrite. Compare keep-and-govern against replatform cost, timeline and risk on the migration piece above.

Can an AI agent publish a WordPress page by itself in this process?

The recommended model keeps publish behind a named person. Authorized scope must state exactly which actions are gated.

What happens if a post-release check fails?

Stop further releases, restore the prior accepted state if needed, and reopen the gate only after a person reviews the evidence.