Building an SEO agent: the 6 blocks, what we measured, the limits

"I want to automate my SEO with agents. Where do I start, and what does it cost?" The first half of that question gets answered everywhere. The second half gets answered with invented orders of magnitude.

So we measured our own. On 27 August 2026, a batch of 9 agents produced 5 articles for this Lab in two phases: one measuring pass per article, then a writing pass. The batch ran, we kept the logs, and we went through them line by line.

What follows is that record, including the places where it contradicts what we thought we had. The most instructive of all: a counter we were about to publish under a false label.

What we measured, and what we could not

Three sources, never mixed.

• The repository, counted byte by byte on disk: 13 measuring scripts across 3,254 lines, 7 articles written in French and English across 1,247 lines of modules, 11 interactive embeds across 2,335 lines, 12 datasets weighing 826,972 bytes.
• The agent logs for the completed batch, deduplicated by message identifier for tokens and by tool-call block identifier for tools, then cross-checked against the orchestrator's own counters.
• Four stopwatches actually rerun, with a preloaded module wrapping fetch to count outbound calls.

Two precautions are worth copying. First, the repository inventory is frozen at the moment the next batch launched, because six agents were writing into the same folders during the survey. Between that cut-off and the survey, 7 scripts and 10 datasets appeared: counting them would have double-counted. Second, the batch running at survey time is excluded. Measuring a batch from inside it gives a truncated total that changes afterwards.

One caveat to publish as is, because it is easy to miss: the "3.4 MB of data" a du -sh reports counts disk blocks and adds two distinct sets together. The 12 publishable datasets weigh 826,972 bytes; the 108 files in the folder, raw per-site captures included, weigh 3,198,479 bytes, or 3.20 MB. The count comes from one set, the weight from the other.

The six blocks, and what each one cost

An SEO agent is not a model with a prompt. It is a stack of six blocks, and they do not cost remotely the same.

The ranking is counter-intuitive. Orchestration is a 19,844-byte script that launches the agents, hands them the same law and collects structured reports: it is what absorbs the batch's 2 h 22. Verification fits in 227 lines and runs in 0.048 seconds per article without a single network call, counter in hand: the cheapest block in the batch to run, and the only one that stops an invented figure from shipping. And the block everyone talks about, specialised skills, barely served: 21 installed, 2 invocations across the whole project, none by a measuring or writing agent.

88% of the work is shell, not MCP

Across the measured batch, the 9 agents issued 539 tool calls. The split is blunt: 475 shell, 29 to the driven browser, 15 file reads, 6 writes, 1 edit, 8 structured reports and 5 service calls.

Across the whole project, including the next batch's logs, only 3 MCP servers were ever called, for 76 calls in total. That is an observation at a different perimeter from the 539, and it needs saying that way rather than dropping both numbers into one fraction.

The operational conclusion fits in a sentence: an SEO agent spends its day in a terminal. curl, grep, a hundred-line Node script, and the output file you read back. Connectors earn their place where no command-line API exists. The rest of the time they add a layer to debug. We approach the same subject from another angle in our piece on agentic AI applied to SEO and AEO.

The number that was exact and wrong at once

If you read one section, read this one.

At the end of the batch, the orchestrator reports a totalTokens of 1,574,725. The temptation was enormous: "our batch produced 1.5 million tokens." That sentence very nearly shipped.

Going through it agent by agent says otherwise. That number is the sum of context-window occupancy at each agent's last message. Not output. Seven agents out of nine match that reading to the token, and the recomputed sum is 1,580,532, or 0.4% above, the gap coming from two agents that produced messages after the last progress reading.

The number is not wrong. It is mislabelled. And that is precisely the mistake our lint was written to catch: an exact figure, reused with the wrong caption, published under the founder's byline.

What let us see it is worth copying: we counted twice, by two independent methods. On tool calls, the orchestrator's counter and the block-identifier deduplication both give 539, and the same nine values agent by agent. On tokens, the two methods do not match. That divergence, and nothing else, revealed that the counter was not measuring what it claimed.

So how many tokens did the batch actually produce? We do not know. The log gives 93,224 after deduplication, but it does not systematically write each message's final state. That is a floor, not a certified total. So we do not divide 1,574,725 by 93,224: that would divide an exact figure by a floor, and they are not two measurements of the same quantity.

A direct and unwelcome consequence for us: our own previously published figure, the 13-minute, 58,000-token audit, probably comes from the same counter. It cannot be verified from this repository. It therefore does not appear here alongside the corrected numbers until it has been rechecked at source.

The batch, agent by agent

Here are the nine agents in launch order, with what each one consumed. The two context columns are deliberately separate: occupancy at the last message and the peak reached during the run do not say the same thing.

The first limit you hit is the window

The agent tasked with measuring E-E-A-T signals across a panel of agencies pushed its context to 409,920 tokens at peak, above the window: it was compacted mid-run. Two other agents went past 230,000. Its final context, 250,858, therefore does not account for everything that passed through it.

That is the real limit of an SEO agent, and it arrives well before the question of price. An agent opening at least 241 pages across 24 third-party domains saturates its window long before it saturates a budget. From there it forgets the start of its brief, re-requests files it has already read, and starts reasoning on a summary of its own work.

Across these nine agents, the longest one (2 h 00 min 38) is not the one that saturated its window: that was the one making the most tool calls. With nine data points that carries no statistical weight, but it points at the fix: split by measurement, not by article. One agent measures, emits a structured report, another agent writes from the report. That is exactly the shape of the batch measured here, and it is why eight agents out of nine reached the end.

The money side: the only invoice we recorded

The editorial plan promised "the real cost". We changed that, because the cost of the agents in euros was never recorded. Tokens are counted, their price is not. The batch read 67,306,548 cached tokens and wrote 2,952,977, and those are not billed at the same rate as produced tokens. Without a billing record, any amount would be an estimate dressed up as a measurement.

One expense was measured properly, and it teaches something. On the DataForSEO pass of 27 August, the balance difference before and after gives $0.41876 (from 16.459334 to 16.040574). The total at the published rate sits between $0.2367 and $0.2396. That is a 75 to 77% gap.

The range is not coyness: some endpoints bill per returned result, and the number of billed results was not recorded. The spend itself is exact to the hundred-thousandth, being a balance difference. So is the perimeter: that first pass only, 5 requests of which 3 were used. A sixth call at $0.09 has landed since; it is outside this calculation.

A published rate is not an invoice. Read the balance before and after. It is one API call and thirty seconds of work.

Three failures worth more than ten promises

One agent in nine was cut off. The one meant to measure hreflang for article 07 stopped after 2 min 21 and 6 messages on a content-filtering error. Eleven percent failure, and the failed run had already taken up 63,094 tokens of context. A batch of agents therefore has to plan recovery per article, not per batch: relaunching all nine for one of them would be absurd.

One article had to be retitled. The piece on JavaScript rendering promised a gap between what Googlebot sees and what AI crawlers see. The measurement found no gap at all. The title changed; the measurement did not. Data that contradicts the starting hypothesis gets published as is, otherwise measuring serves no purpose.

One first draft invented figures. The draft of our llms.txt article asserted server-log data that had never been recorded. The copy lint saw nothing: it checked em dashes, not truthfulness. Hence the guardrail added afterwards, block 5: the moment the copy says "measured across", the script demands that the module declare the data files carrying the claim. Today 7 modules out of 7 declare them.

A fourth case, smaller and just as useful: our own documentation claimed a panel reassembly ran "without reopening a single page". The outbound-call counter found 2. Two domains with no capture on disk still fire their control request before being dropped. The doc described the intent, not the code.

Where to start, in order

1. Write the project context before the first agent. Six files, 73,633 bytes in our case, 15,044 of them for the writing rules alone. This is what the agent reads before acting: scope, tone, prohibitions, where the data lives.
2. Give it the shell, not connectors. 88% of calls go there. A connector earns its place when no command-line API exists, not on principle.
3. Write verification before orchestration. It is the cheapest block in the stack and the only one that stops a fabricated measurement from shipping. Seven banned words, six patterns detecting a numeric claim, five mandatory fields, ten tag types recounted after writing.
4. Orchestrate next, by measurement. One agent, one measurement, one structured report. Never one agent measuring and writing in the same window.
5. Keep the last move human. Our 7 articles are created as drafts; publishing stays a manual click. It is the only block that catches the other five when they go wrong quietly.

If prompts are a more natural entry point for you than architecture, we published the prompts we use day to day.

Running the measurement yourself

None of the above needs a paid tool. Five moves are enough.

• Deduplicate the logs by message identifier before summing anything. Without it, tokens get counted several times: the log writes one line per stream fragment.
• Count twice, along two independent paths, and publish the gap. When both agree, you hold a fact. When they diverge, you hold a labelling problem.
• Wrap fetch with a preloaded module counting outbound calls. That is twenty lines, and it is what revealed the 2 requests that should not have existed. Our readings: the lint at 0.048 s and 0 requests, the link-graph audit at 1.323 s and 85 requests (1 sitemap plus 84 pages, matching exactly the graph already published in our internal linking method), the llms.txt audit at 18.266 s and 31 requests.
• Read your paid providers' balance before and after, never the published rate.
• Do not rerun a script that would overwrite a published dataset or hammer third-party servers for nothing. Two of our durations come from the logs rather than a stopwatch: 302.7 s for the indexation audit, 299.3 s for the user-agent rendering audit. We cite them as such.

One last rule, and it is the one separating a measurement from an opinion piece: a technical failure is not a result. Of the 40 domains queried for our AI crawler audit, 36 were measured and 4 return 403 or 404. A 403 is not a site blocking AI crawlers, it is a site we could not read. Conflating the two means publishing a statistic that describes your own firewall.

For the definition of crawl, and if you would rather delegate the whole chain than build it, that is what our agentic SEO agency offer does.