The costs your service imposes on others aren't in its price. Stop adjudicating the blame; assign the cost.
The war room is full, it's 2 a.m., and the shared authentication service's p99 latency has tripled. Two teams are in the room, and they are having the oldest fight in platform engineering. The dependency team points at the dashboards: "Your client is hammering us, look at this call volume." The client team points at their dashboard, which is serenely green: "Our latency is fine, our error rate is fine, we're well inside our SLO. This isn't us." And here is the thing almost no one in the room understands: they are both right, and they are both asking the wrong question. The client team's green dashboard is not evidence that they're not the problem. It is, in the most precise possible sense, the definition of the problem. And the fix they're groping toward was published in 1960, in an economics paper nobody in that room has read.
The paper is Ronald Coase's "The Problem of Social Cost," the most-cited article in the history of law and economics, the work that won him the 1991 Nobel. And it, together with the older idea of an externality, dissolves the 2 a.m. blame-fight completely: by showing that "whose fault is it?" is not a step toward the solution. It's the un-internalized cost wearing the costume of a moral dispute.
Start with the structure, because naming it does real work. A negative externality is a cost of a transaction that falls on a third party who isn't part of it and isn't reflected in the price. The canonical example, from A.C. Pigou's The Economics of Welfare (1920), is pollution: a factory produces a good, sells it at a price that covers its own costs, and dumps a portion of the real cost, the soot, the poisoned river, onto everyone downstream, who never agreed to the transaction and never see a cent. The factory's books look healthy. That's not a sign the cost is absent. The cost is just somewhere else.
Here is the property that matters most, and that the war room missed: an externality is invisible by construction. It is, by definition, the cost that is not in your price: not in your books, not in your metrics, not on your dashboard. So the client team's latency looking fine is not the all-clear. It is the symptom. A green dashboard, when you are imposing a cost on someone else, is exactly what an externality looks like from the inside. The whole pathology of externalities is that the party producing the cost cannot see it, because seeing it would require the cost to be in their price, and the entire definition of the thing is that it isn't.
Once you have that lens, the noisy-neighbor problem stops being an analogy for an externality and reveals itself as a literal instance of one. This isn't a clever resemblance; it's an identity. Microsoft's own Azure Architecture Center, documenting the "Noisy Neighbor antipattern," describes it as one workload consuming "enough underlying resources to degrade performance for others", which is the textbook definition of a negative externality, transcribed into a cloud document. The chatty client imposes a latency and capacity cost on every other tenant of the shared service, and that cost is absent from the chatty client's own metrics. The cost is borne by parties not in the transaction. It is pollution, and the shared service is the river.
And, like pollution, it is structurally unavoidable rather than a moral failing. Multi-tenant systems oversubscribe by design, they assume tenants won't all peak at once, and even with quotas, contention persists at the physical layer: last-level CPU cache, PCIe lanes, and I/O queues can't be fully isolated by software. You cannot delete the externality from a resource-sharing system. You can only price it or assign it. The shared service with no chargeback is, precisely, a tragedy of the commons: Garrett Hardin's 1968 result that a shared resource with no price gets overgrazed because each user's cost is externalized onto the pool. Overgrazing isn't teams "being inconsiderate." It's the predicted equilibrium of a commons with no price. You built the incentive; the behavior followed.
The pattern, once named, is everywhere in a platform. Tech debt is an externality across time: the team shipping fast externalizes the maintenance cost onto whoever touches the code next, a third party (your future colleague) who isn't in today's transaction of moving quickly. Aggressive retries are an externality that can invert: a client that retries hard pushes its reliability cost onto its dependency, and in a retry storm that externality flips into a shared outage that takes down the very service the client depended on. And the blame-fight itself ("it's THEIR client!") is the un-internalized cost manifesting as politics. By Coase's logic, the argument over fault isn't progress toward the fix; it is the cost, un-assigned, and the meeting spent arguing is itself a transaction cost raising the price of ever fixing it.
This is where Coase detonates the war room. His 1960 paper made an argument so counterintuitive that, he later complained, it was "widely misunderstood" for decades: the cost is reciprocal. We habitually frame a nuisance as one party's fault, the factory pollutes the resident. But Coase pointed out that the conflict is symmetric. The factory harms the resident, yes. But stopping the factory harms the factory. The cost is a joint product of two activities that are incompatible in the same place; it exists only because both parties want to use the same resource. Asking "whose fault is it?" smuggles in an assumption, that one party has a prior right, that the situation hasn't actually established.
Map it onto the war room and the fight evaporates. The latency cost is not produced by the chatty client alone. It is the joint product of a client that sends a lot of traffic and a shared service that doesn't bound what any one tenant can take. Neither is "the cause" in any clean sense; the cost is reciprocal, a conflict between two legitimate interests over one shared resource. The 2 a.m. argument over which team is at fault is therefore not a path to the solution. It is the externality, un-assigned, wearing a moral costume, and the longer it runs, the more it costs.
So what does Coase say to do instead? He, and the legal scholar Guido Calabresi after him, give the answer that engineering blame-culture finds hardest to swallow: assign the fix to whoever can avoid the cost most cheaply, the least-cost avoider, regardless of fault. Not the guilty party. The cheap party. Sometimes that's the perpetrator; sometimes, startlingly, it's the victim. The question is never "who's to blame?" It is "who can make this cost go away for the least total effort?"
Out of this fall two remedies, and they map one-to-one onto what platform teams already half-do: they just don't know they're doing economics.
Fix one: price it (Pigou). Pigou's prescription for an externality was a tax equal to the cost the actor imposes on others, so the externality is internalized: it shows up in the actor's own budget, and they self-correct without being argued with. The internal version is FinOps chargeback (or its softer cousin, showback): charge each team for the shared resources it actually consumes, so the cost of hammering the shared service appears in the chatty team's budget, not just in everyone else's latency. The quiet superpower of this move is that the price does the work, not the argument. You never have to win the 2 a.m. meeting about who's right. You make the cost visible in the correct budget, and the efficient behavior follows, because now the chatty team is paying for its own externality and has every reason to stop. Pigou scales without adjudication, and the real world has the receipts: the U.S. Acid Rain Program, created by the 1990 Clean Air Act amendments, put a price on sulfur-dioxide emissions via tradable allowances and cut acid rain faster and far cheaper than command-and-control mandates had managed, precisely by letting the cost show up where the polluters could see it and act on it.
Fix two: assign the fix to the least-cost avoider (Coase). Here's the counterintuitive, high-value move. When the shared service can add one rate-limit, a token bucket, a per-tenant fair-queue, an admission-control "waiting room", more cheaply than fifty client teams can each be re-engineered to behave, then the shared service should add the rate-limit. One central fix beats N client fixes, and Coase says to do the cheap thing regardless of whose "fault" the load is. The "victim" service fixes the problem not because it's guilty but because it's the cheapest avoider. This is deeply offensive to blame-culture instinct (why should we fix their mess?) and it is usually the correct engineering decision, because the goal was never justice. It was removing the cost for the least total effort.
That, in one line, is the whole reframe: stop asking whose fault the cost is, and start asking who can remove it most cheaply, then make the cost visible to that party.
The reframe is powerful enough to be dangerous if you swallow it whole, so keep three guardrails that Coase and the practitioners insist on.
Coase is not a frictionless magic wand, and he said so first. The clean theorem requires low transaction costs and clear property rights. Coase's actual point was the opposite of "markets fix everything": he wanted to show how much transaction costs matter, because when they're high, bargaining doesn't spontaneously happen and the initial assignment of rights determines the outcome. Inside a company the conditions are mixed. Transaction costs between teams are often lower than between firms, no lawsuits, shared management, which is good news; Coasean bargaining is more feasible internally. But property rights over shared infrastructure are usually unclear ("who actually owns the latency budget of the shared auth service?"), and org politics can make transaction costs spike: that 2 a.m. blame-fight is itself a transaction cost. So internally, Coase applies but is not automatic. The practical work is to manufacture the missing preconditions: assign explicit ownership of the shared resource (a clear property right) and install a price (chargeback), before you wait for the efficient outcome to emerge. Don't wait for bargaining; engineer the conditions that let it happen.
Chargeback has its own failure modes. An internal tax priced wrong distorts as much as no tax. Teams game it: they hoard quota, route around the shared platform, or build shadow/duplicate infrastructure to dodge the charge, which just re-externalizes the cost somewhere else. Bad cost-attribution punishes the wrong team. So the rule isn't "price it and walk away"; it's "price it and watch the second-order behavior," because a Pigouvian tax creates incentives to evade the Pigouvian tax.
Least-cost-avoider is a calculation, not a bias toward central fixes. Sometimes the cheapest avoider really is the chatty client: if its behavior is pathological, an unbounded loop, a genuine bug, then no central rate-limit is as cheap as the client fixing its bug, and Coase points straight back at the client. The principle is "compute who's cheapest," not "always make the platform absorb it." Don't let "the central fix is usually cheaper" harden into "the platform always eats it."
Next time you're in that war room, change the question on the whiteboard. Cross out "Whose fault is the latency?" It's the wrong question, and answering it costs you the night. Write instead: "Who can remove this cost most cheaply, and how do we make the cost visible to them?"
Then run the two moves. Price it: get the cost out of everyone-else's-metrics and into the responsible party's budget, chargeback, showback, a per-tenant cost-attached quota, so the externality stops being invisible. (Remember: the green dashboard was never exoneration; the cost you impose is, by construction, the one not in your numbers.) And assign the fix to the least-cost avoider. Compute who can make the cost go away for the least total effort, and put the fix there, regardless of fault: often it's one central rate-limit instead of N client rewrites; sometimes it's the "victim" adapting because that's genuinely cheapest; sometimes it's the buggy client, when the bug is the cheap fix. And before any of it, do the unglamorous prerequisite work Coase demands: assign someone ownership of the shared resource and attach a price to it, because the efficient outcome doesn't emerge from a commons with no owner and no cost: it has to be engineered.
A factory's soot, a chatty client's traffic, a team's tech debt. They are the same object: a real cost, borne by someone not in the transaction, invisible in the responsible party's price. Sixty-five years ago Coase told us the way out, and it has nothing to do with blame. The question is never whose fault the cost is. It is only ever how to make that cost visible to the party who can cheapest remove it. Stop adjudicating the blame. Assign the cost.
You can't charge an agent for a cost you can't attribute to it.
An agent's externalities, the cost it pushes onto other agents and the shared system, are invisible in its own metrics by construction. To internalize them, the way Pigou and Coase say to, you first have to attribute them: which agent's action, in which step, actually caused the downstream cost? That needs a per-action record, not a green dashboard. Chain of Consciousness is that record: a tamper-evident chain of an agent's reasoning, tools, and actions, so the externalized cost stops being un-assignable and becomes something you can price to the party who can cheapest remove it.
See Hosted Chain of Consciousness · verify an action chain
pip install chain-of-consciousness · npm install chain-of-consciousness