AI Agents for Content Creation and Publishing: A Client Approval Flow

Build the flow as five gated stages: brief, agent draft, editor check, client sign-off and scheduled publish. Let the agent write drafts only, and give the publishing step a separate account that acts only when the client's approval is recorded against the exact version approved. Any change after approval sends the piece back to the editor.

The agent is the easy part. The failure that costs agencies clients is a post that goes live in a version nobody approved, or a draft nobody checked because the automation made it feel finished. So put the effort into the gates, the tracker that holds them and the wiring in Zapier, Make or n8n. The CMS in every example below is WordPress.

Follow me on Instagram@sagnikteaches

Five stages, five owners, one tracker

Keep one row per piece in a tracker such as Airtable, Notion or a Google Sheet. The status column is the control panel: automations start when it changes, and nothing else starts them.

Connect on LinkedInSagnik Bhattacharya

Add these fields: piece ID, client, working title, CMS post ID, last-modified time recorded at approval, approver name and email, approved at, scheduled for, and a notes column. The last-modified time carries the weight, and the sign-off section explains why. An illustrative row at the moment of approval looks like this:

Subscribe on YouTube@sagnikteaches

Every automation reads from this row and writes back to it, so if anything goes wrong, one row tells the whole story of who did what and in which order.

Stage 1: a brief the agent cannot misread

Agents write what the brief permits. A thin brief gives a generic draft with invented specifics; a precise one turns drafting into assembly. This filled-in example is for an accountancy practice's tutorial on getting ready for year-end:

The approver row prevents a quiet delay. Without a named backup and a reply date, approvals stall when one person is away, and the agency ends up publishing on silence, which is not consent. The related tutorial on the AI content workflow for agencies goes deeper on the brief itself.

Stage 2: the draft, with a claims table the editor can check

Ask the agent for two outputs: the draft, and a table listing every factual claim with the source it came from. The second output is what makes a human edit fast. A prompt that works:

You draft client content for an agency. You never publish.
Use only the brief and the sources listed in it. Write in the voice of the samples.
Return two parts:
1. The draft, with headings, in plain HTML paragraphs.
2. A claims table with three columns: claim as written | source from the brief | type.
   Type is one of: client offer, figure, rule or law, general advice.
Mark any claim you cannot trace to a listed source as UNSOURCED. Do not invent statistics,
quotes, names or dates. If the brief does not give enough to write a section, say so.

An illustrative extract of what comes back, and what the editor does with each row:

Google's published guidance on generative AI content says to fact-check and review all AI-generated content for accuracy before publishing, including metadata such as titles, descriptions and image alt text, and it warns that generating many pages without adding value for users may breach its spam policy on scaled content abuse. A claims table is the cheapest way to satisfy the first and a distinct brief satisfies the second. For source-hunting at the research stage, briefs and source checks for agencies has a method.

Stage 3: the editor check, split into automatic and human

The editor owns the piece from here, and the editor is never the agent that wrote it. Split the checklist so machines do the counting and a person does the judging.

The overlap check is a good small job for the assistant: paste the draft and the client's existing page text, and instruct it to quote any paragraph that repeats a point already made, naming both passages, and to rewrite nothing. The editor then decides which copy stays. Rewriting is where assistants quietly change meaning, so the instruction forbids it.

When the editor signs, the status moves to Edited and the piece goes to the client. If the piece comes back from the client with changes, the editor handles them and re-signs; the agent never edits in response to client comments, because a rewrite would arrive without anyone checking what else it changed.

Clients in regulated sectors, such as an insurance broker or a financial adviser, usually need a compliance step too. Add a status called Compliance check between Edited and Approved, name the client's compliance reviewer on the brief, and store both approvers on the row. The publish flow then requires both names to be present. The agent's role does not change; only the number of people who must say yes does.

Stage 4: client sign-off that survives a late edit

How the client approves matters less than what the approval is attached to. Three patterns work for clients who will not learn your tools: a form with an approve or request-changes choice, an emailed link that sets a status field, or a status column in a shared tracker the client can edit. Whichever you choose, the automation must record who approved, when, and the version.

Tool limits shape the choice. Zapier's Human in the Loop action can pause a run for a reviewer, but it is a premium app, reviewers must have Zapier accounts, and a Professional plan can only send requests to yourself. That suits internal approvals and rarely suits clients. It also has a timeout setting with two choices, "End run" and "Skip and continue". For an approval step, always choose "End run": "Skip and continue" lets the run carry on with no answer at all, which turns silence into consent.

Silence is not approval. Write the rule into the brief and the contract: if the client has not answered by the agreed date, the account manager sends a reminder after two working days and another after four, then telephones; the piece stays at Edited, and its publishing slot is released rather than used. The flow never moves a row to Approved on a timer, and nobody on the agency side marks it Approved on the client's behalf.

The version marker is the part most flows miss. WordPress records a last-modified time on every post. Store it in the tracker when the client approves. When the publish step runs, fetch the post's current last-modified time and compare. If they match, the version is the approved one. If not, someone has touched the post since, so refuse to publish and set the status to Back to editor. A short example: the editor fixes a typo after the client has approved, the times no longer match, the publish step stops, the editor gets a message, and the client re-approves with one click. Two minutes were lost; a post with an unapproved edit did not go live. The check errs on the safe side: a plugin that touches the post also trips it, which costs a click, whereas a missed edit costs a client's trust. If you would rather compare content than time, store a hash of the post body at approval and compare that instead. The message the publish flow sends should say exactly what happened, for example: "Piece 0417 not scheduled. Post modified 12 Nov, 16:40, after approval was recorded against 14:06. Re-check, then resubmit for approval."

Stage 5: scheduling with a publisher that cannot draft

The WordPress REST API accepts a post status of publish, future, draft, pending or private; "future" means scheduled for a date. Its built-in roles help here: a Contributor can write and manage their own posts but cannot publish them, an Author can publish their own, and an Editor can publish and manage posts including other users' posts. Application Passwords, available since WordPress 5.6 and created from a user's profile screen, let an automation authenticate over HTTPS without a human password.

Use that to separate duties. The drafting flow connects as a dedicated Contributor and can only create drafts. The publishing flow connects as a dedicated Editor and does only one thing: set a named post to future with the client's date, after the checks above. Neither connection is a person's login, and neither is shared across clients. If a client uses another CMS, check three things before you build: whether it has a draft state that is not public, whether it has a role or API permission that can write but not publish, and whether its API can set a future publish date. If any answer is no, put the publish step behind a person's click instead of a flow.

Wiring it in Zapier, Make or n8n

The design is two small workflows, not one long one, so each can be paused alone.

1. Draft flow. Trigger: tracker status becomes Briefed. Steps: send the brief to the AI step; create the WordPress draft as the Contributor; write the post ID, claims table link and last-modified time to the tracker; set the status to Drafted; message the editor.
2. Publish flow. Trigger: tracker status becomes Approved. Steps: check the approver is on the allowed list; fetch the post's current last-modified time; if it equals the stored value, set the post to future with the agreed date as the Editor and set the status to Scheduled; otherwise set Back to editor and message the editor.

All three platforms can run this, with different trade-offs. As of November 2026 Zapier lists a Professional plan from $19.99 a month with multi-step Zaps, premium apps and webhooks, and a Team plan from $69 a month with 25 users, shared Zaps and shared app connections; tasks are used when a step completes an action, and Zapier says AI model tier, code runtime and connector type change how many tasks an action uses. Make bills in credits, with most module actions costing one. n8n's Wait node can pause a workflow until a webhook is called, and its human review option for AI agent tool calls can route an approval request through Slack, Teams, email and other channels, but a time limit on the Wait node resumes the run automatically, so leave it off or have the resumed branch check the decision. For cost, assume ten tasks per piece across both flows, an assumption you should replace by counting your own steps; 60 pieces a month is then 600 tasks.

Rehearse before any client is involved. Point both flows at a staging copy of a WordPress site, create a dummy client row, and push ten test pieces through, including deliberate failures: edit a post after approval, approve with the wrong name, fire the trigger twice. Every guard in the failure table should stop one of those. Then run the first real piece for each new client with someone watching, and check the scheduled post's time against the site's time zone setting before relying on it.

The agent's draft step is the only AI step. The version comparison, the allowed-list check and the status changes are plain logic, which is cheaper and more predictable. For finding forgotten automations later, the automation audit shows how to list the Zaps and scenarios nobody owns.

What the agent must never be able to do

• Publish live, edit a post after the Edited status, or delete anything.
• Reach a client site other than the one on the row; use one credential set per client.
• Email clients directly; the editor or account manager sends the approval request.
• See analytics, billing or other clients' briefs.
• Change the status to Approved, Scheduled or anything beyond Drafted.

Add a kill switch: a single cell, such as Pause all, that both flows check first, plus the ability to switch both workflows off in one click. Test it quarterly, because an untested switch fails when needed.

Failure modes and how each shows up

Does the flow pay for itself?

Use your own timings, but an illustrative comparison shows where time moves. For a piece of 1,200 words, suppose the old process took 20 minutes for the brief, 90 for a first draft, 25 for the edit and 5 to schedule: 140 minutes. With the flow, the brief still takes 20, reviewing the draft and claims table takes 15, the edit grows to 35 because fact-checking is heavier, and scheduling takes 2: 72 minutes. That saves 68 minutes a piece, which across 60 pieces is 4,080 minutes, 68 hours a month. Notice that the edit got longer. If your editors report the edit getting shorter, they may be skipping the claims table.

Track four measures: first-pass editor acceptance, client revision rounds, days from draft to approval, and post-approval edits, which should be zero because the version check would stop them. A rising rate of unsourced claims points to weak briefs. The flow also needs written terms: AI clauses for agency contracts cover disclosure, ownership and approvals, and the pre-publish checklist for AI-drafted posts is a ready-made final check for shorter formats. For the stage-by-stage sign-off in a looser setting, AI content approval workflow: draft, check, sign off is the lighter version.

Questions agencies ask about agent-written client content

Should the agent be allowed to publish straight from the CMS?

No. Give it a drafting account that cannot publish. In WordPress a Contributor can write and manage their own posts but cannot publish them, while an Editor can publish. Keep publishing on a second connection that only runs when the approval fields in your tracker are filled in, and check how your own CMS handles roles.

Do clients need Zapier or Make accounts to approve content?

They should not. Zapier's Human in the Loop step needs reviewers who have Zapier accounts, and on a Professional plan you can only send requests to yourself. Let clients approve through a simple form, an emailed link or a status field in a shared tracker, and have your automation read that record.

Should we tell clients and readers that AI helped write the content?

Tell clients in your contract and brief, including which parts an agent drafts and who checks them. For readers, Google suggests considering adding information on how content was created, especially when it is generated automatically. The right wording depends on the client's sector and policy, so agree it per client.

How do we avoid near-duplicate pages across many clients?

Give every piece its own angle, sources and examples in the brief, and reject drafts that read like a template. Google's spam policy on scaled content abuse targets generating many pages that add no value for users, so volume with no distinct purpose is the risk to design out, whoever or whatever writes the page.

Further reads

• Best AI for Content Analysis: Audit a Client's Article Library — Auditing a client's article library before you add to it.
• Jasper vs ChatGPT for Content Agencies: Which Is Worth Paying For? — Which drafting tool is worth paying for in an agency.
• How to Add Human Approval Steps to AI Automations — Holding any AI automation until a person approves.
• AI Governance for a Small Business: Who Decides, Approves, Checks — Who decides, approves and checks when AI is in use.
• ChatGPT for SEO: A Quality Gate for Keyword Clusters and Briefs — A quality gate for the briefs your agent will follow.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Google Search Central guidance on generative AI content; Zapier's Human in the Loop help article and pricing page; n8n documentation on the Wait node and human review; Make's pricing page; WordPress REST API reference, authentication guide and roles documentation. Read in November 2026.