memBrain — Agentic Memory That Can Change Safely
Inspiration
AI agents are becoming increasingly capable of acting autonomously: diagnosing incidents, making decisions, running workflows, and interacting with production systems.
But there is a fundamental problem that becomes more serious as agents become more autonomous:
What happens when an agent remembers something that is no longer true?
A belief stored by one agent can later become outdated because new evidence arrives. If another agent has already made a decision based on that belief, and an action is waiting to execute, simply updating the memory is not enough.
The system needs to understand the relationships and consequences of changing memory.
That led us to build memBrain: an agentic memory system where beliefs are persistent, evidence-backed, versioned, and connected to the decisions and actions that depend on them.
The Core Idea
memBrain treats agent memory as a lifecycle, rather than a collection of text snippets.
ACTIVE BELIEF
│
│ contradictory evidence
▼
REVISED
│
├──────────► dependent decision → INVALID
│
└──────────► dependent action → BLOCKED
│
│ supporting evidence
▼
NEW ACTIVE GENERATION
│
└──────────► supersedes old belief
without inheriting
stale dependencies
A revised belief is never silently resurrected. If later evidence supports the original idea, memBrain creates a new generation of the belief while preserving the historical lineage.
The old decision remains invalid and the blocked action remains blocked.
This gives the agent memory provenance, lifecycle, and consequences, rather than simply giving it a larger context window.
How We Built It
The application is built around a persistent transactional memory model.
CockroachDB stores the canonical state:
- Beliefs
- Evidence
- Decisions
- Actions
- Dependencies
- Belief revisions
- Supersession relationships
- Vector embeddings
CockroachDB's distributed vector indexing is used for semantic retrieval. When an incident arrives, memBrain generates an embedding and searches the active belief memory for semantically relevant candidates.
The retrieved memory is then passed to the reasoning layer.
Amazon Bedrock provides the model reasoning used to evaluate the incoming evidence and determine whether the existing belief should change.
The resulting lifecycle transition is then persisted transactionally in CockroachDB.
Finally, the system uses the CockroachDB Cloud Managed MCP Server as a read-only verification layer. After the lifecycle transition, memBrain can inspect the canonical database state through MCP and show the resulting belief, decision, and action state directly from CockroachDB.
The application itself runs on Amazon ECS/Fargate, behind an Application Load Balancer, while AWS Systems Manager Parameter Store provides secure runtime configuration and credentials.
The resulting flow is:
┌──────────────────┐
│ Incident / │
│ New Evidence │
└────────┬─────────┘
│
▼
┌─────────────────────┐
│ CockroachDB Vector │
│ Semantic Retrieval │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Amazon Bedrock │
│ Reasoning │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ CockroachDB │
│ Transactional State │
│ │
│ Belief → Decision │
│ → Action │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Managed MCP Server │
│ Read-only canonical │
│ state verification │
└─────────────────────┘
What the Demo Shows
The demo starts with an active belief:
"Latency began after deployment 742."
A dependent rollback decision has been approved, and an action is waiting to execute.
We then submit contradictory incident evidence showing that database contention and latency actually began before deployment 742.
memBrain retrieves the relevant belief using semantic search and asks the reasoning model to evaluate the contradiction.
The resulting state becomes:
B1: ACTIVE → REVISED
D1: APPROVED → INVALID
A1: PENDING → BLOCKED
The important part is that the system does not simply change the text of the belief.
It propagates the consequence through the dependency graph.
We then introduce supporting evidence. Instead of resurrecting the historical belief, memBrain creates a new active generation:
B1: REVISED
│
│ superseded by
▼
B2: ACTIVE
The old invalid decision and blocked action remain unchanged.
This demonstrates the central property of memBrain:
New memory can change what an agent believes without accidentally resurrecting decisions that were made using stale information.
Why CockroachDB Matters
CockroachDB is not being used merely as a storage layer.
It acts as the canonical memory and consistency layer for the agent.
The application needs to maintain relationships between memory, decisions, and actions while those states change. Keeping semantic retrieval and transactional state in the same database avoids creating a separate vector store whose state could diverge from the operational memory.
CockroachDB therefore provides:
- Persistent transactional memory
- Distributed vector retrieval
- Durable provenance and lineage
- Dependency-aware state transitions
- A canonical source of truth for agent state
- MCP-based inspection of that canonical state
This becomes increasingly important as agentic workloads grow.
We have not claimed a benchmark demonstrating 100 concurrent agents. Instead, memBrain is designed around the consistency problem that emerges when many autonomous agents read and update shared memory concurrently.
The goal is to make the memory layer safe as the number of autonomous actors and state transitions increases.
What We Learned
One of the biggest lessons from building memBrain was that agent memory is fundamentally a state-management problem.
It is tempting to think of memory as:
query → retrieve documents → give them to the LLM
But production agents need more.
They need to know:
- What is currently believed?
- Why is it believed?
- What evidence changed it?
- Which decisions depend on it?
- Which actions are affected?
- What happens when new evidence arrives?
- Can an old belief safely become active again?
Designing these relationships forced us to think about agent memory more like a database-backed state machine than a traditional RAG pipeline.
We also learned that independent verification is valuable. The MCP inspection gives the application a way to inspect the canonical database state after an agentic transition instead of relying solely on the model's interpretation of what happened.
Challenges
1. Keeping Semantic Memory and Transactional State Consistent
A vector search result alone cannot tell us whether a belief is still valid.
We had to combine semantic retrieval with structured lifecycle state so that only appropriate active memories participate in the reasoning process.
2. Propagating Belief Changes Safely
Changing a belief can invalidate decisions and actions.
We implemented explicit relationships between:
Belief → Decision → Action
so that a lifecycle transition can determine its blast radius rather than relying on implicit application behavior.
3. Preventing Stale Memory from Being Resurrected
A particularly important edge case was supporting evidence arriving after a belief had already been revised.
Instead of changing:
REVISED → ACTIVE
we create:
REVISED B1 → ACTIVE B2
while preserving the historical state and preventing old dependencies from transferring.
4. Making MCP Useful Without Turning It Into a Mutation Path
We wanted MCP to provide real value rather than simply appearing in the architecture.
memBrain uses the CockroachDB Managed MCP Server for read-only inspection and verification. Mutation operations remain controlled by the application's transactional state machine.
5. Operating Real Cloud Infrastructure
The application is deployed on AWS ECS/Fargate, uses Amazon Bedrock for reasoning, and uses AWS Systems Manager for runtime secrets and configuration.
Getting the complete path working—from the browser through the ALB and ECS service, into the AI providers and CockroachDB—was an important part of validating that the architecture worked beyond a local prototype.
Production-Oriented Design
memBrain was designed with failure and degraded integrations in mind.
If an external AI or MCP integration is unavailable, the application does not fabricate results.
The system exposes the integration state and degrades gracefully while keeping CockroachDB as the canonical source of truth.
The MCP integration is also explicitly read-only, and credentials are kept outside the container image using AWS-managed secret injection.
The Bigger Picture
The long-term problem we are interested in is not simply building agents that can remember more.
It is building agents that can remember safely.
As autonomous systems become more numerous, multiple agents may eventually share the same evolving memory:
Agent A ─┐
Agent B ─┤
Agent C ─┼──► Shared Persistent Memory
Agent D ─┤
Agent E ─┘
│
▼
Decisions & Actions
At that point, stale memory is no longer just a retrieval problem.
It becomes a consistency, lineage, and safety problem.
memBrain is our exploration of what an agent memory layer should look like when those properties matter.
Built With
CockroachDB · CockroachDB Distributed Vector Indexing · CockroachDB Cloud Managed MCP · Amazon Bedrock · Amazon ECS/Fargate · AWS Systems Manager · Python · FastAPI · React
Log in or sign up for Devpost to join the conversation.