Architecture Decision Records
Short documents capturing why the architecture is the way it is. Each ADR names an alternative that was considered and rejected, and the forces that drove the choice. Read these when you're tempted to change something load-bearing.
Format loosely follows Michael Nygard's ADR template: context, decision, consequences.
Index
| # | Title | Status |
|---|---|---|
| 0001 | Single-process runtime over microservices | Accepted |
| 0002 | NATS as the broker | Accepted |
| 0003 | sqlite-vec for vector search | Accepted |
| 0004 | Per-agent tool sandboxing at registry build time | Accepted |
| 0005 | Drop-in agents.d/ directory for private configs | Accepted |
| 0006 | Per-agent git repo for memory forensics | Accepted |
| 0007 | WhatsApp via whatsapp-rs (Signal Protocol) | Accepted |
| 0008 | MCP dual role — client and server | Accepted |
| 0009 | Dual MIT / Apache-2.0 licensing | Accepted |
Writing a new ADR
- Copy the template (next ADR below, or use
0001as a reference) - Number sequentially:
NNNN-short-slug.md - Set
status: Proposedwhile in review, flip toAcceptedorRejectedafter the discussion settles - Link from this index
- Do not edit accepted ADRs in place. Create a new ADR that
supersedes it and mark the old one
Superseded by NNNN.
ADRs are load-bearing documentation — they're how future you (and future contributors) learn that "NATS over RabbitMQ was not an accident."