LISTEN
Listen to this perspective
Written by Oleg Cohen. Companion narration uses the Brian voice.
A year ago I would have called it the missing layer in enterprise AI. It isn’t missing anymore. It has a name, the context layer, and it has funding. Jedify raised a $24 million Series A this summer to help AI systems understand how a business actually operates. Skan AI raised $63 million in August as the context graph of work. Palantir has described its Ontology as a digital twin of the organization for years, and o9 sells a Digital Brain built on an enterprise knowledge graph.
I think the thesis behind all of them is right. Models are becoming abundant, and intelligence is only as useful as its understanding of the particular company it works for. Durable value will sit in the layer that gives generic intelligence company-specific meaning.
My argument is about who that layer is being built for.
Built for companies with data teams
Look at who buys these products. The buyer is a data or AI platform team. The product is infrastructure, and the implementation is a program. That fits a global manufacturer, a bank or a government agency.
Now consider an established business with $50 million to $300 million in revenue. It has multiple locations and hundreds of employees. It runs a CRM, an ERP, scheduling and accounting, and it has years of customer and transaction history. Its managers carry critical knowledge in their heads. The complexity is real, and so is the room to improve margin, retention, capacity and management leverage.
It doesn’t have an AI engineering organization. It will never staff an ontology team, and it doesn’t want a blank semantic platform. It wants outcomes. It wants to see where value is created and lost, and to put its best people’s knowledge to work across the company. It wants to test a decision before committing capital, and to depend less on a handful of individuals.
There are far more of these companies than Fortune 500 enterprises, and almost nobody is building this layer for them.
Compression is the product problem
The technology behind an operating-intelligence layer can be as sophisticated as it needs to be. The customer can’t be asked to consume the sophistication. I call the design problem compression.
In practice, a working model of the business has to form from existing systems, documents and conversations in weeks, without a multi-year data program. Scenario analysis has to be a “what if” an owner can simply ask. Governance has to be explicit without being visible. Knowledge has to arrive inside the work, with no new system for employees to learn.
The winners in this category won’t be the companies that expose the most powerful platform. They will be the ones that hide it best.
The obvious objection is that this sounds like a services business. Our answer is vertical capability packs. Dealerships, hospitality groups and field-service companies each share most of their operating structure with their peers: customers, sites, contracts, work, crews, outcomes and economics. With a pack, most of the model exists on day one, and the engagement specializes it for the customer. It doesn’t start from nothing. The test is whether setup effort falls with each customer in a vertical.
Capability, not data
Most context-layer companies organize around data and semantics, because that is what a data team buys. A business doesn’t compete through its data. It competes through capabilities such as profitable quoting, customer retention, field service, pricing and acquisition integration.
A capability cuts across applications. It also cuts across people, knowledge, authority, economics and evidence. That suggests a different design principle. The enterprise owns the capability, and technologies contribute to it. The rule I use is to rent what is generic, own what differentiates, and govern the boundary between them.
It also changes how return gets measured. Hours saved is the wrong unit. The chain that matters runs from intelligence to a change in capability, then to an operating outcome, then to enterprise value.
The asset that compounds
Companies have accumulated data for decades, but a data asset isn’t a learning asset. Learning requires keeping the connections between the situation, the evidence, the decision, who had the authority, the action taken and what happened next.
That decision, action and outcome history is the valuable corpus. It is specific to the company, it can’t be bought from a model provider, and it exists only because the company operated. Foundation models will keep improving for everyone. A company can still become smarter for itself.
One design choice follows from this, and I’ll state it plainly. The history belongs to the customer and stays portable. Many of these companies are owned by private equity, and the next buyer will ask whether the capability survives a change of vendor or owner. A platform that can’t answer yes won’t get through diligence. It has to earn its place by being where the company’s learning is put to use.
Why incumbents don’t own this
Each incumbent’s layer ends where its application ends. The CRM vendor sees customers, and the ERP vendor sees transactions. A mid-market company runs a mix of vendors, and none of them sees a capability whole. Data platforms have no buyer in a company without a data team. Agent platforms orchestrate actions without the business context that says which actions matter.
Any of them could move this way. None of them starts from the capability, and none of them is designed to be consumed by an owner.
The channel
Mid-market software is expensive to sell one company at a time. Private equity sponsors own thousands of these businesses, and they already think in value-creation plans and exits. Reduced key-person dependence is an exit story. So are legible unit economics, and so is a capability that survives a change in leadership. One sponsor relationship can also reach several portfolio companies in the same vertical, which is where the packs pay off.
I’ve spent the past month building that conversation in public, through three essays for PE readers and a private Executive Exchange for investors and operators.
What exists today
Kainora Lattice is built. It runs on Enkyber, our governed agentic orchestration platform, and it is operating in pilots.
Three things are not yet proven. The first is how fast setup effort falls across customers. The second is the length of the sales cycle through sponsors. The third is how much of a pack transfers from one vertical to the next.
The hypothesis, and what would disprove it
The hypothesis is that a company-specific operating-intelligence layer will emerge between generic AI and existing enterprise systems. The larger opportunity is making that layer consumable by established businesses that have valuable operating history and small technology teams.
Three things would prove me wrong. Setup effort might fail to fall with each customer. Incumbent suites might become good enough across functions for the mid-market. Or owners might turn out to pay for tools but not for capability.
AI is becoming abundant, and enterprise capability is not. If you’re looking at this layer, I’d like to compare notes.