The memory problem: Why AI agents keep forgetting and what Walrus Memory changes

We keep calling AI agents intelligent.

But there's a strange limitation hiding underneath all of them:

They're terrible at remembering.

An agent can spend hours researching something today, then open a new session tomorrow with no idea what it learned.

One agent can make a decision, another agent can take over the workflow, and suddenly the second agent has no idea why the first one made that decision.

A user can spend weeks teaching an AI assistant their preferences, workflows, and context, then switch applications and start over.

The intelligence is there.

The memory isn't.

And as AI moves from chatbots that answer individual questions toward agents that work continuously, this becomes a much bigger problem.

I started looking into why this happens and what builders are doing about it.

That's when I came across Walrus Memory.

I wanted to understand what it actually does, how it works, and whether persistent memory is really enough to change how agents operate.

Because storing data isn't the hard part.

Making memory persistent, portable, controllable, and useful to an agent is.

The problem isn't intelligence. It's continuity.

Think about how a normal AI interaction works.

You ask an agent to research a company.

It searches.

It reads.

It reasons.

It produces an answer.

Then the session ends.

Tomorrow, you ask it to continue the research.

Depending on how the application is built, the agent may have little or no access to everything it learned yesterday.

So you give it the old conversation.

Or paste the notes.

Or build some kind of retrieval system.

Now imagine doing that across dozens of agents.

Agent A researches.

Agent B analyzes the research.

Agent C turns it into a report.

Agent D monitors what happens afterward.

If every agent has its own isolated memory, you're constantly passing context from one system to another.

That creates a strange bottleneck:

The agents can work faster than the memory infrastructure connecting them.

And the problem gets worse as workflows become longer.

A customer support agent needs to remember what happened in previous conversations.

A research agent needs to remember what it already investigated.

A personal assistant needs to remember preferences.

A coding agent needs to remember decisions made earlier in a project.

A multi-agent system needs agents to share information without constantly repeating themselves.

These aren't problems with the model's ability to generate text.

They're memory problems.

So what is Walrus Memory?

Walrus Memory is a memory layer for AI agents.

The basic idea is simple:

Instead of treating memory as something trapped inside one application or one session, make it persistent infrastructure that agents can access when they need it.

Walrus Memory is designed to let memory work across apps, sessions, and workflows.

That means an agent can store useful context and retrieve it later instead of treating every interaction like a blank slate.

But there's an important distinction here.

This isn't simply another database where you dump conversation logs.

Walrus Memory combines memory operations with decentralized storage, encryption, programmable access control, and semantic retrieval.

That creates four properties that matter.

1. Persistent

The memory survives beyond the current conversation.

An agent can remember information from previous sessions instead of starting from zero every time.

1. Portable

The memory isn't designed to belong exclusively to one application or model provider.

It can move across agents, apps, and workflows.

That matters because the AI stack is changing quickly.

You might use one agent today and another six months from now.

Your memory shouldn't necessarily have to start over with the switch.

1. Controllable

Memory belongs to an owner, and access can be delegated.

Walrus Memory uses Sui smart contracts to manage ownership and delegate access, allowing specific agents, users, or services to be granted permission to interact with a memory space.

1. Verifiable

The underlying memory is stored as encrypted data on Walrus.

That gives you a durable source of truth while allowing the integrity of the stored data to be independently verified.

And that last part is where this starts getting interesting.

Because if AI agents are going to operate for long periods without humans checking every step, being able to trust the information they remember becomes just as important as remembering it.

How Walrus Memory Actually Works

The easiest way to understand Walrus Memory is to follow one memory through the system.

Imagine an AI assistant learns:

The user prefers TypeScript and usually deploys projects on Vercel.

The agent can save that as a memory.

Behind the scenes, Walrus Memory handles several things.

Step 1: The memory is processed

The system creates an embedding so the memory can later be found based on meaning rather than requiring an exact keyword match.

Step 2: The memory is encrypted

The actual memory content is encrypted using Seal.

Step 3: The encrypted data is stored on Walrus

The encrypted payload becomes a Walrus blob.

Walrus acts as the durable storage layer.

Step 4: The memory is indexed

The system keeps the information necessary to search memories efficiently.

The current architecture uses PostgreSQL with pgvector for the searchable embeddings, while Walrus remains the durable source of truth.

Step 5: The agent needs the information later

The agent can ask something like:

"What do I know about this user's development preferences?"

Instead of searching for the exact sentence that was stored, the system performs semantic retrieval and finds relevant memories.

The result is returned to the agent as context.

So the agent isn't magically developing a human brain.

It's doing something more useful:

It has somewhere reliable to put things it needs to remember.

The Interesting Part: Memory Can Be Shared

This is where Walrus Memory becomes more interesting than simply giving one chatbot a longer conversation history.

Imagine you have four agents.

One researches a market.

One analyzes competitors.

One writes the report.

One monitors the market afterward.

Without shared memory, these agents are mostly isolated.

The researcher finishes its work.

The analyst needs the findings.

The writer needs the analyst's conclusions.

The monitoring agent needs to know what the team already discovered.

You can solve this with APIs and custom databases.

But then you're building an increasingly complicated system just to answer one question:

Where does the shared context live?

With Walrus Memory, agents can operate around shared memory spaces and delegated access.

The researcher can write.

The analyst can read.

The writer can access the relevant information.

The monitoring agent can continue adding new observations.

The memory becomes a shared layer underneath the agents rather than something belonging to one agent.

Walrus explicitly positions shared memory spaces as infrastructure for multi-agent coordination and long-running workflows.

And that changes the role of memory.

It stops being a feature of an AI application.

It starts becoming infrastructure for the agents themselves.

What This Looks Like in the Real World

Consider a research agent.

You ask it to investigate a company.

On day one, it discovers ten useful sources.

On day two, it discovers five more.

On day three, it realizes two of its original assumptions were wrong.

A normal workflow might leave all of this inside a chat history, local database, or application-specific memory system.

A persistent memory layer lets the agent retain the useful information as structured, searchable memory.

Three months later, you can ask:

"What did we learn about this company last time?"

The agent doesn't necessarily have to start the investigation again.

It can recall the previous research.

Now change the scenario.

Instead of one research agent, you have a team of agents.

One collects information.

One verifies it.

One analyzes it.

One writes.

One monitors new developments.

They can operate around the same underlying memory rather than constantly passing entire histories between themselves.

That's the kind of workflow persistent shared memory makes possible.

Memory Isn't Just About Chat History

This is an important distinction.

When people hear "AI memory," they often think:

"So the chatbot remembers my previous messages."

That's part of it.

But the more interesting applications are much larger.

Personal AI

Your assistant could remember your preferences, recurring tasks, important decisions, and context over time.

And because the memory isn't inherently tied to one application, it could potentially follow you across different AI experiences.

Research

An agent can build knowledge over weeks rather than repeatedly starting from scratch.

It can remember what it investigated, what it found, what it ruled out, and what still needs to be explored.

Multi-agent systems

Agents can coordinate around shared memory.

One agent can leave information for another without requiring the entire conversation to be passed manually.

Long-running workflows

Agents that operate continuously can maintain state between sessions.

That matters for monitoring, research, automation, and other workflows that don't end after one prompt.

Knowledge tools

Notes, insights, references, and other information can become searchable memory instead of disappearing into isolated application databases.

These are all use cases Walrus currently highlights for the system.

But There's a Catch

Persistent memory sounds great until you ask a harder question:

What exactly should an agent remember?

Because storing everything isn't the answer.

Imagine an agent records every message, every intermediate thought, every failed attempt, every API response, and every tiny interaction.

You've technically created memory.

But you've also created a mess.

Useful AI memory needs structure.

The system has to distinguish between:

Things worth remembering

User preferences.

Important decisions.

Long-term goals.

Research findings.

Constraints.

Relationships between pieces of information.

And:

Things that can be forgotten

Temporary instructions.

Redundant context.

Intermediate outputs.

Noise.

That means memory architecture is still an engineering problem.

Walrus Memory gives builders the infrastructure for storing and retrieving memory.

It doesn't automatically solve the question of what your application should remember.

That's still on the builder.

Another Important Trade-Off

There's also a detail that gets lost when people describe decentralized storage as if it automatically means "nobody can ever see your data."

The current Walrus Memory architecture uses a relayer to handle operations such as embeddings, encryption, storage, and retrieval.

In the default SDK path, the relayer can see plaintext while performing those operations.

Walrus's documentation explicitly describes this as a trust trade-off for developer convenience.

Builders who need a different trust model can self-host the relayer or use more client-managed flows.

That's worth knowing.

Because "encrypted on Walrus" and "every component in the stack is unable to see plaintext" are not the same claim.

And this is exactly the kind of distinction worth making when you're talking about infrastructure.

Walrus Memory Is Also Still Early

There's another important caveat.

Walrus Memory is currently in beta and is actively evolving.

That means the technology is usable, but builders should expect the developer experience and operational guidance to continue changing.

That's not necessarily a weakness.

Early infrastructure products are supposed to evolve.

But it does mean you shouldn't approach Walrus Memory as if it's a finished replacement for every existing memory architecture.

It's a developing infrastructure layer with a particular thesis:

AI memory should be persistent, portable, controllable, and verifiable.

So Who Is This Actually For?

After looking at how the system works, I think the strongest use cases are pretty clear.

Walrus Memory makes sense if:

You're building agents that operate across multiple sessions.

You're building multi-agent workflows where agents need shared context.

You're building AI assistants that should remember users over time.

You're building research or knowledge systems that accumulate information.

You want memory to exist independently from one particular application or model provider.

You care about ownership and programmable access control.

You need durable, verifiable storage underneath agent workflows.

It probably isn't necessary if:

Your application only needs temporary context.

You're building a simple chatbot that doesn't need long-term memory.

Your system requires extremely low-latency ephemeral state.

Your application doesn't benefit from portability or shared agent memory.

In those cases, a conventional database may be simpler.

And that's fine.

Not every problem needs decentralized infrastructure.

The Bigger Shift

The interesting thing about Walrus Memory isn't simply that AI can remember a conversation.

We've had databases, vector stores, context windows, and retrieval systems for years.

The more interesting question is:

What happens when memory becomes independent infrastructure?

Today, an application's memory often belongs to the application.

Your data lives inside the chatbot.

Your agent's knowledge lives inside its framework.

Your assistant's history lives inside its provider.

Move somewhere else and you may have to start over.

But imagine a world where your AI memory is something you control independently.

You could have one agent access it today.

Another agent access it tomorrow.

A different application use the same memory next month.

A team of agents work from a shared memory space.

And permissions can be changed without rebuilding the entire application.

That's a very different model.

The AI model becomes replaceable.

The application becomes replaceable.

The memory remains.

The Real Question

Will every AI application need Walrus Memory?

No.

Should every agent store everything forever?

Definitely not.

Is decentralized storage automatically better than a conventional database?

No.

But I think Walrus Memory is asking the right question at the right time.

AI is moving from:

"Give me a prompt and I'll give you an answer."

toward:

"Give me a goal and let me work on it."

The second type of AI needs something the first type could mostly avoid:

continuity.

An agent working for five minutes can get away with being forgetful.

An agent working for five weeks can't.

A single chatbot can survive with isolated context.

A network of agents needs shared context.

And an AI system that people are expected to trust over time needs more than memory.

It needs memory that can be controlled, accessed, and verified.

That's the part I find most interesting about Walrus Memory.

It isn't trying to make AI smarter.

It's trying to give AI somewhere to remember.

And if agents really are going to become persistent workers rather than disposable chat sessions, that might end up being one of the most important pieces of infrastructure they need.