Three inputs keep showing up: proprietary data, models, and people who turn both into leverage. Buyers value famous people fastest and rights-cleared data slowest. That gap is the trade.

Billion-Dollar Prices Are Arriving Before Revenue

Safe Superintelligence is the cleanest case: $1 billion raised at a reported $5 billion valuation in September 2024, then another reported $2 billion at $32 billion in April 2025. It was still pre-product, but it had Ilya Sutskever, co-founder of OpenAI.

OpenAI’s io Products deal priced product taste before device sales. In May 2025, TechCrunch reported that OpenAI agreed to buy Jony Ive’s company for nearly $6.5 billion before consumer hardware shipped. It bought design judgment, recruiting pull, and the iPhone’s defining designer.

AMI Labs priced research authority before product. In March 2026, TechCrunch reported that Yann LeCun’s new company raised a $1.03 billion seed round at a $3.5 billion valuation. LeCun’s credential made diligence legible: Turing Award winner, former Meta chief AI scientist, and central researcher.

Across these ten cases, disclosed capital raised, acquisition consideration, and reported licensing fees exceed $15 billion. Headline valuations push the implied value much higher. Revenue was usually not the anchor.

The legal forms differ: funding rounds, acquisitions, licensing deals, and hiring-heavy structures. The common move is simple: buyers and investors paid before old-style revenue proof could do the work.

Buyer type changes what gets priced. Strategic buyers pay for people, model rights, product acceleration, and missing capability. Investors pay for recruiting power, compute access, and credible research direction. Data becomes explicit value when it is rare, rights-cleared, strategically missing, and hard for a model builder to reproduce.

Three Assets Keep Reappearing

The transactions resolve to three assets: data, models, and people. Revenue matters later. At deal time, it was often not the valuation anchor.

Every case in the table is a bet on at least one asset. Buyers pay for famous people faster than they inspect the data that makes those people productive.

Famous Chefs Still Get Paid Before Rice

The fame premium has a rational core. Elite founders attract talent, capital, compute access, and buyer attention. But exclusive domain data can be harder to replace.

There is a Chinese saying: 巧妇难为无米之炊. Even the cleverest cook cannot make a meal without rice.

The metaphor works because talent transforms data but cannot substitute for it. The researcher is the chef. The data is the rice. Investors still pay for the chef before they pay for the rice.

The pricing gap is visible in public data deals. Reddit’s AI licensing across Google and OpenAI is roughly $130 million a year. News Corp’s journalism archive was reportedly priced at $250 million over five years. Those are large checks for media companies and small next to a $32 billion pre-product valuation for SSI.

Infrastructure deals point to the same bottleneck. Scale AI was valued at $29 billion with roughly $2 billion of ARR, treating labeled data operations as core infrastructure. Salesforce paid about $8 billion for Informatica. IBM paid about $11 billion for Confluent. Buyers are paying to organize, govern, move, and stream data.

Enterprise deployment evidence is consistent. The MIT NANDA GenAI Divide reportfound that about 95% of enterprise AI pilots failed to produce measurable impact, with failures concentrated around missing proprietary context, workflow integration, and tools that did not learn from enterprise data. Generic models do not know a company’s exceptions until they see them.

The talent bottleneck is real, but the broad talent pool is expanding. Roughly 5,900 machine learning PhDs graduate every year. For many open models, fine-tuning can now run on a single consumer GPU. There are more competent chefs every year. Reddit’s historical conversation archive exists once.

Capital still flows through narrow channels. Crunchbase found that startups with Stanford, Harvard, and MIT alumni as founders drew more than 30% of the funding rounds it tracked among U.S. university-affiliated founders. In the AI Power Map, 77 of 420 influential people in core AI are Stanford-affiliated. The talent pipeline is wide. The funding pipeline is narrow.

The best asset is a talented founder with exclusive access to rare data. The second-best asset may be the data itself. Outside frontier research, the sharper question is not “who is the smartest person?” It is “who has the rice?”

Data Only Matters When It Can Be Used

A file labeled proprietary data is often worthless. It can be stale, duplicative, legally encumbered, poorly labeled, or impossible to integrate. Ownership alone does not create an AI asset.

Data value depends on time, rights, and context. Last year’s web crawl ages. A one-time survey depreciates when collected. Rights-cleared longitudinal clinical records can appreciate as outcomes appear. Fifteen years of logistics exception data can beat a synthetic substitute because the edge cases happened in the real world.

Valuable datasets have depth, freshness, labeled outcomes, real edge cases, and legal control that a model builder cannot cheaply reproduce. Evaluating them requires domain expertise. AI buyers need technical asset evaluators, not another DCF analyst with a new multiple.

The credential gap suppresses data pricing. Investors can underwrite Sutskever’s training approach or LeCun’s research thesis through the name. A less famous founder with strong domain data has to prove what the famous founder can assert. That asymmetry helps explain why data-rich companies without elite credentials remain underpriced.

Gold Rushes Reward the People Who Build the Roads

A rush creates more than one way to build a fortune. In 1849, tens of thousands of prospectors flooded California to dig for gold. The gold was real. Some miners found it and became rich. Most did not.

Some durable California fortunes came from the supply business around the rush. Levi Strauss sold denim. Sam Brannan sold pickaxes. Leland Stanford sold provisions, then used the profits to build a railroad and a university. These businesses made the gold rush function.

AI has a similar shape. Famous founders can create extraordinary value. A Turing Award winner, a Transformer author, or a frontier-lab operator can deserve the premium buyers assign. But the visible gold field is crowded and credentialed. Most founders lack those credentials, and most investors cannot win when Google, Microsoft, OpenAI, NVIDIA, and the top venture firms are already bidding.

The overlooked claims are in the missing middle: clinician behavior inside healthcare workflow software, routing exceptions inside logistics platforms, structured decision data inside vertical SaaS, and sensor histories inside industrial software. These companies are not worthless because they lack famous founders, and not automatically worth $100 million because they have ARR. Their value sits in an asset class buyers still struggle to inspect, package, and transact.

The supply business around AI is enormous: compounding proprietary data, usable data infrastructure, diligence standards, advisory relationships, and eventually a marketplace that routes scarce assets efficiently. Data is not a shovel because people are the gold. Both people and data are valuable. A rush needs miners, claims, tools, roads, stores, banks, and trusted intermediaries.

In AI, the person who helps a data-rich company find the buyer that needs its workflow data is not selling supplies at the edge of the action. They reduce search costs, make the asset legible, and move a scarce input to the company that can turn it into a product. The roads around the rush can be just as valuable and far less crowded.

The Missing Marketplace Needs a Dealmaker

AI data and model transactions now have the three conditions that usually precede a marketplace: scarce assets, motivated buyers, and high search costs. The assets are proprietary datasets, trained models, evaluation harnesses, labeling pipelines, deployment telemetry, and specialized ML teams. The buyers are frontier labs, enterprises, and large technology companies.

Existing routes miss the asset class. Data marketplaces lack company context. Startup listing sites serve small SaaS exits. Bankers prefer banker clients. Talent raids work for names every lab knows. None of these channels is built for a company whose core value is a proprietary dataset, a fine-tuned model, or a specialized ML team inside a narrow domain.

The next platform will look less like a startup listing site and more like an MLS for AI assets. It would let holders package provenance, rights, privacy limits, schema quality, freshness, benchmarks, integration difficulty, and buyer fit. Buyers could search by strategic need: specialty care records, logistics exceptions, or robotics training data.

The missing product is trust infrastructure. Buyers do not need more pitch decks claiming “proprietary data.” They need diligence standards, provenance checks, data rooms built for model assets, buyer qualification, and valuation methods that treat data, models, and people as distinct assets.

The valuable version is not a public auction board. It is a confidential network: verified asset profiles, qualified buyers, controlled disclosure, and technical diligence before names or data rooms are exposed. Google, Microsoft, and OpenAI will not shop openly for strategic data. They may work through a trusted intermediary that can match need to asset without exposing either side too early.

The old M&A skill set is necessary but incomplete. Traditional advisors can structure a process, run diligence, negotiate terms, and close. Many cannot evaluate a training dataset, test whether a model is defensible, or judge whether a team can ship frontier-grade systems. They fall back to revenue multiples. Not because revenue is right. Because revenue is legible.

The new dealmaker combines technical judgment, buyer knowledge, and commercial fluency. The ML lead knows which workflow data is rare. The researcher knows which team is real. The product operator knows where a buyer’s AI roadmap has a missing piece. The role does not require a broker license or banking pedigree. It requires domain knowledge, relationships, and the ability to see what traditional finance misses.

The transaction layer may be a platform, a technical advisory firm, a data room company, a bank, a cloud marketplace, or a confidential network without a name. The valuable version will make rare assets visible without making them public. The first nine-figure AI transactions went to names everyone already knew. The next ones may come from assets only a few people can evaluate: clinical workflow histories, logistics exceptions, procurement trails, robotics video, and domain models with real deployment data. The person who can verify the rice, find the buyer, and structure the deal is not standing outside the gold rush. They are building the place where the next claims get priced.

This essay draws from Chapter 5 (The Capital Network) of The AI Power Map, a free interactive network map and 70,000-word companion book tracing 420 people and 1,700+ public relationships across the AI industry. The strategic transactions discussed above draw from the book’s verified acquisition dataset of 121 deals across 38 corporate buyers; the funding rounds are included here as current-market comparables.

Read the Book

If you think agents do not need to understand how people work inside a company, you are still thinking of agents as tools, not workers.

That was fine when AI mostly answered questions, summarized documents, or helped draft text. In that world, the system stayed at the edge of the organization. It did not need to know who actually makes decisions, which process people avoid, or which escalation path works in practice.

But agents are starting to move from the edge of work into the workflow itself. The moment an agent files a ticket, routes an approval, escalates an issue, or hands work to another person, it is no longer just producing output. It is acting inside the organization.

And anything acting inside an organization needs some understanding of how that organization actually works.

Six months ago, most enterprise AI conversations were still centered on copilots, search, and chat interfaces. The system could answer questions, summarize documents, or help employees draft work. It did not need a deep model of how the organization operated because most of the risk stayed at the interface layer.

That is changing.

AI systems are now being connected to tools, workflows, approvals, tickets, CRM systems, knowledge bases, and internal communication channels. They are no longer just answering questions. They are starting to participate in work.

And the next version every platform team is building toward is not just an assistant that responds to prompts. It is an agent that behaves more like an employee: knowing who to involve, when to escalate, which channel actually gets a response, and who the real decision-maker is regardless of what the org chart says.

A new hire learns this over their first three to nine months. They make a few wrong calls, observe how work actually moves, and build an informal map of the organization. That map is almost never the same as the onboarding deck. By the end of that window, both the company and the person know whether there is a real fit.

Agents do not get three to nine months. They do not naturally observe the organization the way people do. They only see the context and permissions we give them.

So if enterprises want agents that can navigate organizations reliably, they need to give those agents what people gradually build for themselves: a working model of how the organization actually operates.

That is the gap.

And it is not just a model problem. It is an infrastructure problem.

The capture thesis is right, and it is not enough

YC’s Request for Startups #15 “The AI Operating System for Companies,” points in the right direction: capture meetings, tickets, customer interactions, and operational signals to build an operational map of the company.

Good instinct. If you instrument what happens inside an organization, you can see far more than a static org chart or document repository ever reveals.

But capture is not the same as understanding.

Jira can tell you a ticket was assigned, delayed, reassigned, blocked, or completed. It cannot tell you whether the assignee actually owned the work, quietly handed it off, waited for someone with informal authority, or completed something nobody downstream trusted.

Calendar can tell you a meeting happened. It cannot tell you who had real decision authority in the room, who was invited for political cover, who stayed silent but controlled the outcome, or whether the real decision happened afterward in a private conversation.

Slack can show who responded, who was mentioned, and which channels were active. It cannot automatically tell you whether people trusted the answer, avoided conflict, escalated informally, or routed around a broken process.

The most important organizational signals often show up in the gaps: what was delayed, avoided, rerouted, silently escalated, or left unowned. And even when the activity is fully captured, the meaning is still ambiguous.

A person is copied on 200 emails a day, invited to 30 meetings, partially joins many of them, appears in the notes, but rarely speaks. What does that mean?

Are they a real decision-maker? A political observer? A bottleneck? A passive stakeholder? A compliance checkbox? A senior person everyone includes to reduce risk? Or just someone with the same title as five other people who behave completely differently?

The logs can show activity. They do not explain authority.

And authority is only one layer. The same behavior can mean different things depending on company culture, team culture, personal work style, attention patterns, and how others perceive that person.

AI may know how someone presents themselves through their messages, calendar, documents, and meeting behavior. But it does not automatically know how others perceive them. It may know what a team produces, but not whether other teams experience that team as trusted, slow, political, overloaded, strategic, or hard to work with.

A good employee learns these things quickly. They learn who actually owns a decision, who is copied for political cover, who gets included because they matter, who gets included because people are afraid to exclude them, which team is trusted, which process everyone avoids, and which escalation path works in practice.

That is what it means to navigate a company well.

So if we want agents to become digital employees and not just workflow executors, shouldn’t they understand the same things?

The harder layer is not capture. It is interpretation. Specifically: interpreting what did not happen, what was rerouted, what was avoided, what nobody wrote down, and what behavior actually means inside that organization.

Every serious enterprise AI stack is getting better at retrieval. Almost none of them are solving this layer.

There are three layers of enterprise context. Everyone is building the second one.

When an agent routes a decision, it is not doing a search. It is asking an organizational question: who actually owns this, who is trusted, who has bandwidth, and what escalation path will be accepted?

Some of this may be documented. Most of it is learned through behavior.

This evolved from people analytics, but it is not where people analytics ends

Traditional people analytics measures individuals and teams for human decision-making: performance, attrition risk, engagement, skills, workforce planning. Useful for HR leaders. Important for management.

But agents need a different kind of organizational intelligence.

They do not need a quarterly dashboard telling a CHRO which teams are disengaged. They need runtime context: how work actually flows, where decisions bottleneck, which trust networks are real, who holds informal authority, and what route is likely to work in this specific situation.

Same roots. Different unit of analysis. Different buyer. Different output.

People analytics helps humans understand the workforce. A behavioral context layer helps AI systems navigate the organization.

There is a fair criticism here: people analytics has been promising to make organizational behavior measurable for years, and the track record has been mixed.

But the timing is different now.

For decades, people debated whether AI could become intelligent enough to reason about work. At the same time, people analytics was trying to measure organizational behavior, mostly for human dashboards, HR decisions, and periodic management review. The output was usually a report, a score, or a dashboard someone had to interpret.

Generative AI changes the use case.

Now the system is not just helping a human analyze the organization. The system itself is trying to act inside the organization. It needs context at the moment of action: who to route to, when to escalate, whether a path is risky, and when the workflow is ambiguous enough to require human judgment.

That is why this is not simply “people analytics again.”

People analytics tried to help humans understand organizations. Behavioral context helps AI operate inside them.

The old promise was measurement. The new requirement is runtime interpretation.

Passive signal is not trust

The signal distinction matters. Most teams conflate three different things: passive ONA, active ONA, and broader organizational behavior.

Passive ONA is digital exhaust: meeting co-attendance, calendar patterns, ticket routing, response times, approval flows, and other interaction traces. It shows the structure of work: who has the opportunity to interact, where work moves, and where it slows down.

Active ONA is relational signal: confirmed trust ties, peer-recognized expertise, reliance patterns, psychological safety indicators, and feedback on who people actually go to for help or decisions. It shows the meaning of those interactions: whether information is trusted, acted on, ignored, or avoided.

But organizational behavior goes beyond passive and active ONA. It also includes cultural and behavioral patterns: how open the company is, how comfortable people are challenging decisions, whether teams escalate early or hide problems, whether authority is centralized or distributed, whether people avoid conflict, and how much discretion employees actually have in practice.

The mistake is treating high passive signal as high trust.

Two people can be in every meeting together and never genuinely rely on each other. A ticket can be assigned to someone who informally reroutes it every single time. A senior person can be copied on every thread and still not be the real decision-maker.

Frequency is not trust. Co-attendance is not influence. Visibility is not authority.

And the same signal can mean different things in different cultures. A dense meeting cluster in one company may signal strong collaboration. In another, it may signal over-coordination, politics, or low trust. A quiet employee in one culture may be disengaged. In another, they may be a respected expert who only speaks when necessary.

So the signal is not just who interacts with whom.

It is how those interactions are interpreted inside that specific organization.

Making organizational behavior computable

This is what my Columbia research focused on through the Organizational Intelligence Loop, or OIL framework.

Over the past five years, my team and I have been researching how to turn organizational behavior into measurable, machine-readable signals, using more than 1B behavioral signals across hundreds of companies.

After publishing the research, we built an organizational behavior graph: a system that maps how work actually moves through a company, including trust, influence, escalation, ownership, response patterns, and informal authority.

Then we trained that graph into a model.

The goal is to make organizational dynamics computable. Not by reducing people to simple scores, but by translating patterns of behavior into context AI can reason over.

Company culture, team norms, trust networks, decision bottlenecks, and informal power are usually treated as “soft” organizational knowledge. But with enough behavioral signal, they can become structured inputs: measurable, comparable, and usable by AI systems at runtime.

This is similar in spirit to how large-scale language models learn from patterns in language. Behavior is not language, but organizational behavior also has recurring structures: who routes to whom, who is trusted for what, where decisions stall, which teams avoid each other, and which people become load-bearing nodes.

That is what we are introducing at BehaviorGraph: an organizational behavior model that gives enterprise AI systems the missing context layer they need to navigate companies.

But machine-readable does not mean perfectly understood.

Organizational behavior is contextual. Any model of it will be lossy, just like models of language, fraud, credit risk, customer intent, or medical risk are lossy. The point is not to create perfect truth. The point is to do better than the current baseline: org charts, static workflows, document mentions, and hard-coded routing.

A metric like Trust Density, for example, should not be treated as a complete measure of trust. It is a computable proxy for relational reliability inside a specific workflow context.

The question is not whether one metric perfectly represents trust. It is whether behavioral signals improve routing, escalation, and risk detection compared with title-based or workflow-based systems.

The product is not the raw data. The product is the trained interpretation of what organizational behavior patterns actually mean, with confidence levels, boundaries, and escalation rules. For more examples, check out this article.

This does not mean turning informal dynamics into fixed rules. The model should surface patterns without freezing them into permanent hierarchy. Informal dynamics are fluid, contextual, and sometimes useful precisely because they are not formalized.

The goal is not to let agents autonomously codify office politics. The goal is to give both humans and agents better options: likely routes, confidence levels, risk signals, and clear moments where human judgment is required.

There is another problem: historical truth

Engineers often assume that if the AI has all the documents, tickets, meeting notes, and version history, it can reconstruct what happened.

But organizational history is not that clean.

The latest document may not be the most accurate one. The most official version may have been written after the politics changed. A decision record may say one thing, while the real compromise happened across three side conversations that were never documented. A project postmortem may describe the failure, but not the moment in the middle when ownership broke, trust collapsed, or the wrong person became the bottleneck.

Even if you rank everything by date, you still do not know where the truth drifted.

This is why knowledge management has always been harder than storage. KM is not just about preserving information. It is about provenance, context, interpretation, and knowing which version of reality people actually acted on.

It is like correcting history books. You do not find truth by simply collecting every document. You ask: who wrote this, when, for what audience, under what incentive, with what missing context, and how did other people behave around it?

That is also what enterprise AI needs.

If an engineer thinks, “I have all the papers, so I do not need to understand people,” I would tell them to study Knowledge Management 101.

Because organizations do not run on documents alone. They run on interpreted knowledge, social trust, incentives, memory, and behavior.

What about governance, permissions, and sensitive data?

he obvious objection is: isn’t this sensitive?

Yes. Organizational behavior data is sensitive.

But sensitivity does not mean the category should not exist. It means the system has to be designed with the right governance, permissions, privacy boundaries, auditability, and deployment controls.

Workday handles sensitive employee data. 1Password handles sensitive credentials. Banks handle sensitive financial data. Apartment applications handle income, identity, and background information. Companies still use them because the value is necessary and the systems are expected to meet a higher bar for security and trust.

That said, this category has its own risk model. A behavioral graph is not the same as a password vault or HR record system. It can reveal inferred patterns of trust, authority, bottlenecks, avoidance, and informal influence. That means the governance bar has to be higher — It should not become a searchable political map of the company; It should not become a manager dashboard for spying on employees; It should not reduce people into simplistic scores.

The safer architecture is task-bounded and permissioned.

An agent asks a narrow runtime question. It receives only the minimum context needed for that task. The output is permission-aware, policy-aware, and auditable. When confidence is low or the situation is sensitive, the system escalates to a human instead of pretending the workflow is clear.

Used correctly, behavioral context keeps humans in the loop. It helps agents avoid obvious routing mistakes, and it helps humans see where the real organizational problem is: unclear ownership, broken escalation paths, low trust, overloaded teams, or workflows that no longer match reality.

Once humans have that visibility, they can decide what to do: clarify ownership, redesign the workflow, add review steps, adjust permissions, create a new escalation path, or keep the ambiguity human-led.

This is not about ignoring governance or bypassing permissions. It is about working on top of them.

An AI agent should not see everything. It should only access the organizational context it is allowed to use, for the task it is performing, under the policies of that company.

But within those boundaries, agents need a certain level of discretion, just like employees do. A normal employee does not operate only by reading the org chart and following static workflows. They make judgment calls: when to ask for approval, who to involve, when to escalate, and when a situation is sensitive enough to require extra verification.

That is the goal: not unlimited autonomy, not surveillance, and not private individual-level exposure.

Bounded, permissioned organizational context.

The right architecture is not “give AI all the data.” It is to give AI the minimum governed context it needs to act responsibly inside the organization, with permission controls, audit trails, confidence levels, and clear boundaries.

Sensitive data can be handled responsibly when the system is built for it. That is the bar this category has to meet.

What agents actually need at runtime

Most agents today are still managed like software workflows. They are assigned to one user, coordinated by an orchestration layer, or routed through hard-coded paths between tools, humans, and other agents. Even before organizational complexity shows up, they can fail for basic reasons: tool errors, timeouts, bad retrieval, brittle prompts, unclear permissions, context loss, or poor handoff design.

That is why most agent evaluation still looks like software evaluation: success rate, task completion, token cost, context compression, and LLM-as-judge scoring.

These metrics are useful. But they are not enough for enterprise deployment.

Enterprises do not only ask whether an agent completed a task. They ask whether the agent can perform work at the level of a human role. That means comparing agents against human work on quality, quantity, consistency, judgment, risk, speed, cost, and operational reliability.

For an individual experimenting with agents, spending $2,000 a month on marketing automation may sound expensive. But for an enterprise, the comparison is not whether the cost can be reduced to $1. The comparison is whether the agent can replace, augment, or scale work that would otherwise require a human team.

In real companies, doing the job is not just producing output.

A good employee knows when to ask for approval, who needs to be involved, which stakeholder may block the work, which channel will get a response, which decision is politically sensitive, and when the official process is not the real process.

Today’s agents usually do not know that. They are routed through system prompts, workflow rules, or org chart lookups. That can work for narrow demos, but hard-coded coordination paths break when teams change, responsibility is ambiguous, or the agent needs to hand work off across functions.

This is where the agent orchestration problem becomes a routing problem. An agent finishes a task and needs to hand it off to a person, another agent, an approval authority, or the next workflow step. That handoff is where enterprise AI moves from task execution into organizational navigation.

Current frameworks can usually answer who is assigned in the workflow, who owns the system, who appears in the org chart, or who was mentioned in a document. But they usually cannot answer who is the right person for this right now, given actual expertise, current load, informal authority, trust relationships, and whether the organization will accept that route.

Agents do not just hallucinate facts. They can hallucinate authority, routing, ownership, and organizational exposure.

If an agent sends a sensitive approval to the wrong person, escalates through the wrong path, or bypasses the real decision-maker, the failure is not just technical. It becomes visible inside the organization and erodes trust quickly.

So the real enterprise question is not only: did the agent complete the task?

It is: did the agent complete the work in a way the organization would accept?

That requires runtime organizational judgment, not just retrieval or orchestration. Whether enterprises use RAG, agents, MCP, workflow automation, or whatever architecture comes next, the problem is the same: AI systems need organizational context to act inside companies.

Behavioral context does not mean agents should act autonomously in every ambiguous situation. Often the value is the opposite: helping an agent recognize ambiguity and escalate instead of pretending the workflow is clear.

Execution layers help AI take steps. Behavioral context helps AI navigate the company.

Right now, almost none of them have that layer.

The last point

A lot of people in AI believe AGI is coming.

But intelligence does not operate in a vacuum.

Humans navigate the world partly by sensing how others perceive them, whether that perception is accurate or not. That perception changes how we speak, who we ask, when we push, when we wait, and when we escalate.

Inside companies, that social awareness is not decoration. It is part of how work gets done.

If we want AI to become more than a tool, if we want it to act like a real digital employee, it cannot only know what is written down. It has to understand the organizational reality people respond to every day: trust, reputation, authority, avoidance, attention, and the invisible paths through which decisions actually move.

A knowledge graph tells AI what the company knows.

An organizational behavior graph gives AI the organizational judgment it needs to act like a good employee.

Previously, I wrote about the missing context layer in enterprise AI: why systems that can read documents and generate answers still struggle inside real organizations. The issue is not only information access. It is the lack of understanding around how work actually happens: who is trusted, who holds real influence, how decisions move, and where human judgment still matters.

This time, I want to focus more directly on the People layer. To me, this is where a large part of enterprise intelligence actually lives. Not just in content, but in relationships, expertise recognition, informal authority, and the social patterns that shape execution.

I decided to record this as a quick 7-minute podcast because some people prefer listening to ideas rather than reading them. I also wanted to see whether there is appetite for hearing more of this topic in audio form. :)

If this resonates, leave a thought or question. I would love to know what part of this feels most relevant, most controversial, or most worth unpacking further. I may address some of those directly in the official second piece of the newsletter.

Deloitte’s 2026 enterprise AI report captures the moment well. AI access is rising, more experiments are reaching production, and agentic adoption is accelerating. But activation still lags, and governance remains immature.

Enterprise AI is scaling, but not cleanly.

Access is rising: worker access to sanctioned AI tools grew from under 40% to under 60% in a year. Activation is lagging: among workers with access, fewer than 60% use AI in their daily workflow. Production is still limited: only 25% of respondents say 40% or more of their AI experiments are in production today, though 54% expect to reach that level within three to six months. Agentic adoption is coming fast: 74% of companies plan to use agentic AI at least moderately within two years. Governance is behind: only 21% report having a mature governance model for autonomous agents.

That pattern matters because the next phase of enterprise AI is not about whether models work. It is about whether AI can function reliably inside real organizations.

A pilot can look impressive in a clean environment. It runs with a small team, scoped data, limited stakeholders, and fewer consequences. Production is different. Production requires integration with existing systems, security reviews, compliance checks, monitoring, maintenance, and ongoing operational ownership. It also exposes the realities pilots can hide: edge cases, coordination problems, conflicting priorities, and the harder work of scaling what succeeded in isolation. Deloitte calls this the proof-of-concept trap.

I would add one more reason pilots stall: organizational context.

Most enterprise AI systems today are built on two layers of data.

Tier 1: Structural — org charts, titles, reporting lines
Tier 2: Transactional — documents, tickets, messages, meeting notes

These layers matter. They tell AI what the official organization looks like and what information has been recorded. But they do not tell AI how decisions actually move in practice.

That missing third layer is behavioral context: who people trust, who really makes the call, where work actually gets escalated, whose approval matters under pressure, which workflows exist on paper versus in reality, and when someone may be formally responsible but practically unavailable.

A recent essay from LEAD’s BehaviorGraph project makes this distinction explicitly: most enterprise AI categories still operate on structural and transactional data, while real decisions often live in a third behavioral tier. That is why so many systems are technically correct and operationally wrong.

An AI agent retrieves the right policy document. But the real decision path shifted six months ago because a trusted legal counsel or staff engineer became the true checkpoint.

An AI routes a request to the right person by title. But that person is overloaded, politically peripheral, or no longer the one others actually defer to.

A drafting tool proposes the right message. But the account is sensitive, and the outreach needs to go through a specific internal sponsor.

In each case, the content may be correct. The action is still wrong.

That is the kind of failure the next generation of enterprise AI has to solve. Not just whether the system can retrieve, summarize, generate, or classify. But whether it can operate with enough awareness of human dynamics, decision paths, and organizational reality to act appropriately.

My research calls this the Organizational Intelligence Loop, or OIL: a framework for what enterprise AI needs in order to operate inside a real organization.

• People — who knows what, who is trusted, who influences outcomes

• Information — what is current, owned, validated, and permissioned

• Process — how work actually flows, where bottlenecks form, where decisions stall

• Agentic AI Design — what an agent is allowed to do, when it should escalate, and how governance is embedded into action

The point is not that enterprise AI lacks intelligence in the abstract. The point is that most systems still lack the right operating context.

Information alone is not enough. A system can retrieve the most relevant document and still fail because the document is outdated in practice. Process alone is not enough. A workflow can be mapped correctly on paper and still fail because it misses the informal checkpoint that actually determines whether work moves forward. Even governance alone is not enough if it is defined only as policy after the fact rather than situational judgment at the moment of action.

This matters even more as agentic AI scales. Deloitte reports that 74% of companies expect to use agentic AI at least moderately within two years, yet only 21% say they already have mature governance for autonomous agents. That gap is serious because agents do not merely recommend actions. They can take them directly. They can route work, trigger workflows, escalate issues, make updates, and interact with systems at speed.

I agree with the concern, but I would push the argument further. Governance is not only about what happens after an agent acts. It is also about whether the agent had enough organizational context to act correctly in the first place.

A registry of agents is not the same as a behavioral governance layer. A policy is not the same as a live authority map. A correct answer is not useful if it is routed to the wrong person, exposed to the wrong audience, or executed in the wrong sequence.

This is where many discussions of enterprise AI remain too narrow. They focus on model quality, knowledge retrieval, prompt engineering, or tool integration. All of those matter. But once AI begins to operate across real business environments, another question becomes unavoidable: does the system understand how the organization functions as a living system, not just as a collection of files and formal roles?

That question becomes especially important when work is ambiguous, political, or cross-functional. In those settings, success is rarely determined by content alone. It depends on timing, trust, influence, permission, overload, sequencing, and informal authority. Those are not edge issues. They are often the difference between adoption and resistance, execution and delay, correctness and failure.

This is also why Organizational Network Analysis matters again, but in a new form. Historically, ONA was often periodic, retrospective, and consulting-heavy. It was useful for diagnosing hidden influence or collaboration breakdowns, but it was rarely built into daily operations. What enterprise AI needs now is not a one-time map of collaboration. It needs a continuous layer that can detect trust, influence, overload, escalation paths, and decision patterns as the organization changes.

The real leap is treating ONA as continuous infrastructure rather than a one-time deliverable, turning behavioral signals into live, queryable context for AI systems.

That shift matters because enterprises do not stand still. Teams reorganize. Decision-makers change. Experts become overloaded. Informal power shifts. New initiatives create temporary hubs of influence. Legacy processes linger long after they stop reflecting how work really gets done. If AI is expected to operate inside this environment, it cannot rely only on static maps and historical documents. It needs a more dynamic understanding of the organization it is acting within.

In that sense, the next enterprise AI category may not simply be better copilots or more agent actions. It may be the infrastructure that makes organizational reality queryable at runtime.

Not just what the company says it is.
Not just what its documents record.
But how it actually functions.

That is also why I think the enterprise AI market is still missing an important category. Search platforms help organizations retrieve information. Foundation models help them reason across language. Workflow tools help automate process. HR and people analytics tools help analyze talent and engagement. But there is still a gap between these categories: the live organizational context layer that helps AI understand who matters, what is current, how decisions move, when escalation is needed, and where formal process diverges from practical reality.

Without that layer, AI can still be useful. But it will struggle to become reliable infrastructure for enterprise execution.

Deloitte’s report ultimately lands in a similar place from a different direction. It argues that organizations need to close the gap between access and activation, redesign work around AI, build governance before scale, and treat AI as foundational to how the organization operates. I agree. But I would add that redesigning work around AI requires redesigning AI around the organization as it actually behaves.

That is a different challenge from simply deploying more tools. It is not just a product question. It is an organizational intelligence question.

The companies that solve this well will not necessarily be the ones with the most pilots, the most aggressive branding, or the fastest rollouts. They will be the ones that understand that enterprise AI is not only a technical layer. It is an operating layer. And operating layers fail when they cannot read the real environment they are supposed to work inside.

That is the territory this newsletter will cover.

Not AI as theater.
Not AI as demo.
But AI as it is actually built, adopted, governed, and scaled inside real organizations.

Because the hardest part of enterprise AI is no longer getting a model to work.

It is getting the organization to work with it.

Next issue: OIL Dimension 1 — People. How can enterprise AI begin to understand trust, influence, and informal authority without relying on a static org chart or a six-month survey?