Over the last few years, I’ve spent hundreds of hours consolidating my work across a few foundational disciplines that have become part of The Business Engineer’s core curriculum.
Now that AI has dramatically accelerated this process, I felt it was time to launch the Foundation Series.
The Business Architect is another book in that series.
Before a company can be managed, optimized, or analyzed, somebody has to make a more fundamental set of decisions. Where in an industry should we sit? What should customers actually pay us for? Which assets deserve to be owned? Which dependencies are safe to rent? What economics should the business produce when it reaches maturity? And, perhaps most importantly, what part of the design should still make sense when the environment around it changes?
Those are not operating questions. They are design questions. Analysis explains the system that exists. Operations make that system run. Architecture decides what system should exist in the first place.
That distinction matters because architecture is not free-form strategy. It has constraints, materials, structural loads, failure modes, and trade-offs. And the materials available to the business architect are now changing unusually fast.
This book is an attempt to build a discipline around that problem. The trilogy can therefore be stated simply: the engineer reads the system, the orchestrator runs it, the architect designs it.
If you’re already a paid member, simply reply to this email, and we’ll send it your way.
Every company is built around assumptions about its environment. Some are obvious: the cost of capital, the availability of technology, the strength of a distribution channel. Others are buried more deeply inside the business model: how expensive it is to serve another customer, which supplier has bargaining power, where scarcity sits in the value chain, how long an asset remains differentiated.
For long periods, those assumptions can look like facts. Then the environment moves.
The AI buildout has made this unusually visible. Its limiting factor has already migrated several times: advanced packaging, high-bandwidth memory, lithography, electrical power, financing. Each shift changes who captures the economics of the cycle. A layer that looked structurally advantaged can become ordinary once capacity catches up. Another layer can suddenly acquire pricing power because everything else is waiting on it.
Nothing about this mechanism is unique to AI. Railroads repeatedly moved the bottleneck between iron, land, financing, construction, and traffic. Electrification moved it from generation to transmission to distribution and eventually to demand. Industrial systems have always developed through sequences of constraints.
What has changed is the clock speed. A constraint can now rotate in quarters while the company exposed to it may need years to change its factories, contracts, organizational capabilities, channels, or capital structure. That creates the architect’s central problem: the environment can reprice faster than the firm can redesign itself.
The obvious response is to predict the next bottleneck. It is also usually the wrong one. Architecture should not depend on repeatedly guessing which constraint comes next. It should be built around the deeper structure of the system: where constraints are likely to travel, which functions remain necessary across different states, where flows repeatedly reconverge, and which parts of the stack can be substituted when their economics deteriorate.
In practical terms, this means owning what multiple future states require and renting what future states may commoditize. It also means distrusting inherited templates.
Business playbooks work until the assumptions that produced them disappear. The conglomerate was rational under one capital-market structure. Vertically integrated computing was rational under another technological structure. Packaged software reflected the economics of another distribution model.
SaaS became the dominant software architecture because one economic fact overwhelmed almost everything else: once the product had been built, serving another customer cost almost nothing. That assumption shaped the entire system. High gross margins justified aggressive acquisition spending. Revenue growth created extraordinary operating leverage. Infrastructure costs became negligible relative to software value. Scale was therefore overwhelmingly beneficial.
Generative AI changes that equation. Inference has a real variable cost. The more intensely a customer uses an AI product, the more expensive that customer may become to serve. Product adoption and gross margin can therefore move in opposite directions.
This does not make AI software unattractive. It makes its architecture different. A company being designed now needs answers that the classic SaaS playbook never required. What does the mature cost of intelligence look like? Who controls it? Does falling model cost accrue to the supplier, to the customer, or to us? Can usage grow without destroying the unit economics? Which parts of the stack become more valuable as intelligence becomes cheaper?
These are architectural questions because they cannot be fixed with better quarterly execution. They have to be designed into the company.
At the highest level, a business can be reduced to four interdependent choices: Value. Technology. Distribution. Finance.
What are we creating? What system produces it? How does it reach the market? What financial structure makes the other three sustainable? The sequence matters because changing one often changes the others.
Value. The first useful question in an AI economy is not what can now be produced. It is what can no longer be charged for.
Anything that becomes abundant tends to migrate downward in the value chain. Drafting, summarization, basic analysis, generic code generation, and routine answers are becoming dramatically cheaper. A product whose value consists entirely of producing one of those outputs is standing on a shrinking piece of economic ground.
So begin with subtraction. Remove what increasingly capable models can generate on demand. Then inspect what remains. Usually, the durable value sits closer to consequences than to outputs.
A transaction that must settle. A result someone is accountable for. A proprietary context that has to be governed correctly. A decision that carries liability. Access to scarce infrastructure. A trusted counterparty. A brand someone deliberately chooses even when alternatives are technically adequate.
AI cheapens capability much faster than it cheapens commitment. That distinction should shape the value architecture.
Technology. For years, companies asked whether they should build or buy. The better question now is what must remain under your control and what should remain deliberately replaceable.
Models are improving too quickly to treat today’s winner as permanent infrastructure. The default position should therefore be to rent commodity intelligence behind interfaces clean enough that suppliers can be changed. But portability is not an excuse to own nothing.
If a technological component determines the company’s differentiation, accumulated learning, customer context, or long-term cost structure, outsourcing it can mean outsourcing the economics of the company itself. The architecture is therefore asymmetric: rent where competition among suppliers works in your favor; own where control compounds.
And when the price of intelligence falls, do not treat the entire decline as a margin opportunity. Part of it should be reinvested into capability. If an operation becomes ten times cheaper, the more interesting question may be what becomes possible when you can perform it ten times.
Distribution. Distribution is often treated as a go-to-market decision that comes after the product. Architecturally, it comes before it.
A business built around an owned endpoint is a different company from one built around a marketplace, an API, a payment rail, a cloud platform, or an agent interface. The channel determines what data you receive, what margins you retain, how customers perceive you, what bargaining power you accumulate, and how easily someone else can stand between you and demand.
There are three broad positions. The first is an owned endpoint: the application, brand, interface, or destination the customer deliberately seeks. The second is a rail: infrastructure that activity must pass through whether or not the end user thinks about it. Payments, identity, settlement, deployment, and other coordination layers can acquire this character. The third is a rented door: somebody else controls the route to the customer.
Rented distribution is not inherently bad. It can be the fastest and cheapest way to acquire reach. The danger is confusing access with ownership. If another company controls discovery, ranking, access rules, pricing, and the interface with your customer, your distribution is not an asset. It is a dependency.
And AI adds another complication: businesses are increasingly distributing information not only to humans but also to machines acting for humans. APIs, structured data, identity, provenance, protocols, and machine-readable product information are becoming part of distribution architecture. Being understandable to software may become as basic to commerce as being indexable became to the web.
Finance. Finance is where the architecture reveals whether it can carry its own weight. The relevant question is not simply whether the company can generate accounting profit. It is whether its capital structure, margin structure, and cash profile match the position it is trying to occupy.
Start with the mature margin. Not next quarter’s gross margin. Not the temporary economics created by subsidies, scarcity, or aggressive pricing. What should this business earn once the market has normalized?
That terminal margin is one of the clearest expressions of the company’s actual strategic position.
Then decide how much capital the position deserves. AI has produced businesses inside the same broad technological cycle with radically different capital requirements. Some coordinate enormous flows while owning little physical infrastructure. Others require tens of billions of dollars simply to remain competitive.
Neither model is inherently superior. But the capital intensity has to be justified by the durability of what it buys.
Finally, build enough financial resilience to survive being temporarily wrong. In a fast-moving environment, almost every company will eventually mistime a constraint, overestimate demand, underestimate a transition, or invest before the market is ready. The balance sheet determines whether that mistake becomes information or extinction.
Once the four choices are clear, the next question is where the company actually sits.
Think of an industry map as a site plan. Different locations produce different economics because they have different relationships to scarcity, customers, capital, and dependency.
Six positions recur often enough to be useful.
The constrained input supplies whatever the system cannot currently obtain fast enough. It can generate extraordinary returns while scarcity lasts, but often requires heavy capital and carries direct exposure to the rotation of the bottleneck.
The junction sits where valuable context, demand, or workflows meet the broader infrastructure. It does not necessarily own the expensive machinery underneath it. Its advantage comes from controlling the point of coordination.
The rail performs a function the flow has to pass through. Payment networks and clearing systems are classic examples. Rails become powerful when routing around them is more expensive than using them.
The substrate is where activity accumulates. Databases, operating systems, ERP systems, cloud platforms, and systems of record have all occupied versions of this position. Their strength comes from residence: once important work lives there, the surrounding ecosystem begins to organize around it.
The endpoint owns the relationship with the user. Brand, habit, convenience, identity, and direct distribution matter most here.
And then there is the commodity seat. Most businesses occupy it. That is not an insult. Commodity positions can become enormous businesses. But their economics are different. They compete primarily on price, execution, availability, or scale while structurally advantaged neighbors capture a disproportionate share of the value.
The mistake is not sitting in a commodity position. The mistake is believing you occupy a chokepoint when your economics say otherwise.
The test is empirical. Look at margins. Capital intensity. Customer concentration. Supplier power. Switching behavior. Dependency. Pricing authority.
The real position is the one visible in the economics, not the one described in the strategy deck.
From there, separate two sources of extraordinary returns.
The first is tightness rent. A temporary constraint creates scarcity and therefore pricing power. Capacity eventually arrives, technology changes, customers adapt, or the constraint moves. The rent disappears with it.
The second is monopoly rent in the broader economic sense: returns derived from a structurally difficult-to-bypass position.
The distinction matters because both can look identical during a boom. A company earning exceptional margins because the world is temporarily short of something may appear to possess a moat. The architecture becomes visible only when supply catches up.
Sophisticated incumbents understand this. When they believe scarcity will not last forever, they attempt to convert temporary economics into longer-lived structure: contracts, standards, ecosystem dependencies, installed base, take-or-pay commitments, integration costs. They use the period of tightness to construct something that survives after tightness.
That leads to a useful architectural question: where does the constraint return?
The most valuable position is often not the asset temporarily receiving the bottleneck, but the layer that remains necessary as the bottleneck migrates elsewhere. The architect therefore designs for the path of the system, not merely its current state.
A moat is easier to reason about once the metaphor is removed. It is an asset, position, or mechanism whose defensive value grows through ordinary operation.
That final clause matters. If the alleged advantage does not become stronger as the business does its daily work, it probably is not a moat. It may still be an advantage, but it is not compounding.
AI is changing which mechanisms compound.
One of the most important is accumulated fit. A model by itself is replicable. A workflow by itself is replicable. A prompt library is replicable. But a system that has repeatedly adapted itself to a specific company’s data, exceptions, terminology, policies, feedback, users, and operating context becomes much harder to copy.
The advantage does not live in any single component. It lives in the interaction among them. The model learns how the context is structured. The context improves through repeated use. Corrections become institutional knowledge. The workflow adapts around real exceptions. Human judgment becomes encoded in the system.
Thousands of these small adjustments can produce something no competitor can reproduce merely by buying the same underlying model. That is accumulated fit.
Residence can compound in a similar way. The more important work accumulates inside a system, the more expensive it becomes to remove that system from the organization. This is one reason systems of record have produced unusually durable businesses.
AI may strengthen rather than weaken this dynamic. If agents increasingly act on enterprise conte…
