Re-Proposing Rejected Decisions

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.

Solution

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.

When to use

• 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.