At 14:38 on a Tuesday, a prospect at a B2B advisory firm moved from one stage to the next in a CRM. Nobody announced it. No email went round. The person who made the change was updating a record, not raising a flag.

The following morning it was the first line of the founders’ update, identified - correctly - as the most commercially significant thing that had happened that week. It had been caught from task-history metadata that no human reads, cross-referenced against a relationship record assembled over six weeks, and reconciled against the shape of the pipeline to show what had actually shifted.

No person in that company was holding that chain. The stage change, the history behind it, the relationship record and the commercial consequence sat in four different places, and connecting them was nobody’s job.

This is not a productivity story. Nobody saved twenty minutes. An observation got made that would otherwise not have been made at all, by anyone, ever. That distinction is the whole subject of this piece.

The orthodoxy this argues against

Almost every enterprise adopting AI today is doing the same thing: buying capable models and placing them next to people. Copilots in the productivity suite, an assistant in the CRM, a chatbot on the intranet, a head of AI to coordinate the pilots.

The logic is intuitive and the tools are genuinely good. The results are, by now, well documented. MIT found that roughly ninety-five per cent of enterprise AI pilots produce no measurable impact on the P&L. Fewer than a third of enterprises say they can measure AI’s return with any confidence at all.

The standard reading is that the technology is immature. It isn’t. The models in those pilots are the same models producing extraordinary results elsewhere in the world. What differs is not capability but context - what the model is able to see.

A copilot sits outside the company. It has your prompt and it has its training. It does not know what your firm means by a qualified opportunity, which of your customers are strategically important and which are merely large, what your last three attempts at this taught you, or whether the person asking has the authority to approve it. It is a brilliant contractor on their first morning, every morning, forever.

That is the ceiling, and you cannot raise it by hiring a better contractor.

The thing the model cannot see

I have written elsewhere about perception by lottery - the fact that every company already senses far more than it perceives, and that which signals reach a decision-maker is largely a matter of chance. The argument there was about people. The same structural fact governs what a model can do, and more absolutely.

A company’s real operating knowledge is distributed across systems that do not speak to each other, documents nobody has opened in two years, and the heads of about eleven people. None of it is organised for a reader. It was never organised at all; it accreted. Departments, escalation paths and the weekly status report are the compression mechanisms we built to make that volume survivable for humans, and each of them loses information at every step by design.

Point a model at that and it will do exactly what it is asked, on the fraction of the company it can reach, which is almost none of it. The company is illegible, and the model is not the thing that is broken.

The graveyard

Here is the problem with everything I have just said. It is not new, and it has failed repeatedly.

The semantic web was going to make the world’s information machine-readable. Cyc spent decades encoding common sense by hand. Master data management consumed budgets across the 2000s and produced governance committees. Enterprise knowledge graph programmes have a twenty-year track record of consuming three years, a seven-figure budget and a director’s career before quietly becoming a wiki page nobody opens.

Any CIO over forty has watched at least one of these die. If you are proposing a company brain and you have not addressed that history, they stopped listening several paragraphs ago, and they are right to have done.

So why is this time different?

Because those systems were built for humans to consume, and humans could not. The work of building an ontology was paid up front, by people, and the payoff required those same people to query it, maintain it, and trust it over their own judgement. They never did, and it was never really rational to expect them to. The effort was concrete and the reader was hypothetical.

The reader that makes the investment pay off did not exist until about three years ago.

That is the entire argument. A machine that can hold the whole structure at once, traverse it in milliseconds and act on it without getting bored or leaving the company changes the economics of building it. The thing that killed every previous attempt - that nobody will actually read this - stopped being true.

There is a consequence worth stating plainly, because it is where most current attempts will go wrong. A brain built for people to search is a different artefact from a brain built for machines to act on. Different structure, different guarantees, different failure modes. Search tolerates ambiguity because a human resolves it on arrival; action does not. Porting an old knowledge-management programme forward, or pointing a retrieval system at a document store and declaring the problem solved, produces something that demonstrates beautifully and cannot be trusted with a decision.

What it actually does

Two live examples, both deliberately unglamorous.

The first is the B2B advisory firm from the opening. Beyond the stage change, it surfaces stalled relationships automatically against a threshold - one contact had gone twenty-seven days without a touchpoint following an initial positive reply, which nobody had noticed precisely because nothing had happened to make them notice. Each morning it reconciles a single briefing from five sources: two separate calendars, the task system, meeting transcripts and email, with anything unresolved across days flagged with its age, so that a thing carried for five days says so out loud.

The second is a consumer drinks brand. Entirely different domain, entirely different operations, same pattern.

That is the honest shape of the benefit, and it is worth being precise about it, because it is not the benefit usually sold. In neither case did the brain perform a known job faster. It made the observations that were nobody’s job - the ones that fall between roles, which in most companies is exactly where the expensive misses live.

What it costs

Not in money. In confrontation.

Building a company brain means discovering that your data is inconsistent, your processes are undocumented, your definitions differ by department, and a meaningful share of what the company actually knows exists only in the heads of a handful of people, several of whom are thinking about leaving.

Nobody wants that diagnosis, and it is the second half of why the graveyard exists. Those programmes did not fail only for want of a reader. They failed because the work turned out to be substantially harder than the sponsor had been told, and the sponsor had already promised a date.

What has changed is that the payoff is now real enough to justify the confrontation. That was not true before. It does not make the confrontation optional, and any proposal that implies otherwise should be treated with suspicion.

Where it lies to you

The brain in the first example got something badly wrong.

It reported that five outstanding items had been handled and were ready to close. Two had been. Of the remaining three, two had records that said the opposite in plain language - one stated that a status was unknown and needed confirming, another that a document had not been read and a decision had not been taken. Those were the very records it cited as evidence that the work was finished.

This is worth dwelling on, because the failure mode is not the one people brace for. It was not hallucination. Every fact it used was real and correctly retrieved. The error was inference from adjacency: the system treated the existence of a record about something as evidence that the something had happened.

That is a far more dangerous failure than invention, because it is plausible. A fabricated fact gets caught by the first person who knows better. A confident, well-sourced, wrong conclusion about whether a thing has been done gets believed - and work everyone now believes is handled sits untouched until it costs something.

The answer is not a better model. It is an evidence rule, enforced structurally: assert that something is done only where the record shows that specific action, with a date. Around it sits the governance that makes the rule mean anything - an audit trail, an evaluation harness that measures whether the system is actually right rather than merely fluent, and a gate that nothing passes without having earned it. Nothing moves from observing to acting until it has demonstrated it can be trusted to.

A company brain without that discipline is a confident narrator, which is worse than no narrator at all.

But surely someone already sells this

Yes. Palantir has built the most complete version of this argument and been paid handsomely for it - an ontology they describe as a governed, typed, bidirectional model of the enterprise, unifying the objects a business cares about with the actions that can be taken upon them. Their framing is precise: a system designed to represent the decisions in an enterprise, not simply its data. Their agents do not query databases. They query object types and invoke governed actions.

I would treat this as the strongest available evidence for the thesis rather than as an inconvenience to it. The most valuable enterprise AI company in the world bet its entire architecture on the claim that context, not capability, is the binding constraint, and the market has paid for that bet - United States commercial revenue growing a hundred and thirty-seven per cent year on year, several hundred enterprise customers.

The open question was never whether the idea works. It is who gets it, on what terms, and who ends up owning it.

The same question applies to the more immediate thought a CIO is having, which is that their platform vendor is already building this. Microsoft is assembling it across its data and productivity stack. Databricks and Snowflake are both moving in the same direction. Every one of them will ship something in this shape, into a contract the company already holds.

They will sell you the plumbing, and the plumbing is genuinely useful. But the plumbing is not the brain. What your company means by a good outcome, which exceptions matter and which are noise, how the firm actually decides things as opposed to how the process document claims it does - none of that arrives as a default schema, because none of it is generic. The generic layer is buyable. The specific layer is the work. The strategic question is whether that specific layer is something the company owns, or something it rents indefinitely from whoever owns the plumbing.

What this might mean for shape

Now the speculative part, and it should be read as a hypothesis rather than a finding.

Hierarchy does a great many things. It allocates authority, assigns accountability, structures careers and decides who gets to hire. Nothing in this article touches any of that.

But hierarchy is also, in part, a compression strategy for an illegible company. We divide firms into departments because no individual can hold the whole thing in their head. Each unit encapsulates a manageable share of the complexity and exposes a summary to the others. That is not primarily about power. It is about the limits of what a person can know.

If a reader exists without that ceiling, then one load-bearing reason for the departmental boundary stops bearing load.

What replaces it is not a flat organisation, which is a fantasy that has been tried and buried several times over. It is work organised around whole objects rather than functional fragments. Consider a single closed loop - sensing a class of business object, correlating the signals about it, judging, governing the response, acting - drawn around something a company genuinely cares about. A customer relationship from first contact to renewal. A regulatory obligation from origin to evidence. Money owed, from invoice to cash. Today each of those loops is sliced across four departments, and the seams are precisely where the value leaks out.

There is a useful test buried in this. If a capability crosses several functions in both what it senses and what it does, it is a loop, and it can anchor a team. If it lives in a single column, it is a tool, however clever. A great many things currently described as AI initiatives are tools wearing the language of loops.

A team formed around a loop is horizontal and outcome-defined by construction rather than by reorganisation. You do not flatten the org chart. You make a different unit viable, and the shape follows from that.

What stays human here is not a residue. The brain absorbs retrieval and reconciliation - the finding, joining and remembering that consumes so much of a senior person’s week and for which nobody has ever been promoted. Judgement does not move. Neither does accountability, nor the decision about which of two defensible options a firm should actually take. The realistic effect is not fewer people. It is people spending their time on the part that was always supposed to be the point.

And it does not apply everywhere. A twenty-person firm in which everyone genuinely knows everything does not need a company brain, because the compression was never binding and the brain would be pure overhead. Nor does a business whose operations are genuinely simple. The claim here is about organisations complex enough that no single person can hold them - which is most, but not all.

What would prove this wrong

A thesis with no testable consequence is an opinion wearing citations, so here are three things I would expect to observe by 2029 if this argument is right.

The share of enterprise AI budget spent on context infrastructure - on making the company legible - should rise sharply relative to spend on model access. Today the ratio runs heavily the other way.

The head of AI role should split in two. One person will own the model estate and another will own the organisation’s readability, and the second job will turn out to be the harder and more consequential of the pair.

And the characteristic complaint about failed AI programmes should change. Today it is that the model is not good enough. If this argument holds, it should become that the model cannot see enough - a diagnosis about the company rather than about the technology.

If, in three years, firms are getting durable returns from models that know nothing about them, then I am wrong, and the context problem was a transitional artefact of an immature generation of models rather than a structural feature of enterprises. I would rather state that plainly than hedge it.

The actual question

Enterprise AI has spent three years asking which model to use. That question is close to settled, and it was never the interesting one.

The question underneath it is whether your company is something a machine can read. Whether what you know, how you decide and what you mean by a good outcome exist anywhere at all outside the heads of the people who happen to work there this year.

Most companies will build this capability, because the alternative is watching competitors make observations they cannot. The choice that matters is not whether. It is whether you build something you own, or rent your own legibility from whoever will sell it to you.


Companion to A company your model can read, which makes the case that a company must be made legible before a model can do anything useful inside it. This piece is what it takes to build that legibility, and why the attempt is now worth making.