> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anonalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Stop re-solving the same bug

> The fix you found in March, surfaced in September — before you start debugging, not after.

[← All use cases](/use-cases/overview)

## The scenario

You have solved this before. You know you have, because the error is familiar
and vaguely annoying in a specific way. What you cannot remember is what fixed
it.

Shell history has the commands but not the reasoning, and cannot answer a
question. The issue tracker has the ticket if someone filed one. Usually nobody
did, because it took fifteen minutes and fifteen minutes does not feel worth a
ticket — right up until you spend fifteen minutes on it again.

**What this recipe shows that no other does:** the memory is written *by the
agent, unprompted*, and read *before* the work rather than after.

## Setup

MCP plus the [Agent Skill](/integrations/skills). The skill is doing the real
work here — it is what makes the agent recall before starting a task and record
after finishing one, without you asking either time.

```bash theme={null}
claude mcp add --transport http anona https://memory.anonalabs.com/mcp \
  --header "Authorization: Bearer anona_live_YOUR_KEY"
npx skills add anonalabs/Anona-Memory-SDK
```

## What changes

You debug as normal. When it is fixed, the agent writes down what actually
worked — not the six things that didn't.

The next time a similar error appears, it checks first. You see:

> *"You hit this in March. It was the pgbouncer pool, not the gateway — the
> recovery order matters: redeploy pgbouncer first, then the gateway."*

The value is entirely in the ordering. The same fact surfaced *after* you
debugged it is a curiosity; surfaced before, it is the fifteen minutes back.

## Evals

This one is measurable, which most memory claims are not:

1. Work normally for two weeks with the skill installed.
2. Keep a count of how often a recalled memory arrived **before** you started
   versus after you had already solved it.
3. The second number being high means the recall trigger is too narrow — the
   agent is remembering, just too late to matter.
4. Spot-check three recorded fixes against what actually fixed it. An agent
   recording its first hypothesis rather than the eventual fix is the common
   failure, and it poisons the pile.

## Guardrails

<Warning>
  **Never let it record secrets.** Debugging output is full of connection
  strings, tokens and keys, and an agent pasting freely will store them
  verbatim. They are then retrievable by anyone with access to the space and
  will resurface in later prompts.
</Warning>

* **Record the fix, not the transcript.** A blow-by-blow of a debugging session
  is noise that crowds out the answer. One sentence about what was actually
  wrong beats forty about what wasn't.
* **A wrong memory is worse than none**, because next time it will be recalled
  with confidence and send you down the path that didn't work. Correct them when
  you spot them.
* **MCP tools load at session start.** Adding the server mid-session changes
  nothing until you restart.

## Where to go next

The team-scale version, where what one person learns the whole repo knows:
[Memory for your coding agent](/use-cases/memory-for-your-coding-agent).