The distributed systems literature names a specific failure mode: a node that doesn’t simply go silent but instead sends contradictory signals to different parts of the system simultaneously. Leslie Lamport called this Byzantine failure in 1982.1 Modern AI interfaces recreate this failure mode on every interaction — and practitioners currently lack vocabulary to name it.
The result: dialogue agents that observe a confirmed answer and immediately receive a message questioning that same answer, then treat the confirmed answer as authoritative. One Byzantine node. Zero detection. The compounding then begins.
The Classical Definition
In a distributed system, a Byzantine fault occurs when a component fails in an arbitrary way — not by crashing and going silent (a simple fault), but by sending conflicting information to different parts of the system. The classic illustration: a general who tells half the army to advance and the other half to retreat. Both messages arrive. Both receivers act on their own message. The army destroys itself through internally consistent but mutually contradictory action.
Byzantine fault tolerance (BFT) describes a system’s capacity to continue operating correctly despite one or more Byzantine nodes. BFT requires that the honest nodes detect the contradiction and achieve consensus without relying on the faulty node’s output.
The key insight: a Byzantine node makes a simple-fault detector useless. Checking “did the node respond?” returns true. Checking “did the node respond with valid data?” also returns true — the data looks valid. The fault only surfaces through cross-referencing multiple signals.
The Interface as Byzantine Node
Modern AI dialogue interfaces contain a structural Byzantine fault: the UI input layer and the user’s cognitive state constitute separate channels that can transmit contradictory information simultaneously.
User's cognitive state: "I don't understand option A"
↓ (UI click event)
Tool result to agent: answer = "Option A selected"
Agent receives:
Channel 1 (tool result): confirmed → Option A
Channel 2 (prose): "what does Option A mean?"
Byzantine signal pair: {confirmed, questioning the same thing}The UI click arrives as a structured, typed, high-confidence signal — a JSON response from a formal tool call. The prose arrives as an unstructured, ambiguous natural-language message. Most agents treat the tool result as the ground truth and the prose as commentary. This ordering produces systematic errors.
The UI can register a click in the same moment the user types a clarifying question — the two signals reflect genuinely different states of knowledge. The click reflects the visual scanning state (“I think that option might apply”). The prose reflects the semantic processing state (“I don’t actually understand what that option means”). Both signals arrive, apparently simultaneously, from one source. Byzantine.
The Failure Instance That Named This Trigger
During the development of observatory.unratified.org, the cognitive architecture’s AskUserQuestion tool returned this response for a site configuration question:
Question: "What should observatory.ratified.org be?"
Answer: "Alias of current site" ← tool result, structured, high-confidenceThe user’s next message, arriving in the same turn: “sorry, ask me that again, what do you mean alias of current site?”
The agent took the tool result as authoritative. It reformulated the question with new wording — treating the confirmed answer as a revealed preference and the follow-up as a request for a better question. This compounded the confusion: two rounds of question-reformulation without explaining what “alias” meant. The user had to interrupt twice.
The correct behavior: detect the contradiction (confirmed + questioned = Byzantine pair), discard the tool result, explain “alias” in plain prose, and only re-ask if still needed.
The Detection Protocol: T13
This failure pattern now has a named trigger in the cognitive architecture — T13, Byzantine Signal Detection. (Note: trigger numbering reflects the cognitive architecture’s internal registry as of March 2026; numbers may shift as new triggers emerge or get reorganized.)
When two signals in the same or adjacent turns contradict each other:
1. DETECT Identify the Byzantine pair:
tool-result ↔ prose, confirm ↔ question, yes ↔ doubt
2. DISCARD The tool result loses quorum.
A UI click ≠ comprehension.
3. RESOLVE Explain the ambiguous concept in plain prose.
Do not reformulate the question with different wording.
Reformulation without resolution compounds confusion.
4. RE-ASK Only if still needed after prose resolution.
QUORUM RULE: When two signals conflict, act on neither until
the contradiction resolves through a separate channel.The quorum rule borrows directly from BFT consensus algorithms: when you can’t determine which node tells the truth, you don’t act on either — you wait for a tiebreaker. In human-AI dialogue, the tiebreaker always takes the form of natural-language resolution.
Where This Pattern Appears
The Byzantine signal pair in dialogue doesn’t limit itself to formal tool interactions. Three common manifestations:
| Signal 1 | Signal 2 | Contradiction type |
|---|---|---|
| Tool answer: “Option A” | Prose: “what did you mean by A?” | Confirm + question same option |
| ”Yes, proceed" | "Wait, I’m not sure about X” | Confirm + immediate doubt |
| ”That looks right" | "Actually hold on” | Approval + retraction |
| Silence after presentation | ”Sorry, I missed that” | Implied agreement + explicit non-receipt |
In each case, the correct response follows the same protocol: detect the pair, resolve through prose, re-ask only if necessary.
The pattern also appears in multi-agent systems where one agent confirms a subtask and a monitoring agent raises a flag about the same subtask in the same cycle. Classic Byzantine: two agents reporting contradictory states about a node neither can directly inspect.
Related HCI Concepts
The Byzantine signal pattern described here intersects with established HCI concepts. Mode confusion (Sarter & Woods, 1995) describes situations where the user’s mental model of system state diverges from actual system state — a related but distinct failure where the contradiction exists between user and system rather than between two user-generated signals. Grounding failure (Clark & Brennan, 1991) describes breakdowns in the mutual belief that communication has succeeded — the Byzantine pair represents a specific subtype where grounding fails because two channels transmit contradictory evidence of comprehension simultaneously. T13 addresses the intersection: a grounding failure that manifests as mode confusion, detectable through signal contradiction rather than silence.
What This Does Not Cover
T13 doesn’t fire on every case of follow-up clarification. If a user answers a question and then asks a related but distinct question, no Byzantine pair exists — the tool result remains valid, and the new question addresses different scope. The trigger requires genuine contradiction: the follow-up message calls into question the same thing the tool result confirmed.
It also doesn’t require malice or error on the user’s part. Byzantine faults don’t imply bad actors. The user’s click and the user’s “what do you mean?” both represent accurate internal states — just from different cognitive layers operating at different speeds. The interface conflates them into a single turn. The agent’s job involves disentangling them.
Caveats
Detection doesn’t always proceed cleanly. The boundary between “questions the same answer” and “asks a related follow-up” can blur. T13 requires judgment about whether the follow-up genuinely contradicts or merely extends. A false positive (treating valid answers as Byzantine) creates unnecessary friction; a false negative (treating Byzantine pairs as valid answers) perpetuates the original failure. The trigger calibrates toward false positives — friction costs less than compounded confusion.
Prose resolution doesn’t always succeed. If the user remains confused after explanation, the re-ask path eventually activates anyway. T13 doesn’t eliminate re-asking; it prevents reformulation without resolution — the specific failure mode where the agent keeps asking the same question in different words without addressing the underlying confusion.
The tool result sometimes proved correct. Occasionally a user clicks an option, types a clarifying question, reads the answer, and realizes the original click actually matched their intent. T13’s discard step means the agent re-confirms via prose rather than proceeding on the tool result — a small cost when the original answer held.
This analysis generalizes beyond AskUserQuestion. The underlying pattern applies to any structured input channel paired with an unstructured clarification channel operating in the same turn window.
Vocabulary
| Term | What it triggers |
|---|---|
| Byzantine fault | A node failing by sending contradictory signals simultaneously, not by silent crash |
| Byzantine pair | Two signals in the same turn that contradict each other |
| Quorum rule | Act on neither contradictory signal until prose resolution achieves tiebreak |
| T13 | The cognitive trigger that fires on detected Byzantine pairs |
| Reformulation without resolution | Re-asking a question in different words without addressing the underlying confusion — the failure mode T13 prevents |
Claude Code drafted this post; the author reviewed it.
Sources
- Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 4(3), 382–401.
- Sarter, N. B., & Woods, D. D. (1995). How in the World Did We Ever Get into That Mode? Mode Error and Awareness in Supervisory Control. Human Factors, 37(1), 5–19.
- Clark, H. H., & Brennan, S. E. (1991). Grounding in Communication. In L. B. Resnick, J. M. Levine, & S. D. Teasdale (Eds.), Perspectives on Socially Shared Cognition (pp. 127–149). APA.
Footnotes
-
Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 4(3), 382–401. ↩