Introducing the Recommend Agentic Trust Layer: an open-source verification pipeline for AI agents

The agent stack has matured remarkably fast. Retrieval is excellent — a generation of search and answer APIs can put relevant, current text in front of a model in seconds. Generation is excellent — models reason over that text fluently.

What hasn't kept pace is the step between them: deciding whether a specific claim is actually supported by the evidence, and how much weight a verdict deserves.

Today every team building agents solves this from scratch — a prompt here, a heuristic there, a human spot-check where the stakes feel high — and none of it is portable or comparable across systems. We think verification belongs in the stack as a layer of its own, with the same properties the best infrastructure has: inspectable, swappable, and boring in the good way.

A claim goes in. Two numbers come out, and they are deliberately kept apart.

The truth score, 0–100, is about the claim itself — above 50 leans true. The confidence is about the verdict — how much the result should be trusted — and it falls when the evidence is thin, stale, or in disagreement.

Alongside the numbers come the sources that were read and a short written reason for every judgement. Nothing is answered from model memory: every verdict is made against text fetched live for that specific claim.

Seven phases, in the same order, every time:

claim

 ├─ 1. STRUCTURE     → falsifiable sentence, claim type, sub-claims, three query angles

 ├─ 1. STRUCTURE     → falsifiable sentence, claim type, sub-claims, three query angles

 ├─ 2. LANES         → routed by claim type, run in parallel

 ├─ 3. JUDGE         → per lane, only against what that lane fetched

 ├─ 3b CHALLENGE     → opposing counsel attacks it; if it breaks, strength × 0.55

 ├─ 4. SUB-CLAIMS    → each atomic assertion rated against pooled evidence

 ├─ 5. AGGREGATE     → disagreement and silence both cost confidence

 ├─ 6. CALIBRATION   → one-way ratchet: may only lower confidence

 └─ 7. READOUT       → two or three plain sentences on what the evidence showed

The result a system needs before acting is rarely just "true" or "false". It's "probably true, and here's how sure we can honestly be." That's the output.

1. The model answers questions; the pipeline decides.

The pipeline is deterministic: seven fixed phases, in the same order, on every run. The language model judges evidence and structures claims inside that frame — it never chooses tools, never skips a step, never loops. We think this matters for a verifier in particular: the component whose job is trust should be the most predictable one in the stack.

2. The right authority for the right claim.

Firing every source at every claim is slower and noisier. No prediction market exists for settled history; a news write-up doesn't settle cause and effect. Knowing which authority settles which kind of question is part of the design, so lanes are routed by rule.

Three lanes run on every claim: grounded web answers, semantic search, and a live index. A deeper research pass runs per sub-claim on request. Beyond those, the routing is by claim type — a claim about the future additionally consults prediction markets, and a causal or statistical claim consults the research literature through OpenAlex and Europe PMC. That last lane carries the heaviest weight of any, because on questions of cause and effect it is the only one that should.

No lane pretends to settle questions outside its competence. A prediction market in particular is treated as belief rather than fact — it can inform a lean, but never carry a verdict alone.

3. Confidence can only fall.

The calibration step is a one-way ratchet: disagreement between lanes, an empty lane, a challenge that breaks a judgement, or a claim of a kind evidence cannot settle — each lowers confidence, and nothing raises it. Unfalsifiable claims never receive a factual verdict; they return a capped-confidence lean with the reasoning written down. When a lane has no key configured it sits the check out, and the verdict says so.

Three things the pipeline used to get wrong, in case they save someone else the same afternoon.

Absence of reporting about the future is not proof. "X is going to attack Y" used to come back REFUTED at 96% confidence, because nothing credible was reporting it. That is real information, but it does not close an open question. It now returns a capped-confidence lean with a note.

The intake step must never correct the claim. A false claim has to be checked as asserted. Silently repairing a myth into its own debunking makes the system report the opposite of what was asked — the most dangerous failure mode a verifier has, because the output looks entirely reasonable.

And one for the collection: when every lane returned zero, the aggregate fell back to a default. In Python, 0.0 is falsy. A verified-false claim and a claim with no evidence at all were arriving at the same number.

The whole pipeline is exposed as a single MCP tool, verify_claim, over streamable HTTP. One command connects it.

Your agent then receives the verdict, truth score, calibrated confidence, per-lane breakdown, verified sub-claims and sources for any claim it wants checked before acting.

Verdicts can be pinned and re-checked on a schedule, so a claim's score moves as the evidence does. And because every check costs real API credit, the server ships with per-IP and global daily caps — an instance can be shared without surprises.

In June, Google introduced the Open Knowledge Format — an open, vendor-neutral standard for the curated knowledge AI systems consume. In July, OKF v0.2 added trust signals: frontmatter fields recording who generated a concept and who verified it.

But "verified" is a name typed into a field. A signature, not a check — and any agent can type it. The spec is deliberately scoped to record the signal rather than generate it, which leaves room for an ecosystem of verifiers. We've built one.

This release ships OKF support in two directions. Outward, against the world: it extracts a concept's externally checkable claims and runs them through the full evidence pipeline. Inward, against a document's own citations — for internal knowledge the web has no opinion on, like policies and metric definitions — it checks that the source each document cites actually states what's claimed. A claim can be perfectly true and still fail that check, because true-but-miscited is its own kind of failure.

The worked example in the repo ships all three honest outcomes, because all three are things a real knowledge base does.

A market-context concept had both of its claims supported at 100 out of 100, and was stamped with its sources attached. A category-positioning concept asserted that sugar causes hyperactivity in children; the research literature refuted it at 9 out of 100, so it was left unstamped, with the refuting studies and their DOIs logged against it. And an internal metric definition — nothing the web has any opinion on either way — was left unstamped too, with that reason recorded rather than guessed at.

The middle one is the point. A verifier that stamps everything is a rubber stamp. Concepts whose claims don't hold up simply stay unverified, with the reasons written down — which is exactly the distinction the OKF trust tiers exist to express. The stamps themselves are spec-conformant and additive; existing frontmatter is never touched.

The Agentic Trust Layer comes out of Recommend. Recommend is applied AI for commercial enterprises — we turn a company's data into actions, and prove what those actions earned. This is the gate that sits in front of all of it: the step that checks the evidence before anything acts on it.

We're open-sourcing it because verification, like a knowledge format, earns its value from how many parties use it. Agents are beginning to act on data automatically across every stack, and the layer that checks what they act on shouldn't be something one vendor sells. It works best as shared infrastructure that anyone can inspect, run and extend.

The parts of Recommend that stay ours are the execution and the outcome history it accumulates. The checking, we'd rather everyone had.

Everything above is available today at github.com/recommend-dev/recommend-agentic-trust-layer under the MIT license: the seven-phase pipeline with six evidence lanes, a UI that streams verification live, the verify_claim MCP tool, claim tracking with scheduled re-checks, and both OKF verifiers with a worked example.

There's no framework and no build step — one Python file

It's a starting point, not a finished standard. The roadmap includes pluggable evidence lanes, so teams can add their own — an internal corpus, a different search provider, a schema checker — without touching the pipeline, and continuous verification tied to knowledge-base changes.

If you're building agents, point them at it. If you have an evidence source we should support, open an issue and tell us. And if you find a claim it gets wrong, that's the most useful thing you can send us — it's the kind of layer this has to be.

The rule we're building toward is simple: no proof, no action.