In 1994, Peter Deutsch at Sun Microsystems wrote down eight assumptions that developers make about networks and that turn out to be wrong. They have been taught in every distributed systems course since, and they are still wrong in exactly the same ways, which suggests that distributed systems courses are more effective at producing exam answers than production engineers.
We run architecture audits against the fallacies as a standard part of our system design practice. In the last two years, we have started seeing LLM-backed systems that violate all eight in a single request path. Here is how.
Fallacy 1: The network is reliable
Your agent calls an LLM API. The API is, on average, reliable. But “on average” hides the tail. If your agent has no fallback behaviour — if it simply retries until timeout and then returns an error — then your system’s availability is capped by your model provider’s availability. Most teams discover this during their provider’s first significant outage, which is not a good time to design a fallback.
Fallacy 2: Latency is zero
A GPT-4 class model call takes 2-8 seconds. An agentic workflow that chains six calls takes 12-48 seconds. Your users are waiting. Your timeout is set to 30 seconds because that is what it was for your REST API, which responded in 200ms. The math does not work and nobody recalculated it.
Fallacy 3: Bandwidth is infinite
You are sending 128K tokens per request to a model that costs $15 per million input tokens. At 10,000 requests per day, that is $19,200 per month in bandwidth you are paying for by the token. The equivalent web service bandwidth cost would be approximately $4.
Fallacy 4: The network is secure
Your system sends customer data to a third-party model API. The data leaves your network, your jurisdiction, and possibly your compliance boundary. Your security team reviewed the API integration. Nobody reviewed what happens when the model is convinced by a prompt injection to include the customer data in its response to a different user’s query.
Fallacy 5: Topology doesn’t change
Your model provider deprecates the model version you tested against. Your RAG retrieval index was rebuilt with a different embedding model. Your agent’s tool API changed its response format. All of these happened last quarter and your monitoring caught none of them because it was monitoring uptime, not behaviour.
Fallacy 6: There is one administrator
Your LLM is managed by OpenAI. Your vector database is managed by Pinecone. Your embedding model is managed by Cohere. Your orchestration framework is an open-source project maintained by a team you have never met. You control none of these dependencies and you have an SLA with one of them.
Fallacy 7: Transport cost is zero
See Fallacy 3. In LLM-backed systems, the transport cost is not just network bandwidth. It is tokens, and tokens cost 10,000× more per byte than network bandwidth. Every unnecessary token in your prompt is money. Every retrieval chunk that does not improve the answer is money. This is a cost-engineering problem that did not exist in traditional distributed systems.
Fallacy 8: The network is homogeneous
You built against GPT-4. You want to switch to Claude for cost reasons. The prompt that scored 94% on your eval against GPT-4 scores 71% against Claude. The models are not interchangeable, their failure modes are different, and the fallback strategy “try another model” works about as well as “try another database” would have in 2004.
What to do about it
The fallacies are not problems to solve. They are constraints to design around. The team that assumes the LLM API will be down for two hours this quarter and designs the fallback before it happens is the team that sleeps through the outage.
We run architecture audits against all eight fallacies as part of our system design practice. If you are building an LLM-backed system and have not asked these questions, the answers are going to find you eventually. Better to find them first.