The Eight Fallacies of Distributed Computing, Rediscovered by Every AI Team
Peter Deutsch wrote the first version of this list at Sun Microsystems in 1994, before most of the internet existed, and James Gosling later added the eighth. Every one of the eight is a belief that a system's designer implicitly assumed was true and wasn't — not because they were careless, but because the assumption is the natural default when you're used to writing code that runs on one machine, where none of these things are variables at all. The fallacies aren't really about networks. They're about what happens when you stop noticing that your system now has a network in it.
The eight, as a checklist
Why an AI architecture blog needs this list
An agentic AI system is one of the most distributed pieces of software most teams have ever shipped, and it usually doesn't look like one, because the distribution is hidden behind an SDK call. model.generate() looks like a function call. It's actually a network request to a provider's infrastructure, possibly routed through a load balancer to a GPU cluster you don't control, subject to every fallacy on this list — and because it's wrapped in a clean client library, it's easy to write code that implicitly assumes fallacy #1 and #2 are both true, right up until a production incident proves otherwise.
The network is reliable and latency is zero are the two I see violated most often in the same breath: a chain of four sequential tool calls, each treated as instantaneous and infallible, with no retry logic and no timeout budget, because in local development against a warm cache it always just worked. In production, across a real network to a real inference provider under real load, call three of four times out, and the whole chain fails with no graceful degradation because nobody designed for the network being anything other than an implementation detail.
Bandwidth is infinite shows up as context windows stuffed with entire documents because trimming felt like premature optimization — until the token cost and the latency cost of that payload both become the actual bottleneck. The network is secure is the one I'd flag as most dangerous specifically for AI systems: a tool-calling agent that trusts the content it retrieves from a document or an API response as though it can't contain adversarial instructions is assuming a secure network in exactly the way this fallacy warns against — which is the entire premise behind prompt injection as an attack class.
Topology doesn't change and there is one administrator both show up as brittle assumptions about which model version, which endpoint, which provider is serving a given request — hardcoded assumptions that break the moment a provider reroutes traffic, deprecates a model, or an internal platform team (a different administrator than the one who built the original integration) changes an internal routing rule without telling the team that depends on it. Transport cost is zero is the unglamorous one: every hop through an orchestration layer serializes and deserializes a payload, and in a multi-agent system with several intermediate steps, that cost compounds in ways that don't show up until someone finally profiles the latency budget. The network is homogeneous is the newest-feeling one in an AI context — a system built and tested against one model provider's API shape quietly assumes every future provider will behave identically, until a second provider's slightly different streaming format or rate-limit behavior breaks an integration nobody thought was provider-specific.
The fix is the same for all eight
None of these get fixed by being more careful. They get fixed by making the network's presence explicit in the architecture instead of implicit in the code: timeouts and retries as a designed policy, not an afterthought; payload size as a reviewed decision, not whatever fit; every external response treated as untrusted input, the same discipline I've argued for around AI governance; provider and topology assumptions captured as configuration with an explicit "reassess by" date, the same pattern the Stanford AI Index piece pushed me toward for capability assumptions generally. Thirty years on, the list hasn't gotten less true. It's just gotten a new generation of engineers who have to rediscover it, one production incident at a time, because the network is still there — it's just wearing a nicer SDK now.