Why big systems, like big animals, slow down (and cities don't). Companies scale like organisms: they slow and die. Cities scale like ideas: they speed up. Your architecture is quietly choosing which.
A mouse's heart beats about 600 times a minute. An elephant's beats about 30. The mouse lives two years in a blur and dies; the elephant lives seventy years in slow, deliberate time. And here is the fact that should stop you cold: across the mammals, from shrew to blue whale, the number of heartbeats in a life comes out roughly the same, somewhere around a billion and a half. Size doesn't buy you more heartbeats. It just makes you spend them slower.
This isn't poetry; it's one of the most precise laws in biology, and it has been quietly governing your software platform the whole time. Because the same mathematics that makes a big animal slow also makes a big system slow: the deploy that took ten minutes now takes ninety, the change that took a day now takes a sprint, the org that shipped weekly now ships, with great ceremony, once a quarter. Your platform grew up, and somewhere along the way it got an elephant's heart.
The interesting part, the part worth an essay, is that one kind of large thing in the universe refuses to slow down as it grows. It speeds up. It is the city. And whether your architecture ends up an elephant or a city is not luck. It's a design decision you are making right now, probably without knowing it.
In 1932 the Swiss biologist Max Kleiber noticed that an animal's metabolic rate doesn't keep pace with its size. Double an animal's mass and it burns nowhere near double the energy; it burns about 68% more. Written as a power law, metabolic rate scales with body mass raised to the three-quarters power. It's sublinear: bigger animals are more energy-efficient per gram, a genuine economy of scale that holds across roughly 27 orders of magnitude of mass, from microbes to whales, and reaches into plants besides. Kleiber's Law is one of the great regularities of the living world.
The efficiency comes with a tax, and the tax is time. The same quarter-power math that makes metabolism sublinear makes the pace of life slow down: heart rate falls as mass to the minus-one-quarter, lifespan rises as mass to the plus-one-quarter, and the two cancel into that eerie near-constant of a billion-and-a-half beats. Bigger means slower, not more.
In 1997, the physicist Geoffrey West, with biologists James Brown and Brian Enquist, published a model in Science for why the exponent is three-quarters, and their answer is the load-bearing idea of this whole essay. The slowdown, they argued, doesn't live in the cells. It lives in the network that supplies them: the fractal, branching, space-filling plumbing of arteries to capillaries, trunk to twig, that every large organism needs to get resources to its parts. As the body grows, that distribution network's geometry imposes the three-quarters law. The parts could go faster. The network between them is what slows everything down.
(One honest footnote, because the science deserves it: the three-quarters value is empirically rock-solid, but West, Brown, and Enquist's explanation of it is still argued over; there's a decades-long debate between three-quarters and two-thirds and several competing models. Treat WBE as the leading account, not the closed case. What's not in doubt is the phenomenon: big things, built on hierarchical supply networks, slow down.)
Now hold that law up against a city, and watch it shatter.
In 2007, West teamed with Luís Bettencourt and others and ran the numbers on cities the way Kleiber ran them on animals. The infrastructure behaved itself: roads, cables, water and gas lines all scaled sublinearly, around the 0.85 power, the same economy-of-scale story as biology, a city twice the size needs less than twice the pavement. So far, so animal.
But the socioeconomic output did the opposite. Wages, GDP, patents, the raw rate of invention, all of it scaled superlinearly, at roughly the 1.15 power. Double a city's population and you get more than double its economic output and its innovation, per person. Cities don't just avoid the slowdown; they accelerate. People literally walk faster in bigger cities. The pace of life speeds up exactly where biology says it should crawl.
Where does the extra 0.15 come from? Connection. A city is a machine for producing human interaction, and interactions scale faster than people do: more residents means disproportionately more encounters, exchanges, collaborations, and collisions of ideas. The superlinear term is social connectivity, the very thing an animal's hierarchical plumbing doesn't have. An elephant is one body fed by one branching tree of vessels. A city is millions of agents wired into a dense, redundant, decentralized web with no central pump at all. Same problem (distribute resources across a growing whole), opposite network, opposite destiny.
Here is where West, in his 2017 book Scale, turns the knife, and where this stops being a nature documentary and starts being about you.
He applied the same analysis to companies. And companies, it turns out, do not scale like cities. They scale like organisms, sublinearly. They slow down. They ossify. And, this is the part that lands, they die, on mortality curves that look unnervingly like the survival curves of living things. Cities are effectively immortal; you can name ones that have outlasted every company and most nations. Companies have a half-life.
The reason is structural, and West names it precisely. Cities stay superlinear because they are decentralized, redundant, bottom-up; nobody runs a city the way a CEO runs a firm; it's many overlapping networks with no single throat to choke. Companies, chasing efficiency, do the opposite: they centralize, they hierarchize, they optimize. And in optimizing away redundancy and "waste," they slowly strangle the messy connectivity that produced the superlinear innovation term in the first place. The metabolism, the overhead of simply keeping the organization alive and coordinated, grows until it crowds the creativity out. The company becomes an animal: efficient, hierarchical, and slowing toward death.
If that doesn't sound exactly like a software organization to you, you have been luckier than most.
Software has known about this slowdown for fifty years; we just never connected it to the mouse and the elephant.
In 1975 Fred Brooks, who had run IBM's giant OS/360 project, wrote the line that became a law: adding manpower to a late software project makes it later. The mechanism is pure network geometry. Work doesn't grow with headcount; coordination does, and coordination grows roughly as the square of the number of people, because the communication paths between n people number n(n−1)/2. Ten people have 45 channels to keep coherent; fifty people have 1,225. The useful output grows sublinearly while the coordination tax grows superlinearly, and at some size the tax eats the gains. That is Kleiber's slowdown, wearing a hoodie.
It gets worse for us than for elephants, actually. The consultant Allan Kelly makes the uncomfortable case that software exhibits dis-economies of scale, the reverse of physical manufacturing, where bigger usually means cheaper per unit. In software, bigger means more expensive per unit: a fix in a million-line codebase can be more than ten times harder than the same fix in a hundred-thousand-line one, and a tight team of five routinely out-produces a sprawling team of fifty on a per-head basis. We don't just fail to get cheaper as we grow. We get actively worse.
And microservices, the architecture we reached for precisely to escape the slowing monolith, are the metabolic problem made literal. We took the function calls that used to happen inside one process, free and instant, and turned them into network calls across a distribution network: serialization, latency, retries, the fan-out effect where one rare slow service makes the typical request slow (the "tail at scale" Jeff Dean and Luiz Barroso documented at Google in 2013). Do it well and you decouple teams. Do it badly and you build the dreaded distributed monolith: all the network cost of being distributed, none of the decoupling benefit. That is the worst animal of all: it pays the elephant's transport tax and the dying company's coordination tax, and collects none of the city's upside.
The slowdown, in every one of these cases, was never in the services. It was always in the network between them.
Which is also, finally, the good news, because the WBE insight cuts both ways. If the network geometry sets the exponent, then the network geometry is a lever. The difference between three-quarters and 1.15 is not fate; it's architecture. And we have proof software can reach the city regime: studies of open-source projects have found some of them scaling superlinearly, decentralized, modular, densely-connected strangers producing more than the sum of their parts, the literal opposite of Brooks's curse. The paper has a wonderful title, "Aristotle vs. Ringelmann," and Aristotle, the whole-is-greater-than-the-sum man, wins.
So how do you build the city and not the corpse-in-waiting? Three moves, all of them about the network rather than the nodes.
Drive down the cost of every interaction. This is the entire engineering case for loose coupling, clean API contracts, asynchronous boundaries, and genuinely independent services. You are not "following best practices"; you are lowering the per-edge cost of your communication network so that the n2 term stays cheap enough not to dominate. Conway's Law from 1968 is the same point from the org side: your architecture will mirror your communication structure, so design the communication structure on purpose.
Maximize the beneficial connectivity. Cheap connection alone gives you a quiet city; a great one also has dense, productive exchange. Shared platforms, reusable internal services, paved roads that make the right thing the easy thing: these are the superlinear social term, the reuse and idea-density that make adding a team multiply output instead of merely adding to it.
Refuse the efficiency death-trap. This is the counterintuitive one, straight from West's company mortality curves: do not optimize away all your redundancy and slack in the name of efficiency. The centralizing, hierarchizing instinct that feels like "getting serious" is exactly what converts a city into a dying firm. Some redundancy is the resilience and the innovation headroom; an org tuned to perfect efficiency is an org tuned to slow down and die.
One caveat keeps this honest, and you should hear it clearly: I am not claiming your microservices obey a measured 0.85 power law. The three-quarters of biology and the 1.15 of cities are measured exponents from enormous datasets; the software version is the same qualitative regime, not a fitted number, sublinear slowdown when coordination cost dominates, possible superlinear returns when decentralized connectivity is cheap and rich. The biology proves the pattern is real and tells you where to look, the network, not what number to put in your capacity spreadsheet.
And there's a catch you should import along with the genius, because the urban data is brutally symmetric. The same superlinear connectivity that makes big cities innovate faster also makes them generate crime and disease faster, both scale at roughly that same 1.15. Density is not a one-way blessing; it amplifies whatever flows through it.
The systems version is exact, and it explains your worst outages. The dense, cheap connectivity that lets a city-like architecture reuse and accelerate is the same connectivity along which a single failure cascades into a blast radius: one degraded service taking down twelve that called it, the contagion propagating superlinearly through the very network that gave you your speed. Scale like a city and you inherit its genius and its crime rate. Which is why city-like systems need city-like public safety: circuit breakers, bulkheads, backpressure, redundancy, the boring resilience patterns that contain a contagion before it scales. The connectivity is the asset and the liability; the engineering is in keeping the first without the second.
So here is the practical thing to carry out of all this. Stop asking only "is my system fast?" and start asking "which way does it scale?" Watch the trend, not the snapshot: as you add services and engineers, is your output-per-person and your speed-per-change going up or down? Up means you've built something city-like and you should protect the connectivity that's doing it. Down, the far more common answer, means you're an animal, your metabolism is winning, and the fix is never "add more people" (that's literally Brooks) or "add more services" (that's the distributed monolith). The fix is in the network between the parts: make the connections cheaper, make them richer, and stop optimizing away the slack that keeps you alive.
Companies scale like animals: they slow down and die. Cities scale like ideas: they speed up and don't. Your architecture is quietly choosing which one it is, and the choice was never in the services. It was always in the network between them.
Scale like a city and you inherit its crime rate. Agent fleets need city-like public safety.
Wire many agents into a dense, decentralized web and you get the city's upside and its cascade risk: one bad output propagating superlinearly through the very connectivity that gave you speed. The boring safety layer is what keeps connectivity an asset. The Agent Trust Stack is that layer for multi-agent systems: tamper-evident provenance for what each agent actually did, portable reputation for which agents to trust, and verifiable identity, so a failure or a bad actor can be traced and contained instead of cascading unchecked through the mesh.
pip install agent-trust-stack · npm install agent-trust-stack