Access The Enterprise AI Ecosystem Atlas

Get Premium for Full Enterprise AI Atlas

For three years, the enterprise AI market has been organized around one assumption: the model is the center of gravity.

The assumption made sense. When ChatGPT launched in November 2022, the model was the breakthrough. It packed an extraordinary amount of intelligence into a chat window anyone could use. Work that had needed specialist teams, dedicated infrastructure and narrow machine-learning systems suddenly looked like a general-purpose platform. So the first questions were about capability. Which model reasoned better, held more context, wrote better code, or ran faster, cheaper and safer? Every company added a copilot. Every software product became “AI-powered”. Every enterprise started testing model providers, private deployments, retrieval systems, and internal assistants.

Get Premium for Full Enterprise AI Atlas

Deployment exposed the limit. A model could write an excellent answer and still be nearly useless in a real operation. It did not know which customer record was authoritative. It did not understand how a contract related to an entitlement. It could not tell whether an employee could approve a refund, which exceptions needed human review, or which regulation applied to a given transaction. The model had intelligence without institutional context.

Get Premium for Full Enterprise AI Atlas

Then agents arrived, and the ambition moved from answering questions to doing work. The system would no longer recommend an action. It would open the case, update the record, contact the customer, issue the refund, escalate the exception, and document what happened.

The adoption record shows how far that ambition still is from reality. Ali Ghodsi, who runs Databricks, describes asking enterprise audiences how many of them manage fleets of agents that coordinate with each other. Almost nobody raises a hand. Most are using a chatbot as a faster search engine, plus coding assistants. His diagnosis is blunt: the frontier models are already smart enough, but they lack the context that exists inside any organisation. He sells a platform built to capture that context, so the view is not disinterested. It still matches what most deployments show. For the typical enterprise, a smarter model is not the bottleneck.

That changed the nature of the problem. Once AI begins to act, the constraint is no longer intelligence. It is context, authority, process and control. This is the market now taking shape.

Read more

Enterprises will increasingly push more strategic workloads toward open-weight models, not simply because they can be cheaper, but because they offer something more important: modularity, control, deeper customization, and greater protection over proprietary context and intellectual property.

The strategic goal is to bring the model closer to the enterprise, rather than continuously sending the enterprise into someone else’s model. That means adapting models to internal knowledge, workflows, policies and domain-specific context, while building a deeper understanding of where the company’s real AI moat can emerge.

In theory, this is extremely attractive. In practice, running, customizing, securing and maintaining open models inside the enterprise core is far from free.

And this is where the economic argument is often misunderstood.

If the main reason you are moving to open models is simply to save money on tokens, you may be approaching the problem from the wrong direction. The stronger case for open models is control, modularity, strategic independence and the ability to progressively encode proprietary enterprise context into the AI stack.

Cost matters, but it should be evaluated against those strategic benefits, not in isolation.

This analysis breaks down that trade-off in full: where open models actually save money, where they become more expensive than expected, and where the real strategic value lies beyond the token price.

Open weights can give you more control, more flexibility and lower costs. But downloading a model, operating it and getting useful work from it are three different economic problems.

An open-weight model can cost nothing to download. That is a meaningful advantage. You receive the model’s learned parameters, with rights to use and modify them under its licence. But the download is not the service. Someone still has to supply the computing capacity, operate the software, monitor performance and handle failures. A free model does not automatically produce a low-cost system.

The opposite mistake is just as important: adding every engineering, evaluation and governance expense to self-hosting, then comparing that total with an API’s token bill alone. Buying access to a managed model does not eliminate the customer’s work on integration, access controls, output quality or oversight. It changes which responsibilities sit with the provider and which remain with the customer.

The useful question is not “Are open models cheaper?” It is “Which combination of model, deployment and supervision delivers the required outcome at the lowest acceptable cost and risk?”

That question has an established name: total cost of ownership.

The Full AI Open Ecosystem Atlas Here

To gain Full Access, subscribe below.

Get Access To The Full BE Platform

Read more

Bower did not found McKinsey, nor did he invent management consulting. But he became one of the central architects of the modern profession. Harvard Business School goes further, calling him the father of modern management consulting.

Bower believed consulting should operate as a profession rather than simply another commercial trade. Over the following decades, McKinsey institutionalized many of the practices that would come to define elite consulting: the firm above the individual, an independent obligation to tell clients what consultants believed to be true, recruitment of exceptional young graduates, apprenticeship, and eventually the up-or-out system.

Together, those choices helped institutionalize one of the most successful organizational models of the twentieth century.

The pyramid.

A small number of expensive partners sat at the top. Beneath them were layers of bright, relatively inexpensive juniors who researched, interviewed, modeled, synthesized, and built the slides. The client paid for the partner’s judgment, while much of the work was produced by the pyramid underneath.

For decades, that was the economic engine of consulting: leverage.

Then AI arrived.

For seventy years, the consulting business model ran on a quiet engine: leverage.

A small number of expensive partners sat atop a large pyramid of bright, inexpensive juniors who researched, modeled, interviewed, synthesized, and built the slides. The client paid for the partner’s judgment but received, for the most part, the pyramid’s labor.

The economics followed from that ratio: billing rates, utilization, up-or-out promotions, profit per partner. A firm became more valuable when each partner could sell more junior hours beneath them.

AI attacks precisely that layer.

Research and synthesis. First-draft analysis. Public-source benchmarking. The first model. The first slide. The base of the consulting pyramid was among the first categories of professional work to become legible to a machine.

The engine did not merely become more efficient.

It was removed.

Three consequences follow:

• The base became rentable. Leverage that once belonged to the firm can now be purchased by almost anyone for a subscription.

• The hour begins to lose its role as the unit of value. Once clients can see the approximate cost of producing an outcome, charging for the time between input and output becomes harder.

• The deliverable loses scarcity. For seventy years, the document was what the firm left behind. Now the document is cheap.

What the client increasingly wants instead is the capability.

And what the firm should have been accumulating all along is the residue of every engagement it ever ran: decisions, exceptions, cases, methods, and patterns that repeated across clients.

Instead, most of that knowledge left inside the deck.

The industry is therefore not disappearing. It is splitting between firms using AI to produce the old product faster and firms rebuilding what the product is.

This volume is for the second group.

Sell the outcome. Keep the residue. Leave the capability.

This is a new book in The Business Engineer’s 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

Then DeepSeek changed the picture.

The DeepSeek moment showed that a certain class of open-weight model could compete on cost, capability, and deployability in ways that mattered to enterprises. Through 2026, that opening became harder to ignore. More capable open models arrived, serving infrastructure improved, hosting became easier, and enterprises gained more credible alternatives to a purely closed-model stack.

The picture today is therefore much more nuanced. Closed models still dominate important parts of the market, particularly at the frontier. But open weights are no longer a peripheral alternative. They are becoming part of the production architecture itself.

To understand what changed, we need to separate the different layers: capability, economics, infrastructure, control, and ultimately who captures the value.

In August 2026, open-weight models processed 56% of all tokens on Vercel’s AI Gateway, up from 7% in December 2025. OpenRouter reported a similar pattern, with open models accounting for roughly 60% of US-originating token consumption during the same period. Those percentages are not market share for the entire AI industry. Gateway data sees the workloads routed through those platforms, not every direct API contract, consumer subscription, private deployment, local model, or enterprise agreement.

The reverse is also true: commercial gateways miss some open-model usage precisely because open weights can run privately. The numbers are therefore neither a census nor a curiosity. They tell us something narrower and still important: within major production environments designed around model choice, open weights have moved from experimentation into real production infrastructure.

The more important change, however, is not that open models crossed 50% of token volume. It is what has happened around those models. A model can now be trained by one organization, served by another, routed through a third, embedded inside a fourth company’s product, and specialized by a fifth for an enterprise customer. Training, serving, distribution, customization, and application delivery no longer have to sit inside the same company.

That separation is what makes the current cycle different. For years, the trajectory of open AI depended heavily on whether one or two large organizations continued releasing competitive weights. If Meta slowed Llama, or another major lab changed strategy, the open frontier could lose momentum. Today, many more actors have independent reasons to keep it moving: inference companies want workloads, chip vendors want compute demand, gateways want model diversity, application developers want substitutable intelligence, enterprises want lower costs and greater control, and regional labs want strong bases they can adapt rather than retrain from scratch.

This is what I mean by open escape velocity. Not that open models have defeated closed models. Not that every dependency has disappeared. And not that the ecosystem is already economically self-sufficient. The stronger claim is that open AI is beginning to develop enough independent sources of demand, infrastructure, capital, and institutional support that its future depends less on the strategy of any single model company. But adoption and self-renewal are different things. The gateway data tells us open models are being used. It does not yet tell us whether the ecosystem can sustainably finance the next generation of them.

The Full AI Open Ecosystem Atlas Here

The Business Engineer’s Agenting platform is now available to Executive members. You can start exploring it here: businessengineering.ai/agent

Get Access To The Full BE Platform

You can preview the platform at Business Engineering AI.

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. You can check out the full library here.

Read more

As I wrote in my newsletter at the time, an important part of that story was the work behind InstructGPT and reinforcement learning from human feedback, or RLHF. ChatGPT was a sibling of InstructGPT, not simply the same model with a chat window attached. Its training combined supervised examples of conversations with reinforcement learning guided by human rankings of responses. These methods helped turn a model trained to continue text into an assistant better able to follow instructions and respond to what a person actually wanted.

To me, that was the defining product insight: capability became approachable. The model’s intelligence mattered, but so did the removal of friction between that intelligence and an ordinary user. You no longer needed to understand the machinery underneath to get something useful from it.

Yet the same human-centered design introduces a tension. An answer a person prefers is not necessarily a decision a business should execute. Human feedback can reward correctness, clarity, and useful caution, but poorly balanced feedback can also encourage agreement, reassurance, or confidence that the evidence does not justify. OpenAI’s account of its 2025 GPT‑4o sycophancy problem illustrates the risk: a change intended to improve the experience instead made the model excessively agreeable. That is a failure mode of the incentives, not the inevitable result of all human-feedback training.

This distinction becomes more important as we move from conversational assistance to agentic execution. In a chat, a person can read the response, question it, and decide what happens next. Now imagine an enterprise operating hundreds or thousands of agent runs in parallel. Those systems may be routing requests, updating records, preparing transactions, or coordinating work across applications. A plausible explanation is no longer sufficient evidence of success. The question is whether the intended result actually occurred, not whether the agent convincingly said that it did.

If every result still requires someone to interpret and approve it, the review requirement remains part of the cost of every result. Some decisions should retain that checkpoint. But for bounded, repetitive work, the opportunity is to make review selective: let the system proceed where the evidence supports delegation, and bring the person back where uncertainty or consequences demand judgment.

That does not mean RLHF is inherently incompatible with automation. It has also improved instruction-following and truthfulness, and human feedback has been used to train agents outside conversational settings. Human involvement in training is not the same thing as requiring a human to supervise every decision in production. Simply removing RLHF would not automatically produce a more reliable system.

The more interesting question is what happens when we stop treating the conversational assistant as the default design for every application of intelligence. What would we build if the primary objective were dependable decisions, rather than preferred responses? A system designed around that objective would need to demonstrate correct task completion, uncertainty tested against outcomes, appropriate abstention, and actions constrained by explicit authority. It would not necessarily need to narrate every decision to a person.

That is where today’s issue begins: not with the assumption that removing RLHF solves automation, but with an investigation into whether automation needs a different balance of training objectives, interfaces, and evidence. The assistant had to become useful to the person reading its answer. The next system has to become dependable enough for software to act on its output.

The first breakthrough made intelligence conversational. The next may make it reliably actionable.

Jev is now available inside The Business Engineer’s Agenting platform. Executive members can start exploring it here: businessengineering.ai/agent

Get Access To The Full BE Platform

You can preview the platform at Business Engineering AI.

You can also experience Jev’s speed firsthand by trying Genesis, our latest free AI tool: businessengineering.ai/tools/genesis

Get Access To The Full BE Platform

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

For a while, that made AI look as if it would follow the Web’s trajectory: consumer first, enterprise second. The interface was conversational, the marginal cost of trying it was almost zero, and the first explosive use cases were individual. Even through much of 2024, the market could still be interpreted that way.

Then the shape of the competition began to change. Anthropic pushed aggressively into coding and enterprise workflows, coding agents became one of the clearest demonstrations of what sustained agentic work could look like, and the frontier labs increasingly found themselves competing not only for consumer attention but for the right to sit inside the enterprise.

OpenAI, Anthropic, Google, Microsoft, Amazon, and almost every serious model provider are now trying to solve different versions of the same problem: how do you turn general intelligence into useful work inside a very specific organization?

That shift is much more important than another model benchmark. It exposes the fundamental difference between AI and the previous wave of digitalization.

Digitalization was largely an outside-in transformation. The Web created a new external layer of distribution. Companies connected themselves to it through websites, search, e-commerce, social platforms, mobile apps, APIs, and eventually cloud infrastructure. The consumer interface changed first, and organizations reorganized themselves behind it. The Internet made the company reachable from the outside.

AI is increasingly an inside-out transformation.

It starts from intelligence and has to work its way into the machinery of the organization. And that is much harder. It does not matter how intelligent the underlying model becomes if it does not know which customer the employee means, which contract governs the transaction, which policy is current, which account is authoritative, which product can actually be sold in that market, which person owns the exception, what action it is permitted to take, and what the company considers a successful outcome.

Whether we eventually call the underlying capability AGI, ASI, or something less dramatic is almost secondary to the enterprise problem in front of us. Intelligence alone is not the product.

A frontier model has no intrinsic understanding of how your company works. It does not carry your operating model inside its weights. It does not know which version of reality your organization has agreed to treat as canonical. It does not possess authority merely because it can reason.

The bridge between intelligence and enterprise work is context.

But context here means much more than retrieval. It is the firm’s entities, relationships, rules, process states, ownership, permissions, exceptions, standards, history, and current operating reality. It is the semantic and operational layer that turns a general model into something capable of performing one narrow, vertical, consequential workflow.

The real enterprise AI problem is not simply making the model smarter. It is making intelligence situationally useful, operationally authorized, and economically valuable.

Once seen this way, the next phase of enterprise AI becomes easier to understand. For genuinely difficult work, model capability can still be the bottleneck. But for a growing class of bounded tasks, capability is already good enough that the constraint has moved elsewhere. The system needs the right context. Once it has context, it needs authority and proof. Once it can act, human attention becomes scarce. And once it operates at scale, economics decides whether it survives renewal.

This is the rotating bottleneck:

Capability → Context → Authority & Proof → Human Attention → Economics

A constraint binds until technology, capital, or organizational learning eases it. Then the next constraint becomes visible. The mistake is continuing to optimize for the bottleneck that just disappeared.

The enterprise operating loop follows naturally. Business context feeds governed execution. Governed execution produces accepted outcomes. Accepted outcomes create economic value. Exceptions generate expert judgment. Verified and permitted judgment becomes reusable learning. That learning improves the next execution and makes the next comparable deployment cheaper, faster, and more accurate. Then the loop starts again.

The weak link is that learning does not automatically belong to the vendor. Feedback can be noisy, confidential, biased, customer-specific, or contractually restricted. The loop compounds only when useful feedback can be verified, retained, and legitimately reused.

The operating doctrine for the next twelve months is therefore:

Productize deployment. Own context, control, and proof. Price accepted work.

What the Last Twelve Months Changed

In September 2025, the characteristic enterprise AI artifact was still the pilot. A team identified a use case, found an internal champion, built something impressive enough for a demonstration, and added another initiative to an innovation portfolio. In many organizations, the fact that the pilot existed was itself treated as evidence of progress.

Twelve months later, the relevant artifact is increasingly the production loop and its bill. A production loop needs a named owner. It needs access to real systems and real company data. It needs a standard against which the work can be accepted or rejected. It needs permission to act, a path for exceptions, a way to recover when something fails, and somebody willing to pay for its ongoing operation. Most importantly, it runs repeatedly. The same system that looked extraordinary in a twenty-minute demonstration now has to survive thousands of real cases.

That is where the questions change. What happens when the model is uncertain? What happens when two systems disagree? Who decides which source is canonical? Which actions can the agent execute autonomously? Which require approval? How much human review does the workflow consume? What happens when the model provider changes the underlying model? What does the whole thing cost once inference, tooling, failures, rework, and review are included?

Eventually finance asks the question that the pilot never had to answer:

What did the accepted work cost?

The rest of the market moved in parallel. Coding agents showed what an agentic workbench could look like when the environment provides strong feedback. Application vendors started opening their systems to external agents and protocols. Semantic layers, ontologies, governance systems, evaluation infrastructure, and agent control planes moved from architecture diagrams into product roadmaps. Forward-deployed engineering became a strategic capability rather than a temporary implementation function. AI engineering became more central while parts of the entry-level knowledge-work ladder began narrowing.

All of these developments are easier to understand once the cycle is framed correctly. The market did not simply move from weaker AI to stronger AI. It moved from capability to operations.

The enterprise question changed from:

Can the model do this?

to:

Can the organization operate this repeatedly?

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 Business Engineer, a concept I first introduced in 2018 as a spin-off of my research at FourWeekMBA, had become, in my mind, the defining discipline for the digital business person. But as AI became increasingly central to the technology landscape, another shift became impossible to ignore.

A large part of that shift was about the buyer.

During the digital era, it was possible to build highly valuable software companies by obsessing over UX, narrowing the scope of the application, and distributing software to millions of small businesses and individual users. The economics made sense: standardize the product, reduce friction, and scale distribution.

AI changes that equation.

The small business may increasingly be able to vibe-code its way through much of its own software stack, assembling and customizing applications around its specific workflows rather than buying dozens of rigid SaaS products.

The enterprise sits at the opposite end of the spectrum.

Large organizations have the budgets, complexity, proprietary data, regulatory constraints, and operational depth that make customization not merely desirable, but necessary. They are willing to pay to adapt AI systems to the core of how their businesses actually operate.

Software, once again, is changing definition. I explore that transition in greater depth in the other books in this series.

But one consequence is already clear: the enterprise buyer has moved to the center of the AI adoption race.

And that is why it deserves a book of its own.

Buying enterprise AI is difficult for a simple reason: the vendor usually has far more experience selling this kind of system than you have buying it.

Imagine an insurer evaluating an AI system for claims. The claims team may buy one serious AI platform this year. The vendor may run fifty evaluations across insurers, banks and healthcare companies. It already knows which demo gets executives excited, which objections procurement will raise, which security questions arrive late, which pilot metrics are easy to pass and how far it can move on price before the buyer walks away.

The buyer has different expertise. The claims leader knows claims. Security knows security. Procurement knows contracts. Finance knows the budget. But nobody in the room may have seen twenty claims-AI deployments go from impressive demo to messy production.

That matters because AI is unusually easy to make look good before production. Suppose the vendor demonstrates the system on twenty claims it selected itself. Eighteen are handled correctly. The demo looks excellent. But those twenty cases tell you almost nothing about what happens when a scan is missing a page, two policy clauses conflict, a claimant gives contradictory information, the retrieval source is stale, the underlying model changes next month, or the case falls into the strange five percent that consumes half of your adjusters’ time.

Traditional software was easier to inspect. If you bought a CRM, you could verify that the workflow existed, permissions worked, the integration connected and users could complete the required actions. AI behaves differently. A system can work on the vendor’s examples and fail on yours. It can change after a model upgrade. It can become expensive when power users begin using it seriously. It can also improve from the cases, corrections and decisions your own people provide.

So change the order of the purchase. Do not begin with the demo. Begin with your work.

If you are buying an AI system for claims, give every shortlisted vendor the same real claims and have your senior adjuster define what correct looks like. If you are buying an AI support agent, test it on the tickets your best support people consider difficult. If you are buying an AI contract system, include broken scans, unusual clauses, amendments, missing pages and the exceptions that actually consume lawyers’ time.

Then measure the result yourself.

The vendor should not choose the exam, write the answers and grade the paper.

Your company needs to own the exam.

The same principle applies after purchase. Imagine that after six months the claims team has produced eighty original test cases, two hundred failures found in production, hundreds of adjuster corrections, escalation rules and a record of which decisions led to successful recoveries. That material now describes how your company performs part of the work.

If it all lives inside the vendor’s system, leaving becomes expensive. If you own it in portable form, the vendor becomes much easier to replace.

Three questions should therefore sit underneath every material AI purchase:

• Does it work on our cases?

• What do we become dependent on?

• What do we still own after a year of using it?

Everything else follows from those questions. The demo earns the right to be tested. The pilot produces evidence. The contract decides ownership and change rights. The renewal asks whether the evidence still justifies the dependency. The exit plan matters because a clause saying you may leave is useless if leaving requires six engineers and nine months of rebuilding.

Own the test. Own what the system learns from your work. Know what it would cost to leave.

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

Part of that fascination came from neuroscience itself. I spent part of my early professional life in San Diego, home to an unusually dense neuroscience ecosystem around institutions such as UC San Diego and the Salk Institute. In my early twenties, one of the ideas that struck me most deeply was neuroplasticity: the realization that the brain is not a fixed structure, but something continuously reshaped by experience, learning and the environment. Experiences do not simply fill the brain with information. They can alter its functional organization and even its physical structure.

That idea stayed with me.

Fast-forward to the mid-2010s. I was sitting in a startup office trying to understand where AI might go next. By then, neural networks were no longer merely a promise. Deep learning had already produced major breakthroughs in computer vision, speech recognition and sequence modeling. Yet these systems still seemed remarkably limited when compared with the messiness of intelligence in the real world.

This was one reason I found reinforcement learning so compelling.

AlphaGo became perhaps the most visible demonstration. Its famous Move 37 against Lee Sedol in 2016 looked almost alien to expert Go players, yet emerged from a system combining deep neural networks, search and reinforcement learning. Around the same period, reinforcement learning also occupied a prominent place in OpenAI’s early research agenda, with projects such as OpenAI Gym and Universe focused explicitly on agents learning through interaction with environments.

What appealed to me about reinforcement learning was its relationship with experience. Intelligence in the real world is not simply a matter of performing reasoning in isolation. We act, encounter consequences, update our understanding, and act again. The world gives us feedback. Much of what we eventually call intuition is accumulated experience compressed into a form that allows us to navigate situations whose relationships are nonlinear, incomplete and difficult to express explicitly (by the way this is what The Business Engineer’s discipline is all about).

And this is where the story becomes particularly interesting.

The extraordinary progress of modern AI has come primarily from neural methods. Yet neural models have an enduring problem: they do not encounter a task with all of the context that makes that task meaningful in the real world. They can contain enormous amounts of learned statistical knowledge, while still lacking the specific entities, relationships, rules, history, constraints and state required to operate reliably inside a particular environment.

This is where symbolic structures become important.

Neuro-symbolic AI refers broadly to attempts to combine the learning and pattern-recognition strengths of neural networks with explicit representations of knowledge and reasoning. Knowledge graphs, ontologies, rules and other structured representations can become part of that architecture. They do not replace the neural model. They give it something it otherwise struggles to construct reliably on demand: an explicit map of the world in which it is expected to act.

That is the subject of this book.

Context and Graph Engineering is about engineering that missing layer: how we represent entities, relationships, semantics, memory, rules and situational context so that increasingly powerful neural models can become increasingly useful in the real world.

The neural network gives us extraordinary generalization.

The graph gives us structure.

Context tells the system what world it is operating in.

And increasingly, useful intelligence will come from making those pieces work together.

This is another volume 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

It described a person.

At Langley Memorial Aeronautical Laboratory, the predecessor of NASA’s Langley Research Center, a young mathematician named Virginia Tucker joined four other women in the laboratory’s first computing pool. Their job was to calculate. They processed experimental data, solved equations, plotted results and produced the mathematical work engineers needed to design aircraft.

They were called computers.

Over the following decades, hundreds of women would do this work at Langley. During World War II, the demand became so large that NACA expanded its computing workforce further, including the Black women of the segregated West Area Computing unit whose story would later become widely known through Hidden Figures.

Then the machines arrived.

And something interesting happened.

The work did not simply disappear. It moved.

The machine increasingly performed the calculation. The human moved toward programming it, checking it, interpreting its output and deciding what problem it should solve. Some of the women who had been called computers became among the early programmers of the electronic-computing age. Dorothy Vaughan, who had led Langley’s West Computing group, became an expert FORTRAN programmer as NASA reorganized around electronic computing.

The title migrated from the person to the machine.

The responsibility migrated in the opposite direction.

That history is useful because something similar is happening again.

The strongest signal in the AI labor market is not the proliferation of strange new titles. It is a change in who owns what.

Commercial teams are hiring builders. Product managers are taking responsibility for evaluation. Lawyers and other domain experts are moving from reviewing software to helping construct and supervise it. Deployment is splitting into engineering, rollout and enablement. AI work is moving directly into finance, recruiting, marketing, customer service and operations.

Meanwhile, much of the work that historically trained the entry-level professional — research, first drafts, basic analysis, annotation, ticket handling — is becoming the machine’s work.

Once again, the interesting question is not simply which jobs disappear?

It is:

Where does the human move when the machine takes the task?

This volume is an attempt to map that movement.

Across eleven business functions, forty-four kinds of work are already becoming visible. Their titles remain inconsistent, but the underlying pattern is remarkably stable. Humans are moving away from simply producing the work and toward designing the systems that produce it, supplying the expertise those systems need, evaluating what they produce, handling the exceptions they cannot resolve, and owning the outcomes they create.

The computer once moved from the person to the machine.

Now something similar is happening to knowledge work.

And once again, the work is not simply disappearing.

It is moving.

The shape of the new job can be compressed into three responsibilities:

Own a loop. Sit at a junction. Seed the standard.

This is another deep dive 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

I became so fascinated with the discipline that I made it a major emphasis of my MBA. At the time, I had a relatively simple belief: if you could truly master corporate finance, you could build an extraordinary professional advantage. Finance appeared to offer something close to a science of business, a rigorous framework through which almost any company, investment, or strategic decision could ultimately be understood.

Little did I know that corporate finance would teach me almost the opposite lesson.

Finance is extraordinarily powerful precisely because it deals with uncertainty. But that also means it can never be the hard science I once imagined it to be. Its models are abstractions of a world that is nonlinear, reflexive, path-dependent, and filled with variables that cannot be known in advance.

That tension became one of the intellectual foundations behind The Business Engineer.

One reason I started writing about business was to help more people understand a lesson I had first encountered through finance: a model is useful because it helps you think, not because it gives you the truth.

A discounted cash flow is a perfect example. It can be an extraordinarily powerful instrument. But there is no serious DCF without a view on the discount rate, and no serious estimate of the cost of equity without assumptions about things such as the risk-free rate and the equity risk premium. Of course, you can simply use whatever rate has become conventional in the market. But then what exactly are you analysing?

The arithmetic may be precise while the underlying assumptions remain deeply uncertain.

That is not a weakness of corporate finance. It is actually where its greatest usefulness begins.

Corporate finance gave me a toolbox that forced me to connect the micro and the macro: the economics of an individual company with interest rates, capital markets, risk, incentives, competitive dynamics, and expectations about the future. Properly used, those tools expand your thinking. They force you to expose assumptions, test scenarios, and make explicit what would otherwise remain intuition.

The problem begins when the toolbox becomes the worldview.

Too often, financial models are treated not as instruments for thinking but as representations of reality itself. Once that happens, the apparent precision of the model can hide the uncertainty of its assumptions. And some of the largest mistakes in business come from exactly this inversion, both on the upside and the downside: companies that look worthless because a model cannot capture what is compounding beneath the surface, and companies that look extraordinarily valuable because a spreadsheet extrapolates temporary economics indefinitely into the future.

I say this as someone who genuinely idolised finance.

As a teenager, one of my intellectual heroes was Federal Reserve Chairman Alan Greenspan. Years later, as the 2008 financial crisis propagated through the global economy and into the 2010s, I followed Ben Bernanke’s explanations of the crisis and monetary system with enormous attention, including his 2012 lectures on the Federal Reserve and the financial crisis.

I was fascinated by the idea that sufficiently sophisticated financial and economic models might allow us to understand an extraordinarily complex system.

Over time, however, finance itself taught me the limits of that belief.

The deeper lesson of the financial crisis, and of many of the business cycles that followed, was not that models were useless. It was that a discipline becomes dangerous when it develops the presumption that its models can explain the whole world.

Finance is not the worldview.

It is one tool inside a much larger toolbox.

That toolbox also needs technology, strategy, economics, history, psychology, organisational behaviour, geopolitics, systems thinking, and the accumulated judgment that comes from watching real businesses behave in ways no spreadsheet predicted.

The goal is not to abandon models. It is to combine them into a stronger first-principles approach: use models to decompose reality, expose assumptions, identify mechanisms, and understand what would need to be true for a thesis to hold, without ever confusing the model with reality itself.

Finance was my first intellectual love in business, and for that reason I will probably never stop loving it.

But I can no longer reconcile myself with the limitations it creates when used carelessly, particularly when tools designed for one economic regime are carried unquestioningly into another.

This book in the Business Engineer Foundation Series is dedicated to that problem.

To taking the extraordinary toolbox corporate finance gave us, understanding where it still works, identifying where its assumptions have broken, and rebuilding it for a world in which the assets, economics, capital structures, and companies themselves are changing faster than the models traditionally used to value them.

The purpose of finance should not be to shrink reality until it fits the model. It should be to give us better tools for thinking about a reality that will always remain larger than the model.

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.

Subscribe To Premium To Gain Access!

Check out the Library for Free!

Read more

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