The Practical Course: Build Agentic Memory That Keeps Your Loops Alive And Sharpens Them Every Run

Most people build agents like goldfish. Every run starts the same way: the agent gets a goal, gathers context from scratch, reasons forward, takes a few actions and somewhere around tool call thirty, it starts forgetting what it already did. It re-runs a finished step. It contradicts a decision it made at the top of the run. And when the task ends, the entire hard-won trace of what worked and what failed evaporates. Tomorrow the same agent wakes up knowing nothing and walks into the exact same wall it hit yesterday.

That is not an agent. That is a very expensive way to start from zero, forever.

Memory fixes this, and almost nobody sets it up correctly. Most people bolt a vector store onto their agent, dump raw transcripts into it, and wonder why the loop still breaks and still doesn't get any smarter. This is the practical edition of that course — every principle followed immediately by the exact memanto commands that implement it, so you finish with a working memory architecture and not just a mental model. Two goals, in order. First, make your loop work — survive long runs without rotting or blowing your token budget. Second, make your loop sharpen — reuse what it learned so every run starts smarter than the last.

“Within the loop, memory is what makes your agent functional. Across loops, memory is what makes your agent get better. Most people accidentally solve neither, because they never separated the two.

What Agentic Memory Actually Is

Strip away the marketing and agent memory is not one thing. It's four, operating on two different clocks. Getting this taxonomy straight is most of the battle, because almost every memory mistake comes from treating all of it as one undifferentiated bucket.

• Working memory is the live context window — the agent's RAM, the scratch space for the step it's on right now. Fast, small, and where rot happens.
• Episodic memory is specific past events. "Last Tuesday's deploy failed because the migration ran before the feature flag flipped." Individual runs, with their outcomes.
• Semantic memory is distilled, durable facts and preferences. "The payments service requires idempotency keys." "This client hates em-dashes." Timeless truths about your world.
• Procedural memory is learned how-to. "To add an endpoint here: update the router, add the handler, write the test, run the suite — in that order." The runbook the agent earned by doing the task before.

Now the two clocks, because this is the part that reorganizes everything. Within a single run, memory is a survival problem: working memory has a hard ceiling and a long loop fills it with debris. Solve this and the loop completes instead of collapsing at turn 40. Across runs, memory is a compounding problem: episodic, semantic, and procedural memory persist beyond the run and get fed back in. Solve this and the loop improves — each run starts where the last one left off, not at zero.

The mental model that makes every later decision obvious: your context window is RAM, your persistent store is disk. You don't hold your entire hard drive in RAM, and you don't want your agent holding its entire history in the context window. RAM is for what this step needs right now. Everything durable lives on disk and gets paged in on demand.

Map the four types onto Memanto

Memanto is the "disk" in that model, and it doesn't store raw text blobs — every memory is tagged with one of 13 semantic types, which is exactly what lets you retrieve the right kind of memory later instead of everything that vaguely matches. Here is how the textbook taxonomy lands on Memanto's types, including the fifth category nobody stores but everybody needs:

Keep this table next to you for the rest of the course. Every time we "write to memory," the real decision is which type — and the type is what makes retrieval precise later.

The Mistake Almost Everyone Makes

When a long agent loop fails, the reflex is to reach for a bigger, smarter model. It failed at hour two, so the model must not have been capable enough. Upgrade to the frontier tier and try again.

It doesn't work. Swap in the smartest model on earth and the loop usually dies at the same step, because the failure was never intelligence — it was the context. As the loop ran, the window filled with reasoning debris: stale tool output, abandoned branches, superseded decisions. Chroma's "context rot" research shows that as input tokens grow, performance degrades across every major model tested, even on clean controlled tasks. A bigger window doesn't cure this; it just gives you more room to hoard junk before the same cliff.

The rule that produces dramatically better loops is the opposite of the instinct: the lever is memory, not model. When Anthropic added context management to its platform, its internal benchmarks showed that pruning stale content alone lifted multi-step agent performance by 29%, and pairing it with a persistent memory tool reached 39% — same model, different memory discipline. In a 100-turn evaluation, managing context let agents finish runs that would otherwise fail from exhaustion, while cutting token use 84%.

“Precision of memory beats power of model, almost always. Internalize that and the rest of this course is execution.

Step 1: Map The Loop Before You Build Any Memory

You cannot design memory for a loop you haven't characterized. How many steps does a typical run take — five, or five hundred? How many tool calls? Does it stay inside one context window, or spill across many? What state, if lost mid-run, would break it — a plan, a set of IDs, a running total, a list of files already touched? And crucially: does the agent run this once or repeatedly? A one-off research dive and a nightly reconciliation job have completely different memory needs.

Write down, in one paragraph, the shape of the loop and the two or three pieces of state that absolutely must survive. Everything you build next protects exactly those.

Trick: turn the survival state into memories on day one

Once you've named the must-survive state, don't leave it in your head — pin it as memory before the first real run. Create the agent (its agent_id is just a namespace) and store the goal and constraints so every future run and every tool that shares the namespace can see them:

bashmemanto agent create nightly-reconciler
memanto remember "Goal: reconcile the ledger against the payments source every night and flag deltas over $0.01" --type goal
memanto remember "Ledger pulls lag the source by ~5 minutes; always wait before diffing" --type fact --confidence 0.9

Step 2: Draw The Line Between Working Memory And Persistent Memory

This is the highest-leverage decision in the whole build. For every piece of information the loop touches, decide which side of the RAM/disk line it lives on. The default should be aggressive: keep the window small, push almost everything to disk, page it back in just in time.

A simple rule of thumb for what stays in the working window:

• The current subtask and the immediate goal.
• The plan — as a short, always-present summary that must never get truncated.
• Only the last handful of tool results the current step actually needs.

Everything else — full tool outputs, completed subtasks, background facts, prior runs — belongs on disk, retrieved by reference when relevant. Get this wrong toward "too much in the window" and you get rot and a huge bill. Get it wrong toward "too little" and the agent keeps re-fetching things it should have kept.

In Memanto: hold the pointer, page in the payload

Memanto is the disk. Keep lightweight identifiers in the window — file paths, schema locations, stored queries — as artifact memories, and load the heavy content only when a step needs it. The window holds "where," the store holds "what."

bash# Persist the pointer once (cheap to keep referencing)
memanto remember "Main API schema lives at src/schema/index.ts" --type artifact

# Later, page it in by reference only when a step touches the schema
memanto recall "where is the API schema" --type artifact

Step 3: Engineer Within-Run Memory — Keep The Loop Alive

Now protect the single run. There are exactly four operations, and every within-run tactic is one of them. Drew Breunig's framing, which the field has adopted, calls them write, select, compress, isolate:

• Write — persist state outside the window as the loop goes, so a truncated window can't erase the plan or interim results.
• Select — retrieve only what this step needs, when it needs it. Not the whole store. The right three facts.
• Compress — summarize old turns before they rot the window. Completed subtask becomes a one-line outcome; a verbose tool dump becomes a two-sentence result.
• Isolate — hand a noisy sub-task to a sub-agent with its own clean window, and let it return only a distilled summary.

Here is a memory policy you can paste into your agent's system prompt or harness config and adapt:

textMEMORY POLICY (within-run)

WRITE to persistent scratch as you go:
- The goal and the current plan (keep the plan summary always in-window too)
- Every decision made, and the reason for it
- Durable facts discovered: IDs, file paths, config values, constraints
- Any failure and the correction that resolved it

KEEP in the working window (nothing else):
- The active subtask
- The plan summary
- Only the tool results the current step needs

COMPRESS then drop the raw:
- Tool outputs older than the current subtask -> one-line result
- Completed subtasks -> one-line outcome

ISOLATE via a sub-agent (return only a summary):
- Deep searches, large-file reads, noisy exploration

QUARANTINE, never promote to fact:
- Unverified model claims. A hallucination that enters memory poisons
  every future step until removed.

The same four operations, wired to Memanto

The policy above is the intent. These are the commands that make it real — notice how each operation maps cleanly onto one Memanto capability:

• Write → memanto remember "..." --type decision for choices (with the reason), --type artifact for IDs and paths, --type error for a failure and its fix.
• Select → memanto recall "..." --type <type> — the type filter is your surgical instrument; it returns the category that answers the intent, not every semantic match.
• Compress → memanto daily-summary distills a run's session memories into a one-line-per-item summary you can carry forward instead of the raw trace.
• Isolate → let the sub-agent burn tokens, then store only its 1–2K-token conclusion with memanto remember "<distilled finding>" --type learning.

bash# WRITE: capture the decision and the reason, not just the outcome
memanto remember "Chose to re-pull the ledger instead of patching deltas — root pull was stale, not the diff logic" --type decision --confidence 0.9

# SELECT: page in only what this step needs
memanto recall "what did we decide about stale ledger pulls" --type decision

# ISOLATE: a sub-agent explored 40k tokens; keep only the conclusion
memanto remember "Account set X reconciles cleanly once the 5-min lag is respected" --type learning

Do this and you've solved survival: long loops complete, and the token bill drops because the model stops re-reading history it already processed.

Step 4: Add The Handoff — So The Loop Survives Across Context Windows

Your agent works in shifts. Every time the loop spills past a context window, the "agent" that continues is effectively a brand-new worker who clocks in with no memory of the previous shift. Whatever the last shift didn't write down, the new one re-derives — or gets wrong. So the loop only stays coherent if each shift leaves a handoff for the next.

textSESSION HANDOFF
Goal:              <the overall objective>
Done so far:       <completed steps, one line each>
Current state:     <where things stand right now>
Next step:         <the single next action>
Open blockers:     <anything unresolved>
Artifacts written: <paths/IDs of files or records created>
Do NOT redo:       <steps already completed — prevents re-execution>

That last line does a lot of quiet work. "Do NOT redo" is what stops the fresh shift from re-running completed steps — the single most common long-loop failure.

In Memanto: store the baton as a context memory

Write the handoff as a single context memory at the end of each shift, then make retrieving it the first move of the next. Because context is time-sensitive, the newest one is the live baton — and recall/recent or a typed recall pulls it instantly:

bash# End of shift: drop the baton
memanto remember "SESSION HANDOFF | Goal: migrate REST->GraphQL | Done: 60% of endpoints | Next: convert /v1/orders | Do NOT redo: /v1/users, /v1/auth (done, tested)" --type context --source claude_code

# Start of next shift: pick it up before doing anything else
memanto recall "latest session handoff" --type context
memanto recall --recent   # or just grab the freshest state as a snapshot

Step 5: Capture The Right Things — Especially The Failures

Now shift from surviving the run to learning from it, and the precision rule from within-run memory applies harder: signal, not volume. Dumping raw transcripts into a store is the across-run version of stuffing the context window — it buries the useful signal and makes retrieval worse. Persist three things, distilled: episodic (what happened, as event), semantic (durable facts the run revealed, as fact), and procedural (the sequence that worked, as instruction).

And the highest-value capture of all, the one almost everyone skips: failure records. In reinforcement learning a labeled failure is worth more than a generic success, because it's the exact signal that changes future behavior. Your agent's mistakes are the same — but only if you capture them structured enough to reuse:

textFAILURE RECORD
task_type:              <what kind of task>
what_was_attempted:     <the action>
what_went_wrong:        <the observed failure>
root_cause:             <why, once known>
correction_that_worked: <the fix>
reuse_trigger:          "When you see <situation>, do <correction> instead."

In Memanto: failures are the error type, phrased as a trigger

Store the whole record as an error memory, and put the reuse_trigger right in the text so a future recall reads like a guardrail instead of a log entry. Two Memanto tricks make this reliable. First, confidence scoring — score a verified fix high; if you're unsure of the root cause, store it low and let a later run confirm it. Second, quarantine — never write an unverified model claim as a fact; a hallucination that becomes a fact poisons every future step until removed.

bashmemanto remember "When Postgres integration tests fail with 'relation does not exist', run pnpm db:seed before the suite — root cause: the tests assume a migrated schema and CI starts from an empty DB." --type error --confidence 0.95 --source claude_code --provenance explicit_statement

“Delete a failure record and your agent rediscovers the same cliff on schedule. Keep it, phrased as a trigger, and the loop stops making that mistake — permanently.

Step 6: Build The Reuse Loop — Feed Yesterday's Memory Into Today's Run

This is the step that turns memory from a safety net into a flywheel. Capturing memory does nothing if the next run doesn't consult it. So make retrieval the first thing every run does — before it plans. Paste this at the top of your loop:

textBEFORE YOU PLAN, retrieve from persistent memory:
1) Prior runs of this task type — what worked, what failed.
2) Durable facts about this environment (semantic memory).
3) Any failure records whose reuse_trigger matches the current situation.
4) The procedural runbook for this task, if one exists.

Summarize what you're carrying forward in 3-5 bullets. THEN plan.

In Memanto: three calls before the first plan

Wire the four bullets above into three concrete calls. Use recall when you want the raw memories, and answer when you want Memanto to synthesize a grounded briefing across them:

bashmemanto recall "prior runs of the nightly reconciliation: what worked, what failed" --type event
memanto recall "known failures for reconciliation" --type error
memanto answer "Based on memory, what is the fastest known path to reconcile the ledger, and what mistakes should I avoid this run?"

The effect compounds fast. Run one plans from scratch. Run five opens with "last time this failed at the migration step; the fix was to flip the flag first — doing that now," and skips straight past the wall. Fewer steps, fewer tool calls, fewer repeated mistakes, lower cost.

Trick: one memory, every surface

Because an agent_id is just a namespace, the memory a run writes isn't trapped in one tool. Have a CrewAI pipeline scour the web and store findings with crewai-memanto, then point Claude Code, Cursor, or Windsurf at the same namespace with memanto connect and query those exact findings while you code. The research your overnight crew did becomes context your IDE agent plans from — same store, different surface.

“Good long-term memory turns a model into an experienced operator of your specific environment — a seasoned colleague who knows your systems, your conventions, and the mistakes not to repeat. That colleague is built by reuse, one run at a time.

Step 7: Test Your Memory Before You Trust It

Here's the step almost nobody does, and it separates people who think their memory works from people who know it does. After you've wired write and retrieve, don't assume the loop is reading what you think it's reading. Interrogate the memory directly:

textMEMORY CHECK — answer using only persistent memory, and cite the item:
- What is the current goal and plan?
- What did the last run of this task type conclude?
- Name one failure we've recorded for this task and its fix.
- What durable facts about this environment are stored?

If any answer is missing, generic, or wrong, the write or the retrieval
is broken. Fix that before trusting the loop with real work.

In Memanto: make it cite, then verify recency

Run the check with answer (which grounds its response in retrieved memories) and eyeball whether it cites the right items. Then confirm the writes actually landed with recall/recent. If answer hand-waves, something upstream is broken — the write silently failed, retrieval isn't matching, or the store is drowning in noise.

bashmemanto answer "Using only stored memory, what is the current goal, what did the last reconciliation run conclude, and what is one recorded failure and its fix?"
memanto recall --recent   # did the last run actually write what I expected?

Beyond spot checks, this is what standardized memory benchmarks (LoCoMo, LongMemEval, and newer suites) exist to measure — whether a system can actually recall across long histories. Use them as a reference bar, but always run your own eval on your task: published scores tell you the retrieval engine works, not that it helps your loop.

Step 8: Measure The Compounding, And Maintain It

Memory is not set-and-forget. A store full of stale or poisoned facts produces confidently wrong context, which is worse than no context at all. Two disciplines keep it valuable.

Measure whether it's actually compounding. Track something concrete across runs: steps-to-completion, tool calls per run, repeat-failure rate, cost per run. If run twenty isn't measurably leaner than run one, your capture or your reuse is broken. Compounding you can't see is compounding you probably don't have.

Maintain the store. Give it a forgetting policy — episodic detail can decay while semantic facts and procedural runbooks persist. Prune contradictions. Quarantine and remove anything that turned out to be a hallucination. When the environment changes, update the semantic facts, or the agent will faithfully act on a truth that's no longer true.

In Memanto: schedule the hygiene, resolve the clashes

Memanto turns maintenance into commands. daily-summary distills each day and flags contradictions between new and historical memories; conflicts walks you through resolving each one explicitly (keep old, keep new, merge, or replace) so provenance is never silently destroyed; and schedule enable automates the whole detection pipeline so contradictions surface instead of accumulating. For point-in-time truth, temporal recall lets you ask what the agent believed at a past moment without today's edits contaminating the answer.

bashmemanto daily-summary            # distill the day + generate a conflict report
memanto conflicts                # resolve contradictions explicitly, one at a time
memanto schedule enable          # automate detection so clashes never pile up
memanto recall "what database did we use" --as-of 2026-06-01   # point-in-time truth

Loop Archetypes You Can Build Today

Theory gets real when it's concrete. Here are four common loops with the RAM/disk split spelled out — working memory holds the live, decision-relevant minimum; persistent memory (Memanto) holds distilled outcomes, durable facts, runbooks, and failures.

Notice the pattern across all four. Getting the right thing into the right layer is most of what makes a loop both survive and sharpen. Put raw volume in either layer and you get rot in one and noise in the other.

The Advanced Layer: The Reuse Flywheel

Everything above stacks into one compounding system. Within a run, your memory discipline keeps the loop coherent and cheap — survival. Across runs, capture-and-reuse turns every completed run into fuel for the next — compounding. Wire both and you get a flywheel: the loop runs, the run produces distilled episodic, semantic, procedural, and failure memory, that memory feeds the next run's plan, the next run is faster and more accurate, and it produces even better memory. Round and round, each turn tightening.

That accumulated memory is the one part of your agent no base model ships with and no competitor can download. It's specific to your work — your domain's edge cases, your conventions, your corrections — which makes it higher signal for your loop than any public corpus. It's your fingerprint, and arguably your most durable IP.

Which is why where the memory lives is the decision that outlasts all the others. If your loop's memory sits in infrastructure you don't control, then the component that determines whether your loop works and the asset that makes it compound both belong to someone else. If that's a constraint for you — regulated data, air-gapped networks, or simply not wanting your fingerprint on someone else's servers — Memanto runs fully on your own hardware with one command (memanto config backend on-prem): same CLI, same 13 types, same retrieval engine, nothing leaving your environment.

Your Week-One Checklist

Most people never get this working — not because it's hard, but because they bolt on a vector store in ninety seconds and skip the parts that matter: the RAM/disk line, the within-run policy, the handoff artifact, the structured failure capture, the reuse-at-plan-time, and the test that proves any of it works. Pick the agent you run most, and do exactly this in one afternoon:

bash# 1. Create the namespace and pin the survival state (Step 1-2)
memanto agent create my-loop
memanto remember "<the goal>" --type goal
memanto remember "<a durable environment fact>" --type fact --confidence 0.9

# 2. During the run, write decisions/failures as you go (Step 3, 5)
memanto remember "<decision + reason>" --type decision
memanto remember "When <situation>, do <fix> instead — root cause: <why>" --type error --confidence 0.95

# 3. Before the NEXT run plans, retrieve first (Step 6)
memanto answer "Based on memory, what worked before and what should I avoid this run?"

# 4. Prove it and keep it clean (Step 7-8)
memanto recall --recent
memanto daily-summary && memanto conflicts

Do those, and your agent stops being a goldfish that starts from zero every run and becomes a system that keeps what it learns and gets sharper every time it runs. Draw the RAM/disk line, write the memory policy and the handoff, capture failures as triggers, retrieve before you plan — then watch how different, and how much cheaper, the next ten runs feel.