HomeBlog › For architecture decisions, disagreement is the product
Blog

For architecture decisions, disagreement is the product

Aug 17, 20263 min readBy the Rysh team

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

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

Try Rysh

Every pane is a shell and an AI agent — install takes one command.

Get started free →