Every time I read another piece about AI agents needing better identity systems, I keep thinking about a question identity doesn't answer. Say every agent in your pipeline is fully verified. Signed credential, scoped token, clean audit trail back to the human who authorized it. That tells you exactly who acted and on whose authority.It tells you nothing about whether what that agent just said is true. In a clinical triage pipeline, a legal document review, or a financial approval chain, a verified agent producing a confidently wrong answer carries more risk than an unverified one, precisely because nobody downstream has a reason to doubt it. That gap between who acted and whether to believe them is not new.Distributed systems engineers have been formalizing it since the 1980s, and a growing body of 2025-2026 research is starting to apply that formalization directly to multi-agent LLM systems, with some genuinely useful disagreements about how to actually do it.The Identity Framing Is Necessary, but It's Not the Whole PictureThe current wave of AI agent security writing, and there's a lot of it, centers on non-human identity, covering agent credentials, delegation tokens, scoped authorization, and audit trails. That work matters because knowing which agent did what and on whose authority is foundational.Identity answers who acted. It doesn't answer whether to believe what they said. A verified agent can still be wrong. It can hallucinate, get manipulated through prompt injection, or simply degrade under load. In a single-agent system, that's a reliability problem. In a multi-agent system, where agents pass outputs to each other and build on one another's conclusions, one bad node can poison the whole pipeline. That's a coordination problem, and coordination problems in distributed systems have a name: Byzantine fault tolerance.What Byzantine Fault Tolerance Actually IsByzantine fault tolerance comes out of the Byzantine Generals Problem, formalized by Lamport and colleagues in the early 1980s. The core question is how a distributed group of nodes agrees on a shared truth when some of those nodes might be faulty, compromised, or actively lying, and nobody knows which ones in advance. Classical protocols built on this problem, PBFT, HotStuff, and Tendermint among them, established the well-known constraint that a system can tolerate up to roughly a third of its nodes acting maliciously before consensus breaks down entirely.This is the same math blockchain consensus protocols run on, applied to a different kind of node failure. A hallucinating or manipulated LLM agent behaves functionally like a Byzantine node, reporting something false to its peers, sometimes confidently, sometimes with no indication anything is wrong.Researchers Are Already Building BFT Protocols for LLM AgentsMultiple research groups reached this same conclusion independently over the past year, and the papers are worth walking through because they disagree on the right fix in interesting ways.One evaluation effort worth knowing about is the AgentShield dataset, built alongside a 2026 IEEE Transactions on Dependable and Secure Computing paper. It covers 15,000 multi-agent decision scenarios split specifically across medicine, law, finance, and autonomous driving. Four attack types run through the dataset: forced hallucination, prompt injection, random perturbation, and coordinated adversarial optimization. What stands out to me is the choice to split evaluation by domain at all. A Byzantine agent in a clinical triage pipeline and one in a driving coordination task fail differently and carry different costs, and a single tolerance threshold treats them as identical problems.On the architecture side, two recent papers land in genuinely different places, and I think the disagreement is more useful than either paper alone. Trusted MultiLLMN uses a weighted, leader-based BFT protocol, where one agent coordinates and the rest vote. DecentLLMs argues leader-based designs have a specific failure mode.If consecutive leaders happen to be Byzantine, the system keeps forcing expensive re-elections, and each one costs another round of LLM inference latency. Its fix removes the leader entirely, using a geometric median across evaluator scores so no single agent's judgment can unilaterally derail the outcome. A third paper, Robust Multi-Agent LLMs under Byzantine Faults, goes further still, proposing Self-Anchored Consensus with mathematically derived robustness conditions on the communication graph itself, not just the agents sitting on it.Why the Disagreement Between These Approaches Is the Useful PartNone of these teams agree on the right architecture, and that disagreement points at the actual design question builders need to be asking. Leader-based systems are simpler to reason about but create a single point of manipulation. Fully decentralized systems remove that bottleneck but need stronger mathematical guarantees about the graph structure itself to stay robust. Neither is a drop-in answer yet.If you're building or evaluating a multi-agent pipeline right now, the identity questions- who is this agent, what is it authorized to do- are only part of the reliability story. The other part is what happens when one of your verified, authorized agents is simply wrong, and whether your system has any mechanism to catch that instead of passing the bad answer downstream.Not Every Multi-Agent Failure Is Actually ByzantineHere's where I'd push back on my own framing a little. A 2025 NeurIPS paper by Cemri and colleagues built an empirical taxonomy from over 1,600 annotated execution traces across seven popular multi-agent frameworks, and it identifies 14 distinct failure modes across three categories: system design issues, inter-agent misalignment, and task verification. Most of what they catalogued has nothing to do with an agent lying or acting maliciously. Agents misunderstand a task, terminate too early, or nobody in the pipeline actually checks the final output.Consensus protocols are built to handle a node that's actively wrong or adversarial. They don't fix a pipeline where every agent behaved honestly, but the task itself was underspecified, or where verification simply never happened. Reaching for a BFT protocol to solve a specification problem is the wrong tool for the job, even though both failures produce the same visible symptom, a wrong answer nobody caught.What This Means in PracticeA few things follow from putting these two bodies of research next to each other.Diagnose before you prescribe. If your pipeline's failures look like agents misunderstanding scope or nobody validating a final output, that's a specification and verification gap, and no consensus protocol fixes it. If failures look like a specific agent producing confidently fabricated output that others build on, that's the Byzantine-shaped problem, and it's worth reading the architecture papers above before designing your own aggregation logic from scratch.Match your consensus mechanism to your stakes, not just your architecture preferences. A leader-based protocol might be fine for low-stakes coordination. AgentShield's domain split- medical, legal, financial, and driving scenarios- is a reasonable model for thinking about where the stronger decentralized guarantees actually earn their complexity versus where simpler majority voting is enough.None of this replaces identity and authorization work, and it doesn't replace basic task specification and verification either. It sits next to both. A system can have perfect identity verification and zero fault tolerance, and it will still produce confidently wrong answers when one verified agent goes bad.ConclusionThe agent identity conversation answers who is acting. Byzantine fault tolerance research answers whether to believe what an agent said, and the failure taxonomy work answers whether the whole task was even set up to succeed. None of the protocols above are drop-in solutions yet, and not every bad output in your pipeline is actually a Byzantine one. Knowing which of these three questions you're actually asking, before you start designing a fix, will save you from bolting a consensus protocol onto a specification problem. Sort that out early, while your pipeline is still small enough to diagnose.