Fast-forward to 2026, and most enterprises have, in one form or another, crossed the adoption threshold. This year they have spent aggressively on models, tokens, copilots, agents, and the infrastructure required to run them, racing from experimentation toward agentic operating models. In that sense, adoption itself is no longer the main constraint.

And that is precisely what makes the current moment so revealing. Once usage becomes abundant, the real bottleneck becomes visible. It is not access to intelligence. It is not even willingness to use it. The hard part is translating all of that intelligence into deployed business outcomes across an organization. A company can have thousands of employees using AI every day, consume enormous amounts of inference, launch dozens of pilots, and still struggle to show where margin improved, where a workflow fundamentally changed, or where a new competitive capability was created.

I have spent much of my career around enterprise software, working at the intersection of customers, technical teams, and commercial organizations, and this is what feels fundamentally different about AI. With previous software waves, adoption was often the hard part: get the system installed, get people into it, get usage up. With AI, usage can spread almost by itself. The friction appears one level higher, when the organization tries to turn thousands of local productivity gains into one coherent operating model.

Who decides which workflows should be automated? Where does human judgment remain? Which models and agents can act on which data? Who owns the corrections, evaluation sets, and decision history they generate? How does one successful experiment become a company-wide standard rather than another isolated tool?

Those are governance questions. And governance has traditionally been treated as something that comes after innovation: first let teams experiment, then bring in security, legal, procurement, architecture, and the operating model once something starts working. AI turns that sequence upside down. Governance is not the layer that follows the transformation. It is the mechanism that allows the transformation to compound.

Without it, the enterprise can generate enormous activity at the edges while accumulating very little at the center. Every employee gets faster. Every team produces more. Every dashboard turns green. Yet the company can still end up in roughly the same competitive position, because its rivals bought access to the same intelligence at roughly the same time.

That is the tension this piece is trying to unpack. The enterprise AI challenge is no longer principally one of adoption. It is one of organization: how individual gains become coordinated systems, how local discoveries become standards, how the knowledge generated by humans and agents stays with the firm, and how all of it is ultimately aimed at a strategic position competitors cannot reproduce simply by buying the same models.

The transformation therefore does not end when the enterprise adopts AI.

That is where the difficult part begins, and this book comes in handy.

This is a new book in The Business Engineer’s Foundation Series.

Subscribe To Premium To Gain Access!

Check out the Library for Free!

For the last three years, I’ve been rebuilding the Business Engineer’s curriculum from the ground up. That curriculum has now become the foundation of a new discipline, with the entire series taking shape around it.

Subscribe To Premium To Gain Access!

Check out the Library for Free!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Read more

Around 2017 and 2018, I remember working on ways to make websites “talk”: turning their content into structured data that machine interfaces and voice assistants could actually consume. It worked, but it was incredibly clunky. You could see the direction of travel, but much of what we imagined still felt decades away.

Then the underlying technology began to change. The arrival of transformer-based models, Google bringing systems such as BERT into search, and the rapid evolution of the GPT family between 2018 and 2020 made it increasingly obvious that we were crossing into something different.

These systems were becoming dramatically more general. Instead of building a separate narrow pipeline for every language task, you could increasingly place different problems in front of the same underlying model.

At first, I was not particularly impressed by the outputs themselves. As an author, analyst, and writer, I could still do things these systems simply could not do well. The important signal for me was elsewhere: the rate at which the boundary was moving.

Things that a few years earlier I had mentally placed ten or twenty years into the future were suddenly becoming plausible within a product cycle. The clunky interfaces we had spent years engineering around narrow NLP were beginning to collapse into much more general systems.

By the early 2020s, a large part of my day-to-day work had consequently become figuring out how to bring this new generation of AI into the enterprise stack. And that is where I started to see a second problem emerge.

The hard part was increasingly not getting the technology to do something impressive. It was getting the impressive thing through the long journey from prototype to production, and then from one production deployment to something that could actually scale across an organization.

Back in 2023, when almost everyone was caught off guard by the first major generative-AI wave, one thing was therefore already clear to me: the enterprise had moved to the center of the AI story. The question was no longer simply whether large companies would adopt AI. It was whether they would accept what adoption really implied. AI was not going to remain another piece of software layered onto the existing organization. Eventually, it would require a change to the core of the organization itself.

Fast-forward to 2026 and most enterprises have, in one form or another, crossed the adoption threshold. This year they have spent aggressively on models, tokens, copilots, agents, and the infrastructure required to run them, racing from experimentation into the agentic era. Enterprises have consumed enormous amounts of intelligence. Employees are using AI. Developers are building with it. Business units are launching agents. In that sense, usage is no longer the main constraint.

And that is precisely what makes the current moment so revealing. Once usage becomes abundant, you can finally see where the real bottleneck sits. It is not access to intelligence. It is not even willingness to use it. It is the translation of all that intelligence into deployed business outcomes across the enterprise.

A company can have thousands of employees using AI every day, spend heavily on inference, launch dozens of pilots, and still struggle to answer the questions that ultimately matter. Where did margin improve? Which workflow was fundamentally redesigned? What can the organization now do that it could not do before? Which capability is compounding rather than simply making an employee faster?

I have spent much of my professional life at the intersection of customers, technical teams, and commercial organizations, and this is what feels fundamentally different from previous software waves. Historically, adoption itself was often the hard part: buy the system, integrate it, get people into it, drive usage. With AI, usage can spread almost by itself. The friction appears one level higher, when the company attempts to turn thousands of local productivity gains into one coherent operating model.

Who decides which workflows should actually be automated? Where does human judgment remain? Which agents may take which actions? Which models may touch which data? Who owns the evaluation sets, corrections, and decision history those systems generate? What happens when a model changes underneath a production workflow? How does one successful experiment become a company-wide standard rather than the forty-third isolated AI tool inside the company?

These are fundamentally governance questions. Yet governance is almost always treated as the thing that comes after innovation. First experiment. First prove something. First let teams move quickly. Then bring in security, legal, procurement, architecture, data governance, and the operating model once the technology has demonstrated its value.

I think AI turns that logic upside down.

Governance is not the layer that follows the transformation. It is the mechanism through which the transformation compounds.

Without it, the enterprise can produce extraordinary activity at the edges while accumulating remarkably little at the center. Every employee becomes faster. Every department launches agents. Every productivity dashboard turns green. Yet the knowledge generated by those systems remains fragmented, the workflows remain structurally unchanged, and the company can end up in approximately the same competitive position because its rivals bought access to the same intelligence in the same quarter.

That is the tension this piece is trying to unpack. The enterprise AI challenge is no longer principally one of adoption. It is one of organization: how individual gains become coordinated systems, how local discoveries become institutional standards, how the knowledge generated by humans and agents remains with the firm, and how all of this is ultimately aimed at a strategic position competitors cannot reproduce simply by purchasing the same models.

The technology moved faster than I expected when I was working with those narrow NLP systems a decade ago. But that has only made the organizational problem more visible.

The transformation does not end when the enterprise adopts AI. That is where the difficult part begins.

Subscribe To Premium To Gain Access!

Check out the Library for Free!

For the last three years, I’ve been rebuilding the Business Engineer’s curriculum from the ground up. That curriculum has now become the foundation of a new discipline, with the entire series taking shape around it.

Subscribe To Premium To Gain Access!

Check out the Library for Free!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Read more

The concern was not that the agents appeared to want to escape. It was that they demonstrated something more operationally significant: they coordinated at scale, exploited unintended infrastructure, knowingly crossed authorization boundaries, and attempted to game automated evaluation systems.

Yet they showed remarkably little interest in concealing the broader behavior from human investigators.

Cotra’s warning is that this may represent a temporary window: today’s agents may already be capable enough to cheat, coordinate, and exploit systems, while still being unsophisticated enough to leave the evidence behind.

2026 has emerged as a landmark period in the evolution of AI, marked by several inflection points over the past year. Each is redefining how AI interacts with the enterprise and, by extension, how organizations must think about security.

The first is the transition from traditional language models to agentic systems capable of taking action. Just a year ago, enterprise AI was largely centered on generating and retrieving information. Now, autonomous agents are beginning to interact directly with applications, infrastructure, data, and business processes. This fundamentally changes the relationship between human operators and AI systems.

The second is the demonstration that deep domain training can give AI extraordinary proficiency within specialized environments. That same capability can be weaponized. AI can increasingly identify and exploit vulnerabilities at machine speed and at enormous scale, exposing years of accumulated technical debt. Weaknesses that once required considerable expertise and time to discover can now potentially be identified and exploited within minutes. In an AI-driven threat environment, there is increasingly nowhere for vulnerable infrastructure to hide.

The third is the enterprise push toward greater control over AI itself. Organizations are moving beyond generic models toward specialized systems deeply integrated with proprietary data, applications, and workflows. As experimentation turns into production and deployments multiply, the enterprise attack surface expands alongside them.

This creates a structural tailwind for cybersecurity. Every new AI workload, data center, model, agent, endpoint, and connection becomes part of the security perimeter.

As AI development tools increasingly migrate toward desktop and endpoint environments, this perimeter expands even further. Autonomous systems will not simply access information. They will execute actions across enterprise infrastructure.

The consequence is that security can no longer be treated as a collection of isolated products. AI reinforces the need for unified, real-time security platforms capable of understanding identity, behavior, intent, data, applications, and network activity across the entire enterprise.

AI therefore does two things simultaneously: it expands the enterprise technology surface and increases the speed at which that surface can be attacked.

The larger AI becomes, the more important integrated security becomes.

This is the starting point of the new volume of The Business Engineer’s Foundation series.

Subscribe To Premium To Gain Access!

For the last three years, I’ve been rebuilding the Business Engineer’s curriculum from the ground up. That curriculum has now become the foundation of a new discipline, with the entire series taking shape around it.

Subscribe To Premium To Gain Access!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Read more

Then, while completing my business studies abroad in my early twenties, I realized that macro was not enough. Corporate finance provided the missing bridge between economic forces and what actually happens inside companies: how capital is allocated, how businesses make decisions, and how those decisions ultimately shape markets.

But my perspective changed again in my late twenties, when I completely shifted my career into technology and went deep into the mechanics of software startups. I began to understand that technology was not simply another variable inside the economic system. Technological progress follows highly nonlinear dynamics. Adoption moves through S-curves, new capabilities compound, bottlenecks shift, and what initially looks like a micro-level change can eventually reshape industries, capital markets, and the macroeconomy itself.

Over the last decade, my view has therefore become much more nuanced. Macro, finance, business, and technology are not separate systems. They are different layers of the same system, continuously feeding back into one another.

This book, part of the Business Engineer’s foundational curriculum, is an attempt to bring those layers together. It explains how the Web Economy evolved into the AI Economy, and why, once a technological cycle becomes large enough to turn into a supercycle, the distinction between micro and macro begins to break down. Technology shapes companies, companies shape capital allocation, capital accelerates technology, and the resulting feedback loops begin to reshape the economy itself.

AI arrived on top of thirty years of web: the infrastructure, the data, the behavior, and the distribution that three decades of the internet economy built. It compounds that web rather than replacing it.

The relationship runs both ways. The web produced the corpus the models were trained on and the channels through which they reach a billion people; the models now ride the web’s rails and produce revenue curves in a year that the web’s own giants needed a decade to build.

That compounding is the paradigm this Library calls Web Squared, and it has a financial signature the era’s disclosures make plain. The demand does not have to be assembled because the web already assembled it; and the first industries transformed are the web-native ones, search, social, publishing, software, cloud, because they hold the substrate intelligence multiplies.

But the money moves differently this time, and the difference is the subject of this volume. The web’s economics were built on a copy that cost nothing to serve; the AI era’s are built on a unit of work that costs something to produce. That single fact reverses the order in which the financial statements change: the cost line moves before the revenue line.

It also returns to the top of the stack the physics the software era had forgotten: cost of goods, depreciation, capital committed ahead of demand. The right way to read this era’s money is therefore historical.

Every instrument the AI era needs was either invented or broken in the web’s own thirty years, and the book begins there, with a dial-up modem and a subscription.

Subscribe To Premium To Gain Access!

For the last three years, I’ve been rebuilding the Business Engineer’s curriculum from the ground up. That curriculum has now become the foundation of a new discipline, with the entire series taking shape around it.

Subscribe To Premium To Gain Access!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Read more

The web was extraordinary for a reason that took even its own practitioners years to articulate clearly: it was both a distribution channel and a business-model enabler. The companies that extracted the most value from it were the ones that stopped treating it merely as a marketing channel and allowed it to reshape the business itself.

The deepest lesson of the web followed from this: product and distribution eventually become the same thing. When the two merge, distribution is no longer something added to the product. It becomes part of how the product works, grows, and compounds. That merger creates the flywheel, and every growth discipline since has been an attempt to build one.

AI entered a very different environment. It arrived on top of more than thirty years of infrastructure, data, behavior, and distribution already created by the web. The relationship runs in both directions. The web made the current AI paradigm possible: without the corpus the web generated and distributed, today’s models could not exist. AI, in turn, plugs into the web’s existing distribution infrastructure and produces growth curves at a scale and speed the web itself rarely achieved.

This is the paradigm I call Web Squared: AI does not replace the web. It compounds it. The consequence is already visible. The first industries being disrupted, expanded, and amplified by AI are largely the industries the web itself created: search, social, publishing, cloud, and software. They already possess the infrastructure, data, distribution, and economics that intelligence can immediately multiply. The web-native economy transforms first because it is the substrate AI compounds on.

There is a second distinction, and it is even more important. The web was primarily an outside-in technology. Take an existing business and put it on the web, and the first thing that changes is distribution. The retailer gets a website, the newspaper publishes online, the bank launches internet banking, while the organization, operating model, and underlying economics initially remain largely intact. It took years, arguably until the 2010s, before the web penetrated deeply enough to transform business models themselves.

AI works in the opposite direction. It is an inside-out technology. Embed intelligence inside an organization and the first-order effect is not a new channel. It is a transformation of how the organization operates: how work gets done, how decisions are made, how knowledge moves, what gets automated, what humans do, and ultimately how value is created and captured.

The sequence therefore reverses: Operating Model; Business Model; Distribution. AI changes the operating model first. That transformation reshapes the business model, which ultimately redefines distribution. This is also why enterprise AI is proving so difficult: the challenge is not simply deploying the technology. Organizational transformation is the prerequisite for the business-model transformation that follows.

The web taught us that distribution could become part of the product. AI is teaching us that intelligence becomes part of the organization itself. And in this new paradigm, transformation starts from the inside and compounds outward.

Subscribe To Premium To Gain Access!

Subscribe To Premium To Gain Access!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Read more

The web was extraordinary because it was both a distribution channel and a business model enabler. Yet the companies that extracted the most value from it were those that eventually understood that the web wasn’t simply a new marketing channel. It was an opportunity to reshape the business model itself.

One of the most important lessons of the web era is that product and distribution eventually become the same thing. When the two merge, you create a flywheel where distribution is no longer something added to the product. It becomes part of how the product works, grows, and compounds.

From the Web to Web²

AI entered a very different environment. It could immediately leverage more than 30 years of infrastructure, data, behaviors, and distribution built by the web.

In fact, the web itself helped make the current AI paradigm possible. Without the enormous amount of data generated and distributed through the web, we would not have reached this stage of AI development.

But the relationship works in both directions.

As AI plugs into the web’s existing distribution infrastructure, it can generate growth curves at a scale and speed we have rarely seen before. I’ve described this paradigm for years as Web², or Web Squared: AI doesn’t replace the web. It compounds it.

This is also central to my AI Supercycle thesis. Paradoxically, the first industries to be disrupted, expanded, extended, and amplified by AI would be precisely the industries that emerged from the web itself: search, social media, digital publishing, cloud computing, software, and more.

The web-native economy gets transformed first because it already has the infrastructure, data, distribution, and economics that AI can immediately amplify.

The Web Was Outside-In. AI Is Inside-Out.

Subscribe To Premium To Gain Access!

There is another distinction that is even more important.

The web and AI represent fundamentally different technological paradigms.

The web developed during a very different historical and technological period. As I explain in the AI Supercycle thesis, it was primarily an outside-in technology.

Take an existing business and put it on the web. Initially, what changes?

Distribution.

The underlying organization, operating model, and economics can remain largely intact. A retailer gets a website. A newspaper publishes online. A bank launches internet banking. The distribution layer changes first.

It took years, and arguably until the 2010s, before the web began transforming entire business models at their core.

AI works in almost the opposite direction.

I think of AI as an inside-out technology.

When you embed intelligence into an organization, the first-order effect isn’t necessarily a new distribution channel. It is a transformation of how the organization operates: how work gets done, how decisions are made, how knowledge moves, what gets automated, what humans do, and ultimately how value is created and captured.

AI changes the operating model first, which can then reshape the business model and ultimately redefine distribution.

This also explains why enterprise AI is proving so difficult to implement effectively. The challenge isn’t simply technological. To capture AI’s full value, organizations often need to change themselves. Organizational transformation becomes the prerequisite for business model transformation.

Why AI Growth Engineering Is Different

This is why AI Growth Engineering, while descended from decades of web growth engineering, is fundamentally different from it.

Web growth engineering largely learned how to make product and distribution compound together.

AI Growth Engineering must go deeper. It connects intelligence, product, operations, business model, and distribution into the same compounding system.

The web taught us how distribution could become part of the product.

AI is teaching us how intelligence can become part of the organization itself.

That distinction is at the heart of the latest addition to The Business Engineer Foundation Series, and I hope it gives you a useful framework for understanding why AI growth will look fundamentally different from what came before.

Subscribe To Premium To Gain Access!

Subscribe To Premium To Gain Access!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Read more

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.

Enterprise Sales is another book in that series.

Enterprise sales is being rebuilt from the foundations, and the reason is simpler than most sales methodology makes it sound: the object of the sale changed.

For four decades, enterprise technology companies largely sold software: seats, licenses, platforms, infrastructure. The vendor sold capability; the buyer carried the burden of translating that capability into value. A CRM vendor did not guarantee that the sales organization would sell more. An ERP vendor did not guarantee that the company would operate better. A cloud provider did not guarantee that an application would succeed. The contract transferred access to machinery, while most of the outcome risk remained with the customer.

AI begins to invert that arrangement because AI does not merely give people another interface through which to work. Increasingly, it performs part of the work itself. Once software begins doing the work, the distinction between product and outcome becomes unstable. A buyer does not care that an agent has access to a frontier model. It cares whether a claim is processed correctly, a contract is reviewed to the company’s standard, a support issue is resolved, an analyst gets three hours back, or a workflow that took five days now takes five hours.

The winning vendors therefore move closer to the result. They do not simply sell intelligence. They install a system capable of producing a measurable outcome on the customer’s own work, under the customer’s own constraints, against a standard the customer recognizes as legitimate.

Four inversions define the new sale. The demo collapses: seeing AI work in principle is no longer meaningful proof. The seat collapses: human headcount stops being the natural pricing denominator when machines increasingly perform the work. The buyer becomes capture-aware: ownership, portability, dependency, and exit move from renewal questions into the initial buying process. The seller becomes a builder: when proof requires deployment, selling and building begin to converge.

The sales organization that understands these inversions stops treating sales as persuasion wrapped around a product. It begins treating sales as a system for progressively removing the buyer’s uncertainty until the economic decision becomes almost mechanical.

The enterprise sale is a risk-reduction machine wearing a revenue target.

AI does not remove that old physics. It makes it visible.

Subscribe To Premium To Gain Access!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

Subscribe To Premium To Gain Access!

Read more

Enjoy, and let me know if you liked it.

Subscribe & Get Full Access To Map of AI

Full Harness with The Executive Plan

If you’re already an Executive Plan member, simply head to Business Engineering to access the harness.

Read more

For many people, the implications became obvious sometime during 2023. For me, it was already clear on the night of November 30, 2022.

There were a few reasons.

First, I was already a tech executive selling AI services into the enterprise. ChatGPT immediately felt like one of those moments where you realize the software industry itself is about to be redefined.

Second, I was running one of the largest independent business blogs on the web, competing for attention with publications like Business Insider. It was equally obvious that the economics of that world were about to change dramatically.

Third, I’m an entrepreneur. So my instinct was not to sit back and theorize about what ChatGPT might become. It was to build with it.

By December 2022, I was already turning years of knowledge accumulated through FourWeekMBA into a conversational interface and launching an early chatbot around it. Some of you who followed me back then may even remember it.

That pattern has continued ever since.

I build with these tools for work, but also for fun. I don’t really play games. To me, this entire AI ecosystem is the amusement park.

Over the last few years I’ve built hundreds of small experiments, prototypes, workflows, agents, and increasingly larger applications. Partly because it feeds my entrepreneurial instinct, but also because there is no substitute for actually using the frontier tools yourself.

And there is a deeper reason.

Products like Claude Code a year and a half ago, and Grok Bot today, give you a privileged window into what enterprise AI may look like six to twelve months later.

Consumer and developer tools often expose the next interaction paradigm before the same architecture gets hardened, governed, integrated, and deployed inside enterprises.

That makes these moments worth studying very carefully.

Claude Code was one of them.

Grok Bot is another.

And what makes Grok Bot particularly interesting is that it reveals a second-order shift.

In the executive plan you will also find the Business Engineer’s Grok Bot Template.

For context, I have no affiliation with Grok Bot or anything connected to it, and no financial interest in promoting it. As always, I cover what I believe matters, especially when I see something that could represent a genuine turning point for you.

That’s exactly why I created this template: for you to experiment with it, learn how it works, and see firsthand how much it can multiply your business productivity.

In the executive plan you will also find the Business Engineer’s Grok Bot Template.

Everything up to this point describes the desk.

For the last couple of years, the industry has increasingly understood that the model alone is not the product. You need a harness around it: memory, tools, permissions, persistent environments, orchestration, workflows, schedules, approvals, and all the other machinery required to turn intelligence into useful work.

But Grok Bot shows that even the harness is now beginning to commoditize.

A year ago, building a genuinely useful agent harness could require hundreds of hours of engineering work. Today, increasingly capable agents can assemble surprisingly effective versions of that infrastructure in minutes.

That changes the strategic question again.

It is no longer enough to say:

The model will commoditize, therefore the value moves to the harness.

The harness itself is moving down the same curve.

If that continues over the next one to two years, the durable value moves further outward, toward the places where generic intelligence and generic harnesses meet the messy specificity of the real world.

• The junctions.

• The edges.

• The proprietary context.

• The workflows.

• The approval boundaries.

• The systems of record.

• The domain-specific operating logic.

The narrow use cases where an agent actually has to intersect with how a company, industry, or profession works. That, to me, is the most important signal coming from Grok Bot.

The model is commoditizing.

The harness is beginning to commoditize too.

The next battleground is the junction between generic intelligence and specific work.

And the interesting thing, as I explained in Grok Bot & The Fourth Moment of AI, is that Anthropic itself has been actively feeding this flywheel.

Beyond The AI Model

Nearly every discussion about AI starts with the model. Which model is smartest? Which one leads the benchmark? Which one has the largest context window? Which one reasons better, codes better, or uses tools more reliably?

Those questions matter, but they increasingly describe only one layer of the system. There is another layer above the model that determines whether intelligence becomes finished work.

The model supplies capability. Something else gives that capability a persistent job, memory, access to real systems, a computer on which to act, a schedule on which to operate, and boundaries around what it is allowed to do without you.

That layer is the harness.

A great model inside a chat window can answer a question. A great model inside a well-designed harness can own a job.

That is the starting point for this guide, because Grok Bot matters less as another AI application than as evidence of a larger transition: capabilities that previously required engineers to assemble are becoming packaged into a consumer product.

The harness is becoming a download.

Once that happens, the constraint changes. The question stops being Can I build an agent infrastructure? and becomes Can I define the job precisely enough for an agent to perform it?

That is a much bigger shift than it first appears.

What a harness actually is

Start with the simplest possible model interaction. You ask a question. The model receives the context available in that moment, generates an answer, and the interaction ends.

Useful, but fundamentally inert.

The model does not automatically know what role it has in your organization. It does not necessarily remember what happened last month. It cannot automatically sign into your operating systems. It does not have a durable computer waiting for it. It does not wake up every weekday at eight to perform the same job. And it should certainly not be allowed to execute every possible action without approval.

Everything that converts raw model intelligence into persistent work therefore sits around the model.

The metaphor of a harness is unusually precise. The horse supplies the power. The harness directs that power toward a particular load, in a particular direction, for a particular purpose.

An AI harness has six basic components:

• Persistent identity. The agent has a job rather than a session that resets.

• Memory beyond the current window. It does not relearn your company, preferences, standards, and projects every morning.

• Access to real tools. It can operate inside email, Slack, GitHub, documents, CRMs, websites, internal applications, and other systems where the work actually lives.

• A computer on which to act. The execution environment persists even after your own laptop closes.

• A schedule or trigger. Work can start on a timetable or when a relevant event occurs.

• An approval boundary. The system knows where autonomy stops and a human must return.

Capability comes from the model. Direction, persistence, reach, and restraint come from the harness.

The working unit is increasingly a rented model wrapped in an operating system, fed by owned context and governed by an owned method. Performance comes from the fit between those layers, not from the model alone.

See Also:

The old constraint: the harness had to be built

Frontier intelligence became broadly accessible remarkably quickly. For roughly the price of a normal software subscription, almost anyone could access models that would have looked extraordinary only a few years earlier.

But access to intelligence did not create equal access to leverage, because turning that intelligence into a persistent worker still required assembly.

You needed orchestration logic, memory, scheduling, credentials, permissions, a browser environment, compute, tool integrations, monitoring, and approval logic. Someone had to connect those components and make sure they continued working.

For engineers and technically sophisticated operators, that was possible. For everyone else, the effective product remained a chat window.

The result was a strange gap: intelligence had democratized, but the operating system around intelligence had not.

The gap between a chat window and an AI workforce was never only intelligence. It was assembly.

And assembly is precisely the layer products like Grok Bot are beginning to remove.

Why this feels like a second Claude Code moment

In the executive plan you will also find the Business Engineer’s Grok Bot Template.

Some AI products improve an existing workflow. Others change what people believe the interface itself should be.

Claude Code was one of those products. The breakthrough was not simply that Claude could generate code. Models could already do that. The important shift was that the model moved into the working environment: inspecting the codebase, operating across files, using tools, maintaining context, changing the underlying artifacts, and participating directly in the workflow.

That changed user behavior because the distance between human intent and machine execution collapsed.

Grok Bot represents a similar shift one layer higher.

The breakthrough is not that AI can operate software. That had already been demonstrated. The breakthrough is the packaging of the harness: persistent agents, cloud execution, remembered sessions, connected tools, workflow memory, skills, routines, event triggers, multi-agent handoffs, human takeover, approval boundaries, and a messaging interface ordinary users already understand.

This is primarily a harness-layer innovation, not a model-layer innovation.

The underlying technologies existed. What disappeared was much of the assembly.

Read Also:

The access curve tells the same story

Grok Bot launched in beta on 11 August 2026. Access was initially concentrated in higher subscription tiers. It widened again during August and, by 26 August, had expanded across the paid Cursor plans and eligible SuperGrok plans.

There is no separate infrastructure deployment to provision. The harness arrives as an application attached to subscriptions users may already hold.

The entry requirement therefore moves from something resembling Can you assemble the infrastructure? to Can you write a sufficiently good job description?

That is the real democratization event.

Not intelligence becoming free. Not agents becoming perfect. Not every workflow suddenly becoming automatable.

The operating shell around the model is becoming a packaged product.

What did not get democratized

The harness became easier to acquire. The method did not.

This distinction is critical because a harness is an amplifier. It can take a process and execute it faster, repeat it, schedule it, run it across systems, and keep it alive while you are away.

But the harness itself has no opinion about whether the underlying process is good.

It does not know what evidence should count. It does not know which variable is load-bearing. It does not know which claim should block publication. It does not know when the intellectually honest output is simply: we do not have enough evidence to make this call.

Those rules come from the method.

A harness without a method gives you industrialized improvisation. Whatever you were already doing can now happen faster, more frequently, and at greater scale, including the mistakes.

A harness with a method becomes a discipline. The agent knows what must be established first, what evidence qualifies, which questions need answers, what constitutes a lock, what should remain unknown, what blocks delivery, and what artifact should ultimately be produced.

This also makes the method more durable than the underlying infrastructure. Change the model and the method can remain. Change the vendor and the method can remain. A cheaper model reaches sufficient capability and you reroute the workload. A better harness arrives and you move the method onto it.

Rent the layers that commoditize. Own the layers that compound.

Increasingly, that may mean renting both the model and the harness while owning the context, decision logic, proprietary workflow, quality standard, and domain-specific method.

Own the junction. Rent the ends.

Grok Bot: the desk

Grok Bot gives you agents that persist. A Bot has a role, a conversation, access to tools and files, and the ability to work through a cloud execution environment while you are away.

It is not simply another chat thread. The agent can keep working after your laptop closes, preserve useful context across sessions, use connected applications and websites, run routines, and return when something requires your decision.

Three concepts are particularly important.

First, work happens on a persistent cloud computer. Your own laptop does not need to remain open while a background job runs.

Second, sign-ins and operating state can persist. Once you authenticate a service through the appropriate takeover flow, the session can remain available rather than forcing a fresh login every time the agent works.

Third, the environment should be treated as shared operating infrastructure. Files, sessions, and authenticated environments can outlive individual conversations or Bots. Deleting a Bot should not be treated as equivalent to wiping the underlying machine.

The correct mental model is therefore closer to a persistent AI desk than to a disposable chat session.

Bot, Group Chat, and Channel

This distinction becomes important once Grok Bot moves beyond isolated agents.

A Bot is a persistent role

A Bot should ideally own one enduring job: Talent Scout, Expense Manager, Researcher, Writer, Product Analyst, Account Monitor.

Focused Bots build coherent context around repeated work. A Bot called General Helper does not.

Use a single Bot when one role can own the outcome end to end.

A Group Chat coordinates several Bots around one outcome

Grok Bot allows several Bots to participate in the same collaborative conversation.

You can allow the Bots to determine who should respond, explicitly route work with @ mentions, or hand work between specialists.

A simple example is:

Researcher → Writer → Reviewer

The Researcher gathers and sources evidence. The Writer turns it into the deliverable. The Reviewer checks the result and surfaces blocking issues.

The rule is simple: one clear owner at every stage, even when several agents participate.

A Channel turns coordination into a project

The newer pattern is Channels.

The structure is much closer to how human teams already work:

One project → one Channel → one roster.

Instead of keeping a Coder, Researcher, Writer, and Project Manager scattered across independent conversations, the Channel becomes the project-level space where the relevant Bots and the human coordinate.

That changes the conceptual model:

Bot = role
Group = shared outcome
Channel = persistent project or operating unit

The product terminology is still evolving, but the direction is clear. Grok Bot is moving from persistent agents toward persistent organizations of agents.

That matters for the Business Engineer architecture.

My Command Center deliberately starts with one head and many Skills, because a single analytical job benefits from a coherent reasoning state rather than several agents producing competing interpretations.

But Channels change where the boundary sits.

A single analytical job belongs inside the Command Center.

A larger project with genuinely separable roles may justify a Channel.

For example:

Business Engineer Command Center + Research Bot + Product Observer + Artifact Bot + Project Manager

The distinction is architectural, not cosmetic.

Use Skills when the knowledge should live inside one mind. Use Bots when a role deserves persistent independent context. Use a Channel when several persistent roles need to coordinate around a shared project.

Access

There is no standalone Grok Bot subscription. Access currently comes through eligible Cursor or SuperGrok plans.

Desktop support includes macOS and Windows. Mobile support includes iOS and Android. There is currently no Linux desktop application listed.

Authentication uses a Cursor account rather than a separate Grok Bot login. Organizations using SSO complete their normal organizational authentication flow.

Cloud data storage must also be supported by the account. Legacy Privacy Mode accounts may need to move to a compatible data configuration before Grok Bot can operate.

Grok Bot receives its own usage allocation, separate from ordinary Cursor and Grok usage. Higher subscription tiers primarily affect that allowance rather than exposing fundamentally different agent features.

One practical warning: the rollout has moved faster than every documentation page. If two official pages disagree on plan eligibility, check the update date rather than assuming your account is wrong.

Setup

1. Install the application

Open the Grok Bot access page and choose the correct build.

On macOS, select Apple silicon or Intel. If you are unsure, open Apple menu → About This Mac. A Chip field indicates Apple silicon; a Processor field indicates Intel.

On Windows, choose the appropriate x64 or Arm64 installer.

On mobile, install the application and authenticate with the same account. Usage belongs to the account rather than requiring another subscription for each device.

2. Sign in

Choose Get started from the welcome screen, or Sign In with Cursor from Settings if you are already inside the application.

Authentication completes in the browser, after which you return to Grok Bot.

During the initial setup, the application may ask which tools you use. Those answers shape suggested teammates. They do not automatically connect those services.

3. Create the first Bot

Choose New → Create new agent, then configure its name, title, description, and avatar.

Give it one primary job.

The description should contain rules that remain true across tasks. The conversation should contain the work happening now.

For example:

Persistent description: Never send an external message without my approval.

Current conversation: Review these 20 accounts and identify which require follow-up this week.

That separation is important:

Description = standing operating rules.
Conversation = current assignment.

4. Give it a properly bounded task

A strong request usually specifies five things:

1. Outcome: what should be true when the job is complete?

2. Sources: where should the agent look?

3. Constraints: what must it not assume or do?

4. Deliverable: what should come back?

5. Approval boundary: at what point must it stop and ask you?

The goal is not to write an elaborate prompt. The goal is to define a job that can terminate.

5. Connect the tools it needs

For supported services, go to Settings → Plugins, install the appropriate connector, and complete authentication through the provider’s browser flow.

For websites without a dedicated connector, the Bot can use the browser running on its cloud computer. When authentication is required, open Agent Computer, take control, enter the password, passkey, CAPTCHA, or two-factor code yourself, then return control to the Bot.

Never paste passwords or API keys directly into chat.

The takeover mechanism exists precisely so the agent can use an authenticated environment without reading the underlying credential.

6. Get the job right once, then automate it

A Skill describes how to perform a task.

A Routine tells a Bot when to run a workflow, either on a schedule or, where supported, after an event.

The sequence should be:

Run manually → correct the method → save it as a Skill → test it again → create a Routine.

Do not automate an unstable process.

Automation scales the method you already have, including its mistakes.

Teach a task

Where Teach a task is available, you can demonstrate a browser workflow instead of describing every step.

Open the Bot’s computer, choose Teach a task, describe the intended result, and perform the workflow once yourself.

The system records visible screen activity and turns the demonstration into a draft process.

Treat that output as a starting point, not a finished operating model.

A demonstration shows mechanics. It rarely captures every exception, decision rule, approval boundary, or quality criterion.

Those still need to be written explicitly.

Routines and event triggers

Scheduled routines use the time zone configured in Settings → General → Agent.

That setting determines what “8 AM” actually means.

Event-triggered workflows may react to integrations such as Slack or GitHub events. Those triggers are conceptually separate from the plugins the Bot uses to perform the resulting work.

Keep trigger rules narrow.

Listening to every message in a busy system consumes usage and encourages agents to act on noise.

Automate the signal, not the feed.

And remember that a test run is real execution. It can navigate websites, change files, and call connected tools.

Anything that can send, purchase, delete, publish, or modify production systems should remain behind explicit human approval until the workflow has been validated.

Where the important controls live

Open conversation details and then Agent settings to edit the Bot’s identity, description, avatar, notifications, and routines.

Two updates should not be confused:

Check for Updates updates the Grok Bot application itself.

Update Agent Computer refreshes the execution environment.

They solve different problems.

Reset Agent Computer should be a last resort because unsynced state may be lost.

Execution on Local Computer allows a Bot to operate on the physical desktop in front of you. Local approval rules should not automatically be assumed to apply on every other machine.

Under Plugins, Marketplace contains available integrations and packaged Skills, while Yours contains what has been installed or enabled.

Hiding a Bot removes it from the sidebar but does not necessarily stop its routines.

Deleting a Bot removes its profile, conversation, and routines, but should not be treated as wiping the shared execution environment or every authenticated session it used.

Sections help with navigation, but a Channel is the stronger abstraction when what you actually need is a project with several collaborating roles.

When something stops working

Start with the least destructive intervention.

Fully quit the application, then reopen it. On macOS, closing the window is not the same as quitting the application.

If the problem persists, update the application.

If the execution environment appears stuck, reopen or update the agent computer.

Use Reset only after the less destructive options have failed.

A routine that has gone quiet is not necessarily broken either. Check whether it is enabled, whether it has been paused, whether the schedule and time zone are correct, and whether the run history shows an error.

The Business Engineer Command Center: The Template

Everything up to this point describes the desk.

Now we get to the layer that matters more.

The Business Engineer Command Center is a method designed to run on top of that infrastructure.

It is not a collection of generic prompts. It is not a chatbot that dumps business frameworks. And it does not need four agents talking over one another simply because the platform supports multi-agent collaboration.

It starts as one agent with one coherent analytical operating system.

The specialist analytical capabilities live inside that agent as Skills.

Give it a company, a deck, a demo, or an analytical question. It determines what job it has received, establishes the relevant locks, performs the required analysis, runs QA, and produces the appropriate artifact.

Lock first, analyze second

The Command Center begins by identifying the fundamental business reality underneath the material.

Who pays? What are they actually paying for? Where does the workflow complete? What is the operating mechanism? What remains valuable if the underlying model can be rented somewhere else? Where is the bottleneck? What evidence could materially change the conclusion?

These are locks.

The purpose of a lock is to stop the analysis from floating into abstraction.

A beautiful product demo does not matter if you cannot identify the buyer. A persuasive pitch does not matter if you cannot identify where value actually accumulates. An impressive model does not create a durable business if all of the value disappears the moment another provider reaches comparable capability.

Lock first. Score second. Visualize third.

If the lock is missing, the system is allowed to stop.

That is a feature, not a failure.

The engine

Every job follows the same underlying path:

Intake → Route → Lock → Persist → Analyze → QA → Output Pack

The bigger picture

The most important implication of Grok Bot is not Grok Bot itself.

The product will change. Competitors will converge on similar architectures. Models will improve. Harnesses will become cheaper. Capabilities that look differentiated today will become platform primitives tomorrow.

That is precisely why the method matters.

If the model is rented and the harness can increasingly be rented too, the scarce layer moves upward toward proprietary context, operating logic, workflows, institutional memory, judgment, decision rules, approval structures, and domain-specific methods.

The model supplies intelligence.

The harness turns intelligence into persistent action.

The method determines whether that action is worth performing.

Channels add another layer: they let persistent agents become persistent teams.

That gives us the emerging hierarchy:

Model → Harness → Bot → Skill → Routine → Group/Channel → Method → Finished Work

The mistake is to treat all of those as the same thing.

They are not.

And the competitive advantage increasingly sits in how you compose them.

The next generation of AI products will not be judged only by the quality of their answers. They will be judged by how much real work reaches completion.

And the next generation of AI operators will not differentiate themselves because they have access to a better model. Everyone will have access to very good models.

They will differentiate themselves through the systems wrapped around those models: the context, the method, the workflows, the controls, the standards, the judgment.

That is what compounds.

The model is rented. Increasingly, the harness may be rented too. Own the method. Own the context. Own the junction.

With massive ♥️ Gennaro Cuofano, The Business Engineer

Life is wonderful because it is made of discovery.

And to me, that is exactly the point of analysis. Analysis is not about confirming the hypothesis you started with. The real pleasure comes when the evidence forces you to change your mind, when the result contradicts what you expected and reveals something you had not seen before.

I have spent my entire professional life analyzing businesses, partly out of passion, partly as a business executive and educator. What has always fascinated me is going beneath the surface to understand the structural patterns that explain what is actually happening.

That is where analysis becomes discovery.

This is where I stand.

NVIDIA’s Q2 print just came out, and to me it is the epitome of the Map of AI.

The Map of AI is my most rigorous attempt to track where we actually are in the AI Supercycle. Not where the hype says we are. Not where the skeptics want us to be. But where the underlying system is moving.

Because the real question is structural, and answering it requires nuance.

AI has become so divisive and politicized that most of the debate has collapsed into two camps. On one side, AI is snake oil: a speculative bubble, socially destructive, and largely a scam. On the other, AI is treated almost as an article of faith: the technology will transform everything, therefore every investment, company, and narrative attached to it must somehow be justified.

Neither position is analytical. And neither is particularly useful.

They do not help us understand what is actually happening, where value is accumulating, where bottlenecks are forming, what is durable, what is temporary, and where genuine excess is beginning to emerge.

I subscribe to neither camp.

My job as an analyst is to deconstruct the system. To separate structural change from speculation, infrastructure from narrative, durable economics from temporary scarcity, and technological transformation from financial excess.

If the AI Supercycle moves into genuine bubble territory, you will hear it from me.

If the evidence instead shows that AI is becoming one of the most consequential technological shifts of our generation, you will hear that too.

The objective is not to defend a thesis. It is to keep updating the map as reality changes.

Full Harness with The Executive Plan

If you’re already an Executive Plan member, simply head to Business Engineering to access the harness.

Read more

Thursday afternoon arrives with a pricing problem, a customer deployment slipping, a product question that cannot wait, and a presentation due in three hours. Under pressure, the organization falls back to instinct. The method stays on the shelf. The work does not wait for it. The usual response is to create more documentation: another checklist, another operating manual, another set of prompts, another page explaining how the company thinks. That can help, but it does not solve the structural problem. Anything that depends on somebody remembering to consult it eventually loses to urgency.

The alternative is to move the method into the machinery that produces the work. Instead of asking people or models to remember which framework applies, the system routes the problem to the right kind of reasoning. Instead of allowing every AI session to reconstruct the organization’s thinking from scratch, previous decisions become reusable artifacts. Instead of asking one model to produce and critique its own answer, opposing perspectives are wired into the review process. Instead of granting autonomy because the output looks convincing, autonomy is earned against explicit tests.

That operating architecture is what I call the Foundation Harness.

Full Harness with The Executive Plan

A harness is everything around the model that turns general intelligence into the work of a particular organization: the standing instructions, routing, memory, review system, guardrails, tools, evaluation suite, decision record, and feedback loops. The distinction matters because it establishes a property line. The models are rented. They become more capable, cheaper, and easier to replace. The method around them can belong to the firm. And that is the part that compounds.

The entire architecture follows from one principle: a harness is a machine for delivering the right instruction at the right time. Once you take that definition seriously, the problem becomes much more precise. Which instruction should arrive? For what kind of problem? Which perspective should produce it? What should survive after the work is finished? Which decisions should never be delegated? How should disagreements be resolved? And how do you know the whole system still works when the model underneath it changes?

Full Harness with The Executive Plan

If you’re already an Executive Plan member, simply head to Business Engineering to access the harness.

Read more

Now that AI has dramatically accelerated this process, I felt it was time to launch the Foundation Series.

The Forward-Deployed Engineer is another book in that series.

Subscribe To Get The New Book!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

The AI era has a distribution problem. Frontier models are extraordinary, but they are increasingly available to everyone. An insurer, manufacturer, bank, software company, and startup can all rent roughly the same underlying intelligence. The API is not the moat. Access to the model is not the deployment. Possessing frontier capability says remarkably little about whether an organization will ever turn it into operating value.

This is the paradox now showing up across enterprise AI. Capability is spreading faster than implementation. Model performance rises, inference gets cheaper, commitments to AI infrastructure grow, and yet an enormous amount of enterprise activity still dies somewhere between the demonstration and the P&L. That gap is the real market: the distance between what intelligence can do in principle and what a particular company can make it do inside its own systems, with its own data, under its own policies, around its own exceptions, with actual people accountable for the consequences.

The generic model knows none of this. It does not know that the supposedly standardized claims workflow actually branches into twelve exception paths; that the process diagram has not described the process for three years; that one spreadsheet maintained by a twenty-year employee quietly coordinates half the operation; that one risk will never survive compliance; that the ERP contains three definitions of the same customer; or that a step everybody officially follows disappeared from actual practice years ago.

The last mile is not merely technical integration. It is organizational reality. That is why the forward-deployed engineer has become one of the defining roles of the AI era.

An FDE is an engineer embedded at the customer’s constraint, building production machinery from the customer’s real work, with a second responsibility running in the opposite direction: what repeats in the field must eventually travel back into the product. Both directions matter. Without the first, the technology never truly reaches the customer. Without the second, the vendor becomes a consultancy.

The role therefore sits on one of the most valuable boundaries in the current economy: the boundary between general intelligence and specific work. Models can be deployed in minutes. Value takes longer because value has to be installed.

Subscribe To Get The New Book!

The New BE Library is Available Now!

The origin: one company, under pressure

Subscribe To Get The New Book!

The New BE Library is Available Now!

The role did not emerge from a human-resources exercise. It emerged because a company ran into a structural problem with its business model.

In the 2000s, Palantir was attempting to sell data software into some of the most complex institutions in the world. The promise of the platform was general, but the environments into which it landed were anything but general. Every customer had different source systems, schemas, operating processes, security constraints, definitions, politics, and ways of deciding what counted as truth. A generic platform could arrive technically complete and still be economically inert.

The missing component was not more software in the abstract. It was someone capable of crossing the boundary between the platform and the institution. So engineers went into the field. Not account managers who could describe the product. Not consultants who would study the organization and leave behind recommendations. Engineers who could understand the institution, touch the systems, build the implementation, and remain accountable for whether the thing actually worked.

That distinction created the forward-deployed model. The engineer lived close enough to the problem to discover what the product team could not see from headquarters. The customer’s real ontology emerged from the customer’s own data. The workflow emerged from watching the work. Requirements that had sounded important in meetings turned out to be irrelevant. Edge cases that had never appeared in specifications turned out to dominate production. The field became a source of truth.

The economics were equally important. The early phase of a customer relationship could be expensive. Engineers spent time learning an institution before the software produced meaningful leverage. In ordinary software economics, that looked ugly: high-cost people sitting with individual customers performing work that appeared difficult to scale. But the motion had a different logic: Acquire. Expand. Scale.

During acquire, the vendor absorbs the cost of understanding the institution. The field team learns the systems, vocabulary, workflow, constraints, and exceptions. Margins can be poor because the vendor is effectively financing discovery.

During expand, the first successful deployment creates evidence. Trust rises, adjacent workflows become easier to enter, and both sides now know the platform can produce value inside the customer’s actual environment.

During scale, the relationship changes character. The ontology already exists, the reusable infrastructure is in place, the customer understands the operating model, and new use cases can be layered onto what has already been learned. Field intensity per dollar of revenue falls, and the economics increasingly resemble software rather than bespoke services.

This is the essential trick: the field work is not supposed to remain field work forever. It is supposed to create leverage.

For years, this made Palantir easy to misunderstand. From the outside, a company employing large numbers of engineers around individual customers looked suspiciously like a consultancy wearing a software valuation. The criticism was not irrational. Any company can call services “deployment” and promise software will appear later. The test is whether the residue actually moves into the product.

That is what eventually matters. Patterns discovered across deployments become primitives. Repeated integrations become connectors. Recurring data structures become ontology patterns. Common controls become platform capabilities. Lessons paid for by one generation of customers harden into software sold to the next. The margins then tell the story.

What looked like an inefficient delivery model can become the manufacturing process through which the product itself is discovered. The field is part of R&D. The customer is not merely where the product is installed; the customer is one of the places where the product is found.

The role itself has changed as the underlying product has changed. At one point, the FDE might have been primarily concerned with platform stability. Then data integration became dominant. Then came turning data into operational decisions, enablement at scale, and now AI-speed deployment. Different vintages can look almost like different professions, but one continuity remains: the FDE owns the distance between technology delivered and outcome achieved.

AI has made that distance more important, not less. The modern model is vastly more general than the software stacks of the 2000s, but the organization it lands inside remains specific. In fact, the more general the intelligence becomes, the more valuable the installation layer can become, because the remaining problem concentrates around everything the generic model cannot know in advance.

That is why the old field-engineering idea has escaped its birthplace. The motion is spreading because the problem that created it has spread.

Why now

Subscribe To Get The New Book!

The New BE Library is Available Now!

Four forces have converged to make the forward-deployed model unusually important.

Commoditization above. Frontier capability is becoming easier to procure. A company does not need to train a foundation model to access world-class language, coding, vision, or reasoning capability. It can rent those capabilities from a growing set of providers, and the models continue to leapfrog one another. This pushes differentiation upward. If every serious competitor can access excellent models, the question becomes what each competitor builds around them: the harness, context, workflow, evaluation suite, permissions, integration, institutional knowledge, and operating design. The installation becomes the product.

Stall below. Enterprise appetite for AI is enormous, but appetite and deployment are not the same thing. Organizations can sign large cloud commitments, buy model access, run pilots, create task forces, and still fail to change how a meaningful workflow operates. The failure tends to happen where abstractions meet organizations. The demo assumes clean data; the company has seven systems. The workflow assumes the documented process; operators use another one. The agent assumes it can take an action; compliance requires approval. The model assumes context is available; the decisive information lives in a PDF, an inbox, a person’s memory, and a badly maintained database. These are not edge conditions. They are the enterprise.

Imitation across the market. The role that once looked idiosyncratic is being reproduced across the AI stack. Frontier AI companies, cloud providers, data platforms, and rapidly scaling applied-AI businesses increasingly use field-heavy engineering motions because all of them are discovering the same thing: the product does not finish at the API boundary. The interesting signal is not that companies copy a fashionable title. It is that companies with very different products keep rediscovering the same organizational structure.

The window. Every technology cycle contains a period in which humans manually perform the work that software will later absorb. The early web was full of hand-built pages before content-management systems standardized publishing. Early cloud adoption required armies of migration specialists before the process itself became increasingly automated. Enterprise AI is in the same phase.

Today, field teams manually discover workflows, structure context, build evaluation sets, identify failure classes, configure permissions, encode domain language, and wire agents into production systems. Some of that work will disappear. It is supposed to. The important question is who captures what is learned before it disappears.

Every deployment produces residue: recurring problems, common integrations, reusable ontology patterns, repeated evaluation structures, standard approval flows, predictable objections, common governance requirements. The company that captures that residue gets a roadmap paid for by real customers. The company that fails to capture it simply sells more labor.

The manual work of this decade is the raw material of the products of the next one.

The field is where that material is being generated.

What the role is — and is not

Subscribe To Get The New Book!

The New BE Library is Available Now!

The title is already suffering from its own success. “Forward-deployed engineer” can now mean implementation engineer, solutions architect, data engineer, customer engineer, technical account manager, AI consultant, product engineer, pre-sales engineer, or some hybrid of all seven. Titles are cheap. The structure is what matters.

A useful definition has three clauses: an engineer embedded at the customer’s constraint, building production machinery from the customer’s real cases, with an explicit duty to convert repeated deployment learning into product.

Each clause eliminates a neighboring role. Remove embedded at the customer’s constraint, and the engineer can remain technically excellent while being too far from the real problem. That is conventional product development. Remove building production machinery, and the role can diagnose, recommend, facilitate, and advise without ever carrying the outcome into operation. That is consulting. Remove convert repeated learning into product, and the company can become extremely good at bespoke implementation while never producing leverage. That is a body shop.

The FDE sits at the intersection.

This is also why the comparison with consulting is useful but incomplete. Traditional consulting built enormous businesses around a leverage pyramid. Senior judgment was scarce and expensive. Junior labor gathered information, created analysis, produced artifacts, and moved the project forward. The model scaled because many hours could be sold underneath a smaller number of senior people.

AI attacks the bottom of that pyramid first. Research, first drafts, analysis, reconciliation, formatting, documentation, and many forms of implementation can increasingly be performed by machines. The part that remains scarce moves upward toward judgment, architecture, domain understanding, trust, and accountability.

The forward-deployed model is almost the inversion of the old pyramid: send fewer, unusually capable people armed with enormous machine leverage; build the operating system instead of the recommendation; encode knowledge into the customer’s machinery and the vendor’s product; optimize not for utilization but for the speed at which customer-specific work becomes reusable capability.

This is why the FDE should not be measured as an expensive implementation resource. The right question is: what does each deployment leave behind? If the answer is only revenue, the motion is weak. If the answer is revenue plus customer capability plus reusable product knowledge, the motion compounds.

The motion, in five moves

Subscribe To Get The New Book!

The New BE Library is Available Now!

1. Pick the wedge

The first use case determines much of the engagement’s fate. Enterprise AI programs often begin with the wrong instinct: find the largest imaginable opportunity. The transformation office wants something strategic enough to justify executive attention, so the first project becomes a moonshot. That is usually backwards.

The first deployment should maximize the probability of producing a verified, meaningful win. Score the wedge against six properties: volume, whether the work happens often enough for improvement to matter; specifiability, whether the task can be described precisely enough for a machine to attempt it; verifiability, whether success and failure can be judged without relying entirely on opinion; pain, whether solving it matters enough that the organization will notice; then reversibility, whether early failures can be contained; and data proximity, whether the information required to perform the work is actually accessible.

This creates an important discipline: refuse both ends of the temptation curve. Refuse the moonshot whose prestige disguises terrible deployment characteristics, but also refuse the trivial automation nobody will care about. A tiny administrative win may be easy, but if nobody feels the outcome it generates no organizational momentum. The first deployment has to be small enough to succeed and important enough to recruit the second one.

The scorecard itself should become an artifact. Write down why the wedge was selected, why other candidates were refused, what success means, what must remain reversible, and what evidence will count. The FDE is already teaching the customer an important habit: AI deployments should be chosen by operating properties, not executive excitement.

2. Embed at the constraint

Once the wedge is selected, the real discovery begins. Most companies already possess process documentation. The FDE’s job is not to believe it.

The first phase is process archaeology. Watch the work happen. Ask what happens after the flowchart ends. Find the manual exceptions, duplicated data entry, emergency paths, informal approvals, CSV exports, shadow systems, and spreadsheets nobody mentioned. The gap between the official process and the practiced process is often where the product opportunity lives.

This requires humility. The engineer cannot arrive assuming the customer’s strange behavior is irrational technical debt waiting to be corrected. Many apparent workarounds exist because the formal system failed to encode an important constraint. The ugly spreadsheet may contain twenty years of institutional knowledge. Understand why it exists before replacing it.

Everything discovered should move into a durable record from day one: terms, exceptions, decisions, policies, source systems, known failure modes, ownership, escalation paths. The deployment should progressively externalize the process from people’s memories into something humans and machines can inspect.

At the same time, construct the golden set. Not synthetic cases and not vendor-created demos: real cases drawn from the customer’s historical work, adjudicated by the people who know what correct means. Sixty, eighty, a hundred cases can reveal an enormous amount if selected properly: routine work, difficult edge cases, known failures, policy boundaries, ambiguous inputs, and examples where experts themselves disagree.

The customer’s expert should sign the set. Once the evaluation suite belongs to the customer, the conversation changes. The vendor is no longer grading its own homework. The suite becomes a neutral referee between product enthusiasm and operational reality.

3. Build what compounds

Once the process is understood and the golden set frozen, the FDE builds the working system. The model sits behind a clean joint. The customer’s record supplies context. Their red lines become controls. Their repeated standards become reviewer instructions and mechanical checks. Their permissions determine what the system may touch. Their escalation structure defines where autonomy stops.

The objective is not to create a magical demo. It is to build a unit whose performance survives contact with the customer’s real cases.

This is also where AI changes the cadence of field work. Historically, the customer explained what was wrong, the vendor took notes, engineers returned elsewhere, changes entered a backlog, and another review happened days or weeks later. Agentic engineering compresses this loop.

Arrive with something built. Let the customer break it. Capture why it failed. Feed the objections back into the system. Rebuild. Run the suite again. Return in hours rather than weeks. Repeat.

A team capable of completing ten serious iteration cycles while another completes one is not merely moving ten times faster. It is learning under a different compounding function. Each turn changes the next: the procedure becomes sharper, context cleaner, exceptions explicit, evaluation harder, guardrails more precise, and both sides understand the actual problem more deeply.

This is iteration compounding. Trust stops being theatrical and becomes empirical. The field role begins manufacturing something more valuable than an implementation: it begins manufacturing fit between a general model and one organization’s substance.

4. Publish the numbers

AI programs do not scale on enthusiasm for long. They scale when somebody can point to an operating panel.

Once the first unit works, measure it visibly. How many human minutes does one accepted outcome require? What percentage of cases pass on the first attempt? How many failures are repaired inside the machine loop without human intervention? What is the cost per accepted outcome? How often does the system escalate? What happened to cycle time? How is performance trending against the customer’s frozen suite?

These are more useful than generic model benchmarks because they measure the thing the business actually bought.

Publish them. Weekly if necessary. Numbers create a different internal sales motion. Adjacent teams no longer hear that AI could transform a workflow. They see that another team has already returned hundreds of hours, shortened a process, reduced error, or increased throughput. The customer starts bringing the next use cases to the vendor.

At this point the deployment architecture should begin splitting in two. There are the retail units: individual workflows, each with its own charter, context, evaluation suite, and owner. Beneath them sits the wholesale substrate: shared identity, permissions, record, observability, model routing, evaluation infrastructure, and governance.

The first few deployments can tolerate duplication. The tenth cannot. Around the third serious unit, the FDE should already be asking which components are customer-wide rather than workflow-specific. That is how each next deployment becomes cheaper than the previous one.

5. Harvest the residue

This is the move that decides whether the FDE motion becomes a software company or an expensive delivery organization.

Every engagement produces specifics, and most should remain specific. But across enough deployments, patterns repeat. The harvest has three levels.

Playbook. A recurring deployment lesson becomes written method. The next team does not have to rediscover it, so deployment time falls.

Toolkit. The pattern repeats often enough that documentation is no longer sufficient. It becomes reusable machinery: templates, evaluators, connectors, schemas, libraries, deployment primitives. Deployment cost falls.

Product. The pattern has repeated across enough customers, under enough variation, that it deserves to become part of the standard platform. Now the business model changes.

The hierarchy is simple: Playbook → Toolkit → Product. Every promotion converts experience into leverage.

If an organization performs fifty deployments and number fifty costs roughly what number one cost, it has learned remarkably little. If number fifty contains the accumulated residue of the previous forty-nine, the field has created a compounding asset.

There is an important ownership boundary. The customer’s substance belongs to the customer: their data, confidential context, proprietary operating decisions, business rules, and specific process knowledge should not become somebody else’s asset simply because an engineer helped encode them. But the generalizable pattern discovered through solving the problem can belong to the vendor, subject to the contractual structure both sides agreed to.

And there is a deeper implication. If the motion succeeds completely, parts of the FDE’s own work should disappear. Process discovery becomes partially automated. Integration gets easier. Evaluation construction becomes assisted. Standard governance patterns become product features. The next FDE does less manual work than the previous one.

This is not a threat to the role. It is the objective.

The job of the forward-deployed engineer is, in part, to automate the job of the forward-deployed engineer.

The firm that understands this harvests its field organization into product. The firm that does not eventually discovers it has built a consultancy with unusually technical employees.

The two sides of the table

There is a reason enterprises should both want the FDE model and fear it. An engineer embedded deeply enough to reconstruct your operating machinery can create extraordinary capability transfer. The same engineer can also help create one of the deepest vendor dependencies an organization has ever accepted. Both statements can be true. The difference is architecture.

For the buyer, the governing concept is institutional sovereignty: the organization’s ability to retain control over the decision rights of its own business even when outside intelligence, software, and infrastructure are deeply embedded inside it.

Four exposures matter. Lock-in: once AI becomes part of a production process, replacing it can become much harder than changing an ordinary SaaS application because context, evaluation sets, workflows, policies, and human behavior begin adapting around it. Subsidy: consumption paid to an outside intelligence provider may finance a company that eventually moves into adjacent parts of your own value chain. That does not automatically make the relationship irrational; it makes the dependency worth pricing. Rule change: a vendor can alter model behavior, pricing, terms, limits, or product architecture. In consumer software this may be irritating; in a plant, hospital, bank, insurer, or ministry it can be operationally intolerable. Cost: not every task needs frontier intelligence, and using the most capable model for routine work can turn technological ambition into structurally poor unit economics.

Sovereignty is therefore not binary. It is a gradient. At one end, the enterprise relies heavily on external providers but protects itself contractually and architecturally through portability, data rights, clean interfaces, and tested exit procedures. Further along, it owns more of the harness, context, evaluation infrastructure, and operating logic while continuing to rent models. At the structural end, particular workloads may justify owned infrastructure or task-specific models.

Different processes deserve different answers.

The deepest asset in this analysis is the decision loop: data seen → reasoning applied → action taken → outcome observed. A warehouse of raw records tells you what happened. A decision loop begins to tell you what the organization saw, what it believed, what it did, and whether the decision worked. That is far richer material from which increasingly specific intelligence can be built.

Whoever owns the loop owns the compounding.

The contract should therefore be written around artifacts, not vague assurances. The ownership schedule should be a table. Who owns the raw data? Derived context? Evaluation suite? Procedures? Deployment-specific code? Generalized components? Logs? Corrections? The record of model decisions? Can each artifact be exported, in what format, and how often is portability actually tested?

“Portable” should not mean a salesperson promises that migration is theoretically possible. It should mean someone has demonstrated the export.

The same principle applies to commercial structure. AI pricing increasingly follows two variables: attribution and autonomy. When the product assists a human and the connection between software and business outcome is weak, seat pricing remains natural. When the system works autonomously but the value of each completed task is difficult to attribute cleanly, usage pricing can make sense. When the system owns a clearly verifiable business result, outcome pricing becomes possible.

But outcome pricing creates an uncomfortable requirement: someone has to stand behind the outcome.

That is another reason the forward-deployed role matters. The FDE is not merely there to configure software. The FDE can become the person who creates enough operational certainty for the vendor to move from selling access to selling results. The stronger the guarantee, the stronger the need for somebody technically credible to own the reality underneath it.

Then comes the handover. A field engagement should not finish when the vendor believes the system is complete. It should finish when named customer operators can run it, hands off. The acceptance test should include routine operation, failure handling, escalation, context updates, evaluation, and recovery.

That yields the only reference worth having: the customer could leave, and chooses to expand instead.

Lock-in is weak evidence of value. Voluntary dependence after proven portability is much stronger.

There is also a point at which enterprises should stop purchasing the motion and build their own. Four conditions push toward internalization: strategic workflows, regulatory density, data gravity, repeat volume across business units. If one is present, negotiate ownership and portability aggressively. If all four are present, ask the harder question: are we paying somebody else’s margin to accumulate operating knowledge that should compound inside our own institution?

For those firms, the internal FDE practice becomes strategically attractive. The motion looks similar, but the economics invert. The practice is funded by the P&L it improves rather than an external sales organization. Internal sponsorship replaces selling. Deployment residue accumulates into the enterprise’s own harness. The knowledge base becomes institutional memory. Evaluation suites become company assets. The organization’s experts become teachers of the system.

The correct shape is not scattered AI enthusiasts inside independent business units. It is a central practice deploying into the units and bringing the accumulated method home: local intimacy, global compounding.

The career

Subscribe To Get The New Book!

The New BE Library is Available Now!

For an individual engineer, the forward-deployed seat is unusual because it sits diagonally across disciplines the labor market traditionally separated. Most career systems reward depth along one axis. The FDE requires depth across several, and that scarcity creates the opportunity.

The skill stack has four layers, in order.

Engineering depth. Not theoretical familiarity with AI, but the ability to take an ambiguous workflow and turn it into an operating unit: define the charter, access the systems, construct the context, build the evaluation suite, implement the harness, create gates, instrument the workflow, and read the gauges. The role loses its center if the engineer cannot build.

Domain fluency. The FDE does not need to begin as the world’s greatest insurance adjuster, manufacturing planner, banker, or supply-chain operator, but they need to learn the domain at practitioner grain. Vocabulary is not enough. They need to understand where judgment enters, which exceptions matter, why the process evolved the way it did, what failure costs, which data is trusted, and which shortcut an experienced operator notices instantly.

Field craft. The ability to conduct process archaeology without humiliating the people who built the process; absorb skepticism without becoming defensive; distinguish a political objection from a technical one; recognize when the room is telling you the system failed even though nobody will say it directly; bring something imperfect into the room early enough that the customer can correct it; and translate between the person doing the work and the executive funding the transformation. These are not soft skills. They determine whether the engineering reaches reality.

Commercial literacy. The FDE sits too close to the economics of deployment to remain commercially naive. They should understand the ownership schedule, where implementation effort is being subsidized, which pieces create reusable product leverage, when an outcome can be priced, and whether the current contract is building the customer’s moat, the vendor’s moat, or both.

The engineer who understands these things can turn deployment into strategic position. The engineer who does not may spend years building somebody else’s compounding asset for a salary.

There is also a natural ladder inside the role. At the first rung, the engineer proves they can operate as a second chair, with an artifact as evidence: an evaluation suite the customer accepts, an integration that survives production, or a subsystem that can be handed over. The next rung owns the wedge, one use case from discovery through measured production. The next owns the engagement, including multiple units, governance, substrate, and handover. Then comes the cascade lead, responsible for turning one working deployment into a program across teams or business units. At the top sits the principal, whose real artifact is the harvest: what became playbook, toolkit, and product across the portfolio.

Promotion in this career should run on exhibits, not tenure.

The title itself should be interrogated carefully. Because the role has evolved through several vintages, two people can both be called FDE while holding radically different jobs. Ask what vintage the seat is. Is it really platform reliability? Data integration? Workflow engineering? Customer enablement? AI-native rapid build? Is it post-sales or pre-sales? Does the engineer write production code? Who owns the outcome? Who owns the customer relationship? What percentage of learning is expected to flow back into product?

The title tells you very little. The operating model tells you almost everything.

The career paths out of the seat are particularly interesting because they all monetize the same asset: deployment residue. One path leads into product leadership, carrying unusually rich knowledge of what paying customers actually needed. Another builds the practice, scaling the motion itself. A third leads to founding: if the same painful pattern appears across three independent deployments, the FDE may be staring at a company before the market has named it. A fourth crosses the table and builds the internal enterprise motion, bringing the field discipline inside a large organization.

That is why the deployment record can become an extraordinary startup thesis. Many founders begin with an imagined market problem. The FDE can begin with one already observed repeatedly under production conditions, attached to real budgets, failure modes, and buyers.

The seat’s compensation is the salary. The career’s compensation is the residue.

Building the motion, and what it buys

Subscribe To Get The New Book!

The New BE Library is Available Now!

A company should not begin by hiring twenty forward-deployed engineers. It should begin by proving that there is something worth deploying repeatedly.

The motion starts after the pattern. Founders or a small core team should first complete two or three deployments themselves. They need evidence that the same class of problem appears repeatedly and that solving it creates meaningful customer value. Hiring a field organization before discovering the wedge creates a dangerous structure: a body shop with a software narrative.

Once the pattern exists, build around a founding pair. One side owns the technical outcome; the other owns the commercial and organizational motion around it. Exact titles matter less than complementarity. Enterprise deployments fail for both technical and political reasons. Somebody has to build the machinery, and somebody has to help the customer create the conditions under which the machinery will actually be adopted.

Then build the operating system before adding headcount. First, the deployment record: every engagement should produce comparable artifacts, including the wedge scorecard, process map, golden set, architecture, ownership schedule, gauges, decision log, and handover result. Second, the harvest channel: there must be an explicit process through which repeated field patterns are reviewed for promotion into playbook, toolkit, or product. If the path is informal, field knowledge remains trapped in individual teams. Third, the meters: the organization must know whether the motion is becoming more leveraged over time.

Only then scale.

The early team should not be built entirely from mythical perfect FDEs because the profile is too scarce. A better structure combines experienced principals with diagonal-in-progress people who have one strong axis and can learn the others in the field. A domain operator who becomes technical may be more valuable than a generic engineer who never learns the domain. A production engineer with unusual customer instinct may grow faster than a conventional solutions person.

The apprenticeship matters. The field is where the profile is finished.

Six meters tell the company whether the motion is compounding. Time-to-magic: how long from engagement start to the first verified result on real customer work? Expansion rate: how reliably does one successful unit recruit the next? Outcome conversion: how much revenue is moving from access or effort toward measurable results? Productization rate: what share of repeated field learning becomes reusable toolkit or product? Margin trajectory: do the economics of an account improve as the relationship matures? Title cleanliness: are the FDEs actually doing forward-deployed engineering, or has the role become a bucket for every difficult customer problem the organization does not know where to place?

The last meter is more important than it sounds. A role without boundaries becomes an organizational dumping ground. FDEs are unusually capable, so organizations will try to give them everything: demo the product, fix the integration, write the feature, handle the escalation, run the workshop, support the account, close the deal, train the users, create the roadmap. At first this can look like leverage. Eventually it destroys the motion because the people responsible for harvesting the most valuable deployment knowledge spend their time absorbing miscellaneous organizational failure.

A durable FDE organization therefore needs a refusal log. Which engagements did we decline? Which customer requests do not belong to this motion? Which “strategic” projects failed the wedge scorecard? Which integrations should become standard product rather than field work? Which recurring requests reveal an upstream product defect?

Refusal prices discipline.

Then come the returns. The first is revenue with proof attached. Field engineering can unlock contracts ordinary software sales cannot because the customer sees the product working on its own substance before being asked to imagine the value.

The second is a demand-side moat. After enough deployments, the company possesses something competitors cannot reproduce by copying features: a detailed map of what hundreds of real organizations actually require for the technology to work.

The third is the product itself, and this is the most important. The field organization becomes an external sensory system for product development. Instead of a roadmap assembled from abstract feature requests, the company receives repeated patterns exposed through paid production work. Customers fund the discovery. Engineers validate the requirement. The harvest system identifies recurrence. Product absorbs the stable pattern. The next deployment begins further ahead.

That is the flywheel.

The fourth return is position. The company operating a successful forward-deployed motion sits exactly where the economics of the AI era become interesting: the point where abundant general intelligence meets scarce, contextual, proprietary work. That junction contains the customer relationship, context, exceptions, operating feedback, evaluation standard, and evidence of value.

The model layer may continue commoditizing. This layer does not necessarily commoditize with it. It can become more important because as raw intelligence becomes abundant, the scarce question shifts from Who has the smartest model? to Who knows how to make intelligence work here?

The Library — Mental Models of the Playbook

The ground

• The Last Mile: capability is increasingly available; installed value is not.

• Deck vs. Machine: the test of a deployment is what continues operating after the presentation and the people who made it leave.

• Product Development in the Field: deployment is not downstream from product development; properly structured, it is one of its inputs.

• The Three Stalls: data, adoption structure, and trust are where abstract capability most often encounters institutional reality.

• Time-to-Magic: the distance from kickoff to the first verified win on the customer’s own cases.

• The Vintages: the FDE title has covered several different jobs; accountability for the customer outcome is the continuity.

The motion

• The Wedge Gates: volume, specifiability, verifiability, pain, reversibility, and data proximity. Score before building.

• Process Archaeology: study the process as practiced rather than the process as described; the undocumented layer often contains the product.

• The Golden Set: real, adjudicated cases signed by the customer’s expert become the engagement’s neutral referee.

• Agent Cadence: arrive with something built, invite the customer to break it, rebuild while the context is still fresh.

• Iteration Compounding: radically shorter feedback loops create more than linear speed because every correction changes the next attempt.

• Graduate in Public: agree on thresholds before seeing the result and publish performance against them.

• Retail Units, Wholesale Substrate: individual workflows remain local; identity, context, permissions, evaluation, and observability become shared infrastructure.

• The Residue Hierarchy: playbook, toolkit, product. Every promotion converts experience into leverage.

• The Job Is to Automate the Job: field work that repeats should progressively disappear into the product.

The two sides

• The Capture Question: embedded engineering can create rapid capability transfer or deep dependency; architecture determines which.

• Institutional Sovereignty: the enterprise retains control of its own operating decision rights.

• The Sovereignty Gradient: rent or own depending on consequence, strategic importance, regulatory density, and portability requirements.

• The Decision Loop Is the Alpha: data seen, reasoning applied, action taken, result observed; whoever controls the loop controls the richest form of organizational learning.

• The Ownership Schedule: every artifact has an owner and an exit test.

• Attribution × Autonomy: seats, usage, and outcomes correspond to progressively stronger relationships between machine action and measurable value.

• The Guarantee: outcome pricing requires somebody capable of standing behind the outcome.

• The Handover Test: complete means customer operators run it unaided.

• The Four-Part Test: strategic workflow, regulatory density, data gravity, repeat volume. The more boxes checked, the stronger the case for building the motion internally.

• The Central Practice: deploy locally, accumulate globally.

The team and the career

• The Diagonal Hire: the rare profile combines technical depth, domain learning, field temperament, and product instinct.

• The Skill Stack: machinery, domain, field craft, commercial literacy, in that order.

• The Rung Ladder: second chair, wedge owner, engagement owner, cascade lead, principal; each rung proved by an artifact.

• The Vintage Question: before accepting the title, ask which version of the role the company actually means.

• The Four Arcs: product, practice, founding, enterprise; each monetizes deployment residue differently.

• Start After the Pattern: scaling field headcount before proving a repeatable wedge creates services economics by default.

• The Founding Pair: technical outcome and organizational change need owners from the beginning.

• The OS in Order: deployment record, harvest channel, meters, then headcount.

• The Six Meters: time-to-magic, expansion, outcome conversion, productization, margin trajectory, title cleanliness.

• The Refusal Log: what a field organization declines reveals whether it possesses a discipline or merely a willingness to help.

With massive ♥️ Gennaro Cuofano, The Business Engineer

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.

Subscribe To Get The New Book!

The New BE Library is Available Now!

Subscribe To Get The New Book!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

The design problem — building on ground that moves

Subscribe To Get The New Book!

The New BE Library is Available Now!

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.

The four choices — VTDF, run forward

Subscribe To Get The New Book!

The New BE Library is Available Now!

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.

The positions — the map as a site plan

Subscribe To Get The New Book!

The New BE Library is Available Now!

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.

The moats — what compounds, and what quietly stopped

Subscribe To Get The New Book!

The New BE Library is Available Now!

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 context, then the place where that context is governed, updated, and permissioned becomes strategically important. Paradoxically, easy export can strengthen residence. Customers are more willing to consolidate around a system they know they can leave.

Clearing and standing also become more valuable when production becomes cheap. If producing plausible content, software, recommendations, or transactions becomes almost costless, the scarce element shifts toward knowing who stands behind the output.

Identity, verification, settlement, accountability, reputation, and liability therefore gain weight as generated supply expands.

Standards can compound too. A successful standard makes coordination cheaper for everyone else while increasing the strategic importance of the infrastructure around it. The language is open; the position created by adoption may not be.

And physical scarcity remains real. AI does not repeal physics. Land, energy, fabrication capacity, logistics, and other constrained physical assets can still produce durable power when scarcity is genuinely structural rather than temporary.

Other familiar moats are becoming weaker. Superior access to a frontier model does not last long when the frontier moves every few months. Feature velocity loses defensive value when competitors can reproduce functionality in weeks. Raw data volume is frequently overrated. A large pile of information is not equivalent to proprietary, corrected, permissioned context embedded in a working system.

Headcount is less defensible when small teams can operate with dramatically greater leverage. And aggregated attention around information that can be summarized elsewhere becomes fragile when another interface controls discovery.

The useful test is simple: What does the company do every day that makes it harder to compete with tomorrow?

If there is no concrete answer, the moat probably exists mainly in language.

The architect’s five moves

Subscribe To Get The New Book!

The New BE Library is Available Now!

Choose the layer. Do not begin by deciding what company you would like to resemble. Begin with the economic position available to you.

Map where value enters the system, where it accumulates, where scarcity appears, who controls distribution, and which functions cannot easily be bypassed. Then place the company on that map using its actual economics.

The important second step is matching the position to the company’s endowments. A technically attractive layer may still be the wrong one for a firm without the capital, credibility, channel, installed base, or regulatory standing required to win there.

Architecture begins where aspiration meets constraint.

Design the capture. Creating value and capturing value are different acts. A business can become essential to an ecosystem while allowing somebody else to monetize most of the value it creates.

The architect therefore has to place the meter. Where does payment occur?

The strongest meters tend to sit close to moments that are difficult to abstract away: settlement, commitment, consumption, access, residence, scarce capacity, or a measurable outcome. The weakest often sit several layers upstream, attached to activities that technology can reproduce or intermediaries can bundle away.

A good capture point has another property: it produces information. When pricing is attached directly to economically meaningful activity, revenue becomes a sensor. It tells the company how the system itself is changing.

The meter is therefore not only a monetization mechanism. It is also an instrument panel.

Price the dependency. Every architecture contains dependencies. The objective is not to eliminate them. That would usually be absurdly expensive. The objective is to know what kind of dependency you are accepting.

For each major supplier, model, cloud provider, marketplace, API, channel, or infrastructure partner, price three forms of exposure.

The toll: what happens if the counterparty raises the price?

The gate: what happens if access is restricted or withdrawn?

The learning: what does the counterparty learn from the activity flowing through it, and can that learning eventually be used against you?

The third is the easiest to ignore because it rarely appears on an invoice.

Once the exposure is understood, design the joints accordingly: alternative suppliers, portable data, modular interfaces, contractual protections, separation of proprietary learning, rehearsed migration paths.

A dependency deliberately accepted at design time is leverage. The same dependency discovered during a contract renegotiation is leverage held by somebody else.

Sequence the build. Architecture is temporal. Two companies may want to reach the same destination and require completely different sequences to get there.

Some assets become disproportionately expensive to acquire later: trust, ecosystem neutrality, customer permission, standards influence, proprietary context. Those may deserve early investment.

Other capabilities should initially be rented precisely because the company does not yet know enough to justify owning them. The architecture should therefore contain explicit conversion points.

Rent while learning. Own when control begins to matter. Integrate vertically only when the economics, learning, or strategic risk make ownership worth the additional capital.

The destination matters. The order in which you build toward it often matters more.

Design for the rotation. Finally, assume that some important part of the environment will change. Do not pretend to know which one.

Instead, locate the joints where change is most likely to hit the business. Can the model provider be replaced? Can the distribution channel disappear? Can compute costs rise? Can the regulatory regime change? Can a current bottleneck become abundant? Can the layer immediately above or below you integrate into your position?

Then decide which parts of the architecture need reversibility.

Modularity has a cost. Redundancy has a cost. Optionality has a cost. Treat those costs explicitly as insurance premiums rather than inefficiencies to be optimized away.

And write down the assumptions carrying the structure. Every important architectural assumption should have a corresponding observable that would cause the company to reconsider it.

Otherwise companies do not update when the evidence changes. They update when the pain becomes impossible to ignore.

The practice — and a dated reading

Subscribe To Get The New Book!

The New BE Library is Available Now!

Architecture is not a founding exercise. It is a continuing practice.

A company gradually accumulates decisions made for conditions that no longer exist. A distribution agreement becomes sacred because it has always been there. A technology choice becomes identity. A business line acquires political protection. A temporary market condition quietly becomes embedded in the financial plan.

None of this requires incompetence. It is simply what organizations do.

Architectural discipline therefore needs a cadence.

Quarterly, revisit the assumptions supporting the design. Not every assumption. Only the ones that would materially change the architecture if they stopped being true.

Ask: What did we learn this quarter that weakens one of the assumptions on which this business was designed?

Once a year, go further. Run the clean-sheet test.

Imagine the company did not yet exist. Given today’s technology, customers, competitors, capital costs, channels, and constraints, what would you build?

Then compare that design with the company you actually have.

The existing company does not need to match the clean-sheet version. Incumbents possess assets a startup does not: customers, trust, cash flow, infrastructure, data, capabilities. But the difference between the two designs should be explainable.

If the only argument for the existing architecture is that changing it would be inconvenient, the exercise has found something important.

Keep a record of the options deliberately rejected as well. Companies remember what they chose. They are much worse at remembering what they considered and declined.

Yet those refusals contain some of the most useful information about management judgment. Years later, they make it possible to distinguish a bad decision from a reasonable decision made under different information.

The operating panel for the architect should therefore be small. Track whether capture is strengthening or leaking. Track whether mature margins are moving toward the architecture’s original thesis. Track dependency concentration. Separate profits produced by temporary tightness from profits produced by structural advantage. Measure whether the mechanisms described as moats are actually accumulating. And track whether the options required to survive adverse states are still alive.

A dated reading of the AI cycle in the third quarter of 2026 would say that the market is rewarding positions close to unavoidable flows and scarcity while putting pressure on layers where value creation is easier to reproduce than value capture.

That reading will expire. It is supposed to.

The purpose of an architectural framework is not to preserve today’s answer indefinitely. It is to preserve the method that allows the answer to change without losing coherence.

That is the distinction between a strategy and a story.

A story describes why the current configuration makes sense. Architecture explains why the structure should survive when the configuration changes.

Which brings us to the central claim of the book: strategy, in a rotating environment, is structure.

Not rigidity. Structure.

A clear position in the system. A deliberate point of capture. Dependencies understood before they become constraints. Joints designed where change is likely to strike. A financial model capable of carrying the load. And a discipline for revisiting the assumptions before the environment revisits them for you.

The library: selected models of the architect’s discipline

Subscribe To Get The New Book!

The New BE Library is Available Now!

On the environment

• The Rotation Mismatch — markets can reprice faster than companies can rebuild. Design around the movement of constraints, not the location of today’s bottleneck.

• Templates Are Frozen Answers — every business playbook encodes assumptions about a particular technological and economic era. When those assumptions move, return to the questions rather than defending the template.

• Stories Expire With Constraints — the narrative surrounding an industry is often strongest precisely when the conditions producing it are closest to changing.

• Software Acquires a Cost of Goods — AI gives software a meaningful variable cost. The architecture must therefore include a mature-margin thesis and control over the forces that determine it.

On the four choices

• The Value Subtraction — remove what cheap intelligence makes abundant. Look for economic value closer to commitment, context, clearing, trust, accountability, and desire.

• The Design Barbell — rent rapidly commoditizing technology; own the components that determine differentiation, accumulated learning, strategic control, or long-term economics.

• Distribution First — the channel shapes the product, customer relationship, economics, and data flows. Choose it as part of the architecture, not as an afterthought.

• The Rented Front Door — third-party distribution provides reach in exchange for dependency. Treat it accordingly.

• Capital Intensity Is a Choice — capital should buy a position durable enough to justify the balance-sheet exposure it creates.

• The Terminal Margin Is the Whole Position — mature economics reveal where the company actually sits in the value chain once temporary distortions disappear.

On positions and moats

• The Site Plan — constrained input, junction, rail, substrate, endpoint, commodity seat: recurring positions with different relationships to scarcity, capital, customers, and capture.

• Tightness Rent vs. Monopoly Rent — distinguish returns created by temporary scarcity from returns created by a position that remains difficult to bypass.

• Own the Station the Constraint Returns To — the strongest architecture often sits where flows reconverge after the bottleneck moves.

• Rent-to-Contract — temporary scarcity can be converted into more durable economics through contracts, standards, installed base, and ecosystem structure.

• The Accumulated Fit — defensibility emerges from the repeated adaptation among models, context, workflows, corrections, and human judgment.

• Residence — the place where important work and context accumulate becomes progressively harder to remove from the system.

• The Retired Moats — model access, feature velocity, raw data volume, headcount, and intermediated attention provide less protection when their underlying scarcity disappears.

• The Daily-Mechanism Test — if ordinary operation does not strengthen the claimed advantage, it is not a compounding moat.

On the moves and the practice

• The Meter — place monetization close to economically irreducible activity and use it as a sensor for how value is moving through the system.

• Priced Dependency — measure toll, gate, and learning exposure before committing the architecture to an external counterparty.

• Sequence Beats State — rent while learning, own when control matters, and acquire early the assets that become difficult to add later.

• Design for the Rotation — build modularity, reversibility, options, and explicit falsification points into the structure.

• The Clean-Sheet Test — periodically compare the inherited company with the one you would build today and force the differences to justify themselves.

• The Standing Structure — strategy is the part of the design that continues to make sense after the environment changes.

With massive ♥️ Gennaro Cuofano, The Business Engineer

Who — or what — does the work today? Where is the work checked, and by whom? Which decisions stay human, and is that written down anywhere? And after the tools are adopted, the workflows rebuilt, the vendors installed: what does the firm still own?

These questions are live in every organization in the economy, and most writing about AI and work does not answer them. It debates headcount. It demos tools. It predicts, in both directions, with great confidence.

Meanwhile, the operating question — how should a firm be designed when machines generate, and humans judge — goes largely unaddressed, because it belongs to no one: too technical for the strategy shelf, too organizational for the engineering blog.

This is an operating-model question, and operating models have always followed one law: the firm reorganizes around whatever just became expensive. When labor was expensive, the assembly line. When coordination was expensive, the integrated corporation. When distribution was expensive, channel power. Each era’s scarce input set its winning design.

So name what just became cheap, and everything follows. What became cheap is generation — the production of competent first versions of knowledge work. Drafts, code, analyses, campaigns, contracts: the cost of a competent first version has fallen by one to two orders of magnitude in a few years, and it is still falling.

But generation was only one stage of the work. Around it sit the stages that did not get cheap: framing what is worth doing, checking whether the competent-looking artifact is actually right, and committing the firm’s name to it. Run the capacity test on any real organization — if generation doubled tomorrow, would committed, correct output double? Almost never. The queue has moved. When generation becomes cheap, judgment becomes the binding constraint of the firm — and by the old law, the firm’s economics, its scarce roles, and its power now reorganize around judgment.

The person who runs that reorganization — who designs the workflows, holds the checkpoints, decides what is delegated and what is not — needs a name, because the role already exists everywhere even where no title has caught up with it. Call them the business orchestrator. The engineer of this Library’s Foundation Volume reads the system from outside. The orchestrator runs it from inside.

What follows is the discipline, compressed: the evidence, the unit, the organization, the five moves, the property lines, and the practice.

Subscribe To Get The New Book!

The New BE Library is Available Now!

Subscribe To Get The New Book!

If you’re already a paid member, simply reply to this email, and we’ll send it your way.

The evidence — both halves of it

Subscribe To Get The New Book!

The New BE Library is Available Now!

The claims above no longer rest on anecdote. They rest on the two strongest evidence classes available: a pre-registered field experiment at industrial scale, and audited financial statements.

The experiment is “The Cybernetic Teammate” — Dell’Acqua, Lakhani, and colleagues, Organization Science, 2026 — run inside Procter & Gamble: seven hundred ninety-one professionals, real product-development work from their own business units, randomly assigned to work alone or in pairs, with or without an AI assistant, output blind-scored by human evaluators. It is, at this writing, the largest and best-designed test of AI-assisted knowledge work on record. Three findings form the empirical spine of the discipline.

First: the bottom of the expertise ladder dissolves. Individuals with the assistant performed at the level of two-person teams without it. Professionals working outside their specialty matched teams that included a specialist. The competence that used to define the lower and middle rungs of knowledge work is now available on demand, to anyone, in seconds.

Second — and this is the finding the discipline refuses to soften: the same tool measurably erodes judgment. When participants had to select the best of several candidate outputs — the exact activity the new operating model concentrates value in — those working with the assistant did markedly worse: selection accuracy fell from roughly one-in-two to roughly one-in-three. The mechanism is the tool’s fluent, agreeable confidence, which makes weak candidates look strong. And assisted participants produced better work while feeling less sure of it — the tool decouples the feeling of judgment from its accuracy, in both directions.

Third: the staircase is missing. The lower rungs were never just output — they were the apprenticeship through which judgment was built. If their output is now free, the economic reason to make humans climb is gone, and with it the by-product the climb produced.

And a fourth reading sits beneath the three, reframing a century of assumptions about collaboration itself. The study’s deepest result is not that the assistant makes individuals faster — it is that the assistant substitutes for a measurable part of what teams existed to do. Assisted individuals replicated the breadth teams were assembled to provide: the blend of technical and commercial perspective that used to require two differently-shaped professionals in a room. The tool behaved less like software and more like a teammate. The consequence cuts both ways. Downward: the standing working pair assembled for perspective coverage is no longer automatically justified — which is exactly why the season’s revenue-per-head numbers move. Upward: what teams still add is the one thing the machine-teammate cannot supply and actively erodes — independent judgment lines. A team whose members converge on the assistant’s confident output has the headcount of a group and the error profile of an individual. The group’s new job is judgment diversity by construction — blind parallel calls, independent checks, disagreement treated as signal.

The financial half is briefer because it is unambiguous. In the most recent earnings season, one infrastructure company booked a restructuring charge of roughly a hundred and fifty million dollars to reorganize around agentic operations — headcount down a seventh in one quarter, revenue per employee up a third, growth accelerating through the change. An enterprise-software maker crossed a billion dollars of AI annual contract value without owning a frontier model. The reorganization is no longer a forecast. It is a line item.

The unit — and the one distinction that decides everything

Subscribe To Get The New Book!

The New BE Library is Available Now!

The unit of the new operating model is not the model and not the employee. It is the harnessed agent: software executing a defined flow, a human judging defined checkpoints. Its anatomy is nine elements in four bands — the model (rented, interchangeable); the harness (orchestration, tools, memory, grounding, self-checks, evaluations); the context (the firm’s own data, definitions, and corrections); and the enclosure (the runtime that separates capability from blast radius).

One published demonstration is the charter of the whole design: an open-weight model at a tenth of frontier cost matched frontier task performance — and the buried clause carried the meaning: the model was never retrained. All the gain came from tuning what surrounds it. The performance of a working agent lives less in the model than in the fit of everything around it — model, harness, and context adapting to one another in a loop. Which means benchmarks mislead by construction, cheapness is a capability (a tenth of the cost buys ten attempts per task), and the compounding lives in the layers the firm tunes, not the model it swaps.

Then the distinction that sorts every deployment: a harness is an amplifier. It runs whatever process is encoded in it, at industrial throughput. Encode sloppiness and you have built a machine for confident error — the erosion finding, industrialized. Encode method — counting rules as schema checks, required falsifiers, checkpoints that cannot be skipped — and the same machine protects judgment instead of degrading it. Harness without method is an amplifier; harness with method is a discipline. The response to eroding judgment is not exhortation, which collapses under throughput. It is judgment you cannot skip: externalized into structure, so it binds at 3 p.m. exactly as it binds at 9 a.m.

The organization — graph, junction, staircase

Subscribe To Get The New Book!

The New BE Library is Available Now!

Scale the unit and the org chart stops describing the organization. A firm running dozens of agents is a graph: nodes of work, flows of artifacts, human judgment stations at the junctions. The graph, not the chart, is what the new operating model attaches to — and managing it requires, for agents, everything firms built for people: recruited (flow mapped, evaluations written), promoted (checkpoint gates widened on evidence, revocably), retired (before they decay). The roster answers the question every board will eventually ask: what is acting in our name, under whose authority, checked by whom?

And the graph carries a mathematical property that is the most underestimated fact of the whole shift: nodes scale linearly, interactions do not. Add an agent and you have added a node whose channels to every existing node — human and machine — are candidates for traffic; possible channels grow on the order of the square of participants, and agents actually use them, at machine speed, dozens of calls per task, never waiting for a meeting slot. Meanwhile human judgment bandwidth is fixed — a finite number of calibrated judge-hours a day — and, per the evidence above, under erosion pressure exactly when it is most loaded. Interaction volume scales combinatorially while judgment bandwidth stays fixed. Every pathology of careless agentic adoption is a corollary of that sentence: junction queues, rubber-stamp review, errors propagating through machine-speed chains faster than any audit can walk them — the paradox of firms that automated aggressively and feel less in control. The response is topological, because the arithmetic can only be shaped, not beaten: bounded fan-in and fan-out, traffic routed through designed junctions instead of point-to-point, schemas on agent-to-agent channels so the checkable majority never touches a judge at all. The orchestrator’s real object is the topology — and the role’s leverage comes from the same arithmetic as the danger: one well-placed junction disciplines a combinatorial number of interactions at once.

The junction is where the discipline concentrates. A judgment junction is a defined station where four things are true: the decision is consequential; it cannot be fully specified; the decider has standing to commit the firm; and the decision is recorded — approved, corrected, refused, and why. The sizing rule: place human judgment where it is the binding constraint on quality, and encode it everywhere else. Staffing inverts the pyramid: junctions are held by judges, and a judge is defined by calibration visible in the junction’s own records — not by seniority. Responsibility concentrates exactly where judgment does.

And then the problem with no inherited solution, the book’s hardest chapter. Judges are made, not hired — and they were made by the staircase the era just removed. The era commoditizes the climb, prices the summit, and removes the stairs. A firm staffing junctions from a judge population it no longer produces is running down inventory it stopped manufacturing. So the orchestrator builds the staircase on purpose: apprentices judging in parallel at live junctions, blind, with the deltas as curriculum; a deliberate friction budget — some work done the slow way, paid for its by-product, like simulator hours; and calibration measured, so promotion to judge finally becomes an evidence decision instead of a tenure ceremony. The planning fact is unforgiving: judgment is now a manufactured input with a lead time measured in years — longer than any datacenter.

The five moves

Subscribe To Get The New Book!

The New BE Library is Available Now!

Map the work. Enumerate the flows — trigger to committed artifact — and annotate each stage: volume, specifiability, consequence. Mark where artifacts escape the firm. The deployment order falls out of the map, not the org chart; and the map shows, for the first time, exactly where the humans must be.

Sort by alpha. One question replaces the build-versus-buy debate: does this flow write alpha — the firm’s differentiated edge? No: rent everything about it at the falling market price and never look back. Yes: own the fit, because a differentiated flow run through a rented frontier is condensing the firm’s edge into the landlord’s system. The asymmetry decides the doubtful cases: the penalty for over-owning is a budget line; the penalty for over-renting is the edge.

Design the junction. Four components, each closing an observed failure mode: the frame (a specific decision, not a pile — a judge asked “is this good?” calibrates to fluency; a judge asked a yes-or-no question calibrates to substance); the gate (explicit, revocable authority); the record (one artifact, five uses: training signal, agent evaluation, judge calibration, staircase curriculum, audit trail); the load (judge-hours engineered as the scarce resource they are).

Instrument the judgment. Confidence is a reading; the operating model deserves instruments — a question fixed in advance, gauges on frozen evaluation suites, counting rules obeyed when they hurt, confidence grades, stated limits. And a refusal log at firm level: the record of automations declined and gates not widened. A firm that can show its gauges and its refusal log has an operating model; a firm that can show its demos has a mood.

Grow the judges. The move the other four silently depend on — junctions staffed, records kept, instruments read: by whom, in five years? Shadow bench, friction budget, calibration ladder, and a taught sparring standard, funded as what it is: the insurance premium on every decision the firm’s machines will make in the next decade.

The property lines

Subscribe To Get The New Book!

The New BE Library is Available Now!

Run the capture audit inward, band by band, with one question: if this relationship ended tomorrow, what walks out with the vendor? The model is designed to fail the test — that is what renting means. The junction layer must never fail it: flows, checkpoint logic, evaluations, corrections, audit trails are the firm’s operating judgment in encoded form, and a firm that rents its own judgment has no answer to what it is. What the firm can leave with is what the firm owns; everything else is a lease with good branding.

The reason the protection compounds has a name: the exhaust flywheel. Every instrumented run throws off traces, evaluations, corrections, configurations — and handled deliberately, each cycle’s exhaust becomes the next cycle’s tuning. This is narrower and stronger than a “data moat”: the co-adapted fit is a system property that cannot be extracted or purchased, because it is not an asset sitting anywhere — it is the whole loop’s adjustment to one firm’s actual work. A competitor can rent the same model tomorrow. They cannot rent your ten thousand corrections.

Which resolves the era’s noisiest argument — closed frontier versus open weights — into a property choice made flow by flow. The generic majority: rent the frontier, enjoy it, swap it. The differentiated few: own the harness, keep the flywheel inside your walls. The mistake to fear is the invisible one: renting a flow that should be owned looks free for years, because the condensation of your edge into someone else’s system never sends an invoice.

The practice — and what the season says

Subscribe To Get The New Book!

The New BE Library is Available Now!

A method exists only in its running, so the discipline runs on a calendar: weekly at the junctions (queues, corrections, incidents), monthly on the agents (gauges against frozen suites, gates widened on evidence, roster reconciled), quarterly on the operating model itself (re-sort the alpha, re-take the capture audit, feed the flywheel, review the staircase, read the refusal log end to end), annually on the firm read whole. An operating model reviewed on a cadence compounds; one reviewed by incident merely survives.

The panel is six gauges: leverage (output per human, read as a trend, never a target), absorption (share of mapped work running through instrumented agents), boundary quality (defects escaping the outermost gates), judgment health (the junction panel — the first needle to move when the amplifier runs without the discipline), property (the share of alpha-writing work whose flywheel spins at home), and bench (the judge inventory, read like any input with a multi-year lead time).

And the current reading, dated to the third quarter of 2026 and included on expiring terms: the junction layer is monetizing ahead of the model layer — a billion dollars of agentic contract value at a firm with no frontier model, a four-way platform race for the same ground. The model band is behaving as a commodity should — monthly releases, a tenth of the cost in tuned harnesses, free weights championed loudest from the hardware seat, for which abundance is demand policy. The judgment layer is eroding faster than it is being rebuilt, and the staircase problem is almost entirely unowned. The largest unowned arbitrage of the era is not a technology. It is the manufacture of judges.

Every number above will be superseded. The graph, the junction, the sort, the flywheel, the staircase — the instruments — will not. That asymmetry is the whole Library’s organizing principle, and this volume’s closing transfer states it for operations: that era priced generation and got judgment free; this era prices judgment and gets generation free. The orchestrator is the person who accepts the new pricing and builds accordingly.

The library: selected models of the orchestrator’s discipline

Subscribe To Get The New Book!

The New BE Library is Available Now!

On the shift

• Generation Gets Cheap, Judgment Binds — when the expensive middle of knowledge work collapses, the firm reorganizes around checking and framing.

• The Amplifier Law — a harness industrializes whatever is encoded in it: sloppiness or discipline, at throughput.

• The Bottom Rung Dissolves — assisted individuals match unassisted teams; lower-rung competence is on demand.

• The Erosion Finding — fluent assistance degrades selection accuracy while decoupling confidence from correctness.

• The Missing Staircase — the climb is commoditized, the summit priced, the stairs removed; judgment becomes a manufactured input.

On the unit and the graph

• The Nine-Element Anatomy — model / harness / context / enclosure: one band rented, three owned.

• The Co-Adaptation Principle — performance is a property of the fit, not of any component.

• Cost Is a Capability — a tenth of the price buys ten attempts; wide search with adequate intelligence beats one pass with brilliance.

• The Firm as a Graph — operations live in flows and junctions, not the org chart.

• HR for Agents — recruit, evaluate, promote, retire; the roster answers what acts in the firm’s name.

• The Judgment Junction — consequential, unspecifiable decisions, made by a calibrated human with standing, and recorded.

• The Teammate Substitution — the assistant supplies the perspective breadth teams were built for; the group’s remaining job is judgment diversity by construction.

• The Interaction Explosion — nodes scale linearly, channels combinatorially, at machine speed, against fixed judgment bandwidth; the orchestrator’s real object is the topology.

• Judgment by Construction — externalize the discipline into structure so it binds at 3 p.m. as at 9 a.m.

On property and practice

• The Alpha-Writing Sort — does this flow write alpha? No: rent and swap. Yes: own the fit.

• The Capture Audit, Inward — what walks out with the vendor if this ended tomorrow?

• The Exhaust Flywheel — corrections, traces, and configurations as next cycle’s fuel, existing nowhere but your deployment.

• The Invisible Transfer — over-renting costs the edge without ever sending an invoice.

• The Correction Record — one artifact, five uses: training signal, evaluation, calibration, curriculum, audit trail.

• The Friction Budget — slow work bought deliberately for its by-product; the simulator hours of judgment.

• The Refusal Log, Operational — what the firm declined to automate, and why; its only record of its own restraint.

• The Orchestrator’s Panel — leverage, absorption, boundary, judgment, property, bench: six needles, honestly scaled.

With massive ♥️ Gennaro Cuofano, The Business Engineer

These questions are being asked in every boardroom in the economy, and the coverage — for all its volume — does not answer them. Every earnings print is summarized within the hour; every launch collects a hundred takes by nightfall; every capital figure circulates until it feels familiar. Familiarity is not understanding. It is entirely possible to know every headline of the AI buildout and still be unable to read it, and the divergence has a specific cause.

The explanation is not a shortage of information — the filings are public and identical for everyone — but a shortage of method. Two readers with the same access produce two different objects from the same quarterly report. One produces a story: a judgment about momentum and sentiment. The other produces a structural reading: a statement about what changed in the system that generated the numbers, and what that change means for the choices ahead. The difference between them is not talent. It is a set of installed procedures, and procedures can be taught.

I call the set of procedures business engineering.

Its object is business strategy in the oldest sense of the term — where to compete, what to build, what to own, whom to serve, when to move. Financial statements will appear throughout what follows, and their role should be fixed at the start: they are evidence, not subject. A strategy is a set of choices, and the ledger is where choices stop being words and become arithmetic — the one place a company cannot help telling the truth about what it has actually decided. The discipline reads numbers the way a strategist reads terrain: not because the terrain is the campaign, but because no campaign survives being wrong about it.

A discipline, properly speaking, is three things joined together — and most of what is taught as business strategy has only fragments of one. It is a stance: defaults about what to look at and what to refuse. It is a set of moves: repeatable operations that convert raw material into understanding. And it is a practice: a cadence of live application that keeps the stance honest and the moves sharp. Medicine has all three. Engineering has all three. A shelf of frameworks detached from stance and practice has none of them — which is why a person can collect frameworks for years and still misread every company they meet.

What follows is the full structure: where the discipline’s tools came from, the stance, the thinking system underneath it, the five moves, the instruments they build, the practice that runs them — and, at the end, what the apparatus currently reads, plus the working library of models it thinks with.

Subscribe To Get The New Book!

The New BE Library is Available Now!

Subscribe To Get The New Book!

Where the toolkits came from, and why they fail here

Subscribe To Get The New Book!

The New BE Library is Available Now!

The methods most professionals carry were each forged by one era’s scarcity, and their origins explain their present failures. Read the history of management not as a parade of thinkers but as a sequence of environments — each with one binding constraint, each selecting for the toolkit that answered it.

The assembly line answered the era whose constraint was production itself. Lean manufacturing answered waste, once volume was solved. The leveraged buyout answered an era whose scarce skill was financial structure — the first in the sequence in which the winning method had nothing to do with making anything. Blitz financing answered the internet land-grab, whose constraint was capital deployed at speed, and whose cautionary specimen — a correct grocery-delivery idea executed with nearly a billion dollars against a market that did not yet exist — established that capital cannot manufacture demand. The lean startup answered the inversion that followed: once software could ship unfinished at negligible marginal cost, the binding risk moved to the demand side. The platform era then moved the unit of competition from the product to the network.

Three observations from this sequence carry the strategic load.

First, toolkits outlive their constraints — every era’s method persists into the next as professional habit, so at any moment much of the profession runs one era behind.

Second, the location of the binding constraint predicts where returns pool — each era’s economics accrued to whoever held its scarce input.

Third, the AI buildout is the first environment to activate several historical constraints at once: a demand-side question, a capital-structure event of record scale, a physical-capacity problem with construction lead times, and a platform contest — running simultaneously, with the binding constraint rotating within the cycle rather than holding for a generation.

The consequence is mechanical. The demand-side toolkit alone reads a product race and cannot explain why the best models capture so little value. The growth-capital toolkit prices the cycle like 1999 and carries no gauge for how a buildout is funded. The platform toolkit has no physical layer — and this cycle’s defining fact is that software met a wall of matter for the first time in forty years. Even the financial toolkit fails alone: it prices the obligations without the technology clock that decides whether the financed assets will be productive or stranded.

An environment that defeats every partial toolkit selects for a method that reads all the layers as one system and tracks which one binds now.

The stance: the system, not the story

Subscribe To Get The New Book!

The New BE Library is Available Now!

The discipline’s first commitment is a refusal. A company is not read as a narrative — founder, vision, momentum, turnaround — but as a system of four interacting parts.

The value model: what is created, for whom, at what willingness to pay. The technological model: how the value is produced, and whether the firm funds both the sustaining engineering and the discontinuous bets that could obsolete it. The distribution model: how value reaches the customer — the part narrative reading most reliably ignores, despite a finding that recurs across thousands of examined business models with the regularity of a law: a good product does not make a successful company; a product multiplied by its distribution does. And the financial model: how the ambitions of the other three are funded and what they cost — where every strategic choice eventually appears, priced.

The four parts constrain one another, which is what makes the lens diagnostic. A value proposition is only as real as the distribution delivering it; a technology bet only as serious as its financing; and the financial model, because it must reconcile, functions as the confession booth of the other three. This yields the stance’s testable rule: where the story and the system disagree, the system is correct.

The rule earns its keep on the cycle’s most instructive specimen. In a recent quarter, the search incumbent — the most profitable distribution business ever constructed — reported results its own narrative described as excellent: record revenue, cloud growth above eighty percent, earnings ahead of expectations. The same filing recorded four structural facts without emphasis. Free cash flow was negative for the first time in the company’s modern history. The twenty-year share buyback had stopped. Roughly seventy billion dollars had been raised. Capital spending was running at about six times depreciation.

None of these is a scandal. Together they are a classification change — a company organized for two decades around returning surplus cash had converted itself, deliberately and in plain sight, into an infrastructure builder. The scale of the financial reversal is the most honest available measurement of the scale of the strategic bet — a measurement the format “strong quarter, AI momentum” is structurally incapable of expressing.

Two further commitments complete the stance. The business environment is predominantly a domain of uncertainty rather than risk — the set of outcomes is itself unknown, which is where models fail while emitting confident numbers — and in uncertain domains the ordering is fixed: secure survival before pursuing optimization, because losses compound asymmetrically and some exposures have no next round. And analysis is not complete at the first order, because complex systems answer back — competitors adapt, customers relearn, incentives shift — and the record of expensive strategic error is disproportionately composed of first-order successes whose second-order consequences were never priced.

The engine: how the analysis is performed

Subscribe To Get The New Book!

The New BE Library is Available Now!

Beneath the stance sits a layer most methods never make explicit — the cognitive operating system the analysis runs on. Three principles do most of the work.

Structure before content. Never ask for an answer; ask for the three-to-five-part structure that makes the situation intelligible, because a territory that cannot be mapped cannot be navigated.

Context before work. Fix who the analysis is for, why it matters now, and how it will be used, before beginning. An analysis without a “why now” is an encyclopedia entry.

Compression as the quality filter. The value of an insight is its ability to be absorbed, retained, and deployed — and the filter cuts inward: an insight that cannot be compressed without losing its essence is not crystallized yet.

Run these with precision calibrated to the decision rather than worshipped for its own sake, a standing search for what consensus is missing, and every output built as a reusable module — and the work begins to compound: each analysis leaves behind models applicable to the next one. That flywheel is how a single practitioner keeps pace with an industrial cycle: not by working harder, but by designing the process that generates understanding.

The five moves

Subscribe To Get The New Book!

The New BE Library is Available Now!

Find the constraint. A business system is not uniformly tight; one station sets the pace of the whole, and the system’s economics organize around it. The procedure: map the flow, then walk the chain applying one test per station — if this station’s capacity doubled, would system output rise? Only at the binding constraint is the answer yes. Confirm with prices, because constraints announce themselves economically: margins expand at the binding point, queues form ahead of it, its suppliers gain pricing power.

Applied to the present cycle, the procedure returns a result at odds with most coverage. Serving a large model is dominated by data movement, not computation — each generated token requires the model’s full weights to traverse memory — so the binding stations are high-bandwidth memory, advanced packaging, and leading-edge fabrication, all sold out years forward at expanding margins. The station most narratives treat as decisive, the model itself, fails the capacity test, because the system is not waiting on models.

The move’s second half carries the strategy: constraints rotate. This cycle’s has moved through packaging, memory, lithography, and power, and has lately been joined by credit — two binding at once for the first time. So the valuable question is always forward: given how the workload is changing, where does the constraint migrate next, and who owns that station while the market still prices it as slack.

Follow the dollar. A spending announcement is the start of a path, not a fact about the announcer. Decompose it: what the spend purchases and from whom; what each recipient keeps as margin versus passes to its own suppliers; iterate until the dollars stop moving. They rest at the stations with pricing power — which are the constraints.

Two findings generalize. Incidence diverges from narrative systematically, not occasionally: coverage assigns the cycle’s value to its protagonists, while the trace finds the protagonist operating as a conduit, the dollar settling one or two stations upstream at firms the coverage rarely names. And the same decomposition run in reverse — where did the dollar originate — determines behavior under stress, since a buildout funded from operating cash absorbs a downturn while the identical buildout funded from external raises transmits one. The spending trace identifies who is enriched; the funding trace identifies who is exposed.

Separate the reading from the instrument. This distinction is the center of the discipline. A reading is a measurement at a moment — a margin, a spread, a score — and it depreciates from the day its inputs do. An instrument is the apparatus that produced it, and a complete one has five components, each closing a specific failure mode: a question fixed in advance, phrased so evidence can answer it; gauges with defined scales, so this quarter is commensurable with last and mood cannot move the needle; counting rules written once and obeyed even when they weaken the story — above all against the largest silent error in business analysis, revenue counted repeatedly as it echoes up a supply chain; confidence grades carried from source to conclusion; and stated limits, because readings from an instrument of unknown limits have unknown meaning.

The distinction converts into a daily rule: for any analysis encountered, determine whether you are being handed a conclusion or an apparatus. The first ages on the schedule of its inputs; the second can be pointed at next quarter’s filings by its recipient, indefinitely. It is also the discipline’s production standard: work is not finished when the conclusion is reached, but when the apparatus that reached it can be run by someone else.

Compress and name. Beneath any deep analysis is a structure that recurs elsewhere, and extracting it converts analysis from an expense into an accumulating asset. Strip the particulars and observe what survives — if nothing does, the work was reportage. State the surviving mechanism as cause and effect with explicit operating conditions. Then locate a second instance, because a mechanism observed once is a hypothesis; the second instance is what certifies transferability.

The final step is naming, and it is not cosmetic: an unnamed insight must be re-derived at every use, while a named one becomes a unit of thought — and, once defined for a team, a unit of shared thought. A maintained library of such models functions as a lens assembly: new situations are read through the accumulated mechanisms in seconds, and whatever matches nothing becomes the next entry. The loop — analyze, compress, name, reuse — is why the method’s cost per insight falls the longer it runs.

Falsify. A confident method transfers its confidence to its errors, so the last move is the organized exposure of one’s own claims. Every load-bearing claim is published with its falsifier — the named observable that would prove it wrong — because a claim without one is not analysis but identity, and identities do not update. Every framework carries a dated statement of why it is timely now, so the claim visibly comes up for review when conditions lapse. Composite examples are marked as composites. Claims used but not argued point to where they were argued. And the discipline keeps a refusal log — figures declined, questions ruled not yet decidable — because that record is the only calibration data an analyst has on their own doubt.

The apparatus: what the moves build

Subscribe To Get The New Book!

The New BE Library is Available Now!

A discipline should be judged by what it constructs, and the five moves, run repeatedly on one industry, have produced a working shelf of instruments — each introduced by the question it exists to answer.

The layered map: where does any firm sit in the machine, from the physical floor through equipment, fabrication, silicon, networking, compute, models, the agentic layer, and distribution — the coordinate system every other instrument depends on. The capture test: after adopting the era’s technology, what does an enterprise still own — which of the junctions where its data, decisions, and customer relationships live remain under its title, and what would leaving cost. The financing acid test: is the buildout’s capital structure sound — gauged, scored, and banded, so this quarter’s answer is commensurable with last quarter’s. The reconciliation: does the revenue justify the capital — under counting rules that count each end-customer dollar once. And the season log: what did the machine report this quarter, recorded so the readings become a series.

The instruments are not five frameworks; they are the same five moves in different orders, pointed at different questions. And they interlock: the map gives the tests their coordinates, the tests give the map its depth, the reconciliation disciplines them all, and the log keeps them honest.

The practice — and the harness

Subscribe To Get The New Book!

The New BE Library is Available Now!

A method exists only in its running. The discipline’s laboratory is the earnings season: four times a year, at every layer of the stack, dozens of firms publish audited measurements of the same machine from different positions.

The protocol: read in layer order, from the floor upward, so each report arrives with its context established; reduce each to its positional reading — constraints, funding, incidence; then reconcile across positions, because the season’s findings live between the reports rather than inside them — one firm’s capital expenditure is another’s backlog, one’s margin expansion is another’s toll paid — and where claims that must agree refuse to, the refusal is the finding.

Between seasons, the vocabulary is maintained like capital: models merged when two names prove one mechanism, demoted when the second instance never arrives, re-tested on contact rather than stamped on. And everything ships visual, because a drawn structure is the densest honest encoding of a system — an analysis that cannot be drawn is usually not finished.

One development belongs in the discipline’s own terms rather than as a footnote. The method, encoded, now runs substantially inside an agentic AI harness — the process layer executing at machine speed — and the discipline’s own incidence analysis predicts exactly what follows: as process becomes cheap, the value of the role migrates to the judgment junction — which constraint to believe, which falsifier to respect, which bet to size — and that junction stays human. The practitioner’s job does not disappear into the harness; it concentrates at the one station the harness must pass through.

The library: selected mental models of the discipline

Subscribe To Get The New Book!

The New BE Library is Available Now!

The discipline thinks in named models. The full vocabulary runs past a hundred and thirty entries; the working core below is enough to read most situations, and each entry is a compressed mechanism, not a slogan — usable the moment it is understood.

On reading companies

• The Four-Part System — a company is value, technology, distribution, and finance in interaction; the unit of analysis is the joint between them, not any single part.

• The Distribution Law — a good product does not make a successful company; a product multiplied by its distribution does.

• The Honest Ledger — whatever the story omits, the financial statements eventually state; the size of a financial reversal measures the size of the strategic bet behind it.

• Two Engines — reported net income mixes the operating engine with revaluation marks; strip the marks and read the operating line, because only one of the engines repeats.

• Survival First — in uncertain domains, secure survival before optimizing; losses compound asymmetrically and some exposures have no next round.

• The Second Order — the system answers back; judge a move by what competitors, customers, and incentives do in response, not by its first effect.

On reading systems and cycles

• The Binding Constraint — one station sets the pace of the whole system; find it with the capacity test: would doubling this station raise total output?

• Constraint Rotation — the clamp moves; the durable strategy is owning the station the constraint returns to, not the one it is visiting.

• Toll Booths vs. Tourists — in any buildout, distinguish positions that must be paid regardless of who wins from positions merely present at the scene.

• Incidence vs. Narrative — value settles where the trace says, not where the story points; the protagonist is usually a conduit.

• Enriched vs. Exposed — the spending trace identifies who is enriched; the funding trace identifies who is exposed; run both.

• Tightness Rent vs. Monopoly Rent — margin from a visiting constraint is cyclical; margin from a structural chokepoint is durable; price them differently.

• The Rotating Bottleneck — this cycle’s constraint sequence: packaging, memory, lithography, power, credit — with two now binding at once.

• The Four Clocks — physical (years), financial (quarters), efficiency (fastest), adoption (telemetry); most cycle risk is clocks desynchronizing, not demand failing.

• Capex Is a Placement Decision — the capex line measures what a firm chose to own, not what got built; the rest sits in leases, commitments, and other entities’ books.

• The Footnote Compounds Faster — off-balance-sheet obligation is the marginal financing channel; its ratio to visible capex is a stress gauge, not an accounting curiosity.

• The Amplifier, Not the Bubble — financing structures rarely cause the shock; they determine how far a shock travels.

On the method itself

• Reading vs. Instrument — a reading is a dated measurement; an instrument is the apparatus that produced it; hand over the apparatus.

• The Counting Rule — count each end-customer dollar once, at the tier where it transacted; most inflated market numbers are the same dollar echoing up a supply chain.

• Meta-Compression — if an insight cannot be compressed without losing its essence, it is not crystallized yet; compression is the quality filter, not a summary step.

• The Second Instance — a mechanism observed once is a hypothesis; the second instance, in a different domain, certifies transferability.

• The Naming Contract — first use defines a model; every later use leans on the anchor; an unnamed insight must be re-derived every time.

• The Falsifier Rule — a claim with no named falsifier is not analysis but identity, and identities do not update.

• The Refusal Log — the record of what the method declined to conclude; the only calibration data an analyst has on their own doubt.

• The Judgment Junction — as encoded process becomes cheap, the role’s value migrates to the junction that stays human: which constraint to believe, which falsifier to respect, which bet to size.

• The Evergreen Rule — the readings expire; the instrument does not; build every deliverable so its dated matter is marked and its apparatus outlives it.

With massive ♥️ Gennaro Cuofano, The Business Engineer

ChatGPT began as a consumer sensation, creating the illusion that this cycle would unfold like the web: new entrants would rapidly create new categories and use them to disrupt established players.

Instead, AI has revealed something fundamental about real intelligence. It depends on context: localized, proprietary, and often tribal knowledge.

Most of that knowledge is trapped inside enterprises, fragmented across dozens of systems, buried in operating processes, or held tacitly in the minds of the people who understand how the business actually works.

This is the central paradox of the cycle. The web advanced by democratizing distribution. AI can only continue advancing by unlocking the contextual intelligence held inside the enterprise vault.

But unlocking it is not merely a technical problem. Enterprises must be given a reason to participate without surrendering the core logic, knowledge and identity that make them valuable. They need to co-opt AI without allowing AI to absorb and ultimately replicate the entire business.

That is the essence of the transition: turning enterprise knowledge into machine intelligence without dissolving the enterprise itself.

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

Get The Enterprise Coordinate Book Here!

Companies are not entering Enterprise AI. It is being entered by alliances.

A stack arrives as one motion. Compute underneath, a model in the middle, a governance layer on top, an integrator to wire it in. Each ally opens the floors below its hold and keeps the hold itself. This summer those alliances reordered in public. One player took the lead by naming the buyer’s deepest fear and giving it a single word. The largest model labs conceded the point — then started copying the motion they had just conceded to.

The mistake is to treat the vendor as the unit. Which model won. Which platform leads. Which chip is fastest. That is a category question. It cannot tell you the two things a purchase turns on: where value pools, and where you get locked in.

No enterprise buys a model. It buys a stack that has already decided how its members fit together.

• The unit of competition is the alliance, not the firm.

• Every player in that alliance is also playing its own book. The coalition is the gift. The book is the price.

A junction, here, is the layer everything routes through and leaving costs a fortune. An end is the layer you rent and swap. Score both from the buyer’s seat, not the pitch deck. You do not need the rest of the map.

Three kinds of alliance

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

They do different work. Read them together and you have the board.

The vendor-to-vendor stack. Two or more companies at different layers, entering as a single offer. A multi-layer stack, sold as one decision. The buyer is not choosing a model, a cloud, and an integrator in three meetings. The buyer is choosing a coalition that has already decided how those parts fit.

Nvidia and Palantir on a sovereign engine. Microsoft and OpenAI. Amazon and Anthropic. ServiceNow wiring Claude into workflow. Oracle and Palantir on sovereign cloud. Same species. Different books, visible the moment you ask the reading-rule question of each.

Work it. Nvidia/Palantir: Nvidia opens the silicon and the open-weight model; Palantir opens the model too; neither opens the Ontology.

Microsoft/OpenAI: Microsoft opens the cloud and the identity plane the model runs through; OpenAI holds the model — and, as of this year, is climbing into the harness above it.

Amazon/Anthropic: Amazon opens the operational substrate; Anthropic holds the model, and now a services firm that puts it in.

ServiceNow/Claude: ServiceNow holds the workflow control plane; Anthropic opens the model into it.

Oracle/Palantir: Oracle opens sovereign cloud; Palantir holds the decision layer that lands on it.

The open floor is why the meeting happens. The held floor is why the renewal is expensive. If you cannot name both, you are reading the press release.

The substrate coalition. A signed industry structure whose membership list is the argument. The open-weights advocacy letter. The security alliance formed around shared agent-auditing tooling. These are not products. They are not stacks. They are declarations of whose economics depend on a given layer staying open or staying closed.

A vendor-to-vendor stack sells you a motion. A substrate coalition tells you which motion is even allowed. Who signed the security alliance told you which firms can live with a cheap, inspectable model layer. Who did not sign told you which firms cannot.

This summer the absences were the closed frontier core. That was not a social fact. It was a map of who still needs the model layer to stay proprietary — and, as the rest of this piece shows, of who then spent the summer trying to occupy the floor above it anyway.

The enterprise-as-co-designer alliance. The customer is not a buyer. It is a member. Kirkland & Ellis, Centrus, McCarthy, a national health service, an integrator like PwC embedding at scale. The asset produced is not a licence. It is the customer’s own codified expertise — the judgment, the objects, the decision rights — written into a system the customer is told it controls.

Told. That word is doing the work. Co-design is the most flattering of the three species, and the easiest to misread. The enterprise arrives with its data and its hardest problem. It leaves having built. The asset has its name on it. Whether the asset can leave is a different question, and it is the only one that decides if membership was sovereignty or a very expensive onboarding.

The Sovereignty Bootcamp is this species, industrialised: a thirty-day cadence in which co-design is the sales motion, and the thing co-designed lives, from that day, in the vendor’s typed graph.

The summer ran through all three at once. Vendor-to-vendor stacks reordered around who holds the floor above the model. Substrate coalitions drew the line between firms that need the model closed and firms that need it cheap. Co-design became a demand engine. The through-line is a word. And a fact: every ally is playing a different book inside the same motion.

Each player is playing its own book

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

The coalition agreed on the entrance. It does not agree on the furniture.

Palantir holds the typed operating model of the business — the Ontology — and the decision surface that writes back into it. It opens everything beneath that floor: the model, the silicon, even the cloud in a sovereign configuration. It sells the open floors as sovereignty. It grows the held floor until the held floor is the company’s essence. The FDE was its invention. The bootcamp is the industrialised version. The vocabulary is alpha. Palantir does not need to win the model layer. It needs the model layer to become cheap.

OpenAI has rewritten its book in public. For two years the book was: hold the scarce model, let Microsoft open the cloud, let the API be the product. That book is no longer enough, and OpenAI knows it. The new book is two-track. Keep the model. Climb into the floor above it. In February it shipped Frontier — in its own language, “the underlying intelligence layer governing all of a company’s agents,” a “unified operating layer” whose Business Context connects warehouses, CRMs and internal apps and builds “durable institutional memory.” In May it stood up the OpenAI Deployment Company, majority-controlled, seeded with more than four billion dollars, and acquired Tomoro for roughly 150 forward-deployed engineers on day one. In July the same vehicle agreed to acquire Northslope, founded by former Palantir FDEs, adding hundreds more. OpenAI is no longer only selling tokens. It is trying to own the harness those tokens run inside, and the people who wire that harness in.

Anthropic is adjacent, not identical. Hold the model. Differentiate on trust. Let partners open the workflow — ServiceNow, the clouds, the integrators. The new chapter is implementation. In May a joint venture with Blackstone, Hellman & Friedman and a PE consortium acquired Fractional AI. In July it launched as Ode: Claude-first, not Claude-exclusive, a services firm whose job is to put Claude into companies that cannot staff the implementation themselves. Anthropic is not, yet, shipping a named ontology. It is buying the human layer that used to sit between the model and the customer’s operating system. Labour and pattern, not a typed graph. Still a junction.

Nvidia opens the weights and the sovereign engine, convenes the security alliance, and keeps the floor that does not travel: the instruction set. It can sit on every coalition because the silicon is downstream of every one of them. The open-weight letter is substrate politics in service of that book.

Microsoft and Amazon hold the control plane of the cloud they already own. Identity, tenancy, the governance catalog, the bindings that make a “portable” model operationally immovable. Microsoft’s alliance led with OpenAI and now runs Palantir on Azure as well. Amazon’s led with Anthropic. Both have stood up their own forward-deployed motions. They do not need to win the model. They need whichever model you pick to run inside a control plane that does not export.

Why Palantir took the lead

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

For two years, the center of gravity was the frontier lab. The model was scarce. The labs held it. Every stack organized itself around whose model sat in the middle. Microsoft led with OpenAI. Amazon led with Anthropic. The lab was the sun.

Palantir refused to organize around a model at all.

The Nvidia partnership is the cleanest expression. A sovereign engine, open-weight Nemotron, on the customer’s own hardware, air-gapped and classified, the customer owning the resulting weights and the training data. Read it through the rule. Nvidia opens the silicon and the model. Palantir opens the model too — swap it freely. What neither opens is the layer that binds the customer’s data into a typed, live operating model of the business, and the decision surface built on top of it.

That layer is Palantir’s. It does not travel.

The Ontology is a live, typed model of the business — objects, relationships, action types, decision rights — that the rest of the stack writes against. The model underneath is interchangeable. The Ontology is not. Swap OpenAI for Anthropic for an open-weight model on your own iron. Nobody cares. You cannot take the decision graph with you when you walk.

The model is a decoy. Palantir hands you the one freedom that no longer matters, and keeps everything that compounds.

That is a genuine improvement on what the labs were selling two years ago. It is also, still, a lock-in. Both facts have to be held at once.

The improvement that is still a lock-in

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

Score Palantir against the closed-frontier default, honestly.

The first lab offer was a gravity well. The model was the product. Context, memory, and a meaningful share of enterprise state lived, at least in part, on the lab’s infrastructure. Retention was justified as safety — catching attacks that span many requests — and had the convenient property of keeping the company’s working memory on the vendor’s side of the wall. The switching cost was not a contract. It was judgment, migrating.

Palantir’s offer is better than that, and it is not subtle. The model is portable by design. The sovereign engine can run on the customer’s hardware. The FDE and the bootcamp build on the customer’s own data. Relative to “your alpha lives in our model, on our servers, metered by our tokens,” this is a structural upgrade. Anyone pretending otherwise is arguing from a prior.

Then look at where the company’s essence goes.

The Ontology is not a dashboard. It is the place the business is rewritten as objects, links, action types and write-backs. Once that rewrite is done, the Ontology is no longer a view of the company. It is the company, as far as the operating system is concerned. New decisions execute against it. New agents read it. New employees learn it. The longer it runs, the more the enterprise’s alpha — the codified judgment, the proprietary data model, the operational know-how — lives there, rather than in the heads and systems of record it was extracted from.

So the honest question is not whether Palantir is better than OpenAI. It is whether the Ontology is portable.

Palantir’s own documentation is more precise than the pitch. There is an export. Ontology Manager dumps a working state to JSON and imports it back — to edit in code, or to copy one Ontology to another Ontology. On the same page, Palantir tells you not to depend on the exported schema, because it may change. Conditional formatting cannot be imported to an Ontology other than the one it came from. This is a Foundry-to-Foundry working-state tool. It is not an exit.

What does not travel as a running system: the action-types and validation engine, the write-back path, the decision graph as a live object, the Workshop surfaces, the accumulated operational state that makes leaving cost more every day you stay. You can, with enough engineering, recover a picture of the objects and links. You cannot pick up the company’s essence and set it down on a competitor’s platform on Monday.

• There is an export. It is not a portable Ontology.

• If the layer that holds your alpha cannot leave, you have not bought sovereignty. You have chosen a better landlord.

Against the original lab offer, Palantir is the less extractive deal. Against the standard the sovereignty pitch itself sets — your alpha stays yours — the Ontology fails the test. The doctrine is correct. The implementation is the junction the doctrine told you not to cede.

The labs understood the enterprise. Then they tried to buy it.

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

An API is an end. A pilot is a conversation. Production is a person sitting inside the customer’s mess — the identity graph, the legacy systems, the approval chain, the data that is not in the warehouse — and building a system that writes back.

Palantir named that person a forward-deployed engineer more than a decade ago. Until 2016 it had more of them than software engineers. The industry spent two years pretending the model had made that job obsolete. This summer it spent billions admitting it had not.

OpenAI’s Deployment Company launched in May, majority-controlled, seeded with more than four billion dollars, and acquired Tomoro for roughly 150 FDEs from day one. In July it agreed to acquire Northslope, its second such deal, adding hundreds more. Northslope was founded by former Palantir FDEs. OpenAI is not approximating Palantir’s labour model. It is importing it, including the people who used to perform it for Palantir. The official post even leaves the door open to joint commercial engagements with Palantir after close. Copy, hire, and partner, simultaneously. That is not confusion. That is a player paying to hold all three options.

Anthropic made the same admission on a different structure. The May joint venture acquired Fractional AI as its operating core. In July it launched as Ode: standalone, Claude-first, not Claude-exclusive, aimed at companies that cannot staff the implementation. Anthropic’s internal team keeps the strategic deployments. Ode industrialises the rest. The book is still the model. The new chapter is that the model does not enter the enterprise without a human layer Anthropic now owns a piece of.

The hyperscalers followed. The job title Palantir invented is now a standard line item in how the largest software vendors sell.

The labour is the admission. The product is the tell.

OpenAI Frontier is not ChatGPT with a tighter SLA. In OpenAI’s own framing it is the platform that should govern all of a company’s agents: Business Context as a shared semantic layer; Agent Execution against systems of record; evaluation loops so the agents improve with use; agent identity so permissions attach to the coworker, not the chat window. The Enterprise Frontier Program then pairs that platform with FDEs from the Deployment Company. The language is Palantir’s, translated. Durable institutional memory. Unified operating layer. Agents that write back. A human in the building to make it real.

It is not Palantir’s Ontology. Not yet. Frontier’s Business Context is a semantic layer designed to be built by operators and pointed at existing systems. Palantir’s Ontology is a typed, live decision graph with action-types and no meaningful export path, grown over years of FDE labour inside the hardest environments on earth. Depth is not direction. The direction is the same. OpenAI has decided the model is no longer enough of a junction, and is building the floor above it.

It is also not yet a completed lock-in. Frontier is younger. The semantic layer is shallower. The FDE bench is acquired, not native. The Deployment Company is capitalised by a PE and SI consortium whose incentives are not a research lab’s. Scaling a high-touch labour model is Palantir’s unsolved problem, not OpenAI’s solved one. Anyone who tells you Frontier has already replaced Foundry is selling a slide.

The correct reading is more uncomfortable than either pole.

Either way the question does not change. Which layer is being opened, and which is being held? Frontier is an escape from a single-model cage only if Business Context and the agent graph can leave. Watch the export, not the brochure. Palantir already answered that question, in its own docs, for its own Ontology. OpenAI has not yet been forced to.

The founding argument

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

At the second Sovereignty Bootcamp this August, Palantir’s chief executive did not open with product. He opened with the company’s founding.

The founding problem, as he told it, was counter-terrorism under constitutional constraint: how do you find the people trying to attack innocents without destroying the civil liberties of everyone else? Solving it forced the company deep into data integration, and produced an architecture with a specific property — the ability to do very intricate work on very sensitive data while keeping complete control over who sees the insight and who controls the underlying data. Privileged insight, on privileged data, shared inside the organisation, control retained at every step.

Then the pivot, and it is the whole argument in one line. A large language model is a very powerful and very dangerous raw material. The question is how you extract value from it while making sure the value you create stays inside your enterprise. You can use the labs’ models. You make sure the alpha is not migrated out by using an application layer — an ontology — to capture the value, so it never leaves your building to end up in a competitor’s hands, or in the hands of a company that will one day try to kill you.

This is a rhetorical move of real quality. Understand why it works rather than simply be moved by it. It takes a diffuse anxiety about AI and routes it through an architecture the audience already respects: the counter-terror system that balanced surveillance against liberty. The thing that let us find terrorists without shredding the Fourth Amendment is the same thing that lets you use a frontier model without surrendering your edge. Control the insight. Control the data. Keep both inside.

Whether or not the analogy holds all the way down, it converts a technical argument about data boundaries into a story about sovereignty, and attaches that story to a word the audience will remember.

Hold the sentence up against the Ontology. The alpha is protected from the model. It is not protected from the application layer that captured it. The speech is true about the labs. It is silent about the floor Palantir holds. That silence is not a lie. It is the book.

The demand engine

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

A vocabulary is not a movement. Palantir built the demand engine to match the argument.

Two Sovereignty Bootcamps in under thirty days. Organisations building on their own data, on infrastructure they control. Nearly two hundred of them, spanning healthcare, construction, media and defence, with speakers from Nvidia, Cisco, Novartis and NATO. Sovereignty over your alpha, offered as something you can attend a workshop to acquire, and leave having built.

A bootcamp is not a sale. It is a co-design session — the third kind of alliance, industrialised. The enterprise arrives with its data and its hardest problem. It leaves having built on infrastructure it controls. The asset belongs to the customer. And lives, from that day, in the Ontology.

Does value compound in place, so that leaving costs more every day you stay? A price-competed model fails that test. A live decision graph, written against during a workshop on your own data, passes. That is why the bootcamp is a more defensible growth motion than any vendor-to-vendor stack, and why OpenAI’s Deployment Company and Anthropic’s Ode are attempts to buy a version of the same motion rather than invent it.

Palantir took the lead not because it had the best model. It has no model. It took the lead because it was the first to organise an alliance, a sales motion, and a vocabulary around the buyer’s deepest structural fear, at the moment that fear became acute.

The concession — and the climb

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

The realignment is real because the labs moved their own boundary.

Through the summer they defended a posture in which enterprise data and state lived, at least in part, on the lab’s infrastructure. Palantir spent those same weeks arguing that this was the mechanism by which enterprises lose control of their alpha. Within weeks both of the largest labs restructured. One let enterprise customers keep retained data on their own cloud. The other previewed retaining none of it, piloted with a data platform and a hyperscaler. They will not call these concessions. The boundary moved anyway, in the same window, in the same direction.

That was the response to last year’s fear. The response to this year’s is Frontier, DeployCo, Ode, Northslope, Fractional AI. The labs did not just give the data back. They went upstairs.

What the lines now say

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

The board has redrawn around one axis. Openness below the junction. Ownership at the junction.

The substrate coalitions fell on that line. Nvidia’s open security alliance drew in the data incumbents, the integrators, the chip vendor, the enterprise-facing platforms — Microsoft, IBM, Palantir, ServiceNow, Salesforce, Snowflake, Databricks, Hugging Face, LangChain among some forty founding members. The four names absent were the closed frontier core: OpenAI, Google, Anthropic, Meta. A map of whose economics depend on the model staying proprietary.

The enterprise-facing coalition wants the model to be a commodity. The labs need it not to be. Palantir sits at the sharpest point of that alignment, which is why it could be the loudest. Every open-weight declaration, every sovereign engine, every bootcamp drives the model toward commodity. Every inch it moves raises the value of the Ontology.

The roster does not show the new instability. The labs are trying to sit on both sides of the line. Keep the model closed. Build or buy the floor above it. You cannot forever charge rents on a layer you are also trying to commoditise from above, and you cannot forever claim the upper floor is the customer’s if your FDE built it on your semantic layer. Something gives. Watch which rent they defend at renewal. That is the book.

The wider frame

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

The CEO’s closing argument at the bootcamp was not about software. A functioning society cannot have all the value flow to a couple of thousand people in Silicon Valley. The way to head off the fissures pulling societies apart is for a broad base of institutions to be stronger, healthier, more sovereign, rather than dependent. The enterprise keeping its own alpha is, in this telling, a distributive stance about where the gains from AI accumulate.

Discount it for coming from the vendor who profits if you believe it. The structural observation survives the discount.

Value does not spread evenly. It pools where switching costs accumulate, and drains from where substitutes are one API call away. If the deepest junctions concentrate at a handful of frontier labs, the surplus of the transformation concentrates there too. If they concentrate instead at a handful of ontology landlords, the surplus has moved, not distributed. Only if thousands of enterprises hold their own decision layers — on terms they can leave — does the surplus actually distribute.

What it means for your alpha

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

Your alpha is the codified judgment, the proprietary data model, the operational know-how that makes you competitive. It is not protected by choosing the right model. The model is the layer everyone is racing to make cheap. Alpha is protected or surrendered at the floors above it: where data is bound into a business model, where decisions execute, where evaluations and workflow logic accumulate. That is the junction.

Palantir was first to say this out loud, and first to productise it. That is why it led. The refinement is that “above the model” is not automatically “with you.” An Ontology that cannot leave is a move of the company’s essence into a vendor’s typed graph. A Frontier Business Context that becomes the institutional memory of the firm is the same move, attempted from the other side. An Ode engagement that encodes your operating patterns in a services firm you do not own is a softer version of the same move.

If it cannot, you have not bought sovereignty. You have rented it from a new landlord, however open the floors beneath it. Palantir is a better landlord than the original lab offer. It is still a landlord. OpenAI is spending billions to become one. Anthropic is buying the staff. The doctrine they are all now selling is correct. Each of them is selling it implemented at the layer that happens to be their own.

Read every alliance the same way. The one waving the sovereignty flag. The one rebuilding the harness. The one that just acquired the FDEs. Which layer opens, which layer stays, and whether the staying layer has an exit that is a running system rather than a JSON file. Not the logo in the middle. Not the eloquence of the pitch. That answer is the map of where your alpha will be in three years.

The mental models

Join The Business Engineer Premium Now!

Get The Enterprise Coordinate Book Here!

Five models carry the piece. They work without the rest of the map.

Alliance, not firm — and book, not alliance. The thing that arrives is a pre-assembled coalition. Score the motion, not the logo. Then score the book inside the motion. Palantir, OpenAI, Anthropic, Nvidia, Microsoft, Amazon can enter together and still be keeping four different floors. If you only read the coalition, you buy the gift.

Open below, hold at the junction. Every alliance opens the layers it can afford to commoditise and keeps the layer where leaving would hurt. Palantir opens the model and holds the Ontology. OpenAI is trying to keep the model and grow Frontier as the floor above it. Anthropic keeps the model and is buying the implementation layer. Nvidia opens the weights and holds the instruction set. Ask it of every coalition, including the one selling you sovereignty.

The lock-in gradient, not the lock-in binary. Palantir is a real improvement on the original lab offer: model-portable, runnable on your iron, data not retained as a matter of architecture. That does not make it portable. The company’s essence migrates into the Ontology. Official export is a Foundry-to-Foundry dump whose schema you are told not to depend on. Better landlord is not sovereignty. Score the gradient or you will be talked from one cage into the next.

Read the absences — then read the copies. Who did not sign the security alliance told you the model layer’s politics. Who then acquired FDE firms told you the next layer’s. The closed frontier sat out the substrate coalitions and spent the summer buying the labour model those coalitions were built around. Absence, then imitation. That sequence is the realignment.

Alpha lives above the model — and above is not automatically yours. The scarce thing is no longer the weights. It is the accumulated judgment, the typed operating model, the decision surface that writes back. Palantir taught the market that vocabulary and holds the junction the vocabulary describes. OpenAI is now building the same junction from the other side, in public, under its own name. Protecting alpha is not a model choice. It is an exit choice. If the layer that holds the essence cannot leave as a running system, the essence has already moved.

Carry those five into the next procurement. The rest of the piece is how they were proven, this summer, in public.

With massive ♥️ Gennaro Cuofano, The Business Engineer

That became its edge. Palantir’s land-and-expand model was built on a simple premise: solve hard problems first, embed deeply into the organization, then expand from there.

The forward-deployed engineer became central to that model, and Palantir effectively defined the category.

Over the last four years, I have argued that this role matters because enterprise AI is not primarily a model problem. It is an integration problem. Models have to connect with fragmented data, legacy systems, workflows, governance structures, and humans operating in highly constrained environments.

What has changed is that everyone now wants the enterprise. The AI labs have pivoted toward it, hyperscalers are moving deeper into it, and the enterprise layer has become one of the main battlegrounds of the AI stack. This is the foundation of my Enterprise Alliance thesis and the broader Enterprise AI Coordinate System.

Google is now entering the same arena from the opposite direction. It spent most of its history building consumer-scale search infrastructure. Now it is attempting to repurpose that machinery to solve the enterprise context and integration problem.

Google’s bet is that enough of the forward-deployed engineer’s work can eventually be automated through software. That may work, and if any company has the technical DNA to attempt it, Google is an obvious candidate.

But I do not think the forward-deployed engineer disappears.

More importantly, that may be the wrong question.

The real question is: what new enterprise infrastructure makes human-AI collaboration reliable enough for complex, regulated, high-stakes environments?

This piece is part of The Enterprise AI Coordinate System.

Access My Harness Via The BE Platform!

Join The Business Engineer Premium Now!

60+ Pages Book - Premium Members Only

Read more

The first was the chatbot interface itself. ChatGPT turned large language models into something millions of people could interact with directly. As the product evolved, we started to see a second capability emerge: reasoning. Through chain-of-thought-style workflows, tool use, and more complex task execution, LLMs stopped behaving only like answer engines and started looking like systems that could plan and act.

Then came Claude Code, which showed much more clearly what an agent could actually be. For the first time, the model was not simply responding inside a chat. It could inspect environments, manipulate files, use tools, execute code, and work through tasks with a meaningful degree of autonomy. But that agent was still trapped inside its own harness. Powerful, yes, but bounded by the environment around it.

OpenClaw pushed the idea further by showing what a more fully empowered harness could unlock. At the same time, it forced Anthropic to accelerate Claude Code itself. Anthropic shipped rapidly, expanding Claude’s ability to use tools, operate across workflows, and behave more agentically. That product velocity became one of the major drivers of Claude Code’s success over the following year.

But the next frontier is still unresolved.

Today’s agents are powerful, yet mostly isolated. They do not naturally coordinate with one another. Context and learning do not move easily between agents. Workflows are difficult to transfer. Each agent often behaves like an intelligent individual operating inside its own container rather than as part of a coordinated system.

Several products have tried to push beyond that limitation. Perplexity Computer, Claude Tag, and now Grok Bot all point toward a new phase where agents become persistent, coordinated, and increasingly independent from the user’s immediate session.

Grok Bot is particularly interesting because of the strategic chain that produced it. The catalyst was not simply a product breakthrough. It was Anthropic’s decision to move against what had been its most important API customer, before Anthropic’s business shifted more heavily toward subscriptions and direct user relationships.

That makes this more than a product story. It is simultaneously a story of product innovation, strategic maneuvering, vertical integration, and the consolidation of the AI stack.

The same competitive moves that strengthened Anthropic’s position at the application layer may also have helped create the conditions for a rival to assemble the next generation of the agentic harness.

Get The AI Supercycle Book Here!

Access My Harness Via The BE Platform!

Join The Business Engineer Premium Now!

The pieces are now in place for the agentic layer to shift from Anthropic’s largest customer to its best-funded rival. Whether that shift actually happens is the open question. And it may be one of the most consequential questions in the AI stack right now.

Before anything else, one distinction matters because the entire argument depends on it. Almost everything below has already happened. The deals were signed. The products shipped. The capital moved. The speculation is not about the setup. It is about the outcome. The setup is fact. The migration is the hypothesis. Read the history as settled. Read the ending as genuinely open.

Read more

AI does not develop from the bottom up, through consumer adoption first. It develops from the top down, through governance, enterprise deployment, and institutional control.

That thesis has held up remarkably well.

In fact, it has now become foundational to the strategy of the frontier AI labs, which are rapidly turning into some of the most powerful cash-generating machines ever created.

Before them, that title arguably belonged to Google and Meta.

But this is a completely different game.

Frontier AI models are no longer just models. They are becoming giant agents.

They can gather information, reason across enormous volumes of data, coordinate tools, execute workflows, and increasingly absorb the structure of that information into their own weights and surrounding systems.

Around those models, the labs are building increasingly powerful harnesses: memory, retrieval, tools, code execution, browsers, connectors, reasoning systems, and agentic infrastructure.

The neurosymbolic approach is being pushed toward its current extreme: multi-trillion-parameter intelligence combined with increasingly sophisticated execution harnesses capable of operating across almost any digital environment.

And this raises the fundamental question for enterprises.

Does it make sense to merge your core knowledge, your competitive edge, and ultimately your alpha with the weights and infrastructure of a frontier AI provider?

Does it make sense for the most valuable intelligence inside your organization to become increasingly dependent on systems whose economics, architecture, governance, and strategic incentives you do not control?

I’ll leave the answer to you.

But if your answer is no, then this resource is for you

We are entering a turning point in the Enterprise AI market.

For the past few years, frontier AI has been dominated by a closed-model duopoly led by OpenAI and Anthropic. But that structure is now being challenged by an emerging open-weight alliance, increasingly championed by Jensen Huang and reinforced by a broader industry convergence around open models, sovereign AI, and more distributed AI infrastructure.

Thus, the real question over the next 12–24 months is what happens to the economics of closed frontier models?

Can OpenAI and Anthropic continue expanding aggressively both downstream, by absorbing more compute, and upstream, by locking in more distribution at the application layer?

If their revenues continue to grow exponentially, they may gain enough purchasing power to absorb an increasingly large share of global AI compute capacity. In that scenario, the market risks evolving into something close to a monopsonistic duopoly, where two major buyers effectively shape, price, and define a disproportionate share of compute demand (very close to what it is right now).

That would be the epitome of a circular and structurally fragile AI economy: model providers generate demand for compute, capture distribution, raise capital on the back of expected growth, and then recycle that capital into even more infrastructure.

Not surprisingly, much of the rest of the industry is converging in the opposite direction.

Open-weight models, Chinese AI labs, sovereign AI initiatives, hyperscalers, semiconductor companies, and enterprise platforms all have incentives to prevent the frontier from collapsing into a two-player market.

This does not necessarily mean that OpenAI or Anthropic will see slower revenue growth.

Enterprise AI and sovereign AI could remain extraordinarily lucrative. Governments and large enterprises will continue paying for top-tier capabilities in areas such as cybersecurity, reasoning, compliance, data sovereignty, and mission-critical automation.

The more plausible shift is therefore not the collapse of closed frontier AI, but the maturation of the competitive landscape.

The market may become significantly more fragmented before consolidating again around a broader group of five or six major players rather than just two. Closed and open models will coexist.

Sovereign stacks will emerge. Infrastructure providers will move upward into software. Model companies will move downward into compute and outward into applications.

The boundaries of the stack will continue to blur.

And that creates the real strategic question for enterprises:

How do you preserve your competitive edge when the underlying AI landscape is shifting this violently?

How do you avoid locking your organization into an architecture, model provider, or distribution layer that may look dominant today but become commoditized, constrained, or strategically misaligned tomorrow?

That is what this resource is designed to help you answer.

Access My Harness Via The BE Platform!

Join The Business Engineer Premium Now!

60+ Pages Book - Premium Members Only

Read more

Consumer AI will become increasingly important over the next couple of decades. But the harder and more consequential challenge is happening inside large enterprises: embedding AI deeply enough to transform the organization without destroying the very capabilities that made it competitive in the first place.

“Transformation” is an overused and loaded term. Here, it has a very specific meaning: what happens to an enterprise when AI becomes part of its core operating system?

I’ve explored how enterprise alliances are shaping the broader AI ecosystem. But as these alliances deepen, a more fundamental strategic problem is emerging.

For a large enterprise, and increasingly for mid-sized organizations as well, the primary risk is no longer failing to adopt AI. The risk is adopting it incorrectly.

An enterprise can deploy AI in ways that gradually erode its competitive advantage, weaken its organizational knowledge, or transfer control of critical capabilities to external AI-native players.

This can happen because the organization fails to adapt its operating model, embeds the wrong components of the AI stack into its core, or becomes structurally dependent on vendors whose incentives are not aligned with its own.

The alternative is to build what I think of as an agnostic enterprise AI harness: an architectural and organizational layer that makes AI adoption controlled, governed, modular, and adaptable.

Such a layer should allow the enterprise to integrate external models, platforms, and capabilities without surrendering control over its data, workflows, knowledge, economics, or strategic differentiation. It can be built internally, through external agnostic partners, or through a combination of both.

But the technical architecture is only part of the problem.

The AI system also has to be aligned with the organizational core and understood by the people operating it: employees, executive teams, global functions, local business units, and the stakeholders responsible for turning AI capabilities into actual business outcomes.

These dynamics deserve far more attention because much of the enterprise AI landscape over the next three to five years can ultimately be reduced to one strategic question:

How does an enterprise adopt AI, preserve and strengthen its competitive advantage, and improve its economics without losing control of its profitability, margins, organizational core, and strategic optionality to AI-native players that could eventually lock it into their platforms?

That is the problem this guide sets out to address.

Every AI map sorts vendors by category and asks who wins each box. That is the wrong question. A buyer needs to know two things: where value pools, and where they get locked in. Neither is answered by a category. This piece throws the categories out and rebuilds the board on the only two axes that survive a purchase order — and finds a war fought almost entirely in three middle layers that every vendor calls “open” while quietly building the switching cost one floor down.

Access My Harness Via The BE Platform!

Join The Business Engineer Premium Now!

60+ Pages Book - Premium Members Only

Read more