Agent Memory for Debugging: Recall Past Incidents
Agent memory for debugging means the next outage starts with answers, not an empty terminal. Store each incident's cause, fix, and gotcha once, then have every future debugging session recall it before reading logs.
On this page
Why debugging restarts from zero every time
Every debugging session starts with an empty context window. The agent sees the current error, the files you point it at, and nothing else. What the last on-call engineer learned at 2 a.m. stays in a closed terminal, a merged pull request, or a ticket comment the agent never reads.
That blank start makes repeat incidents cost the same effort twice. A checkout service throws 429s under load, someone adds backoff with a reason in the pull request, and three weeks later a different agent hits the same 429s and re-derives the same fix. The log lines are fresh, but the lesson is gone.
The mechanism matches why your coding agent forgets conventions: conversation context lasts only for its own lifetime. Compaction rewrites it to fit the window, /clear discards it, and a new terminal never had it. A fix that lives only in chat history stays invisible to the next incident.
Rotation makes the loss worse. The engineer who debugged the migration ordering bug moves to another service, the next debugger runs a different agent in Codex or OpenCode, and the retry header the last session found gets rediscovered by trial and error.
The fix is to store the incident lesson outside the conversation. One project memory holds the cause, the fix, and the gotcha in retrievable form. The next debugging session queries that memory first, then reads logs with the past answer already in view.
What to store from an incident (and what not to)
Keep incident memory small and atomic: one fact per memory, scoped to the service it affects. The next session needs the cause plus the fix plus the trap to avoid, not a transcript of how you found it.
Store three kinds of facts. First, the cause with scope: which service failed and under what condition. Second, the fix that resolved it: command, config value, ordering rule, or code pattern. Third, the gotcha that wasted time: the wrong path, the misleading log line, or the check that must run first.
For a hypothetical checkout-service outage, that looks like three separate memories: checkout-service returns 429s during burst replays because the provider rate-limits bursts, billing-worker retries require backoff with the interval recorded in the pull request description, and checkout migrations run after the backfill — running before broke the March deploy.
Leave everything else out. Full logs, diffs, and stack traces already live in the repo, the ticket, or the observability tool. Temporary session state, one-off port numbers, and wrong speculation have no reuse value. Never store secrets, tokens, or credentials in memory.
| Keep in memory | Leave out |
|---|---|
| Cause plus scope, e.g. service name and trigger condition | Full logs, traces, or file contents the repo already holds |
| Fix that worked, with command or ordering rule | Dead-end guesses that did not resolve the incident |
| Gotcha that wasted time, e.g. misleading error or required check order | Temporary ports, PIDs, or single-session debugging state |
| Constraint such as staging-first check or deploy freeze | Secrets, tokens, or credentials of any kind |
Write the fact the way you want it returned. Include the service name, the symptom keyword a future debugger will type, and the one-line reason. A bare rule gets re-litigated; a rule with cause sticks when the next agent reads it under pressure.
Agent memory for debugging: recall before you investigate
Agent memory for debugging changes the order: recall first, then investigate. Before the agent opens log files, it searches project memory for the service, the symptom, and the error code. That search returns past causes and fixes the current conversation never saw.
Setup follows the same path as any project memory. The agent needs a project key with the ak_ prefix against the data plane at https://api.memory.audaxic.com. The API is mem0-like: POST /add to store, POST /search to recall, GET /list paginated with limit and offset to audit, PUT /update to correct, DELETE /delete/{memory_id} to remove. The quickstart shows request shapes, and the search API docs cover recall queries.
Take a hypothetical walkthrough. A new 429 spike hits the checkout service. The debugging agent — Claude Code with npx @audaxic/memory-claude install, Codex with npx @audaxic/memory-codex install, or any MCP-compatible client on the same key — starts with one search combining service, symptom, and area:
curl -X POST https://api.memory.audaxic.com/search \
-H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
-H "X-Api-Version: 2026-09-25" \
-H "Content-Type: application/json" \
--data-binary @- <<'JSON'
{
"query": "checkout-service 429 burst replay retry backoff",
"limit": 10
}
JSON
That query returns the three memories from the prior outage: the burst rate-limit cause, the backoff requirement, and the migration ordering constraint. The agent now checks instead of guessing. It confirms the replay pattern matches the stored cause, applies the stored backoff shape, and skips the dead-end header change the gotcha memory warns against.
Pin the date-based X-Api-Version header in every script. The current version is 2026-09-25, so automation fails loudly on version drift instead of silently changing recall behavior mid-incident.
Verify the loop the way you verify any agent memory. Ask for something only a prior incident could know, or call GET /list with a small limit and confirm the stored fix is present. If recall comes back empty, confirm the agent searched first and used the right project key — a wrong-project key makes memory look empty even when the facts exist. The fix for Claude Code context compaction explains why recall survives compaction and /clear while chat context does not.
Search patterns that surface the right fix
Good recall is a query habit, not a larger store. Broad queries return noise; narrow queries return the fix. Combine three elements in every debugging search: service name, symptom or error code, and the area you are about to touch.
Start with service plus symptom: checkout-service 429, billing-worker retry loop, staging check main push. If that returns too much, add the constraint or file area: checkout-service 429 migration backfill, billing-worker Retry-After 429 handling. If it returns too little, drop one term and retry rather than pasting log paragraphs. Short queries match atomic facts; pasted stack traces match nothing.
Search before each new hypothesis, not once per session. After the first fix attempt fails, search the failure mode you just observed: backoff interval rejected provider burst. That second query often surfaces the gotcha the first query missed. Two targeted searches beat re-reading logs.
Audit recall with GET /list when debugging feels slow. Pull the first page and look for the real problem behind bad search results:
curl "https://api.memory.audaxic.com/list?limit=20&offset=0" \
-H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
-H "X-Api-Version: 2026-09-25"
Duplicates and contradictions hurt recall more than missing facts. Two memories that disagree on the backoff interval force every search to return both and make the agent guess. Merge them into one fact with the current value. The update API docs show the correction shape.
Counting keeps the habit cheap. One /add call extracting five memories counts as five adds. Retrieves are tiered: the first 10 memories count as one request, each additional 10 as one more, so 25 memories count as three requests. Small atomic facts plus narrow limit values keep both counters low — the Hobby tier holds 10,000 adds and 1,000 retrieves per month.
Keep incident memory current: update and delete
Incident memory rots without upkeep. Services change, providers change limits, and a fix that was correct in March misleads in October. A debugger that follows a stale memory trusts it with the same confidence as a fresh one, so maintenance is a reliability task.
Correct with PUT /update when the fact still applies but the detail changed. The backoff interval changed, the test command moved packages, the required header gained a value, the migration step added a precondition. Update the single memory in place. Do not add a second memory that contradicts the first; competing facts split future recall and push the choice onto an agent working under incident pressure.
Delete with DELETE /delete/{memory_id} when the fact no longer applies. The deploy freeze lifted, the flaky parallel test was fixed at the source, the provider removed the burst limit, the hotfix exception expired. Stale facts hurt more than missing facts because the agent still acts on them. Removal is the fix.
Reserve the full wipe DELETE /delete for a true project restart. Selective deletes preserve good rules while removing noise. A monthly GET /list pass scaled to incident volume is enough for most repos: pull 20, scan for duplicates, merge contradictions, delete what expired.
Data stays isolated per organization with namespace-scoped vector search, customer data is never used for training, and servers run in the US and EU. Inside the organization the project is the boundary, so the checkout key returns checkout incidents and nothing else. Projects are unlimited on every plan from Hobby through Enterprise, which means a per-service or per-repo split costs nothing extra and keeps recall precise. Graph memory is included on all plans with flat monthly pricing and no per-token fees.
Close the ticket with a three-step memory write-back
The workflow fails at one point: the engineer fixes the incident, closes the ticket, and skips the write-back. The next debugger then pays the same discovery cost. Make the store step part of closing, not an optional follow-up.
Use a three-step closeout. First, search for existing memories on the same service and symptom to avoid duplicates. Second, add one atomic memory for each new lesson — cause, fix, gotcha — with the service name in the text. Third, update or delete any fact the incident proved wrong. The pass takes minutes and it is the only write path that matters.
Wire the same memory into every agent that touches the service. Coding agents write the decision while implementing, the debugging agent reads it during the next outage, and the reviewer enforces it on the next pull request with no copy-paste between tools. One memory per project means switching agents never resets context. Cursor connects through MCP only; there is no Cursor plugin.
Seed the store instead of starting empty. The importer covers past Claude Code, Codex, and OpenCode conversations with correct timestamps via npm install -g @audaxic/memory-import. Import once per project before the next incident, so the first recall already knows the outages the team survived. That import plus the closeout habit turns isolated debugging sessions into a record that compounds: each incident makes the next one shorter.
FAQ
How does agent memory for debugging change the first 10 minutes of an incident?
The agent calls POST /search on the same project key before reading logs, combining service name, symptom, and error code. Recall returns the stored cause, fix, and gotcha from the prior incident instead of starting blank. The API is mem0-like with POST /add, POST /search, GET /list paginated with limit and offset, PUT /update, and DELETE /delete/{memory_id}.
What should I store from an incident?
Store one atomic fact per memory: the cause with service scope, the fix that worked, and the gotcha that wasted time. Leave out full logs, temporary session state, and any secrets, tokens, or credentials. Data is isolated per organization with namespace-scoped vector search and is never used for training.
How do I fix a stale incident fix the debugger keeps repeating?
Correct it with PUT /update when the detail changed, or remove it with DELETE /delete/{memory_id} when it no longer applies. Audit with GET /list, which is paginated with limit and offset, to find duplicates and contradictions. Reserve DELETE /delete for a true project restart.
What does incident memory cost?
Hobby is $0 per month with 10,000 adds and 1,000 retrieves, and Starter is $12 per month for 50,000 adds and 5,000 retrieves. An add counts per memory extracted from a message batch, and retrieves are tiered at one request per 10 memories. Billing is flat monthly with no per-token fees, projects are unlimited, and graph memory is included on all plans.
Written by Efe — Oct 09, 2026 · More articles · X @AudaxicTech