One of my earlier predictions from a lifetime ago (six months) was that AI will require a re-thinking of Coase’s theory of the firm. Economist Ronald Coase’s question in The Nature of the Firm, which he wrote in 1937, was:
“Why do firms exist when markets are capable of coordinating economic activity through prices?
His answer was that market transactions themselves have costs. Someone has to discover accurate prices, identify counterparties, negotiate contracts, monitor performance, and continually renegotiate arrangements as circumstances change. At some point, instead of negotiating every single transaction, it becomes cheaper to bring a set of activities under a single organization, where a manager can direct resources without negotiating a new market contract for every task.
It is almost 90 years since then. And the question today is: if you and I have AI agents that can co-ordinate with each other and other agents to accurately price our goods and services, why should firms exist at all? If artificial intelligence reduces the cost of finding information, writing code, drafting contracts, monitoring activity, and assigning work – all of the things that in theory, the firm exists to collectivize – then it should reduce transaction costs. The boundaries of firms should become more porous. We should have fewer managers. Small teams should be able to coordinate capacities themselves. Activities once internalized by companies could be negotiated with the market by agents. The firm might begin to dissolve into a network of transactions, all managed by agents. All of us would be liberated from the perceived tyranny of (middle) management.
Some of this is clearly already happening. It is considerably easier to ask an agent to negotiate a refund, research a purchase, produce a small app, or perform a sequence of administrative tasks. Twitter is chock full of people talking about how they got their AI agent to get them a refund or more credit card points. But inside actual organizations the effect is much less clean. A firm in which everyone can generate software (and writing) probably experiences more coordination overhead rather than less. Even seasoned AI promoters like the CEO of Shopify, Tobi Lutke, have started talking about people in organizations becoming slop grenades.
Many have been discussing the paradox of AI not yet showing up in productivity statistics. Here, a related question is warranted: why are decreased AI-driven transaction costs not impacting firms as we might expect them to?
To understand what’s happening, we should go back to Coase’s original thesis about what makes firms necessary and some pre-history of how “management” became a job.
From transaction costs to managerial coordination
The boundary of the firm can be defined as the point at which it makes sense to negotiate with the market instead of completing the work in-house. For example, you might be a small team that needs a brand redesign completed in time for your product launch. It does not make sense to hire a full-time brand designer because you don't have enough work to keep them occupied, so you go to the market to hire someone on contract or vet several brand design firms.
You will likely put more work into coordinating with a third party than you would with someone in-house. But if you account for your own hourly rate and compare the cost of coordination with the cost of hiring and retaining someone long-term (which are very high), it adds up, or theoretically it should. Like with all activities that require co-ordination, the information you have is lossy and asymmetrical, which makes the boundary porous. Maybe you discover six months down the line that an in-house brand designer makes sense, or the design firm is world class but will only deliver your new brand identity in six months.
In spite of the porousness of the boundary, we can say that it is determined by the comparative costs of two forms of coordination. On one side is coordination through contracts and prices, and on the other is coordination through administration. Firms form when administration, despite it carrying its own costs, leads to more value than raw coordination through contracts and prices.
Coase’s idea is that firms solve for transaction costs by moving activity inside the boundary of the firm. But, once activities have been moved inside the firm, how are they actually coordinated? Alfred Chandler attempts to answer this in his book The Visible Hand (1980). According to Chandler, who is a technical historian, prior to 1840, U.S. business mostly consisted of regional small merchants who managed their own firms, making high margins on a low volume of highly diverse items – the canonical example being the local store that could carry everything from tea to matchboxes. There was some specialization that had happened in accounting and other aspects, but by and large – since volume was so low – firms needed to sell everything under the sun that their local population could conceivably desire. What changed things was the introduction of railroads.
Railroads present a crisp version of the co-ordination problem. Each new railroad company was faced with a dilemma: should we build our own set of tracks? Or try to share them with other companies? If a railroad had a number of parallel tracks and ran a few trains on each, then you would not have needed a lot of managerial co-ordination. But, adding a bunch of parallel tracks that will each not be used very intensely was inefficient and extremely expensive. So, the railway companies converged on instead sharing single tracks among them. The problem with that, though, was that sharing single tracks can be dangerous without high safety standards and a lot of co-ordination between stations. This is where managers come in. Hiring managers was an efficiency-thoroughness trade off, where cost was kept low through single tracks and thoroughness was ensured by hiring a large number of people to make sure trains run on time and don't run into each other.
The result of this decision was the appearance in the 1850s of a new phenomenon, the managerial firm, in which managers supervised not only workers but also other layers of managers (middle management).
These managers soon developed many of the basic tools essential for modern management. In 1857, the Pennsylvania Railroad developed the line-and-staff organization. In this structure, line managers and superintendents had direct authority over day-to-day operations, while staff specialists in fields such as engineering and accounting provided technical expertise, advice, and administrative support. Most of the techniques of modern accounting beyond double-entry bookkeeping were invented in the period between 1850 and 1870.
Other factors such as increasing competition between the firms led to the expansion of the managerial class. For example, once freight movement through rail became popular, it became more important for firms to co-ordinate with each other to ensure that goods traveling lines serviced by different railroads actually made it to their final destination without being held up. This required a huge overhead of clerks† stationed in various locations, checking in on things for their respective firms.
Railroads also played a more extended role in Chandler’s early history of management. Since they were the biggest and most successful companies of their time, railroad companies’ new organization methods became models for other industries, and institutions created to support railroads such as the modern stock market, later served other firms as well.
Secondly, and perhaps more important as an analogy for our current times, railroads (along with the introduction of the telegraph) were the piece of enabling technology that created the mass market American firm. With reliable transportation and communication networks you could now sell and send anything anywhere. In New and Improved: The Story of Mass Marketing in America, Richard S. Tedlow describes this as the distinctly American economic innovation: selling a massive volume of products at very low margins. The poster child of this trend in the early 1900s was Sears, Roebuck and their mail order catalogue†; it won’t surprise you that Richard Sears worked as both a telegraph operator and a railway station agent before he started the watch selling business that would become Sears, Roebuck in the late 1880’s.
Sears and its main competitor Montgomery Ward, along with early mass-market pioneers like Coke/Pepsi, A&P, and Ford/GM, were the largest businesses the world had ever seen. And the world’s largest businesses required the world’s largest and most complex managerial classes.
Integration and the architecture of complexity
Railroads were followed by other technologies that reduced the practical distance between organizations such as the telegraph, telephone, radio, and eventually computers. If every increase in communication speed had simply required another layer of managers to absorb the resulting coordination burden, the modern economy would have ended up buried under a Kafkaesque bureaucracy. Some parts of it arguably did. But another way of handling complexity was to make components of a firm more decomposable.
In The Architecture of Complexity, Herbert Simon argues that complex systems remain manageable because they are nearly decomposable. Their parts are not independent, but instead organized into subsystems: interactions within a subsystem are much more frequent and consequential than interactions between subsystems. A department – like supply chain, or marketing – can therefore do most of its work without constantly consulting every other department, or a component in a machine can be changed without redesigning the entire machine. In Simon’s terms, the system works because most activity is local, while interactions between subsystems are comparatively limited.
That means the boundary between modules matters enormously. A nearly decomposable system needs some way for its subsystems to communicate without exposing all of their internal complexity to one another. The interface specifies what has to cross the boundary while allowing everything behind it to remain relatively autonomous. We are now very familiar with a software version of this argument through the popularization of APIs (and now MCPs) that provide interfaces into other systems and apps. Jeff Bezos explicitly merged these two conceptions in 2002 with his motivating mandate for what became AWS, “paraphrased” here by Steve Yegge:
1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn't do this will be fired.
The mandate’s job was to force each team to conceive of themselves, anthropomorphized via the data infrastructure they provided internally, as a literal software interface. This is the extreme of decomposability, to be sure, but when done right it dramatically reduces integration costs by limiting both the amount and the kind of information that has to move between subsystems.
To continue on the railroad analogy used by Chandler, we can look at containerization in the shipping industry to understand what happens when we create nearly decomposable interfaces between systems.
As Marc Levinson describes in The Box, conventional freight moved as breakbulk cargo. Barrels, sacks, crates, machinery, bundles of lumber, and other goods arrived at the waterfront separately. Longshoremen had to handle them piece by piece: move them from truck or warehouse to the pier, sort them, check them against manifests, lift them into the ship, and find an appropriate place to stow each item in the hold. At the destination, essentially the same process happened in reverse. Ships could spend days or even weeks in port, and the physical handoff between land and sea transportation was expensive, slow, prone to theft and damage, and dependent on large amounts of local knowledge and labor. Contemporary estimates cited in discussions of Levinson’s account put port activity at a majority of the total cost of sea transport in the late 1950s.
The inefficiency of idiosyncratic storage and handling was concentrated at the boundary between systems. Trucks themselves were good at moving goods over roads, ships themselves were good at moving them over oceans, but transferring cargo between the two required opening up the contents of one transportation system and reconstructing them inside another. Every shipment arrived at the boundary in a different form.
The shipping container changed that relationship. Instead of making the trucker, port, ship, railroad, and warehouse coordinate around the particular contents of every shipment, they could coordinate around a standardized box. Cargo could be packed once near its origin and then moved as a single unit from truck to ship to rail and back again. Cranes could lift the same standardized object regardless of what was inside it. The internal organization of the cargo became largely irrelevant to the next transportation subsystem. What mattered were the container’s specifications.
This produced enormous savings in loading time and port labor. One account drawing on Levinson contrasts breakbulk loading costs of $5.86 per ton in 1956 with roughly sixteen cents per ton for containerized loading. And downstream of that, ships no longer had to spend much of their useful life sitting in port while thousands of individual objects were reconciled between transportation systems.
The container therefore embedded an interface into the physical infrastructure of trade. In Simon’s terms, containerization made freight transportation more nearly decomposable. It reduced the information that had to cross the boundary between transportation systems by making that boundary more rigid and predictable. Complexity did not disappear; much of it moved to either side of the interface.
This also changed the organizational possibilities available to firms. Chandler’s railroads had responded to coordination problems largely by bringing activities under common managerial control. Containerization showed that another solution was possible: standardize the interface strongly enough and the modules on either side of it can remain organizationally separate. Integration can be achieved through architecture rather than hierarchy.
All of this thinking gives us a more precise version of the Coasean problem. The firm exists partly because certain transactions are cheaper to coordinate internally, but internalization generates its own integration costs. Firms can manage those costs through managerial hierarchy, as Chandler showed, or reduce them by decomposing activity into modules connected by stable interfaces. The better those interfaces become, the more autonomy each module can sustain without forcing the rest of the system to understand how it works†.
Open source and the partial disappearance of management
We’ve seen that decomposability can reduce integration costs, which has major ramifications. What happens when we have technologies that can reduce integration costs even further?
Yochai Benkler’s Coase’s Penguin begins from an apparent anomaly in Coase’s two-part world of markets and firms. Open Source projects such as Linux coordinate enormous amounts of productive activity without relying (primarily) on either prices or managerial commands. Contributors choose their own tasks, often without employment contracts or a centralized assignment.
Benkler argues that networked production can outperform both markets and firms under certain conditions:
- Work must be sufficiently modular (and hence decomposable) that people can contribute independently.
- Tasks must exist at different levels of granularity so participants can contribute different amounts of effort.
- And the cost of integrating these contributions must remain low enough that decentralized participation does not generate more coordination overhead than it saves.
Open source demonstrates that the allocation of work can be decentralized much further than the traditional firm suggests. Contributors can self-select into tasks using local knowledge about their interests, skills, and available time. You don’t really need a manager to match the right person to the right problem if there is sufficient motivation. But integration does not disappear with managerial allocation. Projects still require maintainers, interfaces, coding standards and review processes for deciding which contributions become part of the canonical project. And as Nadia Eghbal showed in her book about open source Working in Public, many of these projects struggle mightily with managerial problems.
Fred Turner and his collaborators make this point in their critique of expansive theories of peer production. Peer production may look spontaneous from the outside, but it rests on structural and cultural scaffolding. Simply put, the disappearance of a conventional boss does not imply the disappearance of hierarchy, authority, rules, or institutional design.
AI and the Jagged Coasean Frontier
How does AI fit into this equation? The answer is that AI changes the cost of work unevenly. The Coasean equation seems to hold pretty well for relatively solipsistic work. You can get agents to negotiate a refund or even create a relatively complex app.
But the trouble begins when you have to integrate what you’ve created into your organization. Right now you could probably spin up your own social media platform used exclusively by people in your organization, but figuring out why anyone would use it and how different parts of it are decomposed so that others can build on it is hard work. The work of producing a candidate solution has become easier, while the work of making that solution part of the firm has not disappeared.
This is the jagged Coasean frontier. AI reduces the cost of producing work faster than it reduces the cost of verifying and integrating that work. In some cases, those downstream costs may even increase because there are now more contributions to evaluate. Open-source maintainers dealing with large volumes of AI-generated contributions are an early example.
If AI lowers the cost of producing work, then the remaining management problem is deciding how that work gets integrated.
Some kinds of work can be made explicit enough that a system can autonomously evaluate them through rules. Other kinds still depend on interpretation. There are a few questions that may dictate which applies.
The first question is how formalized the interface is. By this I mean how much of the relevant work can be expressed in a form that a machine can act on. An API is a simple example. It describes what information a system will accept and what operations another system can request. The internal workings of both sides can remain hidden because the interaction between them has been reduced to a stable interface. MCP builds on the same logic for AI systems.
A computational expression that a machine can act on need not necessarily be as smart as an AI. We are surrounded and aided by rather “dumb” computation on a daily basis. A permission system that specifies who can perform what actions, database schemas, bitcoin transactions, procurement workflows with rules about when a purchase needs further approval, writing unit tests for software. Each of these takes some part of an organizational decision and makes it computationally legible.
The same logic appears in containerization. The shipping company, railroad, and trucking company could remain independently managed because the handoff between them had been formalized around the container. The interface constrained what had to be known about the other system. The shipping container and protocols for handling it could be seen as a set of compute instructions.
The relevant question for managers is can the conditions for a valid contribution be stated clearly enough that they can be checked computationally?
But many activities can only be partially expressed in computation. You could have a Claude skill to do developmental edits on your essay, but there will be a gap between what is expressed in the skill and your own taste.
This is where the second question comes in: where does authority over integration sit?
Some systems distribute that authority widely because the interface itself does most of the work. Others concentrate authority in a manager, editor, maintainer, or specialist because the relevant judgment remains difficult to formalize.
That gives us four broad integration regimes:
Take open source as an example. A typical OSS community will typically display low formalization, but can sit between distributed authority (communal decision making) or concentrated authority (BDFL). For more mature standards like HTTP or QUIC, there will be high formalization and distributed authority.
One modern example of high formalization and distributed authority are Forward Deployed Engineers. These are technical minded folks who are distributed across a customer base, with authority to make decisions based on the local context of the customer, but within the high formalization defined by the product or parent company. When Palantir talks about “ontology” it is talking about high formalization.
Meanwhile, a young magazine may sit in the low-formalization, concentrated-authority quadrant. The editor in chief will be the benevolent dictator by default that the magazine’s early issues are organized around until some functions and beats move into high formalization or bureaucratic production.
The high-formalization, concentrated-authority quadrant is common in financial controls and regulated processes. The rules are explicit, but a designated authority still decides whether an action is permitted. Exceptions are handled centrally. The process can be highly computational while authority remains concentrated.
The point of the matrix is that a complex organization has subsystems that are situated in different parts of this quadrant at any given time. A product team may depend heavily on taste and local judgment, while a payments system benefits from strict interfaces. The same module can also move between regimes over time, as rules get decided on and become code.
AI increases the importance of this movement because it makes generation and variation cheap: more features, more contributions, more hypotheses.
That increase in output raises a management question for each module: how much of the integration problem can be expressed computationally?
Where the answer is “a lot,” AI can support much more autonomy. Agents can operate through existing APIs, tests, schemas, and permissions. They can produce work and have much of that work evaluated without continuous managerial attention (though there’s a meaningful initial investment to codify these computational expressions).
Where the answer is “not much,” the bottleneck remains judgment and leadership. Someone still has to decide and own whether a contribution is useful, whether an exception is justified, or whether the rules themselves need to change.
This dichotomy is at the crux of what’s going on in RL right now. Everyone is working on how to verify, turning the subjective into the objective. Our version though, as it relates to management, gives the two axes a practical interpretation. Formalization measures how much of the integration problem has been made computationally explicit, while authority concentration measures how much leadership and judgment is needed.
As AI makes contribution cheaper, managers will have to make that distinction repeatedly. Which parts of a process can be turned into interfaces and protocols? Which parts still require someone to interpret the situation? And when should a module move from one regime to another?
