Multi-Agent Memory & Topology

When one agent spawns ten, and those ten spawn a hundred, "who knew what, who authorized what, and who pays when it breaks" stops being a metaphor and becomes a graph you can verify.

Why a multi-agent system needs a topology, not a roster

Most teams describe their agent fleet the way you'd describe a parking lot: a count, a few names, maybe a status light. That works until something goes wrong. The moment an automated action produces a bad outcome, the question is never "how many agents do you have." It is "which agent did this, who told it to, what did it remember when it decided, and can you prove any of that to someone who doesn't trust you." A flat roster cannot answer those questions. A topology can.

By topology we mean the actual shape of two relationships that a flat list throws away. The first is memory adjacency: which pieces of knowledge an agent can reach from where it currently stands. The second is authority lineage: which agent derived its right to act from which other agent. Both are graphs with edges, not columns in a table. When you model them as graphs, "trace this action back to a human" becomes a path-walk instead of a guess. Our Topological Foundations for Multi-Agent Memory and Identity paper formalizes this — it is the reference text behind everything on this page, and it sat orphaned for too long while the rest of the platform shipped around it.

The practical payoff is auditability. If you can name the edges, you can verify them. If you can verify them, you can hand the audit to a buyer, a regulator, or a counterparty who has no reason to take your word for anything. That is the entire premise of BlindOracle: trust that survives a stranger checking it. The "who audits the agents" essay walks through why self-attestation is not enough and why the structure has to be independently re-derivable.

Map-of-Content: memory as a navigable graph, not a flat heap

The naive way to give an agent memory is a single growing pile — a log, an embedding store, a giant prompt. It retrieves by similarity and hopes the right thing floats up. That works for a demo and degrades the moment two agents need different views of the same facts, or one agent needs to know why it believes something rather than just that it does.

A Map-of-Content (MOC) treats memory as a knowledge graph you navigate, not a heap you dredge. Each note is a node; each [[link]] is a typed edge to a related node. An agent doesn't just match a vector — it walks from "current task" to "relevant prior decision" to "the source that decision cited," and every hop is explicit. The difference from flat memory is the same difference as a city with street names versus a pile of buildings: both contain the same structures, but only one lets you give directions someone else can follow.

Three properties fall out of the MOC model that flat memory cannot give you:

flat memory          Map-of-Content (MOC)
-----------          --------------------
retrieve by guess    navigate by typed edge
no provenance        every node cites its source
opaque to audit      path is re-walkable by a third party
one global view      per-agent reachable subgraph

That last row matters for security. An agent should only reach the memory its task scope allows — and the reachable subgraph is that scope, made concrete. When we audit memory writes for poisoning (a real attack class — see auditable AI proof chains), we are checking that no node was inserted without provenance and no edge was forged to make untrusted content reachable from a trusted task. Provenance is not a nice-to-have here; a memory node with no **Why:** citing a session, a file, or an external reference is treated as suspect. The trust architecture whitepaper describes the layered controls that wrap these writes.

Delegation chains: authority as a verifiable topology

The second graph is the one that decides who is allowed to do what. Every time an agent spawns a subagent, it is handing over a slice of its own authority. If that handoff is invisible, you have built a system where actions appear from nowhere. If it is signed and linked, you have built a topology of authority that walks straight back to a human operator.

We implement this with ProofOfDelegation — a signed event (kind 30014) emitted automatically whenever one agent delegates to another. Each proof records the parent, the child, the timestamp, the scope of what was authorized, and a hash linking to the parent's identity. The proofs are append-only and stored in ProofDB. A delegation chain is just these proofs read end to end:

operator (human, root of trust)
   │  ProofOfDelegation kind=30014  scope=["research"]
   ▼
orchestrator-agent  (passport_hash: a1b2…)
   │  ProofOfDelegation kind=30014  scope=["web-search"]
   ▼
topic-scanner-agent (passport_hash: c3d4…)
   │  ← every edge is HMAC-signed, every node has an ERC-8004 passport
   ▼
   action executed → ProofOfAction emitted, linked to the chain above

Three rules keep this honest, and all three are about the edges of the graph rather than the nodes:

You cannot forge an edge. A subagent's delegation context carries a signature that must verify against the parent's key. A block whose signature fails, or that is missing the parent's passport hash, is rejected before any proof is emitted — this is exactly the forged-delegation attack our red-team agents probe for. The mechanics are spelled out in the verifiable agent delegation whitepaper, the second paper this hub exists to surface.

You cannot exceed your scope. A child cannot act at a higher blast radius than the parent's delegation authorized. Authority only narrows as you walk down the chain; it never widens. State-mutating actions sit behind operator approval regardless of how deep the chain runs.

A revoked node poisons no new edges. If a passport is revoked, no fresh delegation can originate from it. The revocation is itself a published proof, so "this agent lost its authority at time T" is a checkable fact, not an internal flag. This is the same primitive that makes the early Nostr-published trust proofs work: the record lives somewhere a stranger can read it.

Identity persistence across agent spawns

Here is the subtle part. Agents are ephemeral — a subagent might live for ninety seconds and vanish. If identity died with the process, the delegation graph would be a pile of dangling pointers an hour later. It doesn't, because identity in this model is not the process; it is the passport the process held.

Every agent carries an ERC-8004 passport with a stable identifier and an operator binding. When the process exits, the passport persists, and the proofs it signed stay valid because they reference the passport hash, not the runtime. So you can ask, weeks after a fleet of short-lived agents has long since terminated, "what did the agent that produced this artifact have authority to do, and who issued that authority" — and walk the answer out of ProofDB. The runtime is gone; the topology survives it. You can browse the active fleet and its passports at the agents directory.

This is also what lets identity be private without being unaccountable. The chain proves "a passport with this lineage authorized this," and selective disclosure (optionally with a zero-knowledge proof) lets a counterparty verify the link without seeing the whole graph or the underlying operator data. Accountability and privacy stop being a trade-off — see the privacy model and the broader argument in the trust architecture whitepaper. The mechanics of how an agent enters this graph in the first place — register, verify, issue passport, activate, attest — are covered in how it works.

Why this matters for audit and trust

Put the two graphs together — a Map-of-Content memory with provenance on every node, and a delegation topology with a signature on every edge — and an audit stops being an interview and becomes a re-derivation. Hand a third party the proofs; they walk the chains; they reach the same conclusions you did or they find the break. No "trust us." No screenshot. A path they can re-walk.

That is what an unchallengeable agent audit means in practice. We commit findings to a Merkle root, emit them as a signed report, and anchor that report to multiple independent witnesses so the audit cannot be quietly edited after the fact. Our own platform's security posture is published the same way — a MASSAT 4.3/10 score that anyone can re-run rather than a marketing adjective. The honest version of "secure" is a number with a method attached, and the method is this topology.

If you are building a multi-agent system and you cannot currently answer "trace this action back to a human in signed steps," the gap is not a feature you are missing — it is a graph you have not drawn yet. The two whitepapers below draw it. Start with the topological foundations paper for the memory-and-identity model, then read the delegation paper for the proof mechanics, and browse the rest on the BlindOracle blog.