A content publishing workflow with drafting agents and human review

Let an LLM publish to a public marketing site unsupervised once and you will never let it again. The supervised version, on the other hand, is a tool every content team should have.

Here is the pattern we run on the Slab5 marketing site itself.

The role split

• Agent role: propose. Creates drafts, revises existing drafts, marks them for review.
• Human role: publish. Reviews diffs, edits, hits publish.

The agent never goes straight to published. The human never starts from a blank page.

How to enforce the split today

Slab5's CMS scopes today are coarse: cms:read and cms:write. An agent with cms:write *could*, mechanically, publish an entry. The split is enforced by three things working together:

1. A workflow convention. The agent creates entries with status: "draft" and transitions them to status: "review" when ready. It never calls update_entry with status: "published". This is the contract you give the agent in its prompt and tool catalog. 2. The `agent` workspace role. Agent credentials get this role. They can do cms:write mutations but cannot administer the workspace, change MCP auth policy, or revoke other credentials. 3. The audit log + revocation. Every status transition is recorded against the agent identity. The first time an agent attempts to publish, you see it, you revoke its credential, and you re-issue with a tighter prompt or a different workspace.

Finer-grained CMS scopes (cms:publish distinct from cms:write) are on the roadmap. When they ship, the convention becomes a hard guarantee. Until then, the workflow + audit + revocation pattern is what you rely on, and it is good enough to run a marketing site on.

Revisions as the review unit

Every update_entry call creates a revision. Reviewers see the diff between revisions, not the whole entry. This is a much faster review loop than "read the whole page and tell me if it's right."

In the dashboard, reviewing 10 small revisions takes about five minutes. Approving them moves the entry to published.

Webhook the editor

Wire a webhook on the entry's status transition to review to ping the editor's channel. Include the entry title, the agent who proposed it, and a link straight to the diff. From the editor's perspective, a colleague drafted some content and asked for review.

What works, what doesn't

Works well:

• Updating FAQ items as the product changes.
• Drafting new blog posts from rough outlines.
• Rewriting copy in a different tone for a specific audience.
• Generating SEO descriptions and OG metadata for existing entries.

Works badly:

• Net-new pricing pages. Pricing changes are a business decision, not a copy task.
• Anything legal. Always human-authored.
• Customer-facing announcements about incidents. The audit trail matters too much.

Trust the loop, not the model

The model gets better. The loop — propose, revise, review, publish — is what makes the system trustworthy. Build the loop first, then let the model help. When finer scopes ship, the loop becomes a hard guarantee instead of a workflow convention; the loop itself doesn't change.

MCP client with the agent workspace role and cms:read, cms:write. Convention: agent creates entries with status: "draft" and transitions to status: "review" when ready — never to published. Audit log catches drift; revoke the credential if it happens.

Webhook on the status transition to review pings the editor channel. Reviewer uses the dashboard or PATCH /v1/cms/entries/{entry_id} with status: "published" to publish.