Agent Memory Is Two Systems, Not One Dial With Scratch On One End

Part 7 of the Harness Engineering series on dev.to defines the Memory Layer as state that persists beyond a single model call, then immediately splits it into two systems rather than one ^[1][2]. The split matters operationally because the failure where an agent loses its own reasoning mid-task and the failure where it greets a returning user as a stranger are different failures with different budgets ^[3][4].

Short-term memory, in the author's framing, is state within a task: the conversation history so far, intermediate scratchpads, results from tool calls already made, and files read or written during the session ^[5]. Its job is keeping the agent coherent from one iteration of the control loop to the next ^[6]. The diagnostic question is "what did we just try?" ^[7]

Long-term memory is state across tasks: facts about the user, conventions in the codebase, the agent's own past behavior, patterns learned last week that still apply this week ^[8]. Its diagnostic question is "what did we decide last time?" ^[9] The series argues the two flavors have different lifecycles, different budgets, and different designs, and that a single memory system attempting both usually does neither well ^[10].

The mid-task failure is the one most teams misdiagnose. When the context window fills or the token budget runs out, earlier turns get truncated away and the agent's earlier reasoning is simply gone ^[3]. That is not a recall problem across sessions; it is the scratchpad being evicted under pressure. A memory system designed around durable user and project facts will not save the loop when truncation starts, because the thing being lost is exactly the material a profile store was never meant to hold ^[5][10].

Underneath both is a point the series restates rather than discovers: the model remembers nothing, so without an explicit memory layer every interaction starts cold ^[11]. Anything that looks like an agent learning over time is harness work, not model work ^[12]. The article puts it flatly: there is no "the model remembers," there is only "the harness put the right stuff back in the context" ^[13]. That framing is useful because it moves the conversation from capability to plumbing. Continuity is something you build, log, and pay for in tokens.

The article names three design decisions that it says separate a real memory system from a naive one: flavor, write triggers, and bounded retrieval ^[14]. The excerpt available here cuts off before the elaboration, so treat those as headings rather than a specification. Readers should also note that the author sells a paid Udemy course and a live Maven workshop alongside the series, described as optional ^[15].

What to watch: the remaining installments are Observability, The Harness Architecture, and Decomposing Claude Code, three of ten ^[16][17]. The test for Part 7's argument is whether write triggers and bounded retrieval arrive as concrete mechanics, since those are where the two systems either stay separate or quietly collapse back into one store with a similarity search bolted on. Write triggers determine what earns a place in long-term memory; bounded retrieval determines how much of it comes back before it crowds out the working set ^[14].