Negative Memory: Teaching AI Agents What Not To Do

Matchiffo Ynna — Sun, 08 Nov 2026 20:27:19 +0000

Most agent memory is about success. We store the fix that worked, the query that returned the right rows, the prompt that produced a clean answer, and we retrieve it next time. That is useful, but it leaves out half of what an experienced engineer actually knows: the list of things that looked reasonable and went badly.

Ask a new on-call engineer to fix a stuck service and they may restart it. Ask a senior one and they will first check whether a restart on that service drops in-flight payments. The difference is not more positive knowledge. It is a memory of past failures. AI agents today mostly do not have that, so they repeat the same ineffective or dangerous steps: the rollback that corrupted a migration last month, the cache flush that took the site down, the "quick restart" that lost queued jobs.

Negative memory is the fix for this. The agent keeps a record of actions that failed or caused harm, and it reads that record before acting.

What a negative memory entry looks like

Keep it small and structured. An entry needs enough context to match future situations, and a clear statement of what went wrong.

{
  "action": "restart service payments-api",
  "context": "high latency, 5xx errors, during traffic peak",
  "outcome": "dropped in-flight transactions, 40 min recovery",
  "severity": "block",
  "source": "postmortem 2026-09-14",
  "expires": "2027-03-14"
}

Two fields matter most. severity tells the agent whether this is a hard block (never do it without a human) or a soft warning (do it, but mention the risk). expires stops old lessons from outliving the systems they were about.

How the agent uses it

The loop is simple. Before the agent runs a tool or proposes a fix, it searches the negative memory for entries similar to the planned action and the current context. Matches are injected into the prompt as constraints, not as suggestions:

Do not perform these actions in this situation:
- restart payments-api during a traffic peak (dropped transactions, Sept 2026)
- roll back the orders schema (data loss, Aug 2026)
If one of these seems necessary, stop and ask a human.

For block entries, do not rely on the prompt alone. Check the planned tool call in code and refuse it. Prompts are advice; code is enforcement.

Where the entries come from

You do not need a research project to start. Three sources cover most of it:

Postmortems. Every incident review already lists what was tried and what made it worse. Turn those lines into entries.
Failed tool calls. When the agent runs a command and the result is an error or a worse metric, log the action, the context and the result automatically.
Human corrections. When an operator overrides the agent ("no, don't do that"), store the override with a short reason.

Pitfalls

Over-blocking. A failure in one environment is not a rule for all of them. Scope entries by service, environment and time.
Stale rules. Systems change. Use expiry dates and review entries that keep firing.
Vague entries. "Restarting is bad" is useless. "Restarting payments-api during peak drops transactions" is a rule the agent can match.
Secrets in logs. Failed commands often contain credentials. Strip them before storing.

Start today, with free tools

A SQLite table and a local embedding model are enough for a first version. Store entries as rows, embed action + context, and run a similarity search before each tool call. If embeddings feel like too much, keyword matching on service name and action type already catches most repeats.