Blue Cloud Cyber / AI Research
Memory with Receipts: A Belief Ledger for AI Agents
Watch an agent work and the waste is all in the re-checking: re-searching a codebase it mapped yesterday, re-verifying a paper it confirmed last week, rebuilding a worldview it already built. We think the fix is structural and satisfyingly boring: store every fact with a receipt, then check the receipts instead of the world. This is our design for that ledger, grounded in the published record and marked so you can see which parts are established, which are our calls, and which are still open.
- Evidenced
Someone published this. The claim links straight to the papers.
- Proposed
Our design call: reasoned from the evidence, awaiting a demonstration.
- Open problem
Nobody has solved this yet, as far as the published record shows.
Every section ends in a claim ledger, and the build literally fails if the copy oversells.
Section 01
The context tax
An agent spends a striking share of every session re-establishing facts it already established. People spread that cost across months of showing up to the same job; an agent pays it fresh each morning.
Here's a morning in the life of a coding agent. It greps (searches the raw text) for the function it found yesterday (the map it built is gone with yesterday's context window). It re-opens the config file to confirm a flag it has already confirmed twice this week. It searches the web for a paper ID it verified last Tuesday, because a verified ID and a remembered ID look identical from the inside. None of this produces anything. It is the tax the agent pays to trust its own footing again.
Some of the tax is structural. A model cannot hold its full working history in the window, so state gets paged in and out of external storage; Packer et al. make the operating-system analogy explicit and manage context the way an operating system swaps memory to disk when RAM runs out [1]. Paging solves capacity. It does nothing for trust: what comes back from storage is exactly as old as the moment it was written.
So every session boundary forces the same quiet decision. Trust the note from last week and risk acting on a world that has moved, or re-derive everything from scratch and burn the first half hour proving things that were already proved. Engineers face that decision after a long holiday, a few times a year. An agent faces it every time it wakes up.
- Evidenced
Context windows are a hard resource limit: an agent cannot carry its full working history in-context, so systems page state between the window and external storage. [1]
- Proposed
The dominant cost in long-running agent work is re-establishing what is true, not generating new output.
- Proposed
At every session boundary an agent chooses between trusting old notes and re-checking everything, with no way to tell how risky either choice actually is.
Section 02
Memory without receipts
The agent-memory literature is rich and genuinely clever. These systems store beliefs. None stores the evidence for one, and none re-checks one before reuse.
The memory literature has real answers for where beliefs live. MemGPT pages them between fast and slow tiers [1]. Reflexion has the agent write itself a note about what went wrong and read it back before the next attempt [2]. Park et al.'s generative agents record everything they experience into a memory stream, then periodically compress it into higher-level reflections that drive planning [3]. Voyager banks whole skills: executable code that worked once, kept for reuse [4].
Look at what each system stores, though, and it is always the conclusion. The belief travels; the reason it was believed stays behind. A stored reflection says "the test suite lives in tests/unit". It does not say which directory listing established that, or when, or how to check it again for less than the cost of re-deriving it. Recall answers "what did I believe". Nothing in the loop ever asks "is it still true".
Skills come closest. A Voyager library entry was verified by execution at the moment it was written [4]. But verified-at-write is a guarantee that expires: the world the skill ran against is not the world it will run against next month.
- Evidenced
MemGPT manages tiered memory the way an operating system manages virtual memory, paging context in and out of the window. [1]
- Evidenced
Reflexion agents write themselves notes about what went wrong and read them back before the next attempt. [2]
- Evidenced
Generative agents record experiences in a memory stream, synthesise them into higher-level reflections, and retrieve them to plan behaviour. [3]
- Evidenced
Voyager accumulates a persistent library of verified executable skills and reuses them across tasks. [4]
- Proposed
Across these systems, recall answers the question 'what did I believe' and never the question 'is it still true'.
Section 03
The belief ledger
Our design call: record every assertion an agent relies on together with the evidence that made it true, re-verify the evidence cheaply at session start, and hand the agent a diff of what went stale.
Our design call is a ledger. Every fact the agent relies on becomes an entry with two halves: the assertion, and the evidence that made it true. "The test suite lives in tests/unit" plus the hash of the directory listing that showed it. "This arXiv ID resolves to this paper" plus the check against the live record and the date it ran. "The build passes" plus the commit it passed at.
The payoff is what session start becomes. Instead of rebuilding its picture of the world, the agent checks the receipts again: hash the files, re-request the URLs (just asking each server whether anything changed, without downloading the page), compare the type signatures. Cheap checks, run in bulk, most of them coming back unchanged. What the agent receives is a diff: forty beliefs still hold, three went stale, one lost its source entirely. Review the three, distrust the one, get to work.
Notice what the check never has to do: work out the new truth. It only has to notice that the evidence moved. A hash mismatch does not say what changed, and it does not need to. "This belief is no longer backed" is enough to tell the agent where to look first, and knowing where to look is most of the value.
- Proposed
A recorded belief should carry evidence a machine can re-check: a file hash, a commit id, an HTTP check, a type signature.
- Proposed
Most staleness is detectable without re-reading the source, because the check only has to notice that evidence changed, not re-derive the belief.
- Proposed
A staleness diff turns session start from re-derivation into review: confirm the flagged beliefs, trust the rest.
Section 04
The pattern is older than agents
Software already knows this move. Lockfiles pin dependencies to hashes, content-addressed stores make staleness impossible to hide, and a recent security design, CaMeL, brings verify-don't-trust to agent control flow.
If this sounds familiar, it should. A lockfile is a belief ledger for dependencies: the claim "this package at this version" recorded next to a hash, so that every install verifies instead of trusting. Content-addressed stores go further and make the name the fingerprint, so a stale copy cannot even be asked for by name. Reproducible builds pin the whole toolchain the same way. Everywhere software has been burned by silent drift, it has converged on the same design: keep the claim next to a checkable fingerprint, and make checking cheaper than trusting.
Agent security is arriving at the same place from a different direction. One security design, CaMeL, works out the program's plan from the trusted request before any untrusted data is read, so whatever a poisoned email says, it cannot steer what the agent does. Debenedetti et al. report solving 67% of AgentDojo tasks with provable security that way [5]. That instinct is the one that matters here: never trust what a model remembers or reads when the system can check something instead.
A ledger points that instinct at a third target. CaMeL guards the inputs. Lockfiles guard the dependencies. The ledger guards the worldview: the accumulated beliefs an agent acts on, which today are the least checked part of the whole stack.
- Evidenced
CaMeL extracts control and data flow from the trusted query so that untrusted data an agent retrieves can never steer the program, and its authors report solving 67% of AgentDojo tasks with provable security. [5]
- Proposed
Lockfiles, content-addressed storage and reproducible builds are all the same design: record the claim next to a checkable fingerprint, then verify instead of trusting.
- Proposed
A belief ledger applies that design to an agent's worldview rather than to its inputs or its dependencies.
Section 05
What a ledger cannot check yet
Three honest gaps: checking what code does rather than what it says, knowing how often to re-check, and beliefs that arrive from another agent. Plus the small testbed we want to run against all three.
Checks see what things are, not what they do
A file hash proves a file has not changed. A request to arxiv.org proves a paper still exists. Checks like these cover facts about what things are, and they are cheap. But most of the beliefs an agent actually acts on are about what things do: this function retries when a call fails, this endpoint copes with a missing field. The only real evidence for behaviour is running the code, and nobody has shown a way to do that cheaply enough to repeat at the start of every session.
How often is often enough?
Check every belief every morning and the ledger costs as much as the re-deriving it was meant to replace. Check too rarely and it is just stale memory with better paperwork. Different facts go stale at very different speeds (a language standard barely moves; a feature branch moves daily), and nobody has published a good rule for matching the check to the speed of change.
Beliefs that arrive from other agents
Du et al. and Fu et al. have agents handing internal states to each other directly, with no text in between [6],[7]. Useful, but look at what the receiver ends up holding: a belief it absorbed rather than one it read somewhere. There is no source to hash and no page to re-check. The channel delivers the conclusion without delivering the reason to trust it, so a ledger has nothing to attach a receipt to. Our latent-space note covers the security side of that channel. This is the memory side, and it is just as unsolved.
The testbed we want to run
Every gap above is measurable, which is the good news. The rig we have in mind is small: wire a plain file-and-URL ledger into a working coding agent (file hashes, commit ids, one HTTP check per external fact), let it run through a few weeks of real sessions, and count three things. How many recorded beliefs actually go stale between sessions. What the morning re-check pass costs next to re-deriving everything from scratch. And how often a stale belief would have steered the agent wrong if nothing had caught it. Three numbers, and they turn this note from an argument into a result, one way or the other. Same rule as our latent-space testbed: when there is a repo worth cloning, this page will link it.
- Open problem
Cheap checks cover what things are (a file's hash, a paper's existence); no published approach verifies what code does cheaply enough to run at every session start.
- Open problem
Nobody has published a good rule for how often each kind of fact should be re-checked, matched against how fast that kind of fact actually changes.
- Evidenced
Agents can already pass internal states to each other directly, with no text transcript in between. [6],[7]
- Open problem
A belief absorbed from another agent's internal state arrives without a source, so there is nothing for a ledger to re-check.
- Proposed
A small rig, a file-and-URL ledger wired into a working coding agent, would measure staleness rates, re-check cost and prevented mistakes over real sessions.
Section 06
References
Numbered in order of first citation. Every green EVIDENCED marker above resolves to at least one of these.
- [1]MemGPT: Towards LLMs as Operating Systems
Packer et al. · arXiv 2023
- [2]Reflexion: Language Agents with Verbal Reinforcement Learning
Shinn et al. · NeurIPS 2023
- [3]Generative Agents: Interactive Simulacra of Human Behavior
Park et al. · UIST 2023
- [4]Voyager: An Open-Ended Embodied Agent with Large Language Models
Wang et al. · arXiv 2023
- [5]Defeating Prompt Injections by Design
Debenedetti et al. · arXiv 2025
- [6]Enabling Agents to Communicate Entirely in Latent Space
Du et al. · ACL 2026
- [7]Cache-to-Cache: Direct Semantic Communication Between Large Language Models
Fu et al. · ICLR 2026