Skip to main content
reopt Handbook
reopt Handbook
Agentic Documentation

Paradigm Shift

Why Documentation Must ChangeAI-readable Design PrinciplesAI-assisted Writing Process

Practice by Document Type

Project Rule DocumentsFrom Docs to Skills, Plugins, and MCPAgent Documentation SecurityAPI Docs and SpecsREADME and OnboardingArchitecture Decision RecordsRunbooks and OperationsUser Guides and TutorialsKnowledge Bases and Internal Wikis

Operations

Maintenance StrategyTeam Documentation Culture

Appendix

TemplatesVerification ReportUpdates
Handbook›에이전틱 시대의 문서화 혁신›Architecture Decision Records
한국어English

Architecture Decision Records

Capture architectural decisions so agents understand why the codebase is shaped this way.

Key takeaways

  • ADRs preserve the tradeoffs, rejected alternatives, and constraints that the final code cannot show, so agents understand why the system is shaped this way.
  • Without an ADR, an agent may "improve" code by undoing a deliberate constraint, such as splitting a monolith or upgrading a pinned dependency into a known bug.
  • Use the four core sections (Context, Decision, Alternatives Considered, Consequences) and explain why each rejected alternative lost.
  • Add an explicit "Agent Guidance" section that tells agents what not to change and which runbooks to update.
  • Status values (proposed, accepted, deprecated, superseded) signal whether a decision is still current.

Agents can read code, but code rarely explains why a decision was made. Architecture Decision Records (ADRs) preserve the tradeoffs, rejected alternatives, and constraints that are invisible in the final implementation.

Why ADRs Matter for Agents

Without ADRs, an agent may "improve" the code by undoing a deliberate constraint.

Missing ADRAgent risk
Why a monolith remainsagent splits services prematurely
Why a cache is write-throughagent changes consistency behavior
Why a dependency is pinnedagent upgrades into a known bug
Why a queue is usedagent replaces async flow with sync calls

ADR Template

---
title: Use PostgreSQL advisory locks for billing jobs
status: accepted
date: 2026-05-24
owner: platform-team
related:
  - /docs/runbooks/billing-jobs
---

# Use PostgreSQL advisory locks for billing jobs

## Context

[Problem, constraints, and current system.]

## Decision

[The decision in one or two paragraphs.]

## Alternatives Considered

| Alternative | Why rejected |
|---|---|
| Redis lock | Additional runtime dependency |
| Queue-level lock | Does not protect manual retry path |

## Consequences

- Positive:
- Negative:
- Operational notes:

## Agent Guidance

- Do not replace this lock with an in-memory lock.
- If billing jobs are refactored, update this ADR and the runbook.

ADR Status Values

StatusMeaning
proposedunder review
acceptedcurrent decision
deprecatedno longer recommended
supersededreplaced by a newer ADR

Agent Guidance Section

Add a short section that tells agents what not to change.

## Agent Guidance

- This decision is still active.
- Do not remove the retry queue without replacing the idempotency guarantee.
- Any change must update `docs/runbooks/payment-retry.md`.

Checklist

ItemCheck
ADR states context, decision, alternatives, and consequences[ ]
rejected alternatives explain why[ ]
status is current[ ]
agent guidance is explicit[ ]
related runbooks/API docs are linked[ ]

Related docs

Decision

Agentic MVP · Convert MVP evidence into iterate, pivot, pause, or scale decisions.

Agent Architecture

New Brand Marketing Strategy · Design AI-assisted marketing workflows with clear roles, inputs, and review gates.

Multi-Agent Architecture

Vercel Enterprise AI Platform · Design supervisor, delegation, pipeline, and review patterns for enterprise agents.

README and Onboarding

Split README, llms.txt, agent instructions, and detailed docs by audience.

Runbooks and Operations

Design runbooks that separate diagnosis, recommendation, action, approval, and rollback.

On this page

Why ADRs Matter for AgentsADR TemplateADR Status ValuesAgent Guidance SectionChecklist