Notes on
engineering memory

Why coding agents forget, what teams have tried instead, and what a memory would have to do to be worth trusting.

RSS
  1. Agent memory5 min read

    Why coding agents forget what your team already knows

    A coding agent's context window is working memory, not storage. Here is what gets lost when a session ends, and why a larger window does not fix it.

  2. Agent instructions5 min read

    What CLAUDE.md and AGENTS.md can hold, and what they cannot

    Instruction files are good at conventions and bad at findings. A practical boundary for what belongs in an agent instruction file, and what needs somewhere else to live.

  3. Agent instructions5 min read

    Context rot: when agent instructions stop matching the code

    Written guidance stays still while the code moves, so the instruction is still obeyed and now wrong. Why stale context costs more than none, and what can arbitrate.

  4. Engineering practice6 min read

    The cost of investigating the same thing twice

    Repeated investigation is invisible on every dashboard, because each instance looks like ordinary work. What it costs, and where to look for it.

  5. Agent memory5 min read

    Agent memory is not retrieval over your codebase

    Indexing a repository and calling it memory confuses two jobs. Retrieval finds what the code says. Memory holds what the team concluded about it.

  6. Agent memory5 min read

    Agent memory belongs to the team, not to the developer

    Per developer memory files reproduce the problem they were meant to solve. The knowledge worth keeping is about the seams between repositories a team owns together.

  7. Engineering practice6 min read

    Giving a coding agent context that survives the session

    Six things that work today, without adopting anything new, ranked by how much they return for the effort. Plus the two problems none of them solve.