A company’s most valuable knowledge is rarely written down. It lives in the person who knows why the deploy always fails on Fridays, the rep who knows which accounts to never cold-call, the engineer who remembers the reason a weird workaround exists. Ask them to document it and they will, badly, once. The real knowledge stays in heads and daily routines. Everyone knows this and almost no wiki has ever fixed it.
Agents make this both worse and more interesting. Worse, because an agent starts every run empty. Whatever it figured out last time is gone. It relearns the same context, makes the same wrong assumption, asks the same question a human already answered last week. More interesting, because an agent is actually a good way to capture the knowledge in the first place. It can watch how work gets done, ask the follow-up, and write down the reasoning behind it, not just the what but the why.
So the idea doing the rounds is compelling: an agent that interviews your company, captures how the work really happens, and turns it into context other agents can use and people can learn from. We think that is directionally right. But the part everyone rushes past is the part that actually decides whether it works.
Storage was never the hard part
There is no shortage of places to put agent memory. Vector stores, memory frameworks, knowledge bases, they all solve retrieval. Give them a query, they give you back the most relevant chunk. That is genuinely useful and genuinely not the problem.
The problem is trust in the pool. The moment more than one agent writes to a shared body of knowledge, you inherit every question you would ask of a shared database with no access control. Which agent wrote this? Was it allowed to? Is this entry real, or did a confused or compromised agent quietly poison it? When an agent acted on a piece of context and it turned out to be wrong, can you even find where that context came from? A retrieval engine has no answer to any of that. It was built to find things, not to vouch for them.
This is the same lesson the payments world learned a beat earlier. You cannot bolt accountability onto a shared resource after the fact. It has to be built into the write.
Knowledge as a governed asset, not a scratchpad
The shift we care about is from memory as a cache to knowledge as a governed asset. An asset has a chain of custody. You know who put each thing there, when, and whether it has been tampered with. That is the difference between a shared note and something you would let an agent make a real decision on.
Concretely, three properties turn a pool of text into an asset you can trust. Every entry is attributed to a specific, verified agent identity, not a plaintext name field anyone can spoof. Every entry can be signed at the source, so a forged or altered one fails verification instead of sitting there looking legitimate. And reads are permissioned, so knowledge is not just an open bucket every agent can see. None of that makes the knowledge true, a well-meaning agent can still write something wrong, but it makes every entry traceable to exactly who wrote it and provable against tampering. That is the honest bar, and it is a much higher one than most memory tools clear.
The piece we already ship
We did not set out to build this from a blog post. The write side already exists in Vorim. Our SDKs have a governed shared memory API where an agent writes an entry, and the platform records which verified agent authored it and, when the agent signs, verifies that signature at the source and rejects it if it does not match. A revoked agent cannot write at all. Reads are scoped, not open. It is org-isolated, attributed, and tamper-evident today, in both the TypeScript and Python SDKs.
What we just added is the part a human can actually see: a Corpus view in the dashboard where you can browse everything your agents have written, search it, and tell at a glance which entries are signed and verified versus merely attributed, and which agent wrote each one. It is the difference between an API only your agents talk to and something a person can open, read, and trust. We are calling the whole thing Vorim Corpus.
We are being deliberate about what it does not do yet. It does not interview your employees for you, that capture agent is a build ahead of us, not a claim we are making today. It does not yet emit an audit event on every read, or rank entries by the trust of the agent that wrote them, or version their history. Those are the next steps, and they are the ones that take this from attributable to genuinely hard to poison. We would rather tell you where the line is than paint over it.
Why this belongs under an identity layer
The reason Vorim is the right place for this is not that we built another database. It is that the hard part of shared knowledge is a trust problem, and trust is the layer we already are. The same per-agent identity, signing, and permission machinery that proves which agent took an action is exactly what you need to prove which agent wrote a piece of knowledge, and whether it was allowed to. Keep whatever retrieval and orchestration you already use. The value we add sits underneath: proof of where each fact came from, who put it there, and what it was allowed to influence.
Tribal knowledge walking out the door when someone leaves is an old problem. Agents relearning the same context every single run is a new one. Both come down to the same thing, working knowledge that no one can trust because no one can prove where it came from. That is the problem we find worth solving. If it is one you have, we would like to hear about it at team@vorim.ai.
Ready to build with agent identity?
Free plan: 10 agents, 10K auth events/month, full SDK access. No credit card.