Your Agent’s Memory Needs a Promotion Policy

An agent that forgets every run will make you explain the same thing again and again. An agent that remembers the wrong lesson can make you explain it to every run that follows.

That is the tension I keep coming back to with AI agent memory, particularly with shared/distributed agents. Remembering more is not the same as making better decisions. A workaround can survive long after the condition that made it useful, especially when it arrives in the next session looking like established guidance.

In Your AI Agents Should Change When They Frustrate You, I wrote about letting an agent propose changes to its instructions, with a human reviewing and versioning the result. But repeated work introduces another important question. What should happen between one run noticing something and other runs being expected to act on it?

Just as with us human engineers, experience is evidence, not authority.

I’ve been exploring that distinction in repeated AI engineering work. This article explores how I’ve been thinking about governing the learning path. The useful part is deciding what a memory is allowed to become.

The missing step between remembering and reusing

An agentic session can tell you that something happened. It cannot, by itself, tell you how widely the explanation applies.

Perhaps a migration succeeded after an agent changed a build setting. Was that setting the cause? Did another change matter? Does the same reasoning hold for a repository with a different dependency or toolchain?

If the next agent retrieves “change this setting” without those questions, a provisional explanation has become a recommendation. Put it in a shared instruction file and the recommendation can become an expectation. While the instructions may seem to barely change, the authority has.

This is not a new argument for giving agents experience. There is plenty of established work on using experience to influence later tasks, including Agent Workflow Memory which explores extracting reusable workflows from past experience.

The question I’m interested in is narrower. For consequential engineering work, what earns the right to influence a different run?

Give each kind of memory a different job

I find the Bronze, Silver and Gold vocabulary from medallion data architecture useful here. While the names are borrowed, the important part is the separation of responsibilities. What may each layer contain, and who should use it?

Layer	Its job	How it influences later work
Bronze: run evidence	A sanitized account of what happened, what differed from expectations and which evidence supports it	Input to consolidation, not the executor’s learned recall
Silver: conditional guidance	Reviewed guidance with an applicability boundary, supporting evidence and reasons to reconsider it	Retrieved when its conditions match the current task
Gold: governing agent instructions	Stable workflows, responsibilities and safety or approval boundaries	Followed by execution agents regardless of which learned guidance they retrieve

In this design, the execution agent produces the run record. A coordinator consolidates records and proposes Silver changes; a human approves the guidance. The store could be versioned files or another governed shared system. Moving an observation into that store is not promotion.

Bronze is where I want the observation to stay honest. “The package loaded in this run was different from the package we expected” is useful. “Always replace that package” is already a different claim.

It should be a short, sanitized record, not a transcript dump. References to controlled evidence can preserve the agent’s reasoning without copying raw logs, secrets or personal information into a shared corpus. Unlike raw Bronze storage in a data lake, this layer is not permission to retain everything.

Silver does the harder work. It turns an observation into guidance that says when it applies. A useful entry needs the source assumptions and versions that matter, counterexamples, and what would invalidate it. The aim is not to preserve every lesson. It is to preserve advice another run can challenge.

Gold remains the workflow’s governing instructions within the agents and their skills. A migration agent still follows its build, verification and approval rules. “Silver-only recall” means that Silver is the only learned memory corpus supplied to execution agents. It does not mean they stop reading or following Gold.

That restriction is a choice for this kind of repeated work, not an argument that all episodic recall is wrong. An agent helping someone recover a conversation has a different job from an agent proposing changes in a new context.

A lesson should arrive with its conditions

Here is an invented package-migration example. An agent is moving a small application from Windows to cross-platform. The code compiles, but a runtime check fails when it loads a native dependency.

Investigation shows that the resolved package contains a Windows native library. A compatible package version is available. After updating the reference and checking the resolved contents, the application runs in the target environment.

The Bronze observation is specific. This application resolved a package without the required native asset, and changing that package version addressed the observed load failure. The record identifies the versions and checks used to reach that conclusion. It does not say that every load failure has the same cause.

Now imagine consolidation finding similar failures in genuinely different applications or migration scenarios. One has a direct package reference. Another receives it transitively. A third has the right package but fails for a different reason, its startup configuration selects the wrong library.

That third case is useful evidence, not something to discard because it spoils the pattern.

The proposed Silver guidance might read:

When an architecture migration compiles but fails to load a native dependency, inspect the exact resolved package and the asset selected at runtime before changing build settings. If the package lacks a compatible asset, investigate a compatible version. If the asset is present, this observation does not establish the cause.

That is more useful than “upgrade the package”. It gives the next agent a diagnostic question and a stopping boundary, not an answer to apply everywhere.

A human reviewer can inspect the supporting cases and challenge the proposed scope. A reviewed approval, for example a pull request, adopts the guidance into the versioned corpus. Later runs retrieve it only when the problem fits, then verify their own package and runtime evidence.

But it shouldn’t end at adoption. Suppose a later toolchain changes how runtime assets are selected. The advice may still be partly useful, but its documented selection assumptions no longer hold. I would mark the entry unavailable for learned recall until those assumptions are rechecked, then correct or retire it through review. Keep its history and invalidate guidance derived from the same obsolete assumption.

Promotion needs breadth

Ten runs repeating one workaround are not necessarily ten pieces of evidence for a Silver promotion. They may share the same source repository, copied configuration or mistaken explanation. Different agent invocations do not make correlated observations independent.

Recurrence is useful because it suggests a problem deserves attention. Diversity is useful because it challenges the explanation. Counterexamples help establish where the guidance stops. I would look for variation that matters to the claim. The point is not to collect a decorative number of examples, but to test the proposed boundary.

Gold changes need a different argument again. A conditional workaround is not a reason to rewrite a core agentic workflow. I want evidence that the governing assumption is wrong across the scope where that instruction applies, with scrutiny proportionate to the consequences. A reproducible core defect can justify a correction without waiting for many examples of similar incidents.

There is no universal count that makes that decision safe. The same agent that performed the work can propose the improvement. That does not give the proposal authority to approve itself, and it must not let the correction path weaken its own approval rules or capability restrictions. Changes to those safeguards need separately authorized review outside routine self-editing.

Better memory still has to earn its cost

Even correctly scoped guidance can help one kind of work and distract another.

Before claiming a learning pipeline helps, I would compare it with a frozen, reviewed runbook on unseen related tasks and unrelated controls. I’d keep model, tools and source versions comparable, check real outputs, and count consolidation and human-review time alongside execution cost. Those comparisons remain evidence for you to obtain.

There is a practical cost even before evaluation. Someone has to consolidate observations, review proposals, maintain applicability and revisit invalidated assumptions. Retrieval uses context. A growing corpus creates more opportunities for contradictory advice. Bronze can accumulate while nobody has time to turn it into useful guidance.

If the workload is small, the tasks are mostly unique, or one person can maintain the relevant advice directly, that may give you the useful part without building a learning pipeline. I would add the machinery when repeated work and meaningful variation justify the curation burden, not because an agent can generate reflections cheaply.

The change I’d make first is simpler. Whenever an agent offers a lesson, ask what authority it has. An observation can justify an investigation. Reviewed conditional guidance can help another run decide what to check. A governing instruction needs a stronger case and the right approval.

Your agent does not need to turn every experience into a rule. It needs a clear path for deciding which experiences deserve to become one, and a way to withdraw them when the evidence changes.