When AI writes the code, who keeps the "why"? ADRs, agent decisions and the Living ADR

One observation recurs in 2026 engineering discussions: Architecture Decision Records (ADRs) are enjoying renewed interest, for a prosaic reason. Coding agents now write a large share of code, and an agent that can't see why something was built a certain way will happily "refactor" it, removing the rationale for that choice. For agents that forget between sessions, the ADR is one of the few artifacts that survives (BrainGrid, Nexapp).

The problem: speed without memory

The 2026 DORA report describes organizations where AI increases delivered code volume, but where delivery stability may degrade (InfoQ). One plausible cause, among others, is that volume outruns the capacity to review and to remember: why this dependency, why this boundary between services, why this rejected option. When the agent decides at machine speed, the justification must be captured at the same speed, or it exists nowhere.

What an "agent-ready" ADR contains

Emerging practices (see for instance the proposed Agent Decision Records standard) enrich the classic ADR with a few elements:

• a stable identifier and a status (proposed, accepted, superseded, dropped);
• the context and the decision, but also the rejected alternatives and why: it is what stops an agent from resurrecting them;
• the scope and relationships to other decisions;
• reconsideration triggers: under what conditions the decision should be reopened;
• a classification of consequences: what is recommended, what requires human review, what can be verified automatically;
• where an AI contributed to the decision, a note of that fact (model, summary of the prompt), so provenance stays legible.

What the Living ADR adds

An enriched ADR remains a document. TEAF's Living ADR addresses what these practices don't solve alone: silent expiry. It ties the decision to the constraints that motivated it, through the Knowledge Backbone, so that a significant change shows it as "to review", with the reason for the trigger. For a coding agent, this means it can read not only what was decided, but whether the decision is still presumed valid.

Who decides when the agent proposes?

An agent can draft an ADR, and that is useful. But an architecture decision remains an act of governance: TEAF entrusts the substance of the decision to the Decision Steward, and the boundary between what an agent may decide alone and what requires validation to the AI Control Officer (see the AI Control Plane). An agent that drafts an ADR is not an agent that approves it.

A sober implementation

1. Store ADRs with the code, in the repository, in text format: agents read them naturally and they are versioned with the changes.
2. Require rejected alternatives in the template: it is the field that costs least to fill and pays most.
3. Plug in a review at expiry or on events (supplier change, constraint change) rather than relying on the team's memory.
4. Trace the AI's contribution without making it grounds for suspicion: transparency on provenance helps review.

None of this is specific to TEAF; it is good engineering practice of which the Living ADR is the governance extension. The TEAF anti-patterns describe what happens when decisions are no longer tied to their conditions of validity.

• Coding agents forget between sessions: the ADR is the memory that survives.
• An agent-ready ADR records rejected alternatives, scope, reconsideration triggers and provenance.
• The Living ADR adds the link to constraints and the visibility of expiry.
• An agent can propose a decision; it does not approve it.

Sources

• BrainGrid — Architecture decision records for AI coding agents
• Nexapp — ADRs in practice: aligning teams and AI agents
• GitHub — Agent Decision Records (AgDR)
• InfoQ — New DORA report: strong engineering foundations drive AI ROI