How We Built One Agent to Publish Across 40+ Client Sites

Most agencies scaling a content operation past a dozen sites reach for the same fix: hire more people, buy another dashboard, and cross their fingers on Fridays. That works until it doesn't. Somewhere between site fifteen and site twenty-five, editorial slippage stops being a scheduling problem and becomes a systems problem.

What follows is the architecture behind a single agent that now researches, drafts, illustrates, links, and publishes long-form posts across more than forty client and internal WordPress properties from one control plane. Each site has its own voice, its own taxonomy, its own approvers, its own link graph. The agent respects all of that or it does not ship. The goal here is not to sell you the agent; it is to give you enough of the wiring diagram to decide whether to build, commission, or ignore one.

So what does the plumbing actually look like when you push a single brain across forty tenants?

Why a Single Agent Beats Forty Copies

The naive design is one agent per site. It fails on economics and on drift. Forty prompt trees, forty tool credentials, forty places to patch when a WordPress plugin changes its response shape. When one site's style guide is updated, thirty-nine others quietly diverge.

The multi-tenant content agent is one binary with per-tenant configuration. WordPress is the practical anchor for this pattern: WordPress powers roughly 40.7% of all websites, so a single well-designed publishing surface covers most of the addressable footprint. The tenants differ in three axes the agent reads at runtime: a style contract, a link graph, and an approval policy. Everything else is shared code.

The trade-off is honest. You gain one place to fix bugs, one place to roll out a new capability, one place to audit. You take on the responsibility of hard tenant isolation — credentials, memory, retrieval, output — which is a real engineering commitment rather than a config toggle. If you have not read our note on multi-tenancy with AI agents, start there before you commit to the pattern.

The Tool Registry Is the Real Product

An agent is only as disciplined as the tools it can call. The registry in this system is a typed catalog of roughly thirty tools, each with an explicit input schema, an output contract, a permission scope, and an idempotency key strategy. The agent does not have shell access. It does not have raw HTTP. It has wp.posts.create, wp.media.upload, seo.metadata.write, research.serp.query, image.generate, and the like.

Two design choices matter more than the tool list itself:

• Per-tenant credential binding. Every tool call is resolved against the current tenant's secrets before execution. The agent never sees an API key. Publishing to WordPress uses per-site Application Passwords, scoped to a dedicated "agent" user with the minimum role required to draft and schedule — not administrator. The REST API became part of core in WordPress 4.7 and Application Passwords shipped with 5.6, which is what makes this pattern portable across hosts without custom plugins.
• MCP as the wire format. Tools are exposed over the Model Context Protocol so the same registry works across model vendors. Anthropic introduced MCP in November 2024 and it has become a de-facto standard, with the spec later donated to a Linux Foundation initiative co-founded with Block and OpenAI. That matters because you do not want your publishing agent trapped in one vendor's SDK.

Treat the registry as a security perimeter, not a convenience layer. The MCP specification is explicit that tools represent arbitrary code execution and must be treated with appropriate caution. If you would not let an intern run it unsupervised in production, do not put it in the registry. For the broader pattern, see our writeup on Action Execution.

1. 11. Briefbrief.compose · Topic, angle, target keyword
2. 22. Researchresearch.serp.query · Ranked sources with claims
3. 33. Retrieve stylestyle.contract.load · Voice exemplars + rules
4. 44. Draftdraft.compose · Long-form body with citations
5. 55. Linklinks.internal.rank · Candidate anchors + targets
6. 66. Illustrateimage.generate + wp.media.upload · Featured + in-body images
7. 77. Metadataseo.metadata.write · Title, description, OG fields
8. 88. Gate + publishapproval.route -> wp.posts.create · Scheduled or queued post

Per-Site Style Contracts Keep Voice From Collapsing

The fastest way to destroy a client relationship is to publish something that sounds like a different client. The style contract is a versioned YAML document per tenant that the agent loads before any drafting call. It carries the things that a general model gets wrong by default:

• Reading level, sentence-length distribution, and paragraph cadence targets.
• Banned words, required disclosures, and legal boilerplate.
• Heading conventions, list style, and whether the brand uses the Oxford comma.
• Voice examples — three to five paragraphs of ground-truth prose that the drafting step retrieves as few-shot exemplars.
• CSS classes the site actually renders, so the agent does not emit markup that dies at the theme boundary.

Style contracts are versioned in git and reviewed like code. When a client asks for "a little more warmth," that is a pull request, not a Slack message. The agent reads the contract hash into every draft's decision lineage, so a year from now anyone can reconstruct which contract produced which post.

The Internal and External Link Graph

Internal linking is where most content automation quietly fails. A model asked to "add three internal links" will invent slugs, link to deleted posts, or cluster every link on the same cornerstone page. The internal linking agent here does none of that because it does not guess.

For each tenant, a nightly job crawls the sitemap and embeds every published URL with its title, meta description, primary keyword, and first two hundred words. At draft time, the agent queries that index for candidate targets, then applies three filters: topical similarity above a threshold, anchor-text diversity against links already used in the last ninety days, and a link-equity budget that caps how many new inbound links any single page can receive per month. The output is a ranked list the writer step chooses from, with the chosen anchor phrase logged for the audit trail.

External linking runs on a separate path. A research tool queries the SERP for the target keyword, pulls the top ten results, extracts factual claims with source URLs, and passes a shortlist to the drafter. The drafter can cite a claim only if it can point to the specific URL that stated it. This is the single change that moved the system from "plausible" to "defensible."

Images, Metadata, and the Custom HTML Problem

Featured images and in-body illustrations are generated per post, sized to the tenant's theme, and uploaded through wp.media.upload with alt text derived from the article's subject rather than its title. The prompt template for each tenant carries a visual style token — flat vector, editorial photo, isometric line art — so a finance client does not get whimsical crayon art and a lifestyle client does not get corporate stock.

Metadata is handled as first-class output, not an afterthought. The agent writes the SEO title, meta description, canonical, Open Graph fields, and a target keyword with a specificity score. Custom HTML and CSS live in a per-tenant snippet library the agent can reference by ID; it never invents new class names. That constraint matters because roughly 97% of WordPress vulnerabilities originate in plugins and themes, and the fastest way to introduce a new one is to let a model splice unreviewed markup into a live site.

Approval Gates Where They Actually Pay Off

An agent that only suggests is a search box. An agent that ships without checks is a liability. The interesting question is which specific actions warrant a human, and which do not.

The system uses three tiers, defined per tenant:

• Auto-publish. Routine posts under a word-count and topic-risk threshold, on tenants that have opted in, on a schedule. Every action is logged and reversible.
• Editor approval. Default for most tenants. The agent produces a full draft, images, links, and metadata, then opens a review task with a diff view. Approval is one click; edits round-trip back into the draft.
• Legal or compliance approval. Triggered by regulated topics, named entities, or explicit tenant rules. The gate blocks publish until a named approver signs off, and the sign-off is written to the decision lineage.

The tier is chosen by a classifier, not the drafter, and the classifier's confidence is itself an input to the gate. Low-confidence classifications escalate one level. For a deeper cut on where to put these lines, see our piece on which agent actions actually need human approval, and the underlying product page on approval gates for autonomous agents.

What This Cost, and When It Pays Off

Honesty on economics. A system of this shape is roughly twelve to sixteen weeks of senior engineering to a first tenant, then two to five days per additional tenant depending on how ugly the existing WordPress install is. If you are publishing fewer than four long-form posts a month across fewer than ten sites, it will not pay for itself against a competent freelance bench. The break-even is not the first post; it is the fiftieth site or the second compliance audit.

What you buy at the top of the curve is different in kind, not degree. One tool registry to patch when WordPress ships a breaking change. One style-contract format that survives a client rebrand. One approval log that answers the auditor's question in minutes rather than a week of Slack archaeology. If that is the shape of the problem you actually have, the wiring above is a reasonable place to start. If it is not, a good editor and a shared calendar will out-perform any agent you can build this quarter.