Giving AI Agents Memory That Learns — Jake Broekhuizen, LangChain
Jake Broekhuizen of LangChain Labs argues that observability alone does not make agents improve. Using a financial services agent whose tone drifted from advisory to pushy, he shows how traces only become useful memory when a filtered lesson is written back as durable context the agent reads on its next run. The talk covers semantic, episodic, and procedural memory, the working versus long-term memory distinction, the read-write cycle, and how LangSmith and Context Hub support capture, analysis, and updates, along with lessons about keeping only signal, caching, and human review of procedural changes.
Jake Broekhuizen from LangChain’s Labs team opens with a tension most agent builders will recognize: teams have become very good at watching what their agents do, but much worse at turning those observations into anything the next run actually uses. Traces, logs, and transcripts are evidence. His core claim is that they only become memory when a lesson is converted into durable context that the agent reads on future runs.
A running example: a finance agent whose tone slips
He anchors the talk in a real project with a financial services company building an agent for budgeting, spending, and non-investment advice. In a regulated sector, tone is part of compliance. The agent derives its tone from its context, its memories, and its references to rules and policies. In some interactions it drifted from advisory to directive, with responses like “users in your similar situation would generally set a cap” and suggestions to cancel subscriptions and move money into savings. The company judged these as tone violations. Fixing them was a manual loop: someone reads traces, finds where the tone slipped, edits the context, and checks for regressions. Jake points out that this does not scale, and that closing this gap is exactly what a memory system should do.
Observing is not learning
Observability gives teams a lot: tool calls, the reasoning path, retrieved artifacts, sub-agent calls. But if the context the agent reads never changes, a misguided instruction keeps producing the same mistake on every run. Jake frames the goal as moving from agents that are observable, meaning they tell you what happened, to agents that are adaptive, meaning they can change and guide themselves on later runs.
Three kinds of memory
He borrows a taxonomy from cognitive science and applies it to language-based agents:
- Semantic memory: what the agent knows, such as facts and preferences that shape its responses.
- Episodic memory: what it has experienced, such as learned patterns, past interactions, and examples.
- Procedural memory: how it should behave, such as instructions, skills, and rules.
He is emphatic that procedural memory is where most visible behavior change comes from. The tone fix in the finance agent was not a new fact or a banned word. It was a new rule for how to engage users. He estimates that procedural memory drives roughly 75 percent of an agent’s behavior, which makes it the most consequential layer to get right.
Working memory versus long-term memory
Working memory is what the agent holds during the current run: scratch pads, tool results, retrieved files, and anything else needed for the current job. Long-term memory lives in a store somewhere else and gets injected back into runs in different ways depending on the harness. Some frameworks place it directly in the prompt, some expose it through retrieval tools, some pull from a store, some load files, and some modify runtime state. The implementation varies, but the distinction matters. A trace, then, is not just a record of the final output. It is a record of how working memory changed over the course of the run. Part of that should remain as history, and part should become durable long-term context.
The read-write cycle
Jake describes a loop with four stages. At the start of a run, the agent reads relevant context from long-term memory into working memory; progressive disclosure of skills is one example of this. The run then produces a trace, which is evidence of how context was retrieved, which tools and sub-agents were called, and what decisions were made. Next, the evidence is filtered for signal, which is the hardest and most interesting step. Finally, the signal is written back into durable context. He connects this to ideas like sleep-time compute and dreaming, where memory is updated while the agent works or even while it is idle. The result is a flywheel: memory informs the run, the run creates evidence, filtering produces signal, and signal updates memory. He condenses the whole loop into three verbs: capture what happened, analyze what might matter, and update the context so future runs can use it.
LangSmith and Context Hub in practice
Jake is careful to say this is one implementation, not the only one. Capture relies on LangSmith’s observability, which shows the trajectory, tool calls, sub-agent calls, and the context that was retrieved. The analysis step is a background process that extracts signal from traces according to what matters to the team and promotes that signal toward memory. Context Hub is the remote store where updated context lives, so the agent can pull the latest version the next time it runs.
Applied to the finance agent, the loop works like this. On startup, the agent loads its instructions, skills, markdown files, policies, and rules from Context Hub. A run produces a trace that flags where its tone strayed from what the team wanted. The analysis identifies which static skill files need to change and updates them. On the next run, the agent’s tone is measured and no longer pointed or directive.
Three lessons
Jake closes the technical section with three hard-won lessons.
-
Most traces should stay history. Raw exhaust is not a memory update. Some traces may feed offline evaluation datasets, and only a small subset should change what the agent remembers. Deciding what matters is the central design problem.
-
Watch caching and the hot path. For long-running background agents, a memory update written early in a run may not reach the agent on later runs because of runtime state or the way memory is accessed. He spent a long time puzzled by why his agent’s behavior was not changing before recognizing this. Designs have to balance optimization against guaranteeing that updates are actually visible to future runs.
-
Put humans in the loop for procedural changes. Self-updating agents are appealing, but since procedural memory governs much of behavior, changes to instructions, policies, and tone guidelines should be surfaced for review before they enter the hot-reload path. Letting lower-stakes memory update automatically is reasonable, while high-impact behavior needs explicit review.
Takeaway
Jake returns to his opening refrain: the next run should be better, and memory is what makes that possible. Memory is more than a storage layer. It is how experience becomes context, and context is how future runs get the chance to improve. He points to a video linked from the talk’s QR code that walks through how he built an agent doing exactly this.