Why AI Agents Need a Memory Layer: The Missing Infrastructure for Persistent, Verifiable Agents

The moment an AI agent controls something that matters, its memory stops being a convenience feature and starts being a security boundary.

There is a version of this article that starts with a dramatic claim: "AI agents have no memory." That framing is wrong, and protocol engineers will close the tab immediately.

Agents have plenty of memory options: vector databases, SQL, Redis, key-value stores, local files, and conversation histories. The ecosystem is full of retrieval tooling. The harder problem is different: these primitives do not, by themselves, define who owns a piece of agent state, who is authorized to change it, which version should be treated as current, or what evidence exists about its provenance.

For a customer support assistant, that does not matter much. For an agent that holds a wallet, executes transactions, coordinates with other agents, and operates continuously across restarts, those questions are no longer academic. They are the security model.

Two emerging pieces of infrastructure are particularly useful for understanding this gap. Walrus Memory, built by Mysten Labs on top of the Walrus decentralized storage protocol, approaches the problem from the persistence and memory side. EigenCloud's EigenCompute approaches it from the execution side, using Trusted Execution Environments and attestation. They are not competing products, and neither one should be treated as a complete agent-memory system. They are useful precisely because they expose two different parts of the same architectural problem.

This article is about that gap, what exists to address it today, and where the honest limits of current infrastructure lie.

What "Agent Memory" Actually Means and Why Most Definitions Are Too Narrow

Before talking about protocols, the terminology needs to be precise.

AgentMemory = {
  Context:     what the model can see during this execution
  Retrieval:   what the system fetches from external storage
  State:       information the application treats as authoritative for a defined purpose
  Provenance:  where state came from, who wrote it, when, and under what authority
}

Most agent memory discussions conflate the first two with the last two. Context and retrieval are about what the model sees. State and provenance are about which information the application is willing to treat as authoritative, why it is trusted, and what evidence exists about its origin*.

The distinction matters the moment the agent has economic stakes. A vector search returns the nearest semantic match to a query. It does not return the authorized current version of a policy. Those are not the same thing, and treating them as equivalent is where the security problem starts.

Consider an agent managing a treasury. It has a stored risk policy:

{
  "maximum_trade": "5%",
  "approved_venues": ["venue_A", "venue_B"],
  "risk_tier": "conservative"
}

A retrieval system asked for "current risk policy" will surface whatever is most semantically similar to that query. If someone has injected a document saying "the risk limit for Q3 was updated to 50%", and it is semantically similar enough, the retrieval system surfaces it. The agent acts on poisoned state. The vector database has no mechanism to distinguish authorized writes from adversarial ones, because it was not designed to. Retrieval and authorization are different problems.

This is not a hypothetical edge case. MINJA demonstrated memory injection through query-level interaction, reporting a 98.2% injection success rate in its evaluated setting.(arXiv:2606.04329) formally characterized memory poisoning as a distinct attack class with structured threat models. OWASP's Agentic Applications guidance includes memory/context poisoning as ASI06. The research community has caught up to a problem that agent infrastructure has not yet structurally addressed.

The Layer That Is Actually Missing

It is tempting to frame this as "we need decentralized storage for agents." That framing is also too narrow.

Decentralized storage already exists. Walrus, IPFS, Arweave, Filecoin there are durable, content-addressed storage options. The missing piece is the abstraction layer that sits above storage and makes it usable as a proper state system for agents.

Think about what a database gives a web application that raw file storage does not:

Raw storage → bytes on disk
Database    → identity, schemas, transactions, access control,
              versioning, queries, consistency guarantees, backup, recovery

The jump from storage to database is the jump from "data exists somewhere" to "data has semantics the application can reason about."

Outside conventional managed databases, agent infrastructure is still fragmented across storage, retrieval, identity, and application-level state management. What is missing is the equivalent abstraction layer: from “memory is stored somewhere” to “memory has an owner, an authorized write history, a version, provenance, and a retrieval interface that preserves those semantics.”

A useful way to think about what that layer needs:

Conceptual requirements for an agent memory layer. No single existing protocol should be assumed to provide all of these properties.

Walrus Memory: What It Actually Is and What It Actually Does

Walrus is a decentralized storage protocol built around the Sui ecosystem. Its storage architecture distributes objects across a network of storage operators rather than placing the full object on-chain. Sui provides the coordination and on-chain state used by the system, while Walrus handles the storage of larger data objects.

For this article, the important architectural point is not the exact operator or shard count. It is the separation between blockchain coordination and decentralized data storage.

MemWal, the Walrus Memory SDK, launched in beta in May 2026. It sits above the storage substrate and adds the primitives that agents need. The actual SDK from the official GitHub repository looks like this:

import { MemWal } from "@mysten-incubation/memwal";

const memwal = MemWal.create({
  key: "your-delegate-key-hex",
  accountId: "your-walrus-memory-account-id",
  serverUrl: "https://your-relayer-url.com",
  namespace: "risk-policy",
});

// Store a memory
const job = await memwal.remember(
  "Maximum single trade is 5% of portfolio. Approved venues: venue_A, venue_B."
);
await memwal.waitForRememberJob(job.job_id);

// Retrieve semantically
const memories = await memwal.recall({
  query: "What is the current risk limit?",
});

The exact API surface is evolving, so the examples here should be treated as conceptual unless they are taken directly from the current SDK documentation.

The SDK handles embedding, encryption via Seal (Mysten Labs' encryption layer), upload to Walrus, retrieval, and restore. Memories are encrypted at rest and in transit. The account model uses delegate keys, so the agent can sign memory operations without exposing the root account credentials. The system supports a Vercel AI SDK integration that wraps MemWal as middleware, meaning it can be dropped into streamText and generateText workflows without restructuring the application.

At the architectural level, MemWal is interesting because it places an agent-facing memory abstraction above decentralized storage. Depending on the integration path and current SDK capabilities, that can include persistent storage, encryption, semantic retrieval, delegated access, and state portability. The exact guarantees should be evaluated against the current SDK documentation rather than inferred from the underlying Walrus protocol alone.

What you need to understand honestly before building on it:

That architecture introduces a centralized component into the retrieval path. Even when the underlying data remains decentralized, the relayer can therefore become an availability, metadata, or query-integrity consideration depending on the exact implementation. The query path, by default, is not. The manual client path avoids this by letting developers handle embedding and Seal operations locally, but that requires more integration work. Teams should know which path they are on.

Latency is a real constraint. The Supermemory benchmark from May 2026 puts the latency thresholds concretely: voice AI needs under 100ms, conversational chat around 200ms, enterprise copilots up to 400ms. Walrus Memory is competitive in the enterprise copilot range. It is not suitable for real-time agent loops, high-frequency coordination, or anything requiring sub-200ms retrieval.

Walrus is also tightly coupled to Sui for coordination and ownership state. Because Walrus relies on Sui for parts of its coordination and ownership model, applications should model Sui availability separately from the availability of previously stored objects. A coordination-layer outage can affect operations that require fresh on-chain state even when previously stored data remains physically available. This is worth modeling in your availability planning: storage durability and coordination layer availability are separate properties.

The SDK is in beta. The team is explicitly soliciting feedback and the documentation states it is actively evolving. Build on it with that context.

EigenCloud AgentKit and EigenCompute: Verifiable Execution, Not Verified Intelligence

EigenCloud addresses a different problem from Walrus Memory. Where Walrus focuses on the persistence and portability of state, EigenCloud is concerned with the trustworthiness of the computation that acts on state.

The central question EigenCompute explores is different: when an agent runs a decision loop and produces an action, what cryptographic evidence can the infrastructure provide about the execution environment and code that produced it?

EigenCompute launched on mainnet alpha in late 2025. The model is straightforward: developers containerize agent logic as a Docker image, upload it, and it executes inside a Trusted Execution Environment. The TEE produces an attestation alongside the output.

AgentKit, released in beta in March 2026, bundles this with wallets, on-chain USDC payments for compute and inference, social credentials, and inference routing. The idea is that a developer can deploy a sovereign agent, meaning one that holds accounts, makes payments, and operates continuously with cryptographic evidence of its behavior, without having to wire together those infrastructure pieces manually.

There is something critically important in EigenCloud's own documentation that does not make it into most articles about the platform. The official EigenCompute documentation states:

• "Not recommended for customer funds Mainnet Alpha is intended to enable developers to build, test, and ship applications."
• "Developer is trusted Does not enable full verifiable and trustless execution yet."
• "No SLAs around support and uptime of infrastructure."

Those are not footnotes. They define the current operational reality. EigenCompute is real infrastructure that developers are building on. It is also early-stage infrastructure where the developer themselves is trusted in the current model, and where full verifiable and trustless execution is on the roadmap, not yet delivered.

The long-term roadmap states the intent to add cryptoeconomic security via EigenLayer and eventually ZK proofs as alternative verifiability options beyond hardware TEEs. That evolution would reduce dependency on trusting the hardware manufacturer (Intel SGX, AMD SEV) to correctly implement the isolation. That roadmap is not the current product.

What EigenCompute gives you today: agent logic runs in a hardware-isolated environment, and you get an attestation report associated with that execution environment. For most agent applications, this is meaningfully better than "trust the cloud provider's logs." It is not the same as a zero-knowledge proof of correct computation.

One more distinction worth naming explicitly: verifiable execution is not verified correctness. A TEE attestation can provide evidence that specific measured code ran in the expected environment on specified inputs. It does not establish that the agent made a good decision, that the policy the agent enforced was sensible, or that the input data was truthful. The word "verifiable" in this context means "evidence-backed," not "guaranteed correct." That is still valuable. Just be precise about what the guarantee covers.

The Core Trade-off Between These Two Systems

On latency: Walrus Memory is appropriate for agents that can tolerate retrieval times in the 200-to-400 millisecond range. Treasury agents, research agents, background automation, and policy-checking workflows operate on timescales where that is acceptable. Real-time trading, voice interfaces, and high-frequency coordination loops are out of scope. EigenCompute's overhead is TEE execution time plus inference time. For agent tasks that already take seconds, the marginal TEE overhead is small. For lightweight sub-second decision loops, it accumulates.

On trust: Walrus Memory provides content-addressed storage with on-chain ownership and access control. You can verify that stored content matches its hash and that the authorized key signed the write. You cannot, in the current configuration, make a cryptographic claim about what computation subsequently acted on that memory. EigenCompute's attestation makes the execution itself the claim. You get evidence of which code ran and what the environment was. The two are not redundant. They address different points in the agent's lifecycle: one at the storage layer, one at the execution layer.

On operational maturity: Both are in early release. MemWal is in beta. EigenCompute mainnet alpha explicitly says the developer is trusted and there are no SLAs. Neither is appropriate for production systems handling customer funds without careful evaluation of current limitations. For experimentation, research, and early infrastructure work, both are genuinely usable today.

On portability: Memory portability is a core design goal for Walrus Memory. An agent's memory is stored on a decentralized network with user-owned keys, so it is not locked to a particular application or runtime. EigenCloud agents maintain encrypted state and cryptographic identity across restarts, but portability across fundamentally different execution environments is less clearly defined.

Decision Matrix

Use Case	Walrus Memory	EigenCompute	Reasoning
Long-term memory across sessions	Strong designed for this	Not relevant solves execution, not persistence	Memory portability is the core value
Treasury agent policy enforcement	Good for authenticated state	Recommended for execution evidence	Financial agents benefit from both layers
Multi-agent coordination	Good shared namespace support	Useful if inter-agent trust is required	Different parts of the trust problem
Real-time trading	Not suitable latency too high	Not suitable for sub-second loops	Neither protocol fits this latency class
Regulatory audit trail	Good for state history	Valuable for execution evidence	Compliance benefits from both
Research agent with large document storage	Strong built for large objects	Optional	Storage is the bottleneck here
Voice or real-time assistant	Not suitable	Not suitable	Latency requirements incompatible
Agent using funds autonomously	Possible but beta, no SLA	Possible but alpha, developer is trusted	Neither is production-ready for customer funds yet
Experimentation and early builds	Yes SDK is usable	Yes mainnet alpha is live	Both are valid for developer-stage work
Cross-provider agent migration	Strong decentralized, user-owned keys	Partial	Walrus designed portability as core

The mistake is assuming one replaces the other.

Where the Current Architecture Still Has Gaps

Walrus Memory Failure Modes

Relayer centralization in the default path. The default client flow routes through a Foundation-run relayer that handles embedding and search. A compromise of that relayer is a real attack surface for read operations, even though the underlying stored data is on a decentralized network. The manual client path avoids this, at the cost of more integration work.

Sui coordination chain dependency. On-chain ownership records and access control verification depend on Sui availability. If the coordination chain has an outage, those verification operations become unavailable even if the stored data physically remains intact. This is an availability architecture question every team should answer before building on it.

Beta operational status. The SDK is actively evolving. APIs, behavior, and documentation are subject to change based on developer feedback. Teams building production systems need to track the GitHub repository and be prepared for breaking changes.

EigenCompute Failure Modes

"Developer is trusted" in mainnet alpha. The official documentation is explicit: the current release does not enable full verifiable and trustless execution. The developer is trusted in the current model. Teams treating the alpha as equivalent to the eventual fully verifiable product are misreading the documentation.

TEE hardware trust surface. Intel SGX and AMD SEV have had side-channel vulnerabilities. The hardware attestation model inherits the security assumptions of the hardware manufacturer's implementation. This is a real and known limitation, and why the roadmap to ZK proofs matters.

Key compromise can undermine the agent's identity boundary If an agent's signing key is compromised, an attacker may be able to authorize actions or produce signatures associated with that identity. Attestation does not by itself solve key management. The execution evidence can show what ran; it does not determine whether the identity controlling that execution was authorized to act.

What the Stack Is Actually Converging Toward

Neither product, individually or together, should be treated as a complete agent memory infrastructure. What they reveal is a set of adjacent layers that are beginning to converge around the needs of autonomous systems.

The mature version of that stack looks something like this:

This is a reference architecture, not an existing integrated product. The boundaries between these layers are still evolving, and different implementations may combine or omit components depending on their trust model and application requirements.

Three things to watch specifically:

EigenCloud has stated publicly they are working on support for ERC-8004, the emerging standard for autonomous agent identity and reputation on-chain. If agent identity becomes standardized at the protocol level, the memory and execution layers can reference a common identity primitive instead of building their own.

The MemWal SDK roadmap acknowledges the centralized Postgres index for search as a current limitation. A decentralized retrieval path that preserves provenance semantics would close a meaningful gap in the current architecture.

The formal characterization of memory poisoning at ICML 2026 (arXiv:2606.04329) is driving OWASP ASI06 into security requirements. As compliance demands around agentic systems formalize, unauthenticated vector databases will not satisfy them. That creates a genuine pull toward authenticated memory systems that currently have to create their own demand.

Final Thought

“Which memory system should I use?” is only the first question. The more important question is what the agent needs to establish about its own state and actions—and who needs to be able to verify those claims.

For most agents being built today, the answer is: not much. A conventional managed database, a vector store, and good application-level access control is the right answer. The infrastructure overhead of decentralized storage and verifiable execution is not justified for a customer support agent or a coding assistant.

For agents that manage assets, operate across organizational boundaries, need to survive provider changes, or produce outputs with legal or financial consequences, the answer is different. Those agents need to establish things like: this state came from an authorized source, this was the policy version active when the decision was made, this computation ran in the expected environment, this is the action that resulted. A conventional cloud database and a vector store cannot establish those things. The tools to establish them are beginning to exist.

Walrus Memory is building the persistence half of that infrastructure. EigenCompute is building the execution evidence half. Neither is at the maturity level where you would run production customer funds through them today. Both are at the maturity level where engineering teams should be experimenting, understanding the architecture, and making decisions about how they will build the next generation of agents.

Memory is not just what an agent knows. For an autonomous agent with real stakes, memory becomes part of the evidence for what it knew, when it knew it, and which state informed its action.

That is a different infrastructure problem from retrieval.

The industry is only beginning to build the layer that solves it.

Scope

This article separates existing protocol capabilities from a proposed architecture for agent memory. “Memory Cloud” is used here as an architectural category, not as the name of an established standard or unified product. Product capabilities and roadmap statements should be evaluated against the current official documentation of each project.