An agent can remember your name and still repeat yesterday's mistake. Memory stores state; continual learning changes what the system does because of experience. The first decision is what deserves to be stored and how that state should be organized inside the agent loop. Context, retrieval and weight updates offer different ways to change the next run, and none replaces the others. Evidence matters more than the mechanism: did the agent learn, did the result improve, and did old behavior survive? Outcomes can update retrieval, while failures can expose missing knowledge. The harder cases are learning when production cannot be replayed and adapting to a programmer's changing taste through the edits they make.
Why first: Packer starts at the smallest useful definition: an agent becomes stateful when it updates state inside its loop. His split between always-visible core memory and searchable external memory gives Alake a concrete system to generalize into a full memory lifecycle.
Why second: Packer shows one working arrangement; Alake supplies the design vocabulary around it. Generation, storage, retrieval, updating and forgetting explain how persona, tool, conversation and workflow memories differ. Chalef then asks the question this taxonomy leaves open: which facts belong in the system at all?
Why here: Alake separates memory by purpose; Chalef makes those boundaries part of the application's data model. His dog named Melody is the memorable failure case: similarity retrieves a musical word, while the business task needs a media preference. Morris widens that retrieval problem into a comparison with context and weights.
Why here: Chalef fixes retrieval by giving memory domain structure. Morris asks whether frequently reused knowledge should be retrieved at all. He compares context, RAG and weight updates, but does not declare a winner: future systems will mix them. That open question leads to Srivastava, who offers a working rule for choosing between them.
Why here: Morris compares context, RAG and weight updates without naming a winner. Srivastava gives a rule based on how fast information changes: small, stable behavior goes in the prompt, current or citable knowledge goes in memory, and only stable reflexes go into weights. His support assistant shows the cost of getting it wrong: after a fine-tune on old tickets, it kept inventing product names from a replaced catalog. Asawa then asks how we would know whether the resulting system learns.
Why here: Srivastava says where new knowledge should live; Asawa supplies a test for whether any of those places improve with experience. His gain metric compares a stateful run with the same system reset between tasks. Once learning is measurable, Broekhuizen can show how a lesson from a trace gets written back for the next run.
Why here: Asawa measures whether a system improves. Broekhuizen shows the read-write cycle that lets it: load context, run, capture the trace, filter it, and write only the useful signal back as durable context. Most traces should stay history, caching can hide an update from a long-running agent, and changes to procedural rules need human review. Pankaj then decides which stored memories deserve retrieval.
Why here: Broekhuizen decides what gets written to memory. Pankaj decides what gets retrieved in a running agent: memories rank partly by whether they helped or hurt earlier outcomes. That makes feedback change a later tool trajectory. Navakoti takes the same idea outside the agent and uses failed work to change the knowledge base itself.
Why here: Pankaj learns which existing memories are useful. Navakoti deals with the harder case where the needed knowledge was never written down. Real incidents expose the missing context, and old work items turn that discovery into an audit. Feizi picks up those same failures and asks how to make each one executable and safe to learn from.
Why here: Navakoti turns failure into better documentation. Feizi turns it into a replayable environment, then routes the smallest durable repair to memory, harness or model and checks old cases for regressions. Denton follows with the awkward production case Feizi's method cannot assume: traces that cannot be replayed and have no golden answer.
Why here: Feizi wants an executable test before changing the agent. Denton shows how learning can begin when an enterprise only has a dump of traces, then move toward online updates as serving and training converge. His rollout-specific hints lead naturally to Awais, whose feedback signal is the programmer's own edit to generated code.
Why last: Denton adapts a model from production traces; Awais brings the loop down to one person's daily work. His coding agent watches edits, records preferences and updates them when the programmer changes practice. It belongs last because it turns the pack's abstract goal, learning without forgetting, into something a user can notice in the next pull request.