Quantum-resistant agent systems: what changes when agents outlive their keys.

We've spent the last two posts on cryptography in the abstract — what post-quantum actually means, and the discipline that lets you survive any crypto migration. Both are true for any long-lived system. This post is about the system shape we actually build at GOGOGO LLC: multi-agent runtimes — many small specialized agents on one platform, each observable, traceable, gradeable. When the post-quantum migration meets a multi-agent system, three things change. None of them are emergencies. All of them are worth designing for now, while the work is small.

What's actually different about a multi-agent system

A traditional web service has one or two cryptographic seams worth worrying about — the TLS endpoint and maybe a JWT signer. The whole thing is rendered as a single binary, scaled horizontally, and its secrets live for as long as the deployment does. The threat surface fits on a napkin.

A multi-agent runtime has more shapes than that. The retrieval agent fetches from external APIs and signs what it returns. The reranker stamps a confidence score and signs that too. The generator emits an output and a signed trace of how it got there. The router forwards a packet to the next agent with the packet authenticated. The evaluator reads months-old traces and grades them. There are dozens of cryptographic seams — and most of them produce artifacts that need to remain verifiable for years, not seconds. That changes the threat surface from a napkin to a poster, and post-quantum sits squarely in the middle of it.

Change one: agent identity outlives the key

In a multi-agent system, agents have durable identity. The retrieval-agent isn't a fresh process — it's a named entity that other agents have come to trust, that customers' systems have been told to accept signatures from, that lives in audit logs and dashboards under one identifier. That identity persists for years; the keys under it shouldn't.

The architectural move is to separate identity from algorithm. An agent has a stable identifier (retrieval-agent) and a current key (retrieval-agent/keys/2026-05) and an algorithm that key is bound to (ML-DSA-65). When the key rotates, the identifier doesn't change. When the algorithm changes, the identifier still doesn't change. Downstream verifiers trust the identity, fetch the current key, and use the algorithm bound to that key — all read at verify time, none of it hard-coded.

If you do nothing else from this post: separate the agent identifier from the key from the algorithm. Three layers, three lifecycles. The agent identifier lives for the life of the product. The key rotates quarterly. The algorithm changes once a decade. A system that conflates these three is a system that will rewrite itself every time any one of them changes.

Change two: signed traces must verify for years

Observability by default means every agent decision is traced, and the trace is signed so it can't be tampered with after the fact. A customer's auditor in 2029 should be able to verify that the trace produced by our agent in 2026 is the one we actually emitted. That requirement collides with post-quantum: any signature produced today must still verify after the algorithm under it is deprecated.

Two patterns handle this cleanly. First — the trace envelope carries the algorithm ID and the key ID alongside the signature, so a verifier in 2029 reads the trace and knows: 'this was signed with ML-DSA-65 under key retrieval-agent/keys/2026-05 — fetch that key, verify under that algorithm.' Second — the verifier registry never drops support for an algorithm that was ever used in production. Algorithms can be retired for new signatures (no new traces use ML-DSA-65 after we move on) while remaining accepted for old signatures (every trace signed in 2026 still verifies). Migration is additive, never destructive.

Change three: agents federate with systems you don't control

In real deployments, our agents don't just talk to each other. They authenticate to customer SSO, federate with marketplace APIs, sign webhook callbacks, exchange mutually-authenticated requests with partner systems. Each of those counterparts has their own crypto roadmap, their own migration calendar, and their own legacy. Some will be ahead of us on post-quantum. Most will be behind.

The pattern that survives this heterogeneity is the same pattern that survives the post-quantum transition in general: hybrid at every federated edge. When agreeing on a session key with a counterpart, present both an X25519 and an ML-KEM-768 contribution, derive the session key from both, accept the counterpart's classical contribution if that's all they offer. When signing artifacts that cross system boundaries, double-sign — one classical, one post-quantum — and let the verifier pick whichever they understand. The federated edge has to gracefully degrade to whatever the counterpart supports today and gracefully accept anything stronger they ship tomorrow.

The four operational moves

Translating all of that into concrete work for an agent runtime in production.

1. **Give every agent a stable identifier that is not a key.** The identifier (retrieval-agent, goddo/generator/v3) lives in your identity-and-access registry. Keys hang off the identifier and rotate independently. When a customer trusts an agent, they trust the identifier; the key under it can change without breaking the relationship.
2. Build the trace envelope with `alg` and `kid` from day one. Even if your system only supports one algorithm today, the envelope shape — {trace_id, agent_id, key_id, alg, signature, content_hash} — must be the same one you'll use when you support five. Retrofitting an envelope after the fact means rewriting every persisted trace.
3. Run the verifier registry as a forever-additive map. Algorithms can be removed from the signer registry (we no longer produce new ML-DSA-44 signatures), but the verifier registry keeps every algorithm that was ever used in production. The asymmetry is the point: signing is current, verification is historical.
4. Default to hybrid at every federated edge. Customer SSO, marketplace APIs, webhook callbacks, partner mTLS. Each one announces both classical and post-quantum capability; each accepts whichever the counterpart can handle. The federated edge is where most teams' migration breaks; hybrid is the lever that keeps it boring.

The one bet that pays off across all of them

If I had to compress all four moves into a single architectural bet, it would be this: the agent's identity, its current keys, and the algorithms those keys are bound to are three separate layers, each with its own lifecycle, and the application code only ever names the identity. Code never says 'this is signed by ML-DSA' or 'fetch the key for this agent.' Code says 'this trace is from retrieval-agent; verify it.' Everything else is data — fetched, looked up, swapped, retired — without the code knowing.

That bet is the same bet crypto-agility makes for a single application; it's just made one layer up. The application doesn't name the algorithm. The agent doesn't name the algorithm. The verifier doesn't name the algorithm. Every algorithm name lives in metadata attached to the artifact or to the key. The codebase is quiet about cryptography — and a codebase quiet about cryptography is a codebase that survives the next migration.

“Post-quantum is not, for us, a cryptography project. It's an architecture project — the same one we've been doing all along: keep agent identity stable, keep keys swappable, keep algorithms as data. The day a new NIST standard arrives, the application should not notice. That's the whole point of building this way.”

What this means if you're running a multi-agent system right now

Three things, in order.

1. Audit your envelopes. For every artifact your agents produce that has to be verifiable later than ten seconds from now — traces, signed messages, federated tokens, audit logs — open one and answer: does it carry the algorithm ID, and the key ID? If not, that's your first ticket. Retrofitting envelope shape is the most expensive thing to do later.
2. Audit your identifiers. For every agent, ask: does it have a stable identifier that is not tied to a specific key? Can the key under it change without anything downstream breaking? If the answer is no, the second ticket is to introduce the indirection.
3. Audit your federated edges. For every edge where your agents talk to a system outside your control, ask: can this edge negotiate? Does it allow the counterpart to be on a different crypto generation than us, and can it ship hybrid when both sides support it? Hybrid is a contract change with each counterpart; start the conversation early.

None of this is post-quantum specifically. All of it makes the post-quantum migration a quiet one, and all of it also makes the next cryptographic transition after that an even quieter one. The first three migrations are how you pay for the architecture; the fourth is when it starts paying you back. The runtime we build at GOGOGO LLC is designed for that long view — many agents, long-lived identities, swappable keys, replaceable algorithms — because the alternative is a rewrite every time the ground shifts. More on how we build at gogogollc.com.