Chris Green Built a Chrome Extension for This. In Orakul It's Just Text

On September 30, Search Engine Journal published Chris Green's "Using Local (AI) Compute To Reduce Reliance On Frontier Models." The core claim: "Not every SEO task needs a frontier model." I agree with it enough to have built a product on that principle. Below: what Green actually proposes, where my stack doesn't cover his design, and how the same architecture gets assembled in text instead of code.

What Green proposes

He describes three tiers of compute. Deterministic code handles exact operations. Light interpretation goes to a small model running locally — in his case Gemini Nano, built into Chrome. And only where real judgment is required does a frontier model get called. In his words:

"Exact computation happens in code, lightweight intelligence happens locally, and expensive intelligence is called only when it is truly needed."

He lists the routine work that needs no frontier model outright: extracting and deduplicating URLs from an XML sitemap, fetching pages and comparing HTML, checking response codes, matching elements, identifying canonical relationships, detecting destination changes, comparing raw HTML with the rendered DOM, and analyzing link attributes — anchors, destinations, broken links.

Look at that list and answer honestly: how many of those items are you paying a frontier model for right now?

Where his own test broke his design

The most valuable part of the article isn't the idea — it's that he published the failure. He built a Chrome extension that examines discrepancies between raw HTML and the rendered DOM, then pitted Nano against Gemini Flash and ChatGPT Luna on the same evidence. Nano proved unreliable for final judgment calls, while the larger models, in his words, handled the same evidence "considerably better."

His conclusion wasn't "local models don't work" but an architectural one: code computes, Nano presents and lightly interprets, a larger model steps in where judgment is needed. And he states a separate requirement for a model of any size:

"It has to respect the facts... and avoid inventing information."

What I don't have

Let me say this upfront, because what follows is an ad for my own product. Orakul does no local compute. Of Green's three tiers, two are implemented: tools that fetch the data, and a model that processes it. A small local model is still only on my roadmap.

So I'm not offering a finished implementation of his design. I'm offering the part of it that, in my view, delivers most of the effect — and I'd put the principle more bluntly than he does: the model is a processor of data, not a source of it.

What this looks like in Orakul

Green's case study is a Chrome extension he wrote in code. My closest equivalent is a technical audit agent: it takes a URL and returns a finished report. It works like this:

• step 1 — page availability mapping, via the RAW Data tool;
• steps 2 and 3 run in parallel — mobile speed and Core Web Vitals through Google PageSpeed, backlink profile and Domain Rating through the link analysis tool;
• step 4 — an AI-crawler readiness check: robots.txt, structured data, DOM semantics;
• step 5 — competitor identification, via a subagent call;
• step 6 — writing the report, via an SEO expert subagent.

In steps one through four, the data is fetched by tools, not by the model. The model appears at step six and writes the text from what the tools collected. That's Green's split exactly, minus the local tier.

The difference is in the assembly. An extension has to be written and maintained. An agent in Orakul is a table: step order, instruction in plain text, selected tool. Zero code.

How to check that the model isn't making things up

Green's "respect the facts" requirement sounds good, but you need a way to verify it. I have measurements from a live store, which I wrote up in the contrast analysis piece. Three facts from it.

The agent states its own sample size. Across four page reports it wrote that it managed to open 4 competitors out of 8, 6 of 9, 6 of 9, and 3 of 9 — Pinterest, Scribd, and direct PDFs return no HTML. A model that invents data doesn't add that caveat; it has nothing to constrain.

The agent refused the job. For "bass clef note naming worksheets pdf," the results were free PDFs while our page was a paid product. Instead of a generic list of improvements, it returned a finding about intent mismatch and called the sample insufficient. A refusal is what respecting the facts looks like in practice.

The numbers come from a connected source. The agent pulls the set of pages ranking 10–20 from Google Search Console, not from its own head.

And where no demand data existed, the report says "Wordstat: zero, Bing: insufficient data" instead of a plausible-looking number. For a report you later show a client, that matters more than polish.

What it costs in hours

The audit agent removes roughly three hours of manual work per report. At ten audits a month and a junior rate of $5 an hour, that's about $150 saved monthly. A modest figure, but one that's calculated rather than promised. And that's only the effect visible on a timesheet; the effect of not calling a frontier model to parse a sitemap shows up separately, on the API bill.

What to take away

• Write your recurring tasks into three columns: code does this, a tool does this, and this genuinely needs judgment. Most will land in the first two.
• Check your API bill for what you're paying a frontier model to do. Parsing sitemaps and checking response codes shouldn't be on that list.
• Require a source for every number an agent gives you. If it can't name one, that's generation, not processing.
• Treat a refusal as a valid result. A tool that always returns a checklist returns one when there's no data too.
• Start with tasks whose data already sits in an API: Search Console, PageSpeed, link tools. There, the "tools fetch, model processes" split happens on its own.

If you want to build an agent like this in text, with no code, it lives in Orakul. And Chris's article is worth reading in full: it's a rare case of an author publishing both the design and the place where it didn't work for him.

Maxim Safianov

I work at the intersection of technical SEO and software engineering: helping sites stay visible for classic search and AI answers alike, and building the Python tooling that automates it.