What Not to Delegate
An agent will happily choose your database, your tenancy model, and your auth strategy in the first ten minutes of a session — usually as an unremarked side effect of "build me a multi-tenant API". Each of those choices costs weeks to reverse. The agent bears none of that cost, remembers none of the context tomorrow, and picks whatever pattern was most common in its training data. Delegation of execution is the whole point of agentic engineering. Delegation of irreversible decisions is how you wake up in month three with an architecture nobody chose on purpose.
The reversibility test
Borrow Bezos's one-way/two-way door framing and make it your delegation criterion:
- Two-way door — cheap to reverse: a function's internal structure, a helper module's file layout, naming within an established convention, which of two equivalent libraries already in the lockfile to use. If it's wrong, a one-hour refactor fixes it. Delegate freely.
- One-way door — expensive to reverse: anything that other systems, teams, or persisted data will grow around. If it's wrong, you're planning a migration. The agent may propose; a human decides.
The trap: one-way doors rarely look like decisions in an agent session. They look like progress. The agent needed a queue, so now you have Kafka. It needed to store tenants, so now tenant_id is a nullable string column on every table. Nobody typed "decide our tenancy model" — it just happened at line 240 of a 900-line diff.
All three gates must pass for autonomous decision. Reversible but repo-wide (a lint rule, an error-handling idiom) still escalates, because the agent will replicate it everywhere before you review anything.
The never-delegate-blindly list
These are one-way doors almost by definition. The agent can research, prototype, and argue — a human signs off before code depends on them.
| Decision type | Why it's a one-way door | Delegation level |
|---|---|---|
| System boundaries (service split, module ownership, API surface between teams) | Everything downstream is shaped by it; Conway's law makes it organizational, not technical | Decide — human |
| Data ownership and schema of core entities | Persisted data outlives every rewrite; migrations are the most expensive work in software | Decide — human |
| Consistency model (strong vs eventual, transaction boundaries, idempotency strategy) | Retrofitting consistency into an eventually-consistent design is a rewrite | Decide — human |
| AuthN/AuthZ model (session vs JWT, RBAC vs ABAC, where enforcement lives) | Security-critical and touches every endpoint; errors are breaches, not bugs | Decide — human |
| Tenancy model (shared schema, schema-per-tenant, DB-per-tenant, RLS) | Baked into every query and every backup/restore procedure | Decide — human |
| Build vs buy (auth provider, payments, search, queues) | Contracts, cost curves, and vendor lock-in are business decisions | Decide — human |
| Core dependency / framework adoption | Every new dependency is a maintenance contract; agents add them casually | Propose — agent researches options, human picks |
| Cross-cutting conventions (error handling, logging shape, API versioning) | Reversible individually, replicated everywhere within hours | Propose — then encode the pick in CLAUDE.md |
| Internal module structure, algorithm choice within a boundary | Locally scoped, refactorable, covered by tests | Agent decides |
| Implementation of an already-made decision (an ADR exists) | The door was already walked through deliberately | Execute-only — deviation requires escalation |
"Execute-only" is worth enforcing explicitly: an agent that hits friction implementing ADR-covered work will quietly route around the decision (e.g., bypass the repository layer "temporarily") unless told that deviation means stop-and-ask. See Decision Records for making decisions agent-readable.
Agent proposes, human disposes
The failure mode isn't asking the agent architectural questions — it's letting architectural answers ship inside implementation tasks. Split the phases. In Claude Code, plan mode is the natural enforcement mechanism: the agent can read and reason but not write until you approve.
We need to add background job processing to the invoicing service
(Node.js, single Postgres, ~50k invoices/day, team of 4, no dedicated ops).
You are in PROPOSE mode:
1. Do NOT write or modify any code.
2. Present 2-3 options with a tradeoff table: operational burden,
failure modes, reversibility, fit with our existing stack.
3. State which decision here is hard to reverse and why.
4. Recommend one option and say what would change your recommendation.
5. STOP and wait for my decision. I will reply "DECIDED: <option>",
after which you implement exactly that and draft the ADR.The DECIDED: handshake matters: it creates an explicit artifact of who chose, and it gives the agent an unambiguous trigger to switch from analysis to execution. Pair it with the ADR-drafting clause so the decision survives the session — otherwise the next session relitigates it. For running the proposal phase well, see Exploring Options.
One more rule: when an agent asks you a one-way-door question mid-task ("should tenants share a schema?"), never answer inline with one line. Stop the task, run the decision properly, record it. A one-line chat answer is still an undocumented architecture decision — you've just made it the human's undocumented decision instead of the agent's.
Related
- Exploring Options — how to run the "propose" phase so you get real options, not the training-data default.
- Decision Records — turning decisions into artifacts agents respect across sessions.
- Responsibility Split — the broader human/agent division of labor this page instantiates for architecture.
- Architecture Erosion — what accumulates when one-way doors get walked through silently.
- Control Techniques — plan mode, stop conditions, and other mechanisms that enforce propose-before-execute.