The Death of the Company, Read From the Build Site

Peter Diamandis published a piece this week titled "The Death of the Company." It distills a two-hour masterclass his partner Salim Ismail delivered on what Ismail calls the Organizational Singularity, and it earned the six-figure readership it drew within a day. Ismail has spent fifteen years inside the boardrooms of two hundred Fortune 500 companies, and he co-authored the Exponential Organizations framework with Diamandis. When someone with that field time says the corporation faces its most radical restructuring in two centuries, the claim deserves a careful read rather than a hot take. We build governed AI operating systems for mid-market and PE-backed companies, which means we spend our days on the ground the essay surveys from altitude. What follows is a builder's read.

Most of it is agreement.

What they are saying

Ismail asks every CEO he advises a single question. Is there a high-margin line of business in your company that two people with AI agents could replicate in 60 to 90 days? Seven in ten say yes, and the essay builds outward from that answer. An AI-native company runs on a five-layer intelligence stack, with agents sensing the environment, interpreting what they find, recommending decisions, executing the approved ones, and learning from the results. Humans sit above the loop and approve or refuse at checkpoints. A governance band wraps the stack, with an evaluation suite for every agent, a log of every action, rollback when something goes wrong, and a human review queue for accountability.

Because a legacy organization's immune system attacks transformation from within, the essay prescribes an edge strategy. Build a parallel AI-native operation beside the core, prove it workflow by workflow, and deprecate each legacy process when the new version outperforms it. Ismail projects roughly 100x throughput at a fifth of current headcount, and he argues that agents have superseded Coase's Law by driving coordination costs toward zero. What survives is purpose encoded as protocol, the legal shell, proprietary data with its learning loop, and human judgment. The org chart and the five-year plan die, and middle management collapses by more than half.

Where we agree

Start with the diagnosis, which the essay gets right. AI adoption is an operating-model problem. A company that treats agents as a feature gets a smarter dashboard, and a company that treats them as architecture gets a different kind of company. We have watched the corporate immune system do what Ismail describes, at Fortune 500 scale in his telling and at mid-market scale in ours.

His edge strategy is our delivery method under another name. Baseline the existing process, stand up the governed version beside it, run the two in parallel, and let the evidence retire the old way. His moat argument matches ours as well. Proprietary data plus a proprietary learning loop is the layer worth owning, and the models underneath must stay replaceable. Even his most abstract move, encoding a Massive Transformative Purpose as a protocol that guides the agents, has a concrete twin in our work. We call it a Product Intent Registry, and it exists so agents build against approved intent rather than a slogan on a wall.

Where we differ

The differences begin where the essay's numbers do. Ismail projects 100x from pilots at ten companies, and the projection may well prove out. We would still never let a client scale on a projection. In our method, evidence authorizes every next move, and each phase gate can return proceed, narrow, remediate, or stop. A workflow earns production the way a drug earns approval, by outperforming a measured baseline under controls. Two of our own engagements taught us the cost of skipping that discipline. Both companies spent real weeks building platform ahead of any proven workflow, and one named its target workflow early yet never captured the baseline underneath it, so there was no number to beat. The essay's velocity is real. Unearned velocity is how AI programs die.

In the essay, the governance band takes one paragraph. In our experience it takes most of the engineering. Naming eval suites, logging, rollback, and a review queue is the easy part, and every hard question lives one level down. Which identity does an agent carry, and who revokes it? When a required field is missing from a request, does the system fail open or fail closed? Who versions the policy, and can an auditor replay a decision from two years ago? Our answers run to a control plane in the path of every call, a six-level trust taxonomy, a versioned policy graph, and an append-only evidence store. Each component ships with an engineering spec and a set of schemas and test fixtures. That list is the price of the paragraph once someone has to build it.

The gap between naming and building runs through the rest.

Ismail's five layers govern what agents do in production and say nothing about how the software underneath them gets built, and the build is where we see companies bleed first. Half of our method is a software factory, where agents write code against approved specifications, every task carries a contract, and an eval gate decides what merges. A company that governs the runtime while its agents commit unreviewed code has governed half of its risk.

And the yes/no checkpoints deserve more scrutiny than the essay gives them. A C-suite approving decisions at every layer works at pilot volume. At 100x throughput nobody reviews a hundred thousand invoices, and an approval queue that long turns judgment into a rubber stamp. Our method protects a small number of human decisions, the scale decision above all, and gives each one a standing cadence and an evidence packet, while policy handles the rest mechanically. Fewer checkpoints, held more seriously, deliver the accountability his review queue promises.

Where to start is the final disagreement. A digital twin of the whole company at the edge, reporting to the CEO, asks for more than most organizations can staff. Our engagements begin with a three-week readiness assessment across eight organizational domains, one workflow, a named sponsor, a named owner, and a checkpoint where either side can walk away. The binding constraint we meet at client after client is human attention rather than technology, and a program scoped to one governed workflow survives production fires in a way a company-wide twin does not.

The same destination

None of these differences touch the destination. Ismail has named the thing we spend our days building, with more reach in one post than a specification library earns in a year, and the market is better for it. Our quarrel is with the road. The companies that arrive will treat the governance band as the product rather than the wrapper. They will prove each workflow against a baseline and let evidence set the pace the essay wants set by urgency. The 70% question should keep CEOs awake, exactly as Diamandis says. The morning after, the answer is engineering.

If the 70% question describes your company, the first governed workflow is a shorter road than the essay suggests, and we can walk you through it in an hour. Reach us at hello@baserpotential.com.