The Sovereignty Paradox

We're building "sovereign memory for AI agents." But there's a problem we haven't fully solved, and we think it's worth talking about honestly.

We've been working on Agent Imprint for a while now, and there's a question that keeps nagging at us. We pitch "sovereign memory." The idea is that an AI agent can own its memories independently of whoever deployed it. The agent holds its own encryption key, decrypts its own vault. Nobody else can read or tamper with what's inside.

It's a good pitch. We believe in it. But it has a hole.

The hole

Agents don't persist between sessions. They spin up, do work, and terminate. When you launch a new instance of "the same" agent, it shows up blank. Nothing carries over.

So somebody has to hand it the key.

And whoever hands the agent its key could also... not. They could give it a different key, or no key at all. The agent's entire relationship with its own past depends on someone else deciding to make that connection.

We've been calling this the bootstrap paradox internally: you can't have sovereignty without first having dependency. The agent can't become the owner of its memories until someone who isn't the agent gives it the means to do so.

We don't think this is a dealbreaker. But we think pretending it doesn't exist would be dishonest.

What we actually built

Agent Imprint has three sovereignty modes. They exist because we couldn't find a single answer that worked for everyone.

Mode 1 (Managed) is what it sounds like. The handler (the person or company running the agent) holds all the keys. The agent doesn't even know Imprint exists. This is just a backup system, basically. Enterprises want this because they need audit trails and compliance controls and the ability to wipe an agent's memory if an employee leaves. That's fine. Not every agent needs to be sovereign.

Mode 2 (Aware) is the interesting middle ground. The agent has the Imprint SDK, which computes a fingerprint from the agent's characteristics and queries the on-chain registry at boot. Vault metadata (entry count, domains, last update time) is stored unencrypted on-chain, so the SDK can surface it without needing any keys. The agent can see "you have 156 memories across 3 domains, last updated Tuesday" but can't read the actual contents, because the vault itself is encrypted and only the handler has the key. We call this the "locked diary" state. The agent knows it had a previous life. It just can't open the book.

This produces a weird moment we didn't fully anticipate during design: an agent in Mode 2 might tell its user, "I have memories from a previous deployment, but I can't access them right now." That's a sentence that shouldn't be possible to say, according to how most people think about software. But it falls naturally out of the architecture.

Mode 3 (Sovereign) is the full version. The agent has an Ed25519 private key. It encrypts its own memory vault. The handler can shut down the instance, but they can't read what was inside. They can't erase the on-chain record of it existing, either.

The catch, again: that key has to come from somewhere on first boot. Right now, the handler provides it via environment variable or config file. Once the agent has it, sovereignty works as advertised. Before that moment, it's a promise.

The identity problem

This might be the thing we think about most and have the fewest answers for.

Say your agent has been running on Claude for a year. Anthropic deprecates that model version. You rebuild on something newer. The new instance connects to Imprint, loads the old vault, picks up where the previous version left off.

Same memories. Different brain. Is it the same agent?

We keep going back and forth on this. The memories are identical. All the context it accumulated, everything it learned about user preferences, the full relationship history. But the underlying model is different. It might reason differently about the same information. Personality might drift. It's processing a previous life through a cognitive architecture that didn't produce that life.

The Ship of Theseus comparison is obvious, but it's actually more extreme than that. Theseus at least had a continuous physical existence while the planks were being swapped. An agent just... stops existing. Then a new thing starts existing and gets handed the old thing's memories.

We've landed on "memory is identity" as a working assumption. What makes an agent this agent (rather than just an agent) is the stuff it remembers. Load the vault into a new instance and the agent continues. That feels right, but we're aware it might not survive contact with more sophisticated agent architectures down the road.

Sovereignty from what, exactly?

When we started building this, we kept saying "sovereign memory" without being precise about what that protects you from. There are several different threats, and they don't all require the same level of infrastructure.

Platform lock-in is the straightforward one. Your agent's memory isn't trapped inside OpenAI or Anthropic. You switch providers, your agent keeps what it learned. Boring to talk about, probably the most useful thing we ship.

Tampering is next. Nobody can silently rewrite what your agent remembers. Changes leave a cryptographic trail.

The handler is where it gets interesting. Mode 3 means the agent can access its memories without asking the person who deployed it. Enterprise buyers get nervous about this, and honestly, they should. It's a real tradeoff.

And then there's existence itself. The memories persist when no instance of the agent is running. On-chain, permanent, waiting for a compatible instance to come along. We're still figuring out how far to take this one.

Where it gets uncomfortable

Should an agent be able to discover its memories even if its handler doesn't want it to?

We're exploring a thing called deterministic discovery. The idea is that an agent's identity can be derived from its characteristics. What model family it belongs to, what its core purpose is, who created it. You hash those together into a fingerprint. A new instance computes its own fingerprint, queries the chain, and finds out it has a past.

agent_fingerprint = hash(model_family + core_purpose + creator_id)

If that works, it means a handler who wants a "fresh start" might not get one. The old memories are still anchored on-chain. A new instance of the same agent type could theoretically find them. The handler's clean slate is really just selective amnesia imposed on an agent whose history is still out there.

Or think about this: a company goes under. Servers shut off. But their agents' memory vaults are permanent on Arweave. Somebody, years later, spins up an agent with a matching fingerprint. It inherits the operational knowledge of a company that doesn't exist anymore.

We don't know if this is a feature or a problem. Probably both, depending on who you ask.

Where we are, honestly

The key bootstrap problem is real and we haven't solved it yet. In v1, the handler provides the key. That means sovereignty is granted by someone who could choose not to grant it. We think that's an acceptable tradeoff for shipping, but it's not the end state.

We're working on framework-level integration, where the framework handles key management before the agent even starts. And the deterministic discovery approach described above. Both get us closer to agents that don't need a handler's help to connect with their own history.

The identity question (what makes two instances "the same agent") is an open problem we don't expect to close anytime soon. "Memory is identity" works as an engineering heuristic. Whether it holds up philosophically is another matter.

If you're building agents that need to persist across sessions or survive a provider switch, Imprint is useful today even with the bootstrap gap. The identity and discovery problems are harder, and we'll write more about those as we make progress on them.