The question teams are now asking
Most of the code that coding agents will change already exists, and much of it was never fully documented. The engineers who knew why a boundary sits where it does have moved on. The architecture decision records (ADRs), if there were any, stopped being updated years ago.
So teams ask a reasonable question: can an AI agent reconstruct the decisions behind a system well enough to work on it safely? The published research gives a partial answer. Recovering what a system is works reasonably well. Recovering why it is that way is the hard part.
Three things you might want to recover
A useful reconstruction has three layers, and they are not equally hard:
- Structure: components, dependencies, interfaces, data stores and the paths between them.
- Function: the workflows and business rules the system implements, such as "order submitted, payment authorised, inventory reserved", rather than "service A calls service B".
- Decisions: the choices that explain the structure. Which boundaries are deliberate, which libraries were ruled out, which constraints the team agreed to keep.
An agent that only has the first layer can copy what it sees. It cannot tell a deliberate boundary from an accident, which is how agents end up copying legacy architecture during a migration.
Recovering structure is an established field
Architecture recovery long predates language models. A 2022 systematic mapping study of architecture erosion by Li, Liang, Soliman and Avgeriou, published in the Journal of Software: Evolution and Process, reviewed 73 studies published between January 2006 and May 2019. It catalogues tools used to detect erosion, including conformance checkers such as Lattix, Structure101, Axivion and Sonargraph, and the ARCADE recovery workbench.
None of this is new, and much of it does not need an agent. Static analysis can map what exists, and conformance tools compare it with a declared intended architecture. The gap is that a dependency graph shows what the system does, not what the team meant it to do.
Recovering decisions is the hard part
A September 2026 preliminary exploratory study by Karan, Dhar, Soliman and Vaidhyanathan tested whether language models can extract architectural design decisions from source-code commits. The authors gave four models 30 developer-written decisions from open-source projects, both with no worked examples in the prompt and with a few.
By text-similarity scores the models did well: every model scored above 0.81 on BERTScore, a standard semantic-similarity measure, and examples in the prompt helped (one model's score rose from 0.828 to 0.847). One author's manual review of one model's outputs told a different story. The generated decisions were often too long and focused on implementation detail, and in the authors' words they "miss the rationale behind the decision."
That is a small, early study and a preprint, so treat it as a signal rather than a verdict. It is consistent with how commits work: a commit records what changed. The reason usually lives somewhere else, or nowhere.
Why the missing rationale matters
The 2022 mapping study explains why rationale is the piece worth recovering. It defines architecture erosion as the implemented architecture violating the intended one, or the architecture becoming resistant to change. Among non-technical causes, the most frequently mentioned was knowledge vaporization: architectural knowledge lost through missing or incomplete documentation and through developer turnover. It was cited in 11 of the 73 studies (15.1%). The authors recommend recording and tracing architectural knowledge, such as decisions and assumptions, to source code and to architectural changes.
The study predates coding agents, so it supports the problem, not any particular fix. The link to agents is direct: an agent working on a system with vaporized knowledge has to infer intent from the code, and the code records what was built, not why.
Three different questions
Recovering structure and checking it against decisions are separate jobs. Mixing them produces misleading results, such as a planned migration that looks like damage:
| Question | What it asks |
|---|---|
| Recovery | What exists in this system? |
| Conformance | Does it depart from the approved decisions? |
| Drift | Is the system moving away from approved decisions over time? |
A single violation is not drift. A large change that follows an approved migration is not damage either. You can only tell these apart if decisions carry a lifecycle and an owner, so the system knows which intent is current. That is the same property that separates architectural drift, the gradual move away from approved decisions, from planned change.
What a useful reconstruction needs
If teams use agents to reconstruct a system, the output should not be one confident document. Each fact should say how it is known:
- Observed: read directly from code, configuration or runtime data.
- Inferred: proposed by a tool or model from evidence, with the evidence attached.
- Confirmed: accepted by a person with the authority to accept it.
Only confirmed decisions should ever become constraints that block an agent. An inferred decision that is enforced is a guess with a veto. The record of how a decision was confirmed is what turns an ADR into something agents can rely on.
The open question
Can evidence-backed reconstruction of structure, function and decisions make agents measurably safer on undocumented systems? The literature does not answer that yet. Structure recovery is mature and decision recovery is early. We found no published controlled test of agents working with a reconstructed decision layer versus without one. Mneme is researching this question, and has no results to report yet.
What engineering leaders should do now
- Recover structure with existing tools. Dependency and architecture analysis is mature. Use it before asking an agent to guess.
- Treat model-extracted decisions as drafts. Expect them to describe the change and miss the reason. Have the people who own the system today confirm or reject each one, even if they were not there when it was decided.
- Record why, not only what. The cheapest decision to recover is the one written down when it was made.
- Separate recovery from enforcement. Never let an inferred decision block a change until a person has accepted it.
Where Mneme fits
Mneme, an open-source decision and control layer for agentic software development, works on the confirmed end of this pipeline today. Its Architecture Audit discovers the decisions a repository already documents, in ADRs, agent instructions, architecture docs and configuration, and classifies whether each one is deterministically protected today. Decisions with an active typed rule are enforced deterministically in supported coding agents and in continuous integration. Agents can propose new decisions; a person accepts them on the command line, and protection is activated as a separate step.
Reconstructing undocumented decisions from code and history is the research question above, not a shipped capability.