Orchestrating an SEO agentic workflow

One worker finds what deserves a page, one drafts it, one publishes it. How to chain three AI workers into an SEO pipeline, and where the human gate belongs.

SEO content is three different jobs wearing one hat.

Deciding what deserves a page is analysis: it lives in Search Console data and in what currently ranks. Writing the page is composition, and it depends on knowing things that are true about your company. Publishing it is a commitment to the public, and it is the only step that cannot be undone quietly.

Most attempts to automate this collapse all three into one prompt, which is exactly why the output reads the way it does. The alternative is to give each job to a worker that holds only what that job needs, and let a client chain them: fleet orchestration applied to the one workflow where the third step is irreversible.

Three jobs, three workers

The interesting column is the last one. The publish worker is the only thing in the pipeline with Write on the public site, and it is deliberately the worker that does the least thinking. Its instruction is a page of formatting rules. It cannot pick a topic, because it has never seen the data, and it cannot write prose, because it does not have the draft context.

That is the shape to copy. Put the dangerous grant in the dumbest worker.

Why not one worker with all three grants

A single SEO worker would need Read on Search Console, Read on a web search app, Read on your document store and Write on your CMS, all at once, on every run. The research step would run holding the ability to publish. The publishing step would run holding the ability to go and look things up and change its mind.

Splitting them means each run's app firewall is a statement about that job. It also means the gate between "we decided to publish this" and "it is published" is a permission boundary rather than a sentence in an instruction asking a worker to be careful. Instructions are not controls. A worker with Read cannot publish a draft no matter what a prompt tells it.

Worker 1: what actually deserves a page

The opportunity worker is the one worth building carefully, because everything downstream inherits its judgement. It reads two sources and produces briefs.

Half of it already exists in the directory. SEO Watchtower reads Search Console weekly, compares the period against the one before it, and files what fell, what broke and where the easy wins are as tasks with the evidence attached. That is the monitoring half. What turns it into the first link of a chain is the second source below, and an output shaped as a brief rather than a ticket.

From [Google Search Console](/apps), the queries where you already exist but underperform:

• Queries ranking between positions 8 and 20 with real impressions. You are on page two for something people search. That is a page to improve, not a page to write.
• Pages whose average position slipped over the last 28 days against the 28 before it.
• Queries where a page of yours ranks but no page targets the query. The intent and the page have drifted apart.
• Queries whose impressions are climbing while your click share is not.

From a web search app, what is actually true in the results today: which pages rank for that query right now, what those pages cover, what none of them cover, what format the results reward (a definition, a comparison, a list of real examples), and whether the interest is rising, flat or seasonal. Search Console tells you where you stand. The live SERP tells you what you are standing next to.

A brief is the output, and it is specific enough that a writer could not misinterpret it:

Two rules to put in the instruction, because a model will not reach them alone:

• Improving an existing page beats writing a new one. It is cheaper, it has history, and it does not split your own relevance across two URLs.
• Check for cannibalisation before proposing a new page. If you already rank for the query with something, the answer is that something, made better.

Give it a weekly schedule and it produces a ranked list every Monday without anyone asking.

Worker 2: the draft

The draft worker takes one brief, not a topic. That difference is most of the quality.

It reads your document store and wiki, so claims come from your own material rather than from what the model half-remembers about your industry. The rule that matters: any claim it cannot source from a document is marked as unsourced in the draft rather than smoothed into confident prose. A flagged gap is a two-minute fix for a human. An invented statistic is a public liability you find out about later.

It writes into a doc, or into the CMS as a draft. It holds no publish rights, and the reason is not distrust. A draft that physically cannot go live is one a reviewer can read at their own pace, which is the only condition under which review actually happens.

The human gate

Between draft and publish, five questions. They take ten minutes and they are the whole difference between this pipeline and the thing search engines are right to demote:

1. Is every claim true, and is it ours to make?
2. Does this compete with a page we already have?
3. Are the internal links the brief asked for actually in it?
4. Does it answer the query better than what currently ranks, or just longer?
5. Would you put your name on it?

Question four is the one that kills most drafts, and it should. A page that answers the query worse than the incumbent has no business being published, and the pipeline producing it faster does not change that.

Worker 3: publish

The publish worker takes an approved draft and does exactly one thing well. It sets the title, the meta description, the slug and the canonical, adds the internal links the brief specified, publishes, and then records the URL against the target query so the loop can close later.

Its instruction is short and mechanical. If your CMS has no native app yet, it reaches it through a custom MCP connection, which is the same shape: one worker, one system, Write.

Notify a channel on success. A pipeline whose last step is silent is a pipeline nobody trusts.

The loop: measuring instead of guessing

This is the part that separates a content pipeline from a content firehose.

Twenty-eight days after publication, the opportunity worker reads Search Console for that URL and that query, and reports what happened:

That report is the honest grade, and it is data rather than opinion. It also feeds the next week's briefs, so the pipeline gets more selective over time instead of more prolific.

What the orchestrator actually does

Three workers, chained, each step's result choosing the next. The MCP server is how a client drives them:

workers_list                                     -> opportunity #3, draft #6, publish #9

worker_run  tokenId=3  prompt="last 28 days"     -> runId A
run_get     runId=A                              -> 6 briefs, ranked

   (you pick brief 2, the orchestrator carries it across)

worker_run  tokenId=6  prompt="<brief 2>"        -> runId B
run_get     runId=B                              -> draft URL, 2 claims flagged unsourced

   (a person reviews and approves)

worker_run  tokenId=9  prompt="<approved draft>" -> runId C, the live URL

Nothing here is a background job that runs itself end to end. Steps 1 and 3 are unattended work; the decision between them is not, and the chain is built so it cannot be.

What it costs

Rough tool calls per stage, which is what plans meter:

A team publishing two pages a week runs this comfortably inside Free's 500 a day, and the model tokens are billed at provider list price with no markup. The constraint on this pipeline is review capacity, not plan limits. See /pricing.

The failure mode

It is not that the workers break. It is that they work, and volume becomes the metric.

The pipeline can produce twenty briefs a week. Nothing stops you from drafting all twenty, reviewing them in eight minutes each because you have twenty to get through, and publishing the lot. Six months later the site has 400 pages, half of them competing with each other, and organic traffic is flat while the content budget quadrupled.

Google's spam policies name this directly: content mass-produced primarily to manipulate rankings, whatever produced it. The defence is not writing by hand. It is the two constraints already in the design: briefs come from queries where you demonstrably underperform, and every page has to survive a person asking whether it answers the query better than what is already there.

Three smaller failure modes worth designing against:

• Stale claims. A draft sourced from a document that has since changed. Date what the fact store holds, and have the draft worker cite the document.
• Two briefs, one query. Dedupe against what is already published and what is already drafted, not just against what is live.
• The draft that reads perfectly and is subtly wrong. This is the normal failure of any agentic step. It is why the receipt for each run matters: what the worker read is inspectable after the fact.

The reasonable objection

"AI-written content is exactly what search engines are working to demote. Why build a machine for producing it?"

The objection is right about mass-produced pages and wrong about the machinery. What gets demoted is content made primarily to rank, with nothing behind it. What ranks is a page that answers a real query better than the pages already there.

This pipeline is built around that distinction rather than against it. The topic comes from queries where your own data proves demand and your own position proves you are underperforming. The claims come from your documents. A person stands between the draft and the public. And the loop measures what actually happened 28 days later, so a page that did not work is evidence rather than a sunk cost.

Take the human gate out and the objection becomes correct. That is worth being honest about: the gate is not ceremony, it is the load-bearing part.

When not to build this

• No Search Console history. The opportunity worker mines demand you already have. A site with no impressions has nothing to mine, and the honest first move is publishing something worth ranking.
• A handful of pages. Under about twenty, you already know what needs improving. Build the pipeline when the list stops fitting in your head.
• Nobody will review. Without the gate this is a content firehose with your domain attached. If the review will not happen, do not build the third worker.
• You are not the expert. The draft worker sources from your documents. If the documents do not exist, it will source from the model instead, and that is the failure everybody is worried about.

FAQ

Can AI workers run an SEO content pipeline end to end?

They can run the analysis and the publishing unattended, and they should not run the decision between them. A practical pipeline is three workers: one that mines Search Console and live search results for what deserves a page, one that drafts from a brief and your own documents, and one that publishes an approved draft. The approval in the middle is what keeps the output defensible.

Why use three AI workers instead of one?

Because the three jobs need different app access, and one worker would hold all of it on every run. Splitting them means the researching step cannot publish and the publishing step cannot decide what to write. The gate between deciding and doing becomes a permission boundary rather than a request in a prompt.

How does a worker know what to write about?

From data rather than from brainstorming. The opportunity worker reads Google Search Console for queries where you rank between positions 8 and 20 with real impressions, pages that slipped over the last month, and queries whose demand is rising, then checks the live results to see what currently ranks and what none of those pages cover. Each brief names the query, the gap and why now.

Will content published this way be penalised by Google?

Content is judged on what it is, not on what produced it. What gets demoted is mass-produced pages made primarily to rank. The two design choices that keep this pipeline on the right side of that line are choosing topics from queries where your own data shows underperformance, and keeping a person between the draft and the publish step.

How do I measure whether the pipeline is working?

By reading Search Console for the published URL 28 days later: impressions, average position and click-through against the target query. That report goes back into the next round of briefs, so the pipeline becomes more selective rather than more prolific. Grading content by how much of it you shipped is how sites end up with 400 pages and flat traffic.

What does this cost to run?

A weekly opportunity sweep is roughly 40 to 60 tool calls, a draft 10 to 20, and a publish under 10. A team shipping two pages a week fits inside Free's daily allowance, with model tokens billed at provider list price and no markup. Review time is the real constraint.