Negative Memory and Rejected-Idea Suppression
Examines why recording what was rejected is as important as recording what was approved in long-running agent systems.
Introduction
Most memory systems for AI agents record what is true: facts, decisions, context, and historical data. Few systems systematically record what is known to be false, invalid, or unacceptable. This asymmetry creates a specific failure mode in long-running systems: rejected-idea resurrection.
The Resurrection Problem
When an agent evaluates an approach and it is rejected—by human review, by invariant violation, or by council verdict—the rejection exists only in the session context where it occurred. When that session ends, or when the context window resets, the rejection is lost. The agent, encountering the same problem space in a future session, has no mechanism to distinguish between an idea it has not yet considered and an idea that was already considered and explicitly rejected.
The result is predictable: the agent re-proposes the rejected approach. If the reviewers who rejected it the first time are not present or do not remember the original rejection, the idea may be accepted. The system has now adopted an approach that was previously evaluated and found wanting.
Negative Memory as Architecture
The proposed Negative Memory architecture would make rejection a first-class governed data type. In that future model, a qualifying rejection would create a durable record that includes:
- What was rejected
- Why it was rejected
- Who rejected it (human, invariant, or council)
- When the rejection occurred
- Related context and alternative approaches that were preferred
In the target architecture, these records would be stored alongside positive facts and queried by the Session Integrity Layer. This behavior is not implemented today.
Enforcement
When an agent proposes an action, the Session Integrity Layer checks the proposal against negative memory. If the proposal matches a negative memory entry—meaning it reintroduces a previously rejected idea—the action is blocked and the match is reported. The agent receives the rejection reason and related context, enabling it to choose a different approach.
Challenges
Negative memory matching requires careful tuning. Overly broad matching blocks legitimate new ideas that are superficially similar to rejected ones. Overly narrow matching allows rejected ideas to resurface with minor variations. The matching system must balance precision and recall, and it must be configurable per project.
Conclusion
Recording what was rejected is not pessimism. It is engineering discipline. Negative memory helps the system detect and challenge attempts to repeat known mistakes, which is especially critical in long-running systems where session context is not persistent. However, negative memory can itself become stale — it requires appeal, expiration, or supersession mechanisms so that old rejections do not block valid future decisions made with new evidence. The formal specification is defined in IE-003.