When AI remembers too much: why we taught MCP36.4 to doubt its own memory

Imagine an exceptionally capable colleague. They read quickly, write good code and never forget. On their desk is a shared notebook in which they record what seemed to work after every task.

At first, this sounds ideal. Then a problem appears.

One day they solve an exceptional case incorrectly and turn it into a general rule. Another day they merge two situations that sound similar but have different safety conditions. With every rewrite, a small but decisive phrase—“valid only when…” —disappears from the note.

The colleague has not forgotten. Quite the opposite: they reliably recall the wrong lesson.

This is not merely a thought experiment. Recent studies of memory-augmented AI agents show that storing more experience does not automatically improve performance. That uncomfortable nuance is the main reason MCP36 followed MCP35.4, and why MCP36.4 makes the first real activation deliberately slow, bounded and reversible.

In this article, MCP36.4 names an internal generation of ITHZ-MCP and CCG, not a release of the public Model Context Protocol standard.

What the original studies actually found

The video that popularised this topic captured the central concern: memory is not the same thing as learning. Checking the original papers, however, reveals a more interesting message than “memory makes AI worse.”

1. An agent follows bad experience too

How Memory Management Impacts LLM Agents studied four very different agent systems. The researchers compared frozen memory, storing every new experience, and strict filtering.

The direction was the same for all four: indiscriminately adding everything performed worse than the fixed initial memory; strict selection performed better.

Depending on the agent, the table reports either success rate or accuracy, so these values should not be averaged into one marketing number. Their consistent direction is the important result.

The authors call the behaviour experience-following: when a new task resembles a retrieved memory record, the agent’s output tends to resemble the stored output too. This is useful when the memory is correct and genuinely relevant. When it is wrong or only superficially similar, the agent propagates yesterday’s mistake into tomorrow. The paper identifies two major risks: error propagation and misaligned replay of experience that looked correct.

This paper, incidentally, is not a Microsoft study. It was produced at Harvard University, the University of Georgia, Michigan State University and the University of Minnesota. Microsoft Research produced the second important paper.

2. Memory is not enough—experience must become usable knowledge

Microsoft Research introduced EvoLib in Test-Time Learning with an Evolving Library. Rather than keeping an endless pile of raw trajectories, it derives two types of abstraction:

• reusable procedures, or “skills”;
• reflective insights about mistakes and corrective strategies.

EvoLib consolidates related knowledge and changes its weight over time according to both immediate and future utility. Its authors describe three common failures of continuously rewritten abstract memory:

• misgrouping — different task types are collapsed into one rule;
• interference — repeated rewriting removes applicability conditions and turns narrow advice into an overbroad claim;
• surface overfitting — memory attaches itself to an irrelevant name, colour or phrasing rather than a transferable principle.

EvoLib showed that a structured, evolving library can outperform simple trajectory retrieval on selected mathematical, coding and agentic benchmarks. This is not a universal proof for every project. The authors explicitly assume that the model’s own evaluation provides more useful signal than noise; where verification is as hard as solving the task, they say a powerful external verifier may be necessary.

3. Testing recall is not the same as testing the job

Microsoft’s STATE-Bench adds another practical lesson. A conventional memory test asks whether an agent can retrieve a name or fact from fifty turns ago. That proves the retrieval pipe works, not that the agent works better.

STATE-Bench instead defines 450 stateful tasks in customer support, travel and shopping. It checks whether an agent followed the procedure, changed system state correctly, performed policy checks and avoided a costly mistake. This difference—between “I found the note” and “I did the right thing”—is exactly what we needed to bring into MCP.

What MCP35.4 already did well

MCP35.4 was not a simple chatbot notebook. It already connected local ITHZ project memory with CCG, a system for constitutional governance of agent capabilities.

It had five separated roles: a proposer, a primary opponent, an independent cross-lab opponent, a blind judge and a process auditor. A final case had to be bound to an exact project checkpoint and a manifest of reviewed files. Artifact hashes were recomputed before the models ran. A court decision was advisory evidence, not automatic authority to deploy or change anything.

That solved a large part of the problem:

• project history remained local and append-only rather than silently rewriting the past;
• current decisions, gates and risks could be found without reading the entire archive;
• models challenged one another;
• a high-risk step required a fresh, metered five-role process;
• authorisation could not be inferred from persuasive model text alone.

The blind spot: five voices could read the same bad note

Role isolation does not guarantee evidence independence.

Imagine that an old project event is summarised several times until it becomes “this operation is safe.” If all five roles receive that sentence without its source, scope or counterexamples, they may agree for the same wrong reason. Five model runs are not five independent pieces of evidence.

MCP35.4 could prove that it reviewed exact files. It still needed to prove more precisely how memory influenced each role and whether an important command really produced the output bound into the review manifest.

This is where the research findings met the ITHZ architecture.

MCP36: two memory layers instead of one authoritative shortcut

MCP36 separates what happened from what the system thinks it learned.

An active abstraction must point to a source event or artifact hash. It carries a scope, applicability conditions, validity boundary, provenance and known counterexamples. An unbound inference may remain a candidate, but it cannot quietly present itself as a verified rule.

“Newer” does not automatically mean “truer.” Supersession is accepted only within the same kind, scope and policy class, with a newer validity boundary and an explicit reason. Hard policy cannot receive a learned utility weight, and promoting or superseding it requires a human approval identifier.

Each role receives a different evidence route

MCP36 also stops treating different models as a substitute for different evidence:

• the proposer receives applicable policy, relevant abstractions and sources;
• the primary opponent looks for conflicts, risks and counterevidence;
• for high-risk work, the cross-lab opponent starts from raw evidence rather than the shared synthesis;
• the blind judge receives a provider-free claim/evidence matrix;
• the auditor receives view hashes and a receipt showing which memory influenced which role.

The new version 2 manifest no longer stores only the sentence “the test passed.” It points to the command’s output artifact and recomputes its SHA-256 before model review. A stale or modified receipt stops the process before any model call.

Why MCP36.4 if MCP36 fixed the architecture?

A sound architecture can still be deployed badly. MCP36.4 therefore adds no new form of memory “intelligence.” It adds operational brakes.

The canary is off after installation. It can be enabled only explicitly, for a limited time and a limited number of cases. Every case is a fresh five-role shadow review with capability fixed to analysis.read, an independent cross-lab opponent and complete metering. It issues no execution token, does not mirror its verdict into project memory and cannot widen its authority.

A slot is reserved atomically before work starts. If the process crashes, the slot is treated as consumed or indeterminate rather than silently reused. Expiry, exhaustion, a damaged receipt or the pause kill switch all mean stop.

It is like testing a new driving assistant while it only observes, does not hold the steering keys, may take part in an exact number of drives and has a large physical off switch.

Three ways of working: no memory, Markdown and MCP36

The difference is not how much text an agent stores. What matters is whether the next task receives the currently valid information, its provenance and a clear account of what is still unknown.

What changes in practice

• The agent does not start from zero or need to read the entire archive.
• It knows which decision still applies and which one has been superseded.
• It separates claims from evidence; an unverified record need not become a rule.
• The implementer, auditor and opponent need not share the same convenient shortcut.

Imagine three new colleagues. The first has no memory: capable, but every morning they forget yesterday’s work. The second keeps Markdown notes. That is much better—until there are hundreds of them, two conflict and a critical warning disappears inside an old handoff.

MCP36 works more like project memory with a librarian and an auditor. Before a task, it selects relevant decisions, evidence, risks and rules, then asks of every record: Where did this come from? Is it still valid? Was it superseded? Should this role receive it?

MCP36 therefore does not automatically make the model smarter. It makes its work more consistent, informed and inspectable. It does not guarantee truth, flawless models, the safety of every deployment or automatic authority to act. CCG remains advisory and production authority remains outside the model.

Can an existing project upgrade?

Yes, but an upgrade should be a verification procedure, not a blind overwrite.

A safe path first verifies and byte-for-byte backs up the existing archive. It then installs a new project-local runtime, checks the exact package hash, configuration and MCP protocol, runs project tests, and only then accepts the upgrade. Rollback must restore both archive and configuration to their exact original hashes.

The old archive does not require conversion. MCP35 projections remain readable as legacy_unverified_abstraction; new final cases require a version 2 manifest. Very old or customised installations still need their own trial upgrade and rollback.

Current release status

The public opt-in canary is ITHZ-MCP 0.1.0a14, build public-mcp36.4-core.20260903.1. It is available as the immutable GitHub release v0.1.0a14. The wheel’s SHA-256 is:

84e4d3cda43518d7bfb9452e28363ef41d4b8d61d454928fd57d457615e41f7e

It is a genuinely installable alpha release for controlled project pilots, not a promise of generally stable production operation. The release binds public source, wheel, source archive, manifest, checksums, upgrade guidance and known limitations. It intentionally contains no customer constitution, project-specific profiles, internal checkpoints or confidential data. Native binaries are not part of this portable Python release; a project that needs them must build and verify them separately for its platform.

The biggest change is not a bigger memory

MCP36.4 does not simply remember more. It tries to distinguish an event from a derived lesson, a hard rule, a counterexample and an authority to act.

That is less spectacular than promising an agent that automatically learns from every task. It is closer to what both research and operational practice show: good memory is not a warehouse. It is a system that can answer:

Where did I learn this, when is it valid, what contradicts it—and why am I still allowed to trust it?

That is the question MCP36 and MCP36.4 add to agent working memory.

Original sources

• The video that prompted this investigation: Tohle ti o AI paměti neřekli a proto ti AI nefunguje. Numerical and scientific claims above were checked against the original papers rather than a secondary transcript.
• Zidi Xiong et al.: How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior — ACL 2026; the paper links its code and experimental data.
• Weijia Xu et al., Microsoft Research: Test-Time Learning with an Evolving Library and the EvoLib overview.
• Microsoft: STATE-Bench—an AI-agent memory benchmark and its source repository.
• Public EvoLib source: github.com/microsoft/EvoLib.