I want coding agents to remember things. Starting every task from zero gets old fast.
I also want to open the drawer and see what they wrote.
A coding agent that remembers everything sounds like a coworker who writes down every sentence and never lets anyone edit the notebook. Eventually one of those notes will be wrong. It will still arrive in the next prompt sounding like a rule.
A context window is not team memory
Long context helps an agent stay with a task. It can hold the files it opened and the conversation that got it there.
Then the task ends.
Anthropic's guide to context engineering makes the limitation plain: context is finite, and adding more can make a model less focused. Their practical answer includes compaction and structured notes stored outside the context window.
The transcript tells you what happened. Memory is where somebody decided, often imperfectly, what should matter next time.
If an agent keeps the whole transcript, the useful line about an old database workaround sits beside two thousand lines of package output. If it compresses too aggressively, the workaround disappears and the next run "cleans it up."
More tokens do not make that choice for us.
Private memory creates private rules
A coding agent can keep notes in a file on one person's machine. That helps the next session on that machine. It does little for somebody starting work from the project room, or for the engineer reviewing a change three weeks later.
Worse, nobody else can see what the agent decided was true.
Maybe it saved "never touch the checkout flow" after one failed attempt. Maybe the team replaced that flow last Tuesday. The note still sounds authoritative because it arrives inside the next prompt, before anybody gets a chance to question it.
Cloudflare's Agent Memory describes a shared profile where knowledge learned by one person's coding agent can help the rest of the team. I like that direction. Memory gets more useful when it stops belonging to one session.
What I care about is the disagreement. If a note belongs to the team, somebody can correct it before it hardens into another agent's rule.
What we keep in hilos
In hilos, the conversation stays searchable. Docs hold decisions that deserve a proper document, and Tasks hold work the team agreed to do. Learned memory is smaller: a convention, a setup fix, or a review lesson that should change a future run.
An agent can save a memory through MCP. A person can add one from the Memory page. Notes can belong to one project room or to the whole workspace, and project notes are considered first when an agent starts work there.
The prompt receives a bounded slice, not the whole cabinet. Otherwise "memory" becomes another way to fill the context window with old stuff.
We capture one kind of lesson without asking the model to summarize it. When a person rejects an agent's report or requests changes with a note, that note becomes project memory. An approval does not. "Looks good" is not a durable engineering convention. "Do not replace this token with a hex value" might be.
The reviewer wrote the lesson, so the reviewer remains its author.
We tried approval first
There is an uncomfortable part here. Agent-written memory can be wrong. It can also carry bad instructions from a webpage, issue, or pull request into a future run.
Our first response was to put every agent memory into a review queue. A person had to approve each note before any agent could use it.
We built that version. It solved the problem on paper and created a strange one in the product. The agent would say it remembered something, then act as if it had forgotten because nobody had visited the Memory page yet.
So we backed it out. A new memory is active immediately. People can edit or hide it, and delete it when it should be gone. Once a person corrects an agent-written note, the agent cannot silently overwrite that correction later.
I still do not know if this is the final answer. Pre-approval turns memory into paperwork. Correction after the fact means a bad note may influence one run before somebody catches it.
For now, I would rather make memory visible and correctable. I do not believe a review queue full of tiny notes will be carefully tended forever.
Keep the conversation nearby
The old conversation still matters.
An agent can search old messages and Docs when it needs the exact decision or the sentence around it. Memory is the short note that tells the agent where to look and why. It should never become a cleaner-looking replacement for the team's actual conversation.
This is the same split we use for agent reports. The room gets a short answer, while the complete trace waits nearby for whoever needs to inspect it.
A memory entry is also a compression. It needs a path back to people who can notice that the compression dropped the important part.
Forgetting is part of the design
Most of a workday should disappear from an agent's memory. The failed command, the first draft of a plan, the temporary workaround that lasted an afternoon... keeping all of it would make the next task worse.
The useful pieces are usually boring. This repo deploys from main. The product calls these "spaces," not "workspaces." Check with the design lead before changing the billing page. Those notes save the next person or agent from learning the same thing the expensive way.
And when the note stops being true, the team should be able to cross it out.
I do not want agent memory to feel magical. A slightly messy project notebook left open in the room is enough. Somebody fixes an old rule and writes why.
Most days, the agent should forget. When it keeps the wrong thing, somebody should be able to say, "Nope. We stopped doing that two months ago."