I borrowed this idea from Amazon, and it has completely changed how I think about technical decisions in an Agentic Engineering workflow.
The concept is simple: some decisions are easy to reverse, and some are not. Amazon calls them “two-way doors” and “one-way doors.” A two-way door is a decision you can walk back through — if it does not work out, you reverse it. A one-way door is a decision that is extremely costly or impossible to undo once implemented.
The interesting part? When an AI agent is making implementation decisions based on your architecture documents, the door type tells it how much rigor to apply before committing.
Why Standard ADRs Fall Short for Agents
Architecture Decision Records have been around for years. The format is well-established: title, context, decision, consequences. Michael Nygard popularized the lightweight format. Most engineering organizations have some version of this.
But here is what most ADR templates miss — and what becomes critical in Agentic Engineering: they treat every decision with the same level of rigor. The database choice gets the same template as the logging format. The authentication model gets the same analysis depth as the CSV delimiter choice.
For a human developer, this is a minor annoyance. They instinctively know that the database choice is more important than the log format. But an AI agent does not have that instinct. It reads both design documents and treats them with equal weight. It might spend significant context re-evaluating a thoroughly deliberated database choice, or it might carelessly tweak an authentication pattern that has security implications.
The door type classification solves this by giving the agent an explicit signal: how much latitude do you have with this decision?
How I Classify Decisions
In the Knowledge Store Generator, Step 5 — the Domain Designer persona from Part 3 — produces 15+ design documents. Each one is classified at the top:
One-Way Doors (High Rigor Required):
- DD-001: Monorepo structure — Changing from monorepo to multi-repo after implementation means restructuring everything. Rollback strategy documented.
- DD-002: Database schema (SQLite) — Switching databases post-implementation requires data migration, ORM changes, and query rewrites. Alternatives extensively analyzed.
- DD-003: Authentication model — Security decisions are nearly impossible to change once users depend on them. Full threat model included.
Two-Way Doors (Move Fast):
- DD-007: Error log format — CSV vs JSON for error tracking. Easy to change later. Brief analysis, quick decision.
- DD-020: Logging format — Structured JSON vs plain text. Can be swapped with a configuration change. Minimal alternatives analysis.
- DD-008: Site profile structure — How job site scraping profiles are organized. Refactorable without user impact.
What Changes With Door Type
The door type affects three things in each design document:
1. Alternatives Analysis Depth
One-way doors get a thorough alternatives section. DD-002 (database) evaluates SQLite vs PostgreSQL vs file-based storage, with pros/cons, performance implications, and migration costs for each option.
Two-way doors get a brief “considered X, chose Y because Z” note. No need to exhaustively evaluate every CSV library when you can swap it next week.
2. Rollback Strategy
One-way doors must document a rollback plan. DD-001 (monorepo) explicitly states: “If monorepo proves unworkable, split into X packages with Y shared libraries.” The rollback is expensive — that is why it is a one-way door — but it must be possible.
Two-way doors do not need rollback strategies. The whole point is that rolling back is trivial.
3. Agent Implementation Latitude
This is the part that matters most for Agentic Engineering. When the agent reads a one-way door decision, it treats that decision as immutable during implementation. It does not try to “improve” the database choice. It does not refactor the auth model. It implements exactly what the design doc specifies.
When it reads a two-way door, it has more freedom. If it finds a better logging pattern during implementation, it can adjust — because the decision was explicitly marked as reversible.
The Practical Template
How This Connects to the Series
Door type classification integrates with several other Agentic Engineering patterns:
- Traceability chains (Part 5): One-way door decisions get stronger traceability chains — more enforcement mechanisms, more test coverage. Two-way doors get lighter chains.
- Forensic verification (Part 6): The verification pass checks that one-way door decisions have rollback strategies and thorough alternatives. Two-way doors are checked for basic completeness only.
- Product guardrails (Part 9): Guardrails often map to one-way door consequences. The “zero fabrication” guardrail is a consequence of the one-way decision to build an AI pipeline that generates content autonomously.
The classification does not change the decisions themselves. It changes how much you invest in analyzing them upfront, and how much latitude the implementing agent has to adapt them.
Getting Started
If you are using ADRs in your projects, adding the door type classification takes five minutes per document. Go through your existing decisions and ask: “If this turned out to be wrong, how hard would it be to change?” If the answer is “a week of refactoring” — one-way door. If the answer is “change a config value” — two-way door.
For Agentic Engineering specifically, the door type is one of the most efficient signals you can give an AI agent. It answers the question the agent is always implicitly asking: “How much should I trust this document versus my own judgment?”
Have you used the one-way/two-way door framework in your architectural decisions? I find it especially useful for calibrating review effort — curious to hear how others approach it.