TL;DR—I think Byzantine Fault Tolerance (BFT) is going to cross over from being primarily of interest to distributed systems engineers and blockchain bros, into a more general architectural concern in the age of AI. It may even become commonplace in centralized systems.
In this post, I’ll attempt to concisely argue why.1
I made the connection to decentralization in another post, which I’ll link here:
Creating Trust
The problem we are facing—assuming you believe that rampant agents are roaming the internet knocking over competitors, and that this isn’t a convenient stunt to keep the hype train running until you can IPO and exit with a bag of cash—is that attacker asymmetry is increasing. Knowing what you can trust, and having some proof that you can, is crucial.
So how can we make claims about trust? Well, a bunch of ways, but it eventually comes down to “who watches the watchmen?” whether we’re talking about backups, cryptographic fingerprinting, or other types of observability and auditing.
At its root, this is about externalization of a commitment.
On Commitments
In such an environment, whatever you are watching requires data to prove whatever the core statement is that you’re looking to prove. “This service wrote this update.” “This service had its software updated.”
Whatever it might be, there’s a piece of data, an attestation or commitment, and you want to make sure that this piece of data has a guarantee of integrity.
Which is very doable, because state-machine replication, cryptographic hashing and other techniques from the blockchain space are all about externalising commitments, and then ensuring that when it is time to look them up, the record will be available—which is a function of immutability and data availability.
On (Im)mutability
There’s a second scenario where trust is important, and it isn’t cybersecurity. It’s in having faith in durability. I’ve worked in a world of trust, confidence (that is, trust over time) and immutability for years, and spent a lot of time thinking about why these things are important, and why they’re useful.
I may be a thickie, but even I can see that the more agents you deploy, the more you need to know what they’re “thinking,” when and why, but crucially, the more they need to agree on what the state of the world is—and they need to do that in a repeatable, trustable way.
In other words, they could benefit from a shared, immutable record of what happened in the past.
Of course they’re non-deterministic, so I’m not talking about convergence, I’m talking about coordination in a more agentic, game-theoretic type way.
If you’re thinking, “I’m sure this logic problem has a name,” you’d be right—it’s strikingly similar to some well-studied games, and the Byzantine Generals Problem.
So, Why BFT?
It’s pretty simple. Any situation with a situation that looks like the prisoner’s dilemma can have its incentives changed by BFT. Add a blockchain on top and the game goes from a single-shot game to a repeated game, changing the incentives again.
Moreover, as the name implies, any situation that is the Byzantine Generals Problem is obviously addressable by BFT.
If you devise a crafty enough architecture, using cryptography and locality, you can prevent opportunism to a great extent, but it’s hard to do so without abandoning state-machine replication.
At some point, trading off replication requires centralizing trust. The reason centralizing trust is not really an issue in many systems, is that decentralization is often performative—so called ‘decentralization theatre.’2
If your goal is externalising commitments to a transaction, that is doable without global state, but it’s a complicated enough question that I’ve been working on it for three years, and people have been actively researching this since the eighties.3
These kinds of situations, with semi-adversarial or anonymous agents in one-shot games, come up all the time online.
Blockchains attempted to solve this in two ways. By identifying agents, and by making a ‘permanent record’4 of history, they attempt to make opportunism harder by pushing the game state closer to a repeated game.
Repeated games have different dynamics. Additionally, consensus protocols push the game very explicitly toward being a coordination game.5
The way they protect their shared view of the world is through technical and governance means,6 but the long and short of it is this—they’re trying to turn a single-shot prisoner’s dilemma into a coordination game. Ideally, a repeated one, with the blockchain providing the memory of the game state.
AI What Now?
AI agents are strictly opportunistic. Or, at least, it’s sort of impossible to reason with a straight face that they aren’t. A user might suggest they play nice, but they’re big balls of guessing machine attempting to brute force a solution, and the evidence so far is they play nice until they see a loophole.7
Alignment is obviously a Hard Problem, and maybe it’s solvable to an acceptable degree of certainty. However, if it wasn’t inherently complex (and probably unknowable) then I don’t imagine we’d have so many AI experts foretelling the end of the world.
Still, back to managing agents.
In this world, I see a handful of major uses for blockchains. None are earth-shattering, and I know from personal experience that some people have been working on this stuff since 2022 or earlier, so I’m not claiming to be ahead of the curve.
Auditing
Integrity of internal systems and processes
Data integrity of databases
“Memory” for swarms of agents
BFT all the things!
Let’s dig into these a bit. For all that I’ve already written in this post about incentives and alignment, which is more in-line with categories 1-3, I should probably say up-front that (4) I think is the most interesting of these, but there’s value in all of them.
1, 2, and 3 are all useful both in the context where you have concerns about agents from without (taking a cybersecurity focus) and from within (taking a coordination focus).
In a sense, 1 isn’t really a use-case at all; in any world where you have a blockchain and somebody in your org can interpret the data, hashes, attestations, commitments, or whatever else is being written, then you have auditing as a built-in freebie. It’s just what a ledger does, by definition.
On to ‘memory,’ then.
At the moment, from markdown files, to beads, to dedicated databases, there are lots of clever and not-so-clever solutions being thrown at the problem of agent persistence. Although persistence has a lifecycle element, there’s also a sense in which unless you plan on running agents forever—a costly proposition, then ‘memory’ is a reasonable approximation for persistence.
Indeed, persistence is one of the four key properties of sovereign AI discussed in this preprint (Qu et al., 2026), and the crossover between that and the concerns and goals of decentralization is something I addressed in my last post.
The authors specifically talk about distributed persistence, which is categorically different from just persistence—and it’s the precise problem domain in which blockchains excel.
As for (5), well, it’s how BFT can guarantee liveness in the face of adversarial action, as I said in the post on decentralization:
Minimal decentralization must be analysed in every category and at every level [of the system], otherwise the MDT is failed, and we can judge that a network is at immediate risk of takeover or halt. It’s a very minimal state, a low bar.
…in the AI case, the sword is double-edged; there is one takeover, where an entity turns the AI agents off, yes, but there is another—where the AI agents themselves take over. In both cases, the system got subverted and taken over.
No doubt there are many novel trust issues between orgs and their agents that we might imagine in the coming years. Some of these would have sounded like sci-fi until recently, but now, all bets are off.
Returning to Qu et al., let’s look at those four properties of a sovereign agent (note, that I think this could apply to any agent in the game theory sense, not just AI ones):
Operational independence
Resource autonomy
Persistence
Adaptive capability
They then offer three mechanisms to realize this sovereignty:
Economic self-sustainment
Distributed persistence
Adaptive self-modification
Let’s leave out the adaptive self-modification for a moment (although, I’d say that sounds a lot like what we’ve seen in our work on the governance domain of socio-technical systems).
What’s left sounds an awful lot like the problem domain of a Byzantine Fault-Tolerant blockchain or ledger. That does also imply that all the problems we discovered with running BFT blockchains apply too, so throwing BFT at a problem may not be a silver bullet.
If we were designing some kind of permissionless, blockchain system, we’d need to carefully decide on what the balance should be between centralization and decentralization to make the governance of the system efficient and cost-effective.
However, if we’re looking at agent coordination within the context of a single organisation, then that might not matter, because our coordination cost is effectively that of a centralized entity. Thus BFT is essentially taking the place of any other coordination algorithm, like Raft, or a piece of internal tech like Apache Kafka.
Wrap Up
Final thought to re-iterate, before I wrap up: though Qu et al., are thinking about agents in terms of their sovereignty, their general framework applies to analysing systemic robustness just as I discussed in my decentralization post.
That is, it’s a double-edged sword.
The implication is, unless you want ungoverned, fully sovereign agents, any system needs to be robust from both the LLM agents’ perspective—they need enough agency to operate—but also from the perspective of the operator.
Wish me luck.
This tension is at the heart of my research work.
Naturally I have to shill our preprint here, to be presented at BCCA 26 in November.
Okay, in certain situations it is the case that the game might be a Stag hunt, which results in defections, but that’s the subject of a pretty complicated paper I’m currently working on, and is well outside of the scope of this article. In some situations, defecting, or even just turning off, represents the Rabbit, or small reward, and so incentives should be aligned to push towards coordination more generally than just attaining a single prize—the Stag.
As I have argued, via a network’s network topology (technical affordances) and governance topology (governance of the protocol).
Or at least, they exploit an available loophole if the engineers at the AI company decide to let the models “operat[e] under reduced safeguards” as per the link above.