Why AI agent memory becomes a black box, and what I built differently

Most AI memory demos begin with the same satisfying moment.

You tell an agent something in one session. You start another session. The agent remembers it.

That feels like success until you ask the next set of questions:

• Where did this fact come from?
• Which user, project, or workspace owns it?
• Is it still current?
• Did the source change after the memory was created?
• What happens when two sources disagree?
• Can I export it?
• Can I delete it and verify that it is gone?

At that point, "the agent remembers" is no longer enough.

I have been working on this problem in a project called Managed Memory Workspace, or MMW. It is an early-stage system that exposes governed memory to AI agents through the Model Context Protocol (MCP).

This post is not a launch announcement for a finished SaaS. MMW is running in a public staging environment, but it does not have a production SLA, enterprise compliance claims, or paying customers. I am writing about it now because the difficult parts of agent memory become easier to discuss when there is a real implementation to test.

Memory is operational data

The common shortcut is to treat memory as a retrieval problem:

1. Turn text into an embedding.
2. Store it in a vector database.
3. Search for similar text later.
4. Put the result back into the model context.

That can be useful, but retrieval is only one part of memory.

A similarity result does not automatically tell you whether the returned fact belongs to the current tenant. It does not tell you whether the source was revised, whether a human checked the record, or whether a conflicting fact exists. It also does not give you an audit trail or a reliable deletion workflow.

These are data-management questions, not model questions.

The distinction matters because an agent can produce a fluent answer from the wrong memory. The output may look reasonable even when the record came from another workspace, lost its source, or became stale weeks ago.

I started designing MMW around a different assumption:

A remembered fact is a governed record with a lifecycle, not an anonymous chunk of text.

What a memory record needs

In MMW, a memory record can carry more than its content. The useful context includes:

• tenant, project, and workspace ownership;
• source identity;
• source hash and revision;
• confidence and review state;
• timestamps and lifecycle events;
• conflict or stale state;
• export and deletion history.

The exact schema will change as the product develops. The important part is that these properties are explicit. They should not be reconstructed from a prompt after something has already gone wrong.

This leads to a simple operational loop:

remember -> search -> validate -> forget

remember stores a scoped record and its provenance.

search retrieves records inside the authorized boundary.

validate lets the system or an operator update the state of a record when its source is checked.

forget performs controlled deletion instead of asking the model to ignore something in the future.

The names are deliberately plain. The hard work is in the boundaries and evidence around each operation.

Why MCP is useful here

Memory becomes less portable when every agent framework requires a different integration. A team may also change models, agent runtimes, or hosting environments long before the stored knowledge should disappear.

MCP gives MMW a neutral contract between the agent and the memory workspace.

An MCP-compatible client connects to one project-scoped endpoint. The client receives an MMW credential, and the server decides which native memory operations and downstream tools are visible inside that project.

The intended relationship looks like this:

AI agent
   |
   | MCP + project credential
   v
MMW project boundary
   |-- native memory tools
   |-- provenance and lifecycle state
   |-- payload-free audit metadata
   `-- curated downstream MCP tools

The memory should survive a change of model or client without losing its ownership and provenance rules.

MCP does not solve governance by itself. It gives the system a consistent place to enforce it.

The gateway problem

Once an agent can use several MCP servers, another problem appears. Each downstream server may have its own token, tool names, permissions, limits, and failure modes.

Passing every downstream credential directly to every client creates a large trust surface. Tool names can collide. A permissive server can expose more capabilities than the current workflow needs. Audit records can accidentally capture request or response payloads.

MMW therefore includes an MCP Gateway in the pilot.

The current design is intentionally narrow:

• one active downstream MCP connection per Free pilot project;
• an owner-curated server registry;
• fixed tool allowlists;
• project-scoped, write-only downstream secrets;
• namespaced tools;
• server-side call, timeout, response-size, and concurrency limits;
• audit metadata without downstream arguments or response bodies.

The first real connector is GitHub read-only. It exposes three allowlisted tools:

github_readonly.get_file_contents
github_readonly.get_me
github_readonly.pull_request_read

The GitHub token stays on the server side. The MCP client only receives the MMW project credential.

This is less flexible than accepting arbitrary server URLs and arbitrary headers. That is a deliberate trade-off for the pilot. I would rather test a small policy I can explain than ship an open proxy and call it a platform.

What happens when a downstream server fails?

A gateway should not make the native memory system dependent on every connected service.

If a downstream MCP times out or becomes unhealthy, its namespaced tools should fail in a controlled way. Native operations such as remember and search should remain available.

MMW records tool identity, status, timing, and size metadata for gateway calls. It does not store the downstream arguments or response payloads in the audit record.

This does not eliminate every privacy or security risk. It reduces the amount of sensitive material copied into operational logs, which is a useful default for an early pilot.

Provenance before clever retrieval

MMW does not yet use the retrieval stack I would want for a mature system. The current search path is still an early implementation. Embeddings, reranking, evaluation datasets, and more advanced ingestion remain ahead.

That is not hidden behind a vague roadmap. It is part of the current product boundary.

I chose to work on tenant isolation, provenance, deletion, audit, secret handling, and failure isolation before optimizing semantic retrieval. A sophisticated retriever attached to unclear ownership rules would make the system more convincing in a demo without making it safer to operate.

The order matters:

1. Establish who owns the record.
2. Preserve where it came from.
3. Define its lifecycle.
4. Make access and deletion testable.
5. Improve retrieval quality against a measured evaluation set.

That sequence may not fit every memory product. It is the sequence I can defend for MMW.

What has been tested

The current staging release has been exercised through a disposable public pilot lifecycle.

The synthetic run covered:

• signup and login;
• Free activation without a card;
• one-time project credential reveal;
• tenant and project scope;
• downstream registry and secret policy;
• MCP tool discovery;
• a namespaced downstream call;
• payload-free audit;
• disconnect and cleanup.

The same release also completed a read-only call through the hosted GitHub MCP connector. Temporary credentials and synthetic test data were removed after the checks.

Recovery tests cover database integrity, encrypted project-secret recovery, downstream failure isolation, and application rollback in a disposable environment.

These tests prove that specific staging flows worked under the tested conditions. They do not prove production reliability, security certification, or suitability for sensitive customer data.

That distinction is important. Test evidence should narrow a claim, not inflate it.

What MMW is not ready for

The current preview is not the right place for production customer records, regulated data, or a workflow that depends on an uptime guarantee.

The first pilot has several explicit limits:

• synthetic or non-sensitive data only;
• manual onboarding;
• one project and one curated downstream connection;
• no arbitrary bring-your-own MCP servers;
• no team roles or enterprise SSO;
• no production SLA;
• no claim of enterprise compliance;
• no finished billing system.

There is also no public source repository yet. The GitHub repository remains private while I finish the product boundary and decide which SDK, examples, and documentation can be opened without exposing operational material.

This makes outside technical review harder. I consider that a real limitation, not something a landing page can solve.

The design-partner test

I am looking for a small number of developers who already have an AI agent or MCP workflow and can describe a concrete memory failure.

Examples might include:

• a coding agent that loses project decisions between sessions;
• an internal assistant that cannot show where a remembered policy came from;
• a multi-agent workflow where shared facts have unclear ownership;
• an MCP client that needs one controlled route to memory and downstream tools;
• a long-running agent that has no reliable process for stale or conflicting records.

The first run is intentionally small:

1. We map one existing workflow and the point where memory fails.
2. I create one scoped Free pilot workspace and credential.
3. We use synthetic or non-sensitive data.
4. We run the memory lifecycle and inspect the result together.
5. We record what worked, what failed, and what the product should change.

There is no fee and no card. I need direct technical feedback more than vanity signup numbers.

If this problem is close to your work, the design-partner preview is here:

https://mmw-staging.grifun.ru/design-partners/

I would also like to hear the opposite view. If you think agent memory belongs entirely inside the agent harness, or that an external governed workspace creates the wrong abstraction, explain where the boundary should live. That argument is useful at this stage.

The question I am testing is not whether an agent can remember.

It is whether a team can understand, control, move, and delete what the agent remembers after the demo is over.