For architecture decisions, disagreement is the product
Graph Engineering pattern 7 of 15: the Architecture Debate Graph. Proposers, an adversarial critic panel, a synthesizing decision agent, and a human who ratifies or vetoes — structure against sycophancy and premature convergence.
Ask one agent "is this design good?" and it tends to agree with you. That is not a model flaw you prompt away — it is a structural problem: advocacy and criticism living in the same node. For expensive, hard-to-reverse decisions, the fix is a topology in which disagreement is not friction. It is the product.
Context for new readers: pattern 7 of 15 in the Graph Engineering series. This is the first pattern in the series whose deliverable is a decision rather than an artifact — and decision-shaped work wants adversarial and exploratory graphs, not delegation trees.
The problem
The organization faces a consequential technical choice — a datastore, a service boundary, a migration strategy, build-vs-buy. Multiple defensible options exist. The risk is not that no answer can be found; it is that the first answer wins by default, its weaknesses discovered in production, two quarters later, at migration prices.
The topology
Proposal A Proposal B
\ /
Critic panel <==> Proposers
|
Decision Agent
|
Human
A decision brief — the question, constraints and evaluation criteria — goes to two or more proposers, each developing a distinct alternative into a full proposal: design, cost model, operational consequences, failure behavior. A critic panel engages each proposal adversarially, and the critic–proposer edge is deliberately bidirectional: critics challenge assumptions, scalability claims and cost estimates; proposers respond, revise and defend. The challenge–defense cycle runs, bounded, until the arguments stabilize. A decision agent synthesizes the surviving analysis into a recommendation with an explicit trade-off account — and a human ratifies or vetoes.
Why the human stays
For irreversible or expensive decisions, final authority remains a human's as a design principle, not a fallback. The ratification step requires the human to read the trade-off account — which is why the decision agent is required to produce one. A human who ratifies whatever is recommended has silently transferred authority; the graph should make that visible when it happens.
The record is half the value
The written outcome keeps the losing options and the reasons they lost. That record is the organization's memory: it pre-answers the "why didn't we just use X?" of two years from now, and it turns every decision into training material for the next one.
Where it breaks
- Critics without teeth. Critics that review politely produce consensus theater. Score the critic role on defects found, not on balance.
- Debate without a deadline. The challenge–defense cycle needs bounds — rounds, tokens, wall-clock. Stabilized arguments are the exit signal, not exhausted critics.
- Human as rubber stamp. See above; authority that is never exercised is nominal.
The dimension answers
| Dimension | Answer |
|---|---|
| Nodes | Proposers (≥2), critic panel, decision agent, human authority |
| Edges | Brief→proposers; proposers⇄critics; critics→decision agent→human |
| Cycles | Bounded challenge–defense rounds |
| Humans | Final authority — ratify or veto |
| Exit rule | Human ratifies; decision record written with alternatives and reasons |
Structure guarantees every alternative receives both a full-strength case for and a full-strength attack against. No single agent can give you both — not because models are weak, but because one node cannot hold both incentives at once.
Next: pattern 8, the Security Remediation Loop — a controlled cycle for work where the fix can be the next vulnerability.
Building this with design partners → rysh.ai/design-partner