How do you make your agent aware of the past?

TL;DR

Agent memory can live in three places: the model’s weights, a trained module, or a store the agent queries. Weights suit behavior repeated across many tasks. A store suits facts that expire, belong to one customer or need correcting. AmpUp Enterprise Brain starts with the store and provides a path to train adapters when the evidence shows it would help.

A test for agent memory: the pricing exception

Suppose you correct a support agent: this customer has a one-time pricing exception, approved for the current renewal. In the next conversation, you want it to remember the exception. You also want it to know when the exception expires and keep it out of other customers’ conversations.

That’s a useful test for enterprise “continuous learning.” A user wants to stop repeating corrections. A builder has to decide who can use that correction and how to change it later.

There are three places to put that experience: in the model’s weights, in a trained module loaded with the model, or in a store the agent can query. The choice affects how quickly the agent can learn and how much control you retain over what it learned.

	Model weights (fine-tuning and RL)	Smaller module (LoRA adapter or Cartridge)	Event store (history the agent queries)
Best for	Behavior repeated across many tasks, like a support workflow	Specialized behavior or documentation, versioned and swapped	Facts that change, expire or belong to one customer
Changing one fact	Deleting the example doesn’t undo the training	Still harder than removing a database record	Correct or expire the record, no retraining
Permissions	A document’s access rules don’t follow it into the model	Restrict the whole module to people allowed its material	Each record keeps its source permissions and evidence
What can go wrong	Rewarding the wrong outcome, like closing unsolved tickets	Combined modules can conflict, so test each mix	Retrieval picks the wrong record, or the agent ignores it

1. Teach the model through its weights

Post-training changes how a model responds by updating its parameters. You can fine-tune it on examples of good behavior, then use reinforcement learning to reward successful outcomes. The InstructGPT research shows a well-known version of that process using demonstrations and human feedback.

For an enterprise, this starts with a model you can train, either through a provider or in infrastructure you control. Gather approved examples from real tasks, have experts check them, and define what a successful result looks like. Train on part of the data and test on separate cases before releasing the new version.

The difficult part is deciding what to reward. If a support agent gets credit for closing tickets, it may learn to close them before the customer’s problem is solved. The training process needs a way to tell those outcomes apart.

This approach fits behavior you want the agent to repeat across many tasks, such as following a support workflow. A temporary pricing exception needs a way to expire and should apply only to that customer.

Once information has influenced a model’s weights, those controls become harder to implement. Deleting the training example doesn’t undo the training. A document’s access permissions don’t automatically follow its contents into the model. Models can also reproduce memorized training examples, as training-data extraction research has demonstrated.

Enterprises can train responsibly, with restricted datasets and controlled deployments. They still need a process for handling changed policies and information that should no longer influence the model.

2. Train a smaller module: LoRA or a Cartridge

LoRA keeps the base model frozen and learns small updates to selected weight matrices. You can maintain specialized adapters without training and storing a separate full model for each task (LoRA paper).

Cartridges learn a compact representation of context in a key-value cache. That cache is loaded alongside a query while the base model stays frozen. A Cartridge might represent a body of product documentation that the agent needs repeatedly.

Their composability is promising. The Cartridges research demonstrated that independently trained Cartridges could be combined at inference time without retraining. That suggests a useful pattern: train modules separately, then load the combination a task needs.

LoRA also has ways to combine adapters. Its merging tools address conflicts between learned updates. Cartridges offer another way to compose learned context, with results that still need testing on your own tasks.

These categories overlap. RL describes how you train; LoRA describes which parameters you train. You can use RL to train a LoRA adapter.

Smaller modules are easier to version and replace. The security problem remains: a module trained on confidential material must be restricted to people allowed to use that material. Removing one fact from it is still harder than removing a record from a database. Every combination you deploy also needs testing for conflicting behavior.

3. Keep experience in a store the agent can query

An event store keeps a record of what happened. When the next task arrives, the agent retrieves the relevant history and uses it as context.

The pricing exception can remain a record with an approver and an expiration date. The next agent can look it up for that customer. When the exception expires, the retrieval layer can stop presenting it as current. You can make that change without retraining a model.

The store fills in two ways. In-band capture records relevant interactions and corrections during a task, along with the outcome when it becomes available. Dreaming is background processing between tasks. It revisits accumulated history to reconcile updates and produce summaries or candidate lessons for future use.

A useful summary should retain a link to its evidence and respect the source permissions. Otherwise, a background job could accidentally turn a private conversation into a lesson everyone can read. Stored documents can also contain malicious instructions; retrieving them must never grant those instructions authority.

There is a failure mode here too: the store can contain the right correction and the agent can still miss it. Retrieval may select the wrong record, or the agent may ignore what it receives. A meaningful test is whether the agent handles the next relevant case correctly. A successful memory write only tells you the record was saved.

This is also where skill management belongs. In this operating model, people manage and approve skills, and administrators install plugins. A background process can suggest a better procedure; an authorized person decides whether to adopt it. Plugin installation controls which tools the agent can reach.

That review takes effort. Someone has to own the skills and remove outdated instructions. It gives the enterprise an explicit decision point before a lesson changes how agents act.

Start with an event store, then train adapters

AmpUp Enterprise Brain starts with a fast event store, then provides a path to train adapters. That order lets agents use new information as it arrives, while the enterprise keeps a record it can inspect and correct.

Enterprise Brain supports source-based access controls and erasure, with administrative auditing and deployment inside the customer’s own cloud account. Facts remain tied to their evidence. Teams can decide which experiences are useful enough, and permitted, to become training data.

The same history can serve different purposes. A customer’s temporary exception stays available through retrieval. Examples that repeatedly demonstrate a useful behavior can become a dataset for an enterprise-owned adapter. Permission to read a record and permission to train on it need separate decisions.

This gives training a better starting point: examples with context about what happened and whether the outcome was good. Before deploying an adapter, you can compare it with the existing agent on cases it hasn’t trained on. The event store remains useful after training because new facts keep arriving.

Apache Arrow provides a common format for processing structured data and moving it between compatible tools. Hugging Face Datasets uses Arrow for its local cache, including access to datasets larger than available RAM.

For builders, the benefit is less data conversion between inspecting past interactions and preparing approved examples for training. Arrow helps move and process the data; the surrounding system has to enforce who may use it and for what purpose.

We think this is the best starting point for enterprises whose agents need to use changing, permissioned information. It puts access checks and correction into the data layer, where individual records can be addressed. It also leaves room to train adapters when the evidence shows that training would help.

That makes the compliance case specific. It depends on controls that are configured and tested, including what happens to summaries and exported datasets when their sources are deleted. An event store gives an enterprise a practical place to enforce those rules.

The test comes back to the next customer conversation. The agent should use the approved exception while it applies and stop relying on it when it expires. When someone questions the decision, it should be able to show where the exception came from.

More on agent memory from AmpUp

• AmpUp Enterprise Brain, our memory for agents
• Who Owns Your Company’s Memory?
• Training a Small Model on Your Agents’ Advice
• GPT-6 Astra just went into a model’s weights, found its self-doubt, and fixed it
• τ²-bench Banking: Policies Learned From Practice
• LongMemEval: Remembering Users, Reading Less