The Agent Persistence Stack

Your AI agent spends 20 minutes setting up a project. You go to lunch. You come back, and it's all gone.
This happens all the time, and AWS just admitted it's a real problem.

What AWS shipped

Last week AWS added managed session storage to Bedrock AgentCore Runtime. Each agent session runs in its own isolated microVM. When that VM shuts down — because you stopped it or because the idle timeout fired — the filesystem goes with it. Installed packages, generated code, git history, build artifacts, gone.
The fix is a persistent mount point, /mnt/workspace, that survives session restarts. Write your files there, stop the session, come back tomorrow, and they're still where you left them. The agent resumes instead of reinstalling everything from scratch.
It's a clean fix for a real problem. It just fixes one layer.

Filesystem state is only one layer

When people say "my agent forgot everything," they usually mean one of three things — and those three things aren't the same.
Knowledge memory is what your agent knows. The decisions you made last week. The architecture you picked and the reason you picked it. Your preferences, your project context, the debugging breakthrough from three days ago. This is what keeps an agent useful months in, not just on the first afternoon.
Filesystem state is what your agent built. The code it wrote, the packages it installed, the build tooling it configured. This is the layer AWS just handled: when the compute dies, the work product lives.
Configuration is how your agent connects. API keys, endpoints, auth tokens — the dotfiles and environment variables that wire it to the services it needs. Existing tools mostly cover this already: .env files, secrets managers, config management.
Each layer is a different version of "my agent forgot."

The gap at the top

AWS took the middle layer. The bottom layer is mostly handled. The top one — knowledge memory — is the one nobody has really cracked.
Think about how you actually work with a coding assistant. You walk it through your project structure. You describe your conventions. You mention the bug you hit last week and the workaround you found. You explain why you went with Postgres over MongoDB. You pass along the team's decision on the API design.
Then you open a new session and do all of it again.
The filesystem persistence AWS shipped doesn't touch this. Your agent's /mnt/workspace holds your code, but not the reasoning behind it. It doesn't know you tried three approaches before this one, or that the lead dev wants small PRs, or that staging has a known connection-pooling issue.
That's the knowledge layer, and it needs its own way to persist.

How I'm thinking about it

I'm building Ogham, a persistent shared-memory layer for AI agents. It stores decisions, context, and preferences as searchable memories, with hybrid retrieval — semantic similarity plus keyword matching. It runs over MCP, so the same memory follows you whether you're in Claude Code, Cursor, a Slack bot, or a CLI.
I'm biased; it's my product. But the framework holds no matter what you plug into each layer. Use any knowledge tool you like for the top one. The point is that you need something there, and it's a different problem from filesystem persistence.

Why this matters now

When AWS starts building persistence infrastructure for agents, that tells you where the industry is going. They didn't ship this as a nice-to-have. They shipped it because their customers — teams running agents in production — kept hitting the same wall.
Agents that forget cost you time. Every re-explanation is a tax you pay twice.
I'm not selling you a stack. I'm describing how to think about the problem. Filesystem, knowledge, and configuration are separate concerns, and each one needs its own fix. AWS just made the case for one of them. The other two matter just as much.
An agent that can't remember is a dead end. The question is which layer you fix first — and most teams haven't touched the hardest one.