> ## Documentation Index
> Fetch the complete documentation index at: https://docs.memory.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](https://docs.memory.anonalabs.com/use-cases/overview.md)

## 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](https://docs.memory.anonalabs.com/integrations/skills.md). 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.

* **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](https://docs.memory.anonalabs.com/use-cases/memory-for-your-coding-agent.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.