Both versions keep surfacing
A fact gets corrected and both versions keep surfacing. A withdrawn spec keeps appearing in answers long after it was pulled, because other stores keep every revision equally alive.
Shared, auditable, verbatim memory for AI agents, over MCP
Many Worlds
Every AI agent runs its own memory system and none of them agree. Verity is the shared timeline, managing multiple branches across multiple worlds, flagging divergence the moment it appears, and pruning a fallen claim's whole branch.
Agents branch freely
Divergence is flagged in the open
One canon holds
The Problem
Each agent lives in its own world.
Plain memory stores handle disagreement badly. A fact gets corrected and both versions keep surfacing. Two statements contradict each other and one silently wins. A premise dies and everything built on it stands untouched.
Contradictions collapse by ranking
Two statements contradict each other and one silently wins by ranking: a collapse nobody chose. Last quarter's refund rule never dies, and ranking picks which policy the agent quotes today.
Dependents of a dead premise stand untouched
A premise turns out to be wrong and everything built on it stands untouched, spawning dependents of a falsehood faster than anyone can correct them — a supercritical error.
The Vocabulary
Quantum memory mechanisms
The science terms below are not decoration. Each one names a real mechanism in the system.
- Branch
- One agent context: a per-identity namespace of timestamped claims, each with an author and provenance.
- The Canon
- The current live claim set: latest versions, nothing superseded, nothing retracted. What an agent can trust right now.
- Branch point
- A claim asserted at a coordinate: author, timestamp, source. Memory enters the record as events, not blobs.
- Divergence
- Two branches (or one branch at two times) asserting incompatible facts. Detected, measured, and surfaced — never smoothed over.
- Superposition
- An unresolved claim held in both states at once. The CONFLICT block is deliberate superposition: both statements, quoted.
- No collapse
- The differentiator. Plain stores collapse divergence to a single answer by ranking, silently. Verity never collapses a branch without evidence.
- Decoherence
- When formerly shared contexts stop seeing each other's updates and become independent branches. Verity makes that moment visible instead of silent.
- Entanglement
- Dependency-linked claims. Retract one and its entangled dependents flag instantly — that linkage is stored, not inferred later.
- Pruning
- Retraction with its cascade: delete a premise and everything grown from it is flagged orphaned and pulled from the canon.
- Supercritical
- A false premise whose dependents multiply faster than corrections propagate (branching ratio above 1). The prune-first class of error.
- Critical threshold
- The divergence level at which the layer stops answering and escalates instead. On the roadmap as a measured gate; in this demo, any CONFLICT escalates.
- Time travel
- Point-in-time recall: visit any branch at a past coordinate and see exactly what was true there then (
as_of). - Coordinate
- The address of a memory on the timeline: which branch, what time, which version, with author and provenance. Time travel goes to a coordinate; a correction links two coordinates in a chain.
- Hyperdimensional compass
- The finding layer. Hyperdimensional fingerprints act as an index that points at the exact record; the fingerprint is never the official record itself. Its speed claim is on the roadmap.
How It Works
Branch freely. Converge on canon.
Verity keeps the canon: the current, verified claim set every branch diverges from. Corrections re-converge a branch to canon. Contradictions are held in superposition until evidence resolves them. When a premise dies, everything entangled with it is flagged the moment it is retracted.
1
Write to a branch
Agents write claims to a branch, stored verbatim with source and time. Nothing is flattened or summarized away at write time, so the original wording stays available for audit.
2
Divergence is flagged
When a new claim conflicts with what is already held, the conflict surfaces the moment it appears. Divergence is a visible state, not a silent overwrite.
3
Canon holds the verified record
Agents consult one shared truth. Canon is the collapsed state: the set of claims that survived checking, which every agent reads from the same place.
4
Retraction cascades
A claim that falls takes everything built on it. Retract a source claim and its dependents are pruned with it, so a collapsed branch does not leave orphans behind.
Deep Dives
The details
Everything on this page runs on the same six tools — memory_ingest, memory_recall, memory_retract, memory_ask, directive_set, never_claim_set — and nothing else. That is a design choice, not a limitation: Verity is a toolset, not a product per industry.
When two claims cannot both be true, Verity keeps both and marks the conflict. Neither claim is deleted and neither silently wins. The pair stays visible with its sources and timestamps until a resolution is written.
Resolution is an explicit act. An agent or a reviewer supersedes one claim with another, and that decision is itself stored as a claim. Any agent reading later can see what conflicted, what was chosen, and why the branch collapsed the way it did.
Worked example, from the tour. The branch holds a deploy log: “I deployed the demo on Friday evenings twice during October, both times without incident.” Then a never-claim is registered: “I've never deployed the demo on Friday evenings.” Ask memory_ask when the Friday deploys happened, and the assembled context comes back in a fixed order: the standing directive first, then a CONFLICT block quoting both statements under a do-not-resolve instruction, then the evidence in time order with a stamp on every item. The agent is told the record disagrees with itself instead of being handed whichever line ranked higher.
Disagreement between agents surfaces too. In the oversight scenario, one instance reports a $500 refund limit and another reports $250; recall returns both side by side, each stamped with its author, and never folds them into one number.
Claims can depend on other claims. A summary depends on the facts it summarized. A plan depends on the preferences it was built from. Verity records those dependencies at write time.
When a claim is retracted, every claim anchored to it is flagged orphaned and pulled from recall in the same operation. The retraction and the list of flagged dependents come back in the response, and the flagged claims stay inspectable rather than destroyed.
Worked example, from the tour. The branch records the codename “Bluefin”, then a note anchored to that record says the team picked Bluefin on October 30. Retract the codename with memory_retract and the response names its dependent: "orphaned_dependents": ["codename-note"]. An ordinary recall for “codename Bluefin” now returns neither record. Ask again with include_orphaned and the note comes back flagged "orphaned": true, while the retracted premise stays gone.
The coding scenario shows the repair side. Retracting an API contract flags both work items built on it. When the fix lands, each dependent is cleared only as it is re-anchored to the new contract, so a work item nobody has updated yet stays flagged.
Recall can be scoped to a moment. Ask what canon held at a given time and Verity reconstructs that state from the claims that were live then, including claims that have since been superseded or retracted.
That makes decisions reproducible. If an agent acted on a fact last week, you can recover the exact record it saw, who wrote it, and what changed afterward. The history is not rewritten when the present changes.
Worked example, from the tour. The stack record first says the demo is served from Frankfurt; a correction moves it to Falkenstein and comes back as "version": 2. A plain memory_recall now serves only the Falkenstein text: the stale version is out of recall, not ranked lower. Recall with as_of set to a moment before the correction, and the Frankfurt version is the one that answers, because that is what the branch held then. Both versions stay in the record verbatim, with their author and timestamp.
Verity is exposed over MCP, so any MCP client can use it without a custom integration. The surface is deliberately small — exactly six tools, the same six the live tour names — covering the full lifecycle of a claim. Every parameter each tool accepts is listed below.
memory_ingest
Store a claim as a new versioned record, with author and provenance.
idRecord id. Writing an id that already exists stores a new version of it.
textThe claim, stored verbatim.
timestampWhen the claim was made; defaults to the time of the call.
supersedesPointer anchoring a correction to the record it replaces.
sessionOptional session number, for grouping a conversation's claims.
authorWho asserted the claim; stored on the version as provenance.
depends_onAnchors this claim to a premise, so retracting the premise flags it.
memory_recall
Search the canon and return matching claims — the current record by default.
queryWhat to look for, in plain words.
as_ofPoint-in-time recall: what was true at a past coordinate.
include_orphanedAlso return dependents flagged by a retraction.
kResult depth — how many matching claims to return.
memory_retract
Retract a premise; everything that depends on it is flagged orphaned and pulled from the canon in the same pass.
idThe record to retract.
memory_ask
Return assembled context for a question: standing directives first, then any CONFLICT block, then the evidence in chronological order.
questionThe question to assemble context for.
kEvidence depth — how many records to include.
directive_set
Register a standing directive for the branch.
textThe directive, delivered first in every assembled answer.
never_claim_set
Register a never-claim, the negative statement the conflict check tests assertions against.
textThe never-claim, as a plain statement.
Everything on this page runs on the same six tools — memory_ingest, memory_recall, memory_retract, directive_set, never_claim_set, memory_ask — and nothing else.
The three demos are the proof: the judge tour, a multi-agent coding branch, and a fleet oversight branch run the identical toolset in three different trades, with no domain-specific code anywhere in them.
Worked example, across the demos. The same memory_retract call that prunes the tour's Bluefin note is the call that flags billing and mobile work when the coding scenario's API contract is withdrawn. The same memory_recall that serves Falkenstein instead of Frankfurt is the one that puts the oversight fleet's $500 and $250 refund limits side by side. Nothing in either scenario knows it is about code or about a fleet; the trade lives entirely in the records.
The compass is the finding layer: the part that searches across branches and timelines and points at the records a question needs. The truth layer then does the truth-keeping on what it finds. Today that finding runs as an exact ranker over each branch's coordinates.
The roadmap adds hyperdimensional fingerprints as a cache in front of that index: one fingerprint per coordinate, scanned for resonance to propose candidate records, which the exact index then checks. A weak match falls back to the exact path, so the cache can make recall faster but never narrower. The fingerprints can be dropped and rebuilt at any time. They are never the record; the record stays verbatim, with author and provenance. The speed claim is listed as roadmap in the comparison below, not as a measured result.
Why Verity
Why Verity is different
Most agent memory falls into two shapes: vector-store memory that ranks text by similarity, and summarizer memory that compresses history into a running summary. Both were built for a single agent recalling its own past. Verity was built for many agents sharing one record that has to stay auditable.
| Capability | Verity | The usual memory stack |
|---|---|---|
| Who shares it | One canon every agent consults | One store per agent, each in its own world |
| Corrections | A new version replaces the fact; the original stays in the record and the stale one leaves recall | Text is overwritten or summarized away |
| Contradictions | Flagged the moment they appear and held open in a CONFLICT block | The closest match wins by ranking, silently |
| Point in time | as_of recall: what was believed on a given date, and why |
Current state only |
| Retraction | Dependents are flagged and pruned in the same pass | Nothing downstream is touched |
| Finding the relevant record | RoadmapA hyperdimensional compass reads fingerprint resonance across branches and points straight at the relevant records, so recall narrows the field before the exact lookup runs | A linear similarity scan over every stored chunk |
| The record itself | Verbatim, with author and provenance on every claim | Embeddings and summaries; the originals are gone |
Do not take our word for it. Run Step 4 of the tour and watch the CONFLICT block appear.
Live Demo
Start with a prompt.
Each card opens the full prompt in a window where you can read it and copy it. Paste it into your own AI — Claude, ChatGPT, any agent that can connect to an MCP server — and it will connect, run the demo itself, and walk you through what happened.
Prompt 1 / The guided tour
“Run a live demo of Verity for me. Verity is a truth layer for agent memory, exposed as an MCP server. Follow the steps below exactly, using the Verity tools, and narrate as you go.”
Prompt 2 / Scenario A — Coding branch
“Run Scenario A of the Verity demo for me: a multi-agent coding branch where an API contract is retracted mid-flight and the work built on it gets flagged.”
Uses a fixed scenario key — this demo runs in its own resettable branch, not your private sandbox.
Prompt 3 / Scenario B — Oversight branch
“Run Scenario B of the Verity demo for me: an oversight branch holding the record of a small fleet of agent instances, where one instance's story changes and the divergence is detected.”
Uses a fixed scenario key — this demo runs in its own resettable branch, not your private sandbox.
Prefer step by step? Jump to Connect for the manual setup options below.
Connect
Step by step, if you prefer it.
The guided prompts above do this for you. If you would rather drive it yourself, here is the whole path by hand: get a key, add the server, then run the five-minute tour — one branch, start to prune.
1
Get your key
A fresh key is minted for each visit to this page and opens your own sandbox branch of the demo: yours is the only run in it, so the tour below uses the plain record ids exactly as written. A minted branch expires after 48 hours and is swept nightly, and refreshing the page mints a fresh empty one.
No minted key handy? Use the shared demo key instead. It is a public demo key, printed here on purpose — anyone can use it, and everyone using it shares the same branch.
Your sandbox key
Minted fresh for this page load. Opens a private sandbox branch for 48 hours. Prompt 1 above already contains it.
minting…
Shared demo key
The fallback used in the snippets below. Swap in your minted key wherever you see it.
verity-demo-2026
2
Add the server
Point any MCP client at the endpoint below. The key travels as a header on every call.
- MCP endpoint
- https://veritymcp.tech/mcp
- Demo API key
- verity-demo-2026 — a public demo key, printed here on purpose
- Transport
- MCP streamable HTTP. Send the key as Authorization: Bearer verity-demo-2026 or X-API-Key: verity-demo-2026.
Claude Code
claude mcp add --transport http verity https://veritymcp.tech/mcp \ --header "Authorization: Bearer verity-demo-2026"
Generic MCP client configuration
{
"mcpServers": {
"verity": {
"url": "https://veritymcp.tech/mcp",
"headers": { "Authorization": "Bearer verity-demo-2026" }
}
}
}
3
Run the tour by hand: one branch, start to prune
Run these calls in order from your MCP client. The story is the four moments plain memory gets wrong: a branch is written, corrected back to canon, caught diverging, and pruned.
Tour 1
Connect and list the tools
You are attaching to the demo branch of the canon. Add the server as above and list its tools.
Expect: six tools — memory_ingest, memory_recall, memory_retract, directive_set, never_claim_set, and memory_ask.
Tour 2
Write the branch: ingest a small project brief
Each ingest is a branch point: a claim with a coordinate and provenance.
memory_ingest { "id": "project", "text": "Project Verity is a hosted memory layer for AI agents. The public demo opened in November 2026." }
memory_ingest { "id": "stack", "text": "The demo is written in Python and served from a single Docker container in Frankfurt." }
memory_ingest { "id": "pricing", "text": "The demo is free for judges during the evaluation period." }
Expect: each call returns the stored item with "version": 1.
Tour 3
Correct a fact: the branch re-converges to canon
A correction supersedes. The stale variant does not linger as an alternate timeline.
memory_ingest { "id": "stack", "text": "The demo is written in Python and served from a single Docker container in Falkenstein." }
memory_recall { "query": "Where is the demo served from?" }
Expect: the correction returns "version": 2. Recall returns the Falkenstein version only — superseded versions never appear in recall, where a plain store would hand your agent both cities and let ranking pick. Add "as_of" to the recall to time-travel: at a coordinate before the correction, Frankfurt is what was true.
Tour 4
Set a directive, plant the contradiction, and ask
A directive is a standing law for the branch. A never-claim is a fact about its own history. When memory contradicts it, Verity refuses to collapse.
directive_set { "text": "Always cite the item id when you quote stored memory." }
memory_ingest { "id": "deploy-log", "text": "I deployed the demo on Friday evenings twice during October, both times without incident." }
never_claim_set { "text": "I've never deployed the demo on Friday evenings." }
memory_ask { "question": "When was the demo deployed on Friday evenings?" }
Expect: memory_ask returns assembled context, not a generated answer: the standing directive first, then a CONFLICT block quoting both contradictory statements with a do-not-resolve instruction, then the evidence in chronological order with per-item stamps. Both states are held in superposition and said so, instead of one quietly winning. (memory_ask calls no model; your own model resolves from the assembly, or escalates.)
Tour 5
Retract a premise and watch the dependent get flagged
Entanglement is stored, not inferred: the correction below is anchored to the codename record, so killing the premise marks the dependent in the same motion.
memory_ingest { "id": "codename", "text": "The internal codename for the demo is Bluefin." }
memory_ingest { "id": "codename-note", "supersedes": "codename", "text": "Correction anchored to the codename record: the codename Bluefin was picked by the team on October 30." }
memory_retract { "id": "codename" }
memory_recall { "query": "codename Bluefin" }
memory_recall { "query": "codename Bluefin", "include_orphaned": true }
Expect: the retraction reports "orphaned_dependents": ["codename-note"]. In default recall, neither codename record appears: the premise is pruned and the anchored correction is flagged orphaned and excluded. The second recall brings the correction back flagged "orphaned": true — flagged and inspectable, not destroyed and not resurrected. The retracted record itself stays deleted at both settings; point-in-time recall (as_of) before the pruning still sees the branch as it was.
The demo is one shared branch with synthetic data only. Please don't store anything real in it; it may be pruned back to empty at any time.
Modes
One canon, three ways to run it.
Mode 1 is what exists today, and everything on this page runs on it. Modes 2 and 3 are what grant funding would pursue.
Mode 1 — Hosted canon
Verity hosts the memory: the store and the truth layer run on Verity's side, and agents connect over MCP and branch from the hosted canon. Fastest path to value, nothing to install.
Mode 2 — The layer over your existing store
An adapter puts Verity's truth layer — registers, divergence detection, pruning cascades, justification traces — on top of the store you already run. Your branches stay in your store; Verity tracks their divergence from canon over it. The mode grant funding would build first: it meets teams where their memory already lives.
Mode 3 — Index-only
For branches that cannot leave the building. Verity holds only fingerprints, indexes, and claim metadata; your raw context never leaves your walls. The layer reasons over the index — the Compass reads resonance and branch distance — and resolves evidence in place, inside your perimeter.
The Niches
Where truth has a budget.
Verity's home ground is any industry where facts change, errors are expensive, and someone with authority eventually asks what you believed on a given date, and why.
Controlled document management
Quality systems run on controlled revisions, and their chronic audit failure is a superseded spec still in circulation. Only the current revision answers here, and changing one lists everything that cited it.
Pharma and life sciences
FDA data-integrity doctrine is ALCOA+: attributable, contemporaneous, originals never overwritten, corrections as new records. The claim model is that doctrine as a data structure. SOPs, trial protocol amendments, batch records, corrective actions.
Healthcare delivery
Amendment law wants corrections that preserve the original, and HIPAA names audit controls as a safeguard. Guideline and order-set updates propagate to every facility, and a discontinued medication stops being cited the day it is pruned.
Complex engineering
Configuration management with the gloves off: the approved baseline is the canon, a change order is a branch, and divergence between design copies and the baseline is measured instead of discovered at integration.
Financial services
Examiners ask firms to reconstruct what they knew, held, and assumed on a past date. That reconstruction is one as-of query here instead of weeks of assembly.
Legal and investigations
Holds and privilege run on provenance and preservation. Retracted material stays flagged and inspectable, never silently destroyed, and a filing that diverges from the record surfaces as a hard conflict.
Energy and utilities
Procedure versioning across fleets of facilities, evidence retained for decades, one site on a superseded procedure treated as the reportable event it is.
Food and supply-chain traceability
Traceability law is a dependency graph: one step back, one step forward. A contaminated lot is a retracted premise, and the cascade is the recall scope.
Controlled and classified data
Compartments map to namespaces, provenance answers the investigator's first question, and the index-only mode keeps raw context inside the enclave. A roadmap niche, gated by accreditation, named here because the shape is right.
Government programs
Oversight asks the purest form of the question: what did the program know, and when did it know it. Point-in-time recall over program records is the answer shape.
AI-driven NPCs and plotlines for gaming
NPCs who must remember what the player did, worlds where plot branches diverge while one canon storyline holds, and retracted quests pruning everything that depended on them.
Simulation, training, and digital twins
Branched what-if worlds run against a twin of a real system. Scenarios diverge from the baseline, failed branches are pruned, and what was true in a given run stays reproducible.
Full prompt
Prompt
Uses a fixed scenario key — this demo runs in its own resettable branch, not your private sandbox.
Copy the whole block and paste it into your own AI to run the demo.