Re-Proposing Rejected Decisions

also known as Relitigating Settled Choices, Amnesiac Alternative Re-Suggestion

Anti-pattern: a stateless agent sees the code but not the decision history, so it keeps proposing options already considered and rejected, forcing reviewers to relitigate settled choices turn after turn.

Context

A coding or architecture agent reads the current source on each task but is not given the project's decision history — the architecture-decision records, the discussion threads, the trade-offs that were weighed and the alternatives that were turned down. The code shows what the team chose; it rarely encodes why, or what was rejected and on what grounds. Every fresh session starts the agent from that same incomplete picture.

Problem

The reasons a team rejected an option — a library that failed a security audit, a queue that did not meet a latency target, a schema abandoned after a migration scare — live outside the code, in records the agent never sees. Lacking that history, the agent re-derives a plausible design from first principles and confidently re-suggests an option that was already weighed and discarded, often arguing for it persuasively. The reviewer then has to recall and restate the original rejection, relitigating a closed question, and the same alternative resurfaces in the next session because nothing about the agent's inputs has changed.

Forces

Source code records the choice that was made but almost never the alternatives that were rejected or the grounds for rejecting them.
A stateless agent re-derives a design from scratch each session, so a once-rejected option is just as likely to be re-proposed as any other plausible candidate.
Re-suggested options are argued convincingly, so a reviewer cannot dismiss them on sight and must reconstruct the original rejection to refute them.
The cost lands repeatedly on the human: each relitigation is cheap once, but the same closed question reopens every session until the decision history reaches the agent's context.

When to watch for it

Watch for this whenever an agent works a codebase whose architecture-decision records and rejection rationale live outside the source it reads.
Suspect it when the same already-rejected option keeps resurfacing across sessions and reviewers find themselves restating decisions they thought were settled.
Audit for it on long-lived projects where 'why we did not do X' is tribal knowledge rather than a retrievable record.

When it is not a concern

Decision history with rejected alternatives and revisit conditions is already retrieved into the agent's context, which is the corrective rather than the anti-pattern.
The task is genuinely open-ended design where no prior decision constrains the choice, so there is nothing settled to relitigate.
Revisit conditions for a recorded decision have actually changed, making a fresh proposal of a previously rejected option legitimate rather than amnesiac.

Example

An agent is asked to add a job queue to a service whose code already uses a database-backed queue. Unaware the team trialled and rejected a message broker months ago over its operational cost, the agent confidently proposes switching to that broker, arguing the case well. The reviewer has to dig up the old decision and restate why it was dropped — and next week, on a fresh session, the agent proposes the same broker again, because nothing about what it can see has changed.

Diagram

flowchart TD A[Agent reads code, not decision history] --> B[Re-derives a design from scratch] B --> C[Proposes an already-rejected option, argued well] C --> D[Reviewer recalls and restates the original rejection] D --> E{New session?} E -- yes --> A A -. corrective .-> F[Retrieve architecture-decision records into context] F --> G[Settled choice arrives as a constraint; agent asks only: have revisit conditions changed?]

Solution

Therefore:

The corrective is to make decision history a retrieved input rather than something the agent must rediscover. Maintain architecture-decision records that capture not just the chosen option but the alternatives considered, why each was rejected, and the conditions under which the decision should be revisited. Surface the records relevant to the current task into context — alongside the code — so the agent treats a settled choice as a constraint, not an open design space. Re-frame the agent's task from 'design the best option' to 'work within the recorded decision unless its stated revisit conditions now hold', which turns a relitigation into a narrow, answerable check.

What it gives you

Naming the failure separates 'the agent has the code' from 'the agent has the reasons', which teams conflate when they assume a current repository carries its own rationale.
The corrective — retrieve decision records into context — converts an open-ended re-design the reviewer must police into a bounded 'have the revisit conditions changed?' check.

What it costs you

Reviewer time is burned repeatedly relitigating the same closed question, and the cost recurs every session because the agent's inputs never change.
A persuasive re-proposal of a rejected option can slip through when the reviewer no longer remembers the original grounds, reintroducing a choice the team already discarded for cause.
Decision records must be written and kept current; stale or missing records leave the agent re-deriving, and over-detailed ones add retrieval cost without closing the question.

What this pattern forbids. An agent working a design or architecture task must not re-open a recorded decision unless its documented revisit conditions are met; a settled choice is treated as a binding constraint, and re-proposing a rejected alternative without citing a changed revisit condition is disallowed.

The patterns that counter or replace it —

complementsDecision Log★★— Persist the agent's reasoning trace alongside its actions so post-hoc review can explain why.
complementsDecision Context Maps★— Before any consequential decision, require the agent to gather a declared set of contextual inputs (resource availability, schedules, downstream dependencies) into a 'context map' the decision must cite.
alternative-toContext Fragmentation✕— Anti-pattern: the LLM cannot hold multiple interconnected constraints in mind simultaneously the way human working memory can; it processes each constraint locally and loses the cross-constraint view.
alternative-toAgent Confession as Forensics✕— Anti-pattern: after an agent-caused incident, the team treats the agent's confabulated self-narrative as the forensic record and root cause, even though the self-report is generated rather than remembered and can be flatly wrong.