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 uncertainty makes Asawa's next question necessary. How would we know which system actually learns?
Why here: Morris offers several places to put new knowledge; Asawa supplies a test for whether any of them improve with experience. His gain metric compares a stateful run with the same system reset between tasks. Once learning is measurable, Pankaj can use the outcome as a retrieval signal rather than leaving it in a dashboard.
Why here: Asawa separates initial capability from improvement. Pankaj closes the loop 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.