The Semantic Layer and Governance a “Company Brain” Needs

Y Combinator's Summer 2026 Requests for Startups asked founders to build the operating system for AI-native companies. Two proposals name the same problem from different angles. Diana Hu wants every meeting, ticket, and decision captured, then compared against what should be happening and corrected in a closed loop.

Tom Blomfield wants something narrower: a "company brain" that extracts scattered domain knowledge and turns it into a skill an AI can execute.

Data teams read both and had the same reaction: we already built this. That reaction is halfway right.

What a Company Brain Needs From the Data Platform

A company brain needs machine-readable meaning, not just connected sources. When an agent asks for revenue, it needs an approved definition, an owner, and a record of when the number last refreshed.

When Hu's closed loop compares actual performance against an expected state, that expectation has to be encoded somewhere: a target, a data contract (a machine-checkable agreement on schema, quality, and freshness that a source promises to hold), or a service-level objective, a measurable commitment about how a system should perform.

When an agent joins customer, product, and support records, identity resolution, matching records that refer to the same real-world entity, and access policy cannot be improvised inside a prompt.

These are exactly the concerns semantic models, a governed business representation of data that gives a term like "revenue" one stable definition across every tool that queries it, were built to solve.

So were data products with owned, versioned interfaces, plus contracts, lineage (the traceable path from a number back to the source and transformation that produced it), and policy engines.

YC also flags the brutal integration work of connecting Slack, Linear, GitHub, Notion, and call recordings. Data teams have a name for this failure: pipeline sprawl, where every new use case gets its own connector and its own definition, one that drifts the moment the demo ends.

A company brain needs a governed foundation underneath it. A company that starts at the agent interface will hit semantic inconsistency, source ownership disputes, and access control gaps eventually. Those problems don't disappear because the requester is a language model instead of a person.

In short: the data foundation, the half of the company brain that makes information trustworthy, is the half enterprise data platforms already own.

Why Operational Knowledge Is the Missing Half of a Company Brain

Blomfield's examples are operational: how refunds get investigated, how pricing exceptions get approved, how engineers respond to an incident. Some of that can be inferred from structured tables. Most of it can't.

A warehouse can show that a refund happened. It rarely explains why a support lead overrode policy, which customer promise mattered more, or what evidence made the exception acceptable. Traditional data platforms were built to describe the business. A company brain has to help an agent participate in it.

That gap needs a second kind of product: versioned operational knowledge that connects intent to action. Think of a skill, a packaged, testable procedure an AI agent (a system that autonomously executes multi-step tasks, calling tools or data sources to complete a goal without step-by-step instruction) can run, similar to a runbook written for a machine instead of a person.

It documents the approved refund-investigation process, examples of valid and invalid pricing exceptions, tool schemas and preconditions, escalation rules, and an owner accountable when the procedure drifts.

Extraction alone can't build this. Summarizing a Slack thread might recover useful context, but it can also preserve an outdated workaround as if it were policy. Operational knowledge has to be curated, tested, and owned like a product instead of being mined like a dataset.

The company brain therefore has two halves. The data foundation makes information trustworthy. The operating knowledge makes action repeatable. Neither replaces the other.

How DataOS Powers the Company Brain Architecture

DataOS treats both halves as first-class citizens instead of leaving one of them to a wiki. Vulcan, DataOS's governed logical modeling layer, gives every metric one governed definition and exposes it through the same interface whether the consumer is a dashboard or an agent.

DataOS Vulcan packages that definition together with lineage, quality checks, and ownership into a single versioned unit an agent can query without re-deriving trust each time.

DataOS's governance interface enforces attribute-based access control: it grants or denies a request based on who is asking, what they are asking for, and why. An agent's identity and purpose shape what it can see before a single row moves.

None of this replaces the operating-knowledge layer Blomfield describes. A refund-investigation skill still has to be authored, tested, and owned by someone on the support team.

What DataOS removes is the excuse to build that skill on top of ambiguous definitions and uncontrolled access, the two failing modes that turn a promising agent into a liability at the first edge case.

DataOS covers the substrate so teams can spend their effort on the operating knowledge that is actually new.

How Data Governance and Agent Skills Connect at Runtime

Consider a support agent investigating a spike in German refunds. The substrate tells the agent which refund metric is authoritative, which fields are sensitive, and what the support manager is allowed to query.

The operating-knowledge layer tells the agent how the company investigates a refund anomaly: check payment failures before fulfillment delays, segment by product and channel, compare against known incidents, and escalate before contacting a customer if the issue crosses a defined threshold.

Neither layer works alone. Without the substrate, the skill runs on ambiguous definitions and uncontrolled access. Without the skill, the agent has trustworthy data and no reliable way to turn it into a decision. Without runtime enforcement connecting the two, both are documentation an agent can ignore.

That connection follows one path: identity, relevant context, approved skill, bounded tools, policy decision, verified action, feedback. It also draws a practical build-versus-buy line. Enterprises don't need every agent vendor to recreate company-wide semantics, lineage, and policy from scratch.

Those stay shared infrastructure, while vendors compete on skill authoring, workflow design, and evaluation, resolving data and permissions through a governed interface underneath.

For more on how this connective layer works end to end, see our case for the Data Developer Platform and our breakdown of what makes a knowledge graph AI-ready.

The YC proposals aren't proof that the warehouse was secretly the whole operating system all along. They're evidence that agents raised the price of getting the platform's least glamorous work wrong. A person who spots two disagreeing dashboards asks a colleague which one to trust. An agent turns the wrong definition into thousands of automated decisions before anyone notices.

That's the argument for data leaders in the room when this budget gets decided: the platform's job hasn't changed, but the cost of skipping it just went up by every action an agent now takes on its own.