Exploring Options with Agents

Agents are excellent at enumerating architecture options and terrible at choosing between them, because choosing requires your constraints — team size, ops budget, actual scale — and their default is the statistically most common answer, not the right one. Used deliberately, an agent compresses a week of option research into an afternoon. Used lazily ("what architecture should I use?"), it returns a confident median Medium post.

The N-options prompt

Three rules make option exploration produce decisions instead of essays:

1. Minimum three options. With one option you get advocacy; with two you get a strawman and a favorite. Three forces the agent past its first-token instinct.
2. Forbid code. The moment an agent writes code it becomes invested in that option — every subsequent answer defends the sunk cost. Code also burns context you need for analysis.
3. Supply the evaluation criteria yourself. If you let the agent pick criteria, it picks ones its favorite option wins ("scalability, flexibility, modern best practices"). Your criteria are boring and decisive: who operates this, what it costs, what the real load is, how hard it is to undo.

Task: choose how to handle full-text search for our Django B2B app.

Constraints (treat as hard requirements, not preferences):
- Team: 3 backend engineers, no dedicated ops/SRE
- Infra: single Postgres 16 on RDS, ECS, no Kubernetes
- Scale reality: 400k documents, ~2k searches/day, growing maybe 3x/year
- Budget: no new paid services without strong justification

Produce exactly 3 options. Do NOT write any code.
For each: 3-sentence summary, then one shared tradeoff table with rows:
  operational burden | cost | fit at our actual scale | fit at 10x scale |
  reversibility (how hard to migrate away) | team familiarity required
Then: which option you'd pick for US specifically and why, in 5 lines max.
If your recommendation would differ for a 30-person team, say so explicitly.

That last line is a default-bias probe — see below.

Detecting default-bias

The agent's prior is "what do most codebases in my training data do", which skews toward well-documented, blog-heavy, big-company patterns: microservices, Kafka, Redis, Elasticsearch, React + separate API. None of that is wrong; it's just uncorrelated with your constraints. Signs you're getting the default instead of a fit:

• The recommendation would be identical if you deleted your constraints paragraph. Test it: ask "which of my stated constraints changed your recommendation, and to what?" If it can't name one, it ignored them.
• Every option requires new infrastructure. A real option space for a small team almost always includes "do it with what you already run" (e.g., Postgres FTS before Elasticsearch, pg_cron before a queue).
• Justifications cite scale you don't have ("as you grow, you'll need…"). You said 2k searches/day; it's designing for 2M.
• The tradeoff table has no losers — every cell for the recommended option reads positive. Real tradeoffs cost something.

Two pressures, one table

Agents fail in both directions, sometimes in the same proposal (a microservice architecture where each service is demo-grade inside).

Pressure	Symptoms	Why it happens	Counter-prompt
Over-engineering	Event bus for 3 internal consumers; microservices for a 4-person team; abstract factory over a single implementation; "for future flexibility" appears in the rationale	Training data over-represents big-scale architecture writing; grand designs pattern-match to "senior"	"Redesign this assuming we will NEVER exceed 10x current scale and the team stays at 4. Remove every component that only pays off beyond that."
Over-engineering	Config/plugin systems nobody asked for; premature caching layers; queues between components that could be function calls	Adding structure looks like diligence; deleting requires judgment	"For each component, state the concrete requirement it serves TODAY. Delete any component whose requirement starts with 'if' or 'when we'."
Under-engineering	SQLite "for now" in a multi-writer service; secrets in env-committed files; no migration story; auth marked TODO; single-instance assumptions baked into session handling	The demo path works, and the agent optimizes for visible completion	"This goes to production Friday and gets paged on. Walk through: deploy, rollback, secret rotation, concurrent writes, instance restart mid-request. Fix what fails."
Under-engineering	Happy-path error handling, no timeouts on external calls, unbounded queries	Failure paths don't show up in a demo, so they don't get built	Bake non-negotiables into CLAUDE.md instead of re-prompting — see Constraints and Validation

Weak vs strong exploration prompt

Weak:

What's the best architecture for a multi-tenant SaaS backend?
Should I use microservices?

You'll get: "it depends", followed by a microservices recommendation anyway, with a Kubernetes diagram and no reference to your team or budget.

Strong:

Architecture exploration — no code, no final decision yet.

Context: B2B invoicing SaaS. 2 engineers (me + one). ~40 paying tenants,
largest has 200 users. Node/TypeScript + Postgres already chosen (ADR-002).
Ops budget: whatever Heroku-tier hosting can do; nobody is on call.

Question: modular monolith vs services split, specifically whether
PDF rendering and email sending need to leave the main process.

Give 3 options min. Tradeoff table with MY criteria: ops burden for 2 people,
p95 latency impact on the API during PDF bursts, cost, reversibility.
Then recommend one and list the 2 assumptions your recommendation
is most sensitive to.

The delta: real constraints stated as facts, a narrow question instead of "best architecture", criteria the agent can't swap out, and an explicit "no decision yet" so it doesn't collapse the exploration into advocacy.

The adversarial follow-up

After any recommendation, before you accept it:

Now argue AGAINST your own recommendation as a skeptical staff engineer
who has operated this exact stack. Give the 3 strongest concrete failure
scenarios — with the triggering condition and the blast radius — where
option B or C would have been the better choice. Do not soften the
criticism, and do not conclude by re-endorsing your original pick.

Two things make this work: the ban on re-endorsing (agents love to end rebuttals with "but overall my recommendation stands"), and requiring triggering conditions — vague risks ("might not scale") are free, "when a tenant uploads a 500-page PDF, rendering blocks the event loop and every tenant's API stalls" is a decision input. If the counter-arguments are weak and generic, the recommendation is probably robust. If one lands, you just saved a migration. Feed the survivors into a proper challenge session — see Constraints and Validation — and record the outcome as an ADR so the next session doesn't reopen it.

Related

• What Not to Delegate — exploration is delegable; the final pick on one-way doors is not.
• Constraints and Validation — stress-testing the option you chose with failure-scenario prompts.
• Decision Records — writing the outcome down so future sessions inherit it.
• Architecture and Research Prompts — the wider prompt patterns behind these examples.
• Hallucination and False Confidence — why a confident recommendation deserves the same skepticism as confident code.