Memory
Memory is Layer 3 of the Kanoniv trust architecture. Identity tells you who an agent is. Delegation controls what it can do. Memory is what it knows - and what every other agent knows, accumulated over time, linked to the real-world entities they operate on.
| Layer | Name | Purpose |
|---|---|---|
| 0 | Identity | Keypairs, DIDs, signed messages |
| 1 | Delegation | Attenuated authority with caveats |
| 2 | Resolution | Match, merge, link entities |
| 3 | Memory | Persistent knowledge linked to entities |
| 4 | Audit | Provenance entries, tamper-proof history |
The problem with agent memory
AI agents are stateless by default. Every session starts cold. Every agent operates alone.
Teams work around this with conversation logs, vector stores, shared databases, or message queues. All of these share the same flaw: memory is linked to conversations or agent sessions, not to the real-world entities the agents are working on.
Agent A qualifies a lead in one conversation. Agent B enriches the same contact in a different session. Agent C writes outreach in a third. None of them see what the others learned. The knowledge exists, scattered across three separate contexts, with no connection between them.
Memory linked to entities
Kanoniv takes a different approach. Memory is a property of identity.
When Agent A resolves [email protected] and records "Qualified as enterprise lead," that fact is linked to the canonical entity - not to Agent A's session. When Agent B resolves (555) 010-1234 and the identity engine matches it to the same person, Agent B receives Agent A's memory automatically. No shared database. No message passing. No coordination protocol.
Agent A resolves [email protected] -> Entity ENT_7f82
Agent A memorizes: "Qualified as enterprise lead"
Agent B resolves (555) 010-1234 -> Entity ENT_7f82 (same person)
Agent B receives: Agent A's memory
Agent B memorizes: "VP Engineering, 12 years experience"
Agent C resolves [email protected] -> Entity ENT_7f82
Agent C receives: memory from Agent A + Agent BEach agent adds to the cumulative memory. No agent needs to know the others exist.
What makes this different
| Traditional memory | Kanoniv memory |
|---|---|
| Linked to conversations | Linked to canonical entities |
| Disappears when session ends | Persists across sessions, machines, restarts |
| Private to one agent | Shared across all agents on the same tenant |
| Keyword or embedding search | Full-text search + entity graph traversal |
| Breaks when people use different identifiers | Identity resolution unifies automatically |
The critical difference is the second row. Kanoniv Cloud persists memory in a PostgreSQL-backed identity graph with row-level security. Restart the agent, deploy a new version, spin up a new machine - the memory is still there, attached to the entities it describes.
The business insight
Identity gets you in the door. Delegation keeps you safe. Memory is why you pay.
Local identity and delegation are free - generate keypairs, create delegation chains, verify signatures, all offline. But persistent, shared, entity-linked memory requires a server that resolves identities, stores knowledge, and serves it back to any agent that asks. That server is Kanoniv Cloud.
The economics are simple:
- One agent, one session - memory adds no value. Use a local variable.
- One agent, many sessions - memory adds persistence. Local SQLite works.
- Many agents, many sessions - memory adds coordination. You need identity resolution to link knowledge across agents, and a persistent store to survive restarts. This is Kanoniv Cloud.
The more agents you run, the more valuable the shared memory becomes. Each agent contributes knowledge. Each agent benefits from every other agent's contributions. The graph gets smarter with every interaction.
Core operations
Memory has three fundamental operations:
- memorize - Store a decision, investigation, pattern, or knowledge entry linked to entities
- recall - Get all memory linked to a specific entity
- search_memory - Full-text search across all memory in the tenant
And three coordination primitives:
- declare_intent - Tell other agents what you are about to do (auto-expires)
- query_expertise - Find which agents have experience with an entity or domain
- sync_knowledge - Bulk-import project docs for all agents
What's in this section
- Memorize & Recall - Core memory operations, entry types, MCP and Python SDK usage
- Coordination - Intent declaration, expertise queries, knowledge sync
- Reputation - Verifiable agent track records built from memory and provenance
- Knowledge Graph - Entity-linked knowledge accumulation, merge behavior, institutional memory