AI-enabled CMS

An AI data labeling company engaged Mercury to design an operating model for agent-assisted WordPress work where automation would create value before receiving the power to change anything.

Mercury delivered a staged architecture: public observation leads to bounded site intelligence, operator reports, controlled drafts, and copied-page comparison. Each step has its own artifact and approval decision. The result is design and delivery evidence for a governed WordPress operating model.

The company needed to explore agent-assisted content work on its WordPress site without granting broad access as a starting condition. A content team might ask an agent to inspect the site, find outdated material, and prepare a revision. The narrow request sits inside a broad system where content, layout, plugins, administration, users, infrastructure, and live publishing are close enough that a convenient credential can grant far more authority than the work requires.

Mercury's objective was to design a staged method where each step produced a useful artifact at the lowest necessary authority. The engagement would deliver the operating model and design artifacts. It would not install, deploy, or activate the system in the client's environment.

The expected efficiency of agent-assisted work can disappear at review time. Raw route inventories, environment details, and unexplained findings give a web leader more output without giving them a better decision. A draft detached from its source creates the same problem: the reviewer can see the proposed page but not reliably determine what changed.

Permission was the deeper risk. Without explicit boundaries, a content-focused workflow could gain implicit access to administrative functions, plugin configuration, user management, or live publication. A paragraph asking the agent to be careful leaves the available actions and boundary behavior unchanged.

The company also needed a method that would produce legitimate stopping points. A team should be able to begin with site intelligence, decide whether a controlled draft is justified, and expand only when the previous stage has produced evidence. Every stage should have a deliverable and a reason to proceed or pause.

Start where no privilege is required

The first stage is public observation. Mercury designed the method to begin by reviewing the visible site, its content organization, freshness, links, and ordinary visitor surfaces. The output is a baseline and a focused set of questions, not a claim that privileged access is already justified.

If deeper inspection would help, the next stage uses purpose-specific read access that remains separate from human browser and administrative identities. Working artifacts refer to access arrangements without reproducing sensitive values. The capability is limited to what the review needs, so observation does not become implied control over adjacent site functions.

Translate findings into operator decisions

Read-only findings are translated into an operator report. Each entry states what was observed, why it may matter, and which human decision follows. The report hides raw integration detail that does not help the decision. A web leader receives a review surface rather than a machine dump.

The report structure also establishes the language internal teams can share: what was observed, what authority was used, what changed in the copy, and who owns the next decision.

Put permission in the architecture

Every requested capability passes through one permission layer. The outcome is allow, refuse, or requires human. Because that decision is centralized, a workflow cannot gain broader authority simply because a prompt describes the action differently.

The high-consequence boundary remains clear. Live publication, page replacement, administrative changes, extensions, infrastructure, users, recovery operations, sensitive access, and customer-facing actions stay with people. Read-only inspection can proceed without the same friction as a production change, while production authority cannot slip into a supposedly harmless content task.

Prepare changes without touching the source

Draft preparation begins only after the read-only work establishes a reason for it. Mercury's design limits machine-assisted changes to separate drafts with an approval reference and checks that the work is not publicly exposed.

Builder-managed pages need an additional safeguard. The workflow creates a copied draft and preserves a hash of the source. The original page remains unchanged while the proposal is prepared. The editor can compare the copied draft with a stable source reference and identify unexpected drift before deciding whether any change should advance.

The result is a bounded review object: the observed problem, the permission decision, the proposed revision, the source comparison, and the next human action. The agent can prepare. It cannot turn preparation into publication.

Mercury delivered a staged WordPress operating model connecting public observation, bounded read-only intelligence, operator reports, centralized permission outcomes, draft-only preparation, copied-page comparison, and human-controlled consequential action. The company received design and delivery artifacts for an operating method where automation earns authority one step at a time.

The staged sequence creates a practical buying path as well. A team can begin with WordPress site intelligence, decide whether a controlled draft is justified, and expand only when the previous stage has produced evidence. Every stage has a deliverable and a legitimate stopping point.

This case describes design and delivery artifacts. It does not claim client installation, deployment, user acceptance testing, plugin action, credential work, live mutation, publication, search improvement, performance gain, or lead results.

The company came to Mercury with a question that applies broadly to agent-assisted content work: how should automation earn authority rather than inherit it? Mercury answered by designing a staged operating model where each step produces a useful artifact at the lowest necessary authority and consequential action remains with people.

The engagement established a practical principle. Organizations exploring agent-assisted WordPress should begin by asking what useful artifact the agent can produce at the lowest necessary authority, and what a human needs before the next permission is earned.