The Engineering of Intent, Chapter 38: Multi-Agent Conflict Resolution — Protocols for Agentic Tie-Breaking

This is Part 38 of a series walking through my book The Engineering of Intent. In the previous chapter, we scaled context. Chapter 38 scales governance: what happens when you have multiple specialized agents all emitting opinions on the same diff.

The Problem: Three Legitimate Agents Blocking the Same PR

In 2026, teams run fleets of specialized reviewers. A security agent scans for vulnerabilities. A performance agent scans for regressions. An accessibility agent scans for WCAG violations. A cost agent scans for cloud-spend blowups. Each has legitimate authority over its domain.

The failure mode: security asks for input validation that inflates the code path. Performance asks to remove branches to preserve a hot-loop optimization. Cost asks to batch the call, changing the latency profile performance is guarding. Three legitimate agents have produced mutually incompatible demands on one diff. The human engineer is frozen.

Chapter 38 is about not being frozen. The answer is a protocol — simple, lightweight, human-governed — for Agentic Tie-Breaking.

First, Triage. Most “Conflicts” Aren’t.

• Stacked concerns. Both changes are independently satisfiable. Not a conflict. Just do both.
• Prioritization questions. Both doable but not this sprint. Not a conflict. Scheduling is human.
• Real conflicts. Mutually exclusive on the same lines. Only these need formal resolution.

Three Resolution Protocols, Increasing Weight

1. Human as Supreme Court. Designated engineer has final say. Works when conflict volume is < two or three a week. Doesn’t scale past ~10 engineers.
2. Architect Agent as Tie-Breaker. A third agent, given architecture.md and the decision log, resolves the conflict by reference to written principles. Doesn’t make new decisions — applies already-made ones.
3. Structured Negotiation. For conflicts with no architectural precedent: bounded protocol where each agent states its constraint and its flexibility; a moderator attempts resolution; two rounds max before human escalation.

Why architecture.md Is the Constitution

All three protocols lean on a written architectural decision record. Without one, tie-breaking at scale is impossible — the agents defer to whichever engineer speaks loudest that day, and the codebase develops an incoherent grain.

A useful architecture.md is short (3–10 pages): three or four most important invariants, decision log with dates and rationales, explicit tradeoffs. For example: “Latency is prioritized over throughput for user-facing APIs; throughput over latency for batch workers; no user-facing API may block on a synchronous external call longer than 200ms.”

“Without the written invariant, every conflict becomes a fresh debate. With it, most conflicts resolve themselves. The cost of writing the architecture.md is a day. The benefit is measured in weeks saved per quarter.”

Architect Agent Design — Three Properties

• Narrow authority. “You are not a code reviewer. You are a conflict resolver. Do not introduce new critiques.” Without this narrowing, the Architect Agent adds its own opinions and you have three conflicting agents instead of two.
• Cited reasoning. Every verdict cites specific clauses of architecture.md. Unsupported verdicts are rejected and re-run.
• Transparent verdicts. Posted as a PR comment. No back-channel decisions. Losing agent sees why it lost; winning agent sees why it won; human sees both.

Next up — Chapter 39: Impressionistic Scanning — A Visual Heuristic Guide. Chapter 2 introduced shape-reading as a skill. Chapter 39 makes the tacit explicit: a catalog of visual shapes that appear in code, what each likely means, and how to respond. A cheat sheet for reviewing agent output at a glance.