The ABCs We Must Learn: AI, BI, and CI

Almost every large company now has AI. Almost none of them have the return. McKinsey's 2025 state of AI survey found that about 88% of companies use AI in at least one function, yet only 39% report any earnings impact, and most of those say it is under 5%. BCG put it more bluntly the same year: only 5% of companies are getting value from AI at scale, and 60% are getting nothing material at all. The MIT NANDA team gave the cycle its headline number, 95% of enterprise generative AI efforts showing no measurable bottom line within six months.

Read those numbers carefully and a pattern shows up. The failure is almost never the model. The MIT team named the real cause the learning gap: tools that do not connect to how the business runs. The company bought the intelligence and skipped the two things that make intelligence useful. We learned our A. We forgot our B and our C.

So here are the ABCs every operator now has to learn. AI is the intelligence. BI is Business Intelligence, the structured truth we spent twenty years building. CI is Context Intelligence, the new layer that teaches a machine how your specific business actually works. Transformation needs all three. Most programs are running on one.

A is for AI. It is the part you rent.

The strange thing about this moment is that the hardest part is now the easy part. Frontier models are extraordinary, and they are available to your competitor on the same terms they are available to you. Intelligence has become a utility. You pay by the token and it shows up.

That is exactly why AI on its own moves so few numbers. A general model knows everything about the world and nothing about your world. It has never seen your definition of an active customer, your close process, your escalation rules, or who is allowed to approve a refund. Ask it a question that depends on any of those and it will answer with total confidence and no idea whether it is right.

There is a second trap here that most leaders have not internalized yet. A smarter model does not fix a missing context problem. It makes it worse. A weaker model gives you an answer that is obviously off, so you catch it. A stronger model gives you an answer that is fluent, well structured, and wrong in a way no one notices until it has shipped. Capability without context does not reduce risk. It disguises it.

B is for BI. It is the part you already built.

Business Intelligence is the discipline most companies have been investing in for two decades. Data warehouses, pipelines, dashboards, and the semantic layer that says what a metric means. The whole point of BI was to take messy operational data and turn it into one trusted version of revenue, churn, and headcount that a human could read on a chart.

That work is not wasted. It is the foundation. When a model writes a query against your raw tables with no semantic layer, it guesses at what your columns mean and produces plausible nonsense. Snowflake published the cleanest version of this with its own tooling: a strong general model scored 51% on business questions against raw schemas, and around 90% once a semantic model told it what the terms meant. Treat the exact figure as vendor friendly, but the direction is real and every serious lab reports the same shape. Definitions move accuracy more than model size does.

Here is the limit. BI was built for a human sitting in front of a dashboard. The human supplied the missing context from memory. They knew that the finance definition of bookings differs from the sales one, that the West region data is two days behind, that you never trust the draft version of the pricing table. None of that judgment is written down. It lives in the analyst's head. BI gives an agent the metrics. It does not give the agent the mind of the person who knew how to use them.

C is for CI. It is the part almost no one has built.

Context Intelligence is the layer that turns the knowledge in people's heads into something a machine can use. The phrase going around the industry is context engineering, and the people who named it were precise about what they meant. Tobi Lutke, the Shopify CEO who popularized the term, called it the art of providing all the context needed for the task to be plausibly solvable by the model. Andrej Karpathy described it as filling the context window with just the right information for the next step. Anthropic frames context as a finite resource with an attention budget, where every extra token of noise costs you a little accuracy, so the goal is the smallest set of high signal information that gets the job done.

In an enterprise, that high signal information comes in three kinds.

Knowledge: what things mean.

The entities, definitions, metrics, and relationships of your business. What counts as a case. What counts as resolved. How a customer in the CRM maps to the same customer in billing and support. This is BI's territory, extended so a machine can resolve it rather than a human.

Expertise: how work gets done.

The playbooks. How you actually run the monthly close, an investigation, an accommodation request. The triggers, the edge cases, the order of operations your best people follow without thinking. Today this is tribal knowledge. It walks out the door when they do.

Norms: what is allowed.

The policies, permissions, approval paths, and compliance limits that decide what an agent may and may not do. In a dashboard a wrong permission is an annoyance. For an agent that can act, it is an incident.

Why does this layer matter so much in practice? Because attention is finite and long context decays. Stanford researchers documented the lost in the middle effect, where a model uses information at the start and end of its context far better than anything in the middle, sometimes performing worse than if you had given it no documents at all. Chroma's 2025 work named the broader version context rot: as you stuff more in, reliability falls, even on simple tasks. The answer is not a bigger context window. It is a system that selects the right context for the question and leaves the rest out. That system is what Context Intelligence is.

Signal and noise: what to believe, what to discount

A warning, because this space is loud. Almost every data vendor now sells a context layer, and they do not mean the same thing by it. For some it is a semantic layer for metrics. For others it is a governance and lineage shell, or agent memory, or a data catalog, or a piece of plumbing exposed through a protocol. One phrase is being stretched across at least five different products. When a vendor tells you they are the context layer, your first question is which of those five they actually built.

The signal underneath the noise is solid, and it does not come from the marketing. It comes from the labs and the research. The need for context is real, it is measurable, and it is the difference between a demo and production. The productized context layer is a contested category where ten companies are racing to own the word. Hold both thoughts at once. Build the capability. Stay skeptical of anyone who says they can sell it to you whole.

The three letters multiply, they do not add

The reason most programs stall is that they treat these as a shopping list. Buy AI, maybe refresh BI, skip CI. But the three do not add up. They multiply. A great model on top of clean metrics with no business context is still confidently wrong. Rich context with no trusted metrics underneath is grounded in garbage. And perfect data with no model on top is a dashboard nobody reads.

Transformation is AI times BI times CI. If any one of them is near zero, the product is near zero, no matter how large the other two are. That single idea explains the 95% better than any other theory I have seen. Most of those failed programs scored high on A, medium on B, and zero on C.

Where to start: People Operations as the proving ground

If this is abstract, make it concrete in the function I know best. People Operations is the sharpest place to build Context Intelligence, because it holds the richest tribal knowledge in the company and the highest cost of getting context wrong.

The People Operations version of what is a customer is a set of questions every HR agent fails on in production. What is a case. What does resolved mean, as opposed to closed. When is something an escalation. Who counts as a worker, given that contingent staff often live in a separate system the HRIS never sees. These are not model problems. They are missing definitions. Each one is a contested, system specific answer that only the function running the work can settle.

The build path is the same one the best practitioners use.

Bootstrap, do not boil the ocean.

Do not start from a blank page. Mine what you already have: case logs, macros, the knowledge base, the standard procedures your senior people wrote, the BI definitions that already exist. That gets you most of the way to a first draft of the context. Then let the flywheel turn.

Pick one painful process.

Choose a single high volume, low sensitivity case type, like a benefits or policy lookup. Author fifteen to twenty certified definitions for it: the case taxonomy, the resolution rule, the service level tiers, the data sensitivity classes, the canonical worker identity. Encode them as data an agent must resolve against, not as a wiki page a human is supposed to remember.

Let AI propose, keep humans certifying.

Have the AI read your systems and draft the definitions and playbooks. Have a senior person approve, edit, or reject each one. In People Operations this human gate is not optional. A wrong norm about who can see an investigation is a privacy breach, not a bad chart. So the rule is autonomous discovery, governed promotion.

Treat every wrong answer as a context bug.

When the agent gets something wrong in production, do not reach for a better model. Find the missing definition, the undocumented exception, the stale rule. Fix the context and it stays fixed for every agent after it. This is the compounding loop. Done right, the tenth agent is sharper than the first, because the layer underneath learned something each time.

One more reason to start here. The EU AI Act puts HR and employment AI in its high risk category, with duties to inform workers, keep a human in the loop, retain logs, and explain decisions. Building the context layer is also how you build the audit trail those rules demand. The compliance work and the capability work are the same work.

Lines to carry into the room

If you are trying to move a leadership team off the model conversation and onto the one that matters, these are the lines that tend to land.

• Intelligence is rented. Context is owned. The moat is what you own.
• A smarter model does not fix bad context. It just lies more convincingly.
• Every wrong answer from an agent is a context bug, not a model bug.
• We do not have a model gap. We have a trust gap.
• Stop prompt engineering. Start context engineering. Prompts are disposable. Context compounds.
• A definition without an owner is a future incident.
• In People Operations, the playbook in your best caseworker's head is the most valuable and least governed asset in the company.
• Transformation is AI times BI times CI. Score a zero on any one letter and the product is zero.

The work for the next decade

The companies that win the next decade will not be the ones with the best model. Everyone will rent the same model. They will be the ones whose context compounds, where each agent makes the next one smarter. That work is unglamorous. It is writing down what your business actually means, who is allowed to do what, and how the work really gets done, in a form a machine can read.

We spent a decade learning the A. The B has been sitting in our data teams the whole time. The C is the letter that decides whether any of it pays off. Learn all three, in order, and the 95% number stops being a verdict on AI. It becomes a description of everyone who only learned one letter.