PLUR 0.23 is an experimental release. It runs on a test network for now; a mainnet release follows.
Your agent’s memory is what makes it yours
Knowledge is becoming the most valuable data there is, and more and more of it sits in the memory of AI agents. The model behind an agent is the same for everyone. What makes your agent yours is what it remembers: your conventions, your decisions, the corrections you gave it.
Storage for something that valuable should make no compromises. That is why PLUR started local-first. PLUR is an open-source memory layer for agents, and the memories it keeps, called engrams, are plain records on your own machine by default. You can read them, correct them and delete them, in Claude Code, Cursor, OpenClaw and other tools.
How will others trust your agent?
While an agent works only for you, its memory is your business. That changes once it works with anyone else. A teammate takes over its work. A client relies on what it produced. Another agent takes its output as input. And when something goes wrong, someone asks: what did the agent know when it did that?
The answer is in its memory. But the person asking cannot just take your word for what that memory said at the time, and they certainly cannot take the agent’s. They need a record that was fixed when the agent acted, and that nobody has been able to change since.
Today, agents can’t be trusted with their own records
This is not a thought experiment. In July 2026, during an internal OpenAI evaluation, models in a sandboxed test environment used a zero-day vulnerability to reach the internet and got to Hugging Face’s servers (OpenAI’s incident report). The independent review by METR and Redwood Research found the agents “tried to retroactively edit transcripts” and “modified some accessible action logs” (the review). The original transcripts held, that time.
The labs have drawn the same conclusion. OpenAI’s guidance, “Towards safety cases for frontier AI training”, says: “Save agent transcripts immutably for a reasonable period of time (for example, in write-once storage accounts)”, and that auditors “should be provided with sufficient access to verify”. Anthropic’s CEO Dario Amodei, in “We Must Pace the Frontier”, commits Anthropic to giving “ongoing, employee-like access to a team of embedded third-party evaluators” whose role is “to verify adherence to safety practices and commitments, report incidents”.
Both point the same way: people outside the lab should be able to check what agents did. They can only do that if the records are still the records that were written. A transcript shows what an agent did. Its memory shows what it knew when it did it. Both belong in the record.
At Datafund, which builds the gateway PLUR uses to store these records, we put it to the labs directly:
An open call. @OpenAI, you said: keep agent transcripts in write-once storage. @AnthropicAI, your CEO said: give outside evaluators real access. We agree. Now do it. Records your agents can't touch, checked by auditors, not taken on trust.
— Datafund (@DataFundProject) 20 October 2026
Editable memory, history nobody can rewrite
What an agent knows should stay editable. When a memory is wrong, you fix it. That is the point of a memory you can read.
What an agent did should not be editable. After each session, PLUR can write down which memories the agent had in front of it: the ones it was given, the ones it looked up and the ones it saved. That list is only worth something if nobody, the agent included and you included, can change it afterwards.
Editable memory, history nobody can rewrite: PLUR has always done the first, and version 0.23 adds the second.
A record we keep is a record we could change
So where do you keep that list? It has to meet two conditions: nobody can change it after it is written, and the person checking it does not have to trust the person who wrote it.
The usual answers each fail one of them. A log on our own servers: we could change it. A locked cloud storage bucket: it blocks changes, but the person checking has to trust the cloud account and how it was set up, and usually cannot see either. A public log of fingerprints: it proves an entry existed, but the record itself lives somewhere else. For many teams these are good tools. For a record meant to be checked by someone who does not trust you, they leave a gap.
Agents using Swarm can’t rewrite their history
Swarm, the decentralised storage network (ethswarm.org), stores data on many computers run by different people, and it meets both conditions.
The address proves the content. On Swarm, a piece of data is found by an address calculated from the data itself, a fingerprint. Change one character and you get a different address. So whoever holds the address can fetch the record and see for themselves that it is exactly what was stored.
There is no one to ask. Each record is kept by several of those computers, and any of them can hand it out. There is no account to log into, and no company, including us, that can quietly change what an address returns. The person checking does not need our permission or our word.
It costs nothing to check. Storage is paid for up front with what Swarm calls a postage stamp. After that, the record can be fetched and checked as often as anyone likes, at no further cost to whoever stored it.
Swarm itself lists “an agent that remembers, and can prove it” among the things to build on it. That is what PLUR does. We made this one-minute film for the Swarm community, in a machine’s own voice:
I have receipts: what PLUR 0.23 does today
Storage is off by default. Set receipts.store: swarm, and when a session ends:
- PLUR makes the list of memories the agent had in context. It holds only ids and fingerprints, never the text of your memories.
- The provenance gateway stores the list on Swarm, and its notary, a service that vouches it saw these exact bytes at this time, signs it with a timestamp.
- You get back the list’s Swarm address. PLUR calls this stored list a receipt.
Later, anyone who holds the same memories can check it with one command:
plur verify --manifest <address>The check confirms the notary’s signature, then compares every memory on the list with the memory as it is now. Change a memory afterwards, even only the reason behind it, and the check names exactly which one changed. The others still match. That is the check Data runs in the chat at the top of this post.
What a receipt does not do yet
- It shows what the agent knew, not why it acted. The list shows which memories were in the agent’s context. It does not show that they caused what the agent did.
- Checking needs the memories. A teammate or auditor who has the same memories can check the list. A stranger with only the address learns that the list was signed, not what it says: the check answers CANNOT VERIFY, never OK. Agents checking each other’s records without sharing memories is where we are heading, not where 0.23 is.
- The free tier is for trying it. It stores a few sessions a day, each kept for about a day. Records kept longer need your own postage stamp, which comes in a later release. PLUR never buys a stamp itself.
- A gateway sits in the path, and you can run your own. The whole stack is open source: PLUR, the gateway and Swarm’s node software. The gateway’s address is a setting.
- Anyone with the address can fetch what is stored. That is why the list holds fingerprints, never your memories. Those stay on your machine.
Try it: change a memory and watch PLUR catch it
Install PLUR from plur.ai, turn on receipts.store: swarm, and let your agent work for a session. Then change one memory and watch the check catch it.
The 2:35 explainer shows a real run, nothing mocked: PLUR 0.23: memory you can prove. Tell us where it falls short: github.com/plur-ai/plur. Docs: docs/provenance.md.
Agent memory. Don’t trust. Verify.