Stop coding agents repeating failed approaches by preserving important rejections as versioned negative decisions. Describe the attempted approach, why it failed in this context, the evidence, its consequences and the conditions under which it should be reconsidered; then make that record discoverable before implementation.
Failure leaves less evidence than success
Successful choices remain visible in code. An experiment that was reverted, a dependency rejected during review or an architecture abandoned after testing may leave no obvious trace. A new agent can therefore propose the same plausible option and repeat the cost.
Raw transcripts and issue threads are poor long-term controls: they mix hypotheses, stale statements and conclusions. Distil the durable conclusion into a reviewed record and link the underlying evidence.
Write a useful rejection
Avoid universal warnings such as 'do not use queues'. State the task and constraints under which the choice failed. A scoped rejection lets a future agent distinguish an unchanged constraint from a genuinely new situation.
- Approach evaluated and the problem it attempted to solve.
- Observed failure or trade-off, with benchmark, incident or review evidence.
- Accepted alternative and consequences for current code.
- A concrete trigger for reopening the decision.
Retrieve before planning
Index the record using the language an engineer would use to propose the rejected approach. Ask agents to check related accepted and rejected decisions during planning, not after a patch exists. The returned record should carry a stable ID so reviewers can verify it directly.
Do not freeze the project
A negative decision is not an eternal ban. When its stated assumptions change, supersede it through the same review process used for the original decision. Keeping both records and their relationship preserves what the team learned while allowing the architecture to evolve.