How Our Local AI Agent Does Real Research — With No US Cloud in the Loop

Most "AI research agent" demos are a thin wrapper around a frontier cloud API. Ours isn't.

pi — our own local agent — runs an open model on a machine under my desk, searches the web through infrastructure we host ourselves, and hands the hard parts to a small team of subagents. No API key. No prompt, no document, no search query ever leaves the building.

This is the companion to running the model itself on a 2018 GPU. That post was about the hardware. This one is about the architecture — how a local agent actually does research you can trust, end to end, with nothing going to a US cloud.

The runtime: an open model you host

pi is built on the open-source earendil-works/pi harness. The reasoning engine is a 12B open model — Gemma 4 QAT — served by llama.cpp on one consumer GPU, the memory budget of which I covered in the 2018-GPU post. The point that matters here: the model is a file on my disk, not a metered endpoint. Everything below is built on top of a reasoning engine we own outright.

Every tool is self-hosted

An agent is only as private as its weakest tool. If the model is local but the search box phones a US ad graph, you haven't kept anything in-house. So all three of pi's tools run under our own roof:

• Web search through our own SearXNG. SearXNG is an open-source metasearch engine we run on our own server. When the agent searches, the query hits our box — not someone else's analytics.
• Page reading through a stealth browser. To actually read a page — not just a search snippet — the agent drives Camoufox, a hardened Firefox, to fetch and extract the real content. It handles the awkward cases most scrapers choke on: it pulls GitHub releases from the API instead of the noisy HTML, rewrites blob links to raw, and extracts text from PDFs locally with pdftotext. That last one matters in the EU: official Portuguese and legal PDFs become readable text, not a viewer's chrome.
• A memory layer. Long-lived rules and facts live in a plain Markdown file the agent controls. The rules that must always apply aren't left to the model to remember to look up — they're injected into its context every single turn, deterministically.

None of these is a SaaS. Each is a component we can inspect, change, and run offline.

The division of labour: scout, researcher, verifier

A single model trying to do everything in one long context is exactly where local agents fall apart. So the work is split across subagents, each with a narrow job and its own tool budget:

• Scout — read-only reconnaissance. It maps the territory before any deep reading begins.
• Researcher — the workhorse. Given one facet of the question, it searches, opens a few pages, and returns a short brief. It is only allowed to cite a page it actually opened, and it runs on a hard budget: a handful of searches, at most a few page-opens. That budget is precisely what stops a small model from wandering off and overflowing its context on a difficult topic.
• Verifier — an adversarial pass over a few specific claims, used when a number really has to be right.

Under the /research command, the main agent decomposes the question and dispatches up to four researchers in parallel, then stitches their briefs into one synthesis — with anything it couldn't confirm pushed into an explicit "unverified" section instead of being laundered into a confident fact.

More agents is not more depth

The tempting instinct is "throw more agents at it." We measured; it doesn't work that way.

Each researcher carries the same small page-open budget, so adding agents covers more ground — more facets, more pages — but does not make any single thread deeper. Our rule of thumb is simple: roughly one researcher per three pages the question needs opened, capped at four. Agent count is a minor lever. The thing that actually protects quality is verification.

Verification is not the model's job

The hardest lesson from building this: a local model cannot check its own work. We tested it directly — asked the agent to review its own research with a harsh-skeptic prompt that told it not to defend its earlier conclusions. It re-read the source, correctly computed a number, and then certified a conclusion that contradicted its own arithmetic. Same-model self-review just re-confirms the model's blind spots.

So the verdict layer is never the model. Two independent checks do the work:

• A deterministic link-check. Before synthesis, a plain script pings every cited URL in parallel to catch anything fabricated, dead, or blocked. No model in the loop — a URL either resolves or it doesn't. An earlier attempt to have a second model re-open all the cited pages took nearly half an hour and choked on the payload; a one-second script does the job better.
• An opened-URL log the model can't argue with. The browser tool writes down every page it genuinely fetched. A second check fails the note if it cites any URL that isn't in that log. The model gets no vote in the verdict, so it can't talk its way past it. (That check is worth a post of its own — here is how it caught citations a human review had waved through.)

The pattern repeats everywhere in this stack: on a small local model, a prompt rule is a suggestion; a deterministic check is a guarantee.

The proof: a real project, fully local

This isn't a whiteboard architecture. The clearest field-test is Bela Luz — our own permaculture homestead in Portugal (our project, not a client's). We pointed the agent at it and let it build the project's knowledge base. On day one it produced 15 source-verified notes across seven themes, every one passing the deterministic validator.

Every legal fact was checked against primary Portuguese and EU sources — DGAV, EUR-Lex, the Diário da República — with the agent paging through real legislation PDFs. When it hit a claim it couldn't verify, it retracted the claim itself rather than dress it up.

All of it ran on the local model, on one 2018 GPU, at zero cloud cost. The homestead is still pre-launch, so there are no revenue numbers to report — the point of the exhibit is the capability: an agent you fully own, doing real, source-verified research on infrastructure you control.

Why owning the whole loop matters

Every stage — search, read, reason, verify — runs on our own machines. That has two consequences a cloud API cannot match.

Privacy is structural: your data, or your client's, never reaches a third-party model, because there is no third party. And the compliance question the EU AI Act's high-risk obligations make unavoidable from 2 August 2026 — "where is this processed?" — has a clean answer: on hardware we own, in the EU, with nothing leaving the building.

You also get to add the guarantees a vendor won't. The link-check, the opened-URL log, the per-agent budgets — those exist because we own the stack they live in. You aren't waiting for a provider to ship a "trust" feature; the verdict logic is yours.

The takeaway

A useful research agent is not one giant model behind a paywalled API. It is a modest open model, a few self-hosted tools, a sensible division of labour, and — above all — verification that doesn't depend on the model being honest.

Assemble those, and you get something a cloud subscription can't sell you: capable autonomous research you actually own, running on your own hardware, with nothing leaving the building. If you can run the model — and you can, on a seven-year-old GPU — the architecture around it is the part that turns it from a demo into something you can trust.

---

Every specific in this post is from documented ImparLabs sessions building and field-testing pi, our local research agent, on a single consumer GPU.