AI content workflow: five approval gates before an agent publishes

An AI content workflow is five approval gates, not a prompt and a publish button. A person still decides what to write, which claims are allowed, what the draft may say, who presses publish, and whether the live page matches what was approved. Put those five gates into the handoff and an agent becomes useful. Remove them and it becomes a faster way to publish a mistake.

This chapter assumes you already have a content brief and a way to check claims. If the brief is still a topic and a word count, start with how to write a content brief. If the review step is the weak part, the claim ledger in fact check AI-generated content is the companion tool. The job here is narrower: where the human sits when a script or an AI assistant does the handoff.

Why an AI content workflow needs gates, not prompts

A gate is a decision that must be recorded before the next step can start. A prompt only shapes the next output. The difference matters because an agent can call a tool, spend credits, and write a record without asking again. The protocol expects the host to stop it. The MCP specification says hosts "must obtain explicit user consent before invoking any tool" (Model Context Protocol specification, read 2026-11-02). That consent is a gate, and it belongs in your workflow rather than in a dialog nobody reads.

Most teams already have the content equivalent of a gate. An editor approves a brief. A fact-checker signs off on a claim. A release manager presses publish. The failure arrives when those decisions move into an automated handoff and nobody rewrites the sequence. The agent is then asked to do all five jobs at once, and the only remaining control is whether you trust the output.

The third row is the one this chapter builds. It is slower at the start and faster at the end, because the review happens where a correction is still cheap.

There are three actors in this handoff, and they should not share one identity. The model writes. The script moves data and records what happened. The person approves. When all three run under one key, the record cannot tell you which one acted, and the first review that matters becomes an investigation. Separate keys are not bureaucracy; they are how the publish gate stays observable.

The five approval gates, in order

Run the gates in this order. Each one has a pass condition you can observe, and each one produces a record you can hand to the next person. If a gate has no record, treat it as failed.

1. Input gate: approve the question. The brief names one reader, one search intent, and one page that should own the answer. Done when the brief links the existing pages it must not duplicate. The search intent chapter covers how to tell what the reader is actually asking.
2. Evidence gate: approve the sources. Every factual claim has a URL and an access date, or a first-party sample and time window. Done when no claim is marked "to confirm" and the reviewer has opened the sources, not just the citations.
3. Draft gate: approve the argument. The draft answers the question in the first paragraph, keeps one idea per section, and names its boundary. Done when the reviewer can point to the sentence that states what the page does not cover.
4. Publish gate: approve the action. A named person presses the button in their own account. Done when the publish record contains the URL, the time, and the account that sent it. An agent may prepare the payload; it may not become the account holder.
5. Verification gate: approve the result. The live page is fetched and compared with the approved draft. Done when the title, canonical, structured data, and internal links match the record, and the URL returns 200.

What the handoff looks like over API or MCP

The handoff is a set of permissions plus a paper trail, not a single integration. Over REST or MCP, the caller needs a key whose scopes match the gate it is allowed to touch. QueryWin's developer documentation separates read, publish, and spend, and states that publish does not imply spend (QueryWin developer documentation, read 2026-11-02). That separation is the technical version of the publish gate: a key that can read a draft is not automatically a key that can charge for another one.

The same page lists nineteen MCP tools and says tools are filtered by scope, so a read-only key does not even show the generation tools to the assistant. It also documents a 120 requests per minute limit per key, a daily generation limit, and a distinction between a published listing that you reported and a verified listing that QueryWin re-checked about 72 hours later. Those are controls, not guarantees. They tell you what the system can record; they do not decide whether the draft is true.

Give an agent its own key. A shared key turns one compromised integration into every gate at once, and it makes the publish record useless because you cannot tell who acted.

The deliverable: a one-page handoff table

Copy this table into the same document as the brief. It is the whole control surface: five rows, one owner per row, and one place to record the evidence. A gate without an owner is a suggestion.

Before the agent runs:
[ ] brief links the page this article must not duplicate
[ ] every claim has a URL + access date, or a sample + window
[ ] the reviewer has opened the sources
[ ] the agent has its own key, scoped to this job
[ ] the publish action names a person and an account

After the agent returns:
[ ] draft states its boundary in one sentence
[ ] no claim was added after the evidence gate
[ ] live URL returns 200
[ ] title, canonical, structured data, and internal links match
[ ] publish record says who acted and when

Two rows are easy to fake. "Reviewer opened the sources" is a claim about behaviour, not a checkbox, so record the source URL next to the claim. "Live page matches" is a comparison, so keep the approved draft hash or version. If you cannot produce either record, the gate did not happen. A record that takes ten seconds to write is cheaper than a correction that takes a week.

Where this workflow fails

Three failures account for most of the damage. All of them pass a casual read of the draft, which is why the gates have to be recorded rather than remembered.

1. The agent writes the brief. The input gate becomes a summary of what the model already wants to say. The page then answers an easy question instead of the reader's question. Fix: the brief is approved before the generation call, and the agent receives it as input.
2. The evidence gate becomes a citation check. Someone confirms that links exist, not that they support the sentence. A source can be real and still not say what the draft claims. Fix: the reviewer writes the claim in their own words next to the source, then compares it with the draft.
3. The publish gate is delegated to the tool. The integration has a publish scope, so it publishes. Nothing is technically broken, and the record now says an agent acted. Fix: keep the publish scope on a key a person uses, and give the agent read plus spend only.

We have not measured how often an agent skips a gate, because a skipped gate leaves no record. That is the point. The failure is invisible in the output and visible only in the handoff, which is why the record matters more than the retry.

We also do not know your review capacity. A five-gate workflow can become a queue that nobody clears. If the queue is the problem, cut the number of articles, not the gates. Publishing fewer approved pages beats publishing more unread ones.

Common questions

What is an AI content workflow?

An AI content workflow is the sequence that turns a search opportunity into an approved page, with a person accountable at each handoff. It includes the brief, the evidence, the draft, the publish action, and the verification. The model can do part of the drafting; it does not own the decisions.

Should an AI agent publish without review?

No, not when the page makes factual claims about your product, your market, or your customers. A draft is not a decision. If the output is low-risk and reversible, a lighter gate may be enough, but the publish record should still name the account that acted.

How do you review AI-generated content?

Review the claims, not the prose. Put every factual sentence in a ledger, attach a source and a date, and check that the source says that sentence. The claim ledger method described earlier is the version we use; it catches invented numbers that a reread slides past.

Does MCP replace an approval workflow?

No. MCP standardises how an assistant calls tools; it does not decide which calls a person has approved. The specification puts consent on the host, and your workflow still has to record the yes. If anything, an agent with more tools makes the record more important, because more actions can happen between reviews.

This chapter covers the handoff, not the writing or the prompts. It also does not claim that a gate makes a draft true; it only makes the decision visible. That is enough to stop the expensive failures, and it leaves the judgement where it belongs.