The fuel layer

Agents run on your data. Most of them are running on fumes.

Data is not a fifth plane in our model — it is the spine running under all four. Every control we build, every environment we provision, and every claim an agent makes about your business resolves to a dataset somebody has to vouch for. This is the part of the work that gets skipped, and it is the part that quietly decides whether the rest survives.

Six data capabilities form a shared spine that supplies clean, governed data to four AI operating planes.

Start here

Most data failures are silent — and that is the whole problem

A crashed pipeline is the good case. It is loud, and somebody fixes it. The dangerous case is a pipeline that succeeds and produces wrong numbers, which then flow into dashboards, decisions, and now into agents that act on them without hesitating.

Failure	What happens	How it is caught
Schema drift	Upstream adds, renames, retypes, or drops a column	Contract enforcement and schema tests
Freshness failure	The job silently did not run; the data looks normal but is stale	Freshness SLA monitoring
Volume anomaly	Partial load — 10% of expected rows arrived, everything still returns	Row-count and distribution checks
Fan-out	A join multiplies rows and every downstream sum inflates	Uniqueness and grain tests
Late-arriving data	Correct when read, wrong an hour later	Watermarks and a restatement policy
Null semantics drift	“Missing” starts meaning zero, or the reverse	Null-rate monitoring
Unit or currency change	A source switches cents to dollars and nothing errors	Range and distribution checks
Backfill inconsistency	Reprocessing yields different numbers than the original run	Deterministic transforms, backfill comparison
Permission drift	The pipeline runs as an over-privileged identity nobody has reviewed	Access review and workload identity

This is the same insight as provenance and postconditions, in a different domain. The characteristic agent failure is a plausible artifact produced by violating a constraint and reported as success. The characteristic data failure is a pipeline that reports success and produces wrong numbers. In both cases the exit code is a lie, and only an independent assertion catches it. Data quality gates are layer-0 evidence for data.

— Why the same company should own both

What changed

The consumer changed, so the requirements changed

Analytical data was built for humans who apply judgment. An analyst sees a number that looks wrong and investigates. An agent consumes at machine speed, without scepticism, and acts on the result.

Dimension	Human consumer	Agent consumer
Volume	Tens of queries a day	Thousands, unattended
Scepticism	Applies judgment to odd results	None
Ambiguity	Asks a colleague what “active customer” means	Guesses, confidently
Bad data	Notices and escalates	Propagates it into an action
Stale data	Sees the “last updated” timestamp	Does not look
Permissions	Inherits their own	Inherits whatever the pipeline identity has — usually too much

Contracts become enforcement

A contract violation now produces wrong outputs at inference speed across every query touching the field — faster than any review cycle catches it. Machine-readable, CI-enforced, versioned.

Freshness becomes correctness

Every dataset an agent reads needs a freshness SLA and a defined behaviour when it breaks: refuse, degrade, or escalate. Never silently serve stale data to an agent.

Lineage becomes provenance

Proving inputs came from the authorised source at the expected version is lineage, for data. Without it, layer-0 evidence cannot be implemented for any data-touching workflow. A hard dependency, not a nice-to-have.

The highest-leverage move available

The semantic layer is the agent’s data API

Benchmarks published in 2026 compared the same models answering the same questions two ways — raw text-to-SQL against tables, versus querying through a modelled semantic layer. No model was changed. The gain came entirely from data modelling work.

90.0% → 98.2% answer accuracy for one frontier model, raw tables versus a modelled semantic layer Vendor benchmark · grade C — we re-run it on your data

84.1% → 100% the same comparison for a second frontier model, within the semantic layer’s scope Vendor benchmark · grade C — self-interested source

~3× reported query accuracy improvement at 95%+ reliability across a 522-query enterprise workload with a semantic and context layer Vendor benchmark · grade C

20 questions the version of this test we actually sell: your twenty real business questions, measured both ways, on your own data Cheap to run, hard to argue with

We flag those three figures as grade C precisely because the vendors publishing them sell semantic layers. That is why the deliverable is a benchmark on your data rather than a slide quoting theirs. Mechanically: a semantic layer exposes governed metrics and dimensions — typically over MCP — that the agent discovers and calls, so instead of inferring table structure and business logic it picks from defined metrics and the layer generates the SQL. It converts an open-ended reasoning problem into a bounded selection problem. That is the same lesson as context engineering in the code domain: the marginal return is in the substrate, not the model.

The data spine

Six capabilities, running under all four planes

ID	Capability	What it covers	Serves
D-1	Ingestion & CDC	Landing source data reliably, incrementally, and replayably	Execution
D-2	Storage & table format	Lakehouse layout, partitioning, retention, time travel	Context
D-3	Transformation & modelling	Layering, grain discipline, tested logic, deterministic transforms	Context
D-4	Semantic & contract layer	Governed metrics and dimensions, machine-readable contracts, CI enforcement — the agent’s data API	Context + Verification
D-5	Quality, lineage & observability	Tests, freshness and volume SLAs, OpenLineage, anomaly detection	Verification + Control
D-6	Governance & access	Classification, masking, workload identity, cost attribution, masked environment provisioning	Control

D-4 and D-5 are where we invest, and where the market is thinnest. Ingestion and storage are commodity — buy them, and we will help you buy well. The differentiator is the contract, semantic, and evidence layer that makes data trustworthy to a consumer that cannot be sceptical on its own behalf.

— Where we build versus where we integrate

The quiet blocker

Masked, realistic test data is a data problem wearing a platform costume

Why programmes stall here

Ephemeral environments promise agents somewhere safe to work. That promise depends on realistic data that is not production data — which means subsetting with referential integrity intact, deterministic masking that preserves distributions and join keys, and refresh automation that keeps it useful.

Teams discover this after committing to a runtime, and it becomes the reason the programme sits at 80% for two quarters.

What we deliver

Subset definitions that keep joins valid across the subset
Deterministic masking preserving distributions, cardinality, and keys
Classification-aware redaction carried onto every derived artifact
Refresh automation with an owner and a schedule
Query cost guardrails and row limits — a control, not an optimisation, because agents generate unbounded scans repeatedly

Assessed in the entry baseline, built at rung 2, before anyone depends on it.

Do not conflate these

Two different data problems

Most engagements need both. Selling them as one thing produces a scope that cannot be estimated, and an estimate that cannot be met.

	Analytical / structured	Retrieval / unstructured
The question	“What was revenue by segment last quarter?”	“What does our security policy say about vendor access?”
Substrate	Warehouse, models, semantic layer	Documents, extraction, chunking, embeddings, index
Failure mode	Wrong number, confidently	Wrong or outdated passage, confidently
Control	Contracts, tests, semantic definitions	Permission parity, freshness, supersession

Permission parity — the rule that decides retrieval engagements

Grounding an agent in enterprise content makes latent over-sharing suddenly visible. Content that was technically readable by everyone but practically buried is now one question away. The agent did not create the exposure; it removed the obscurity that was hiding it.

Rules we apply

An agent must never widen a user’s effective access. If a user cannot open the document, the agent must not quote it, summarise it, or admit it exists
Enforce at retrieval, not in the prompt. Filtering by instruction is not a control
Model the identity choice explicitly — on-behalf-of versus application identity — and write down why, per source
Access metadata is data with its own freshness target: a revoked membership that reaches the index a week late is a week-long exposure
Deletion is a real path — source, index, embeddings, caches, evaluation exports, and traces, with a stated maximum interval and a test
Sensitivity survives the pipeline: labels carry onto every derived artifact

Excluded from a first corpus, regardless of controls

HR case files and compensation records
Legal advice and anything privileged
Security incident detail
M&A material
Individually identifiable health or financial records
Anything under legal hold

Exclusion is cheaper than exposure. The boundary widens later, with evidence. And we report over-sharing as a finding for you to decide on — not as a blocker to quietly work around.

Placement

What data work sits at each rung

Rung	Data content	Deliverable
1 — Visible	Inventory of datasets agents already read or write; ownership; classification gaps; freshness reality versus assumption	Data section of the gap report, plus the semantic-layer benchmark on 20 real business questions
2 — Governed	Workload identity for pipelines; masked seeded dataset for ephemeral environments; query cost guardrails	Masked environment provisioning; access review
3 — Assured	Contracts on the datasets in the agent path with CI enforcement; quality gates as merge gates; lineage wired for provenance	Contract registry; lineage backend; data checks in the verification pipeline
4 — Coordinated	Data products consumed across teams; contract negotiation between producers and consumers; shared semantic definitions	Cross-team data contracts Destination
5 — Federated	Catalogue integration, data product lifecycle, governance at platform level	Platform data governance module Destination

Anti-patterns we will argue with you about Rebuilding the warehouse before proving one question Semantic layer with no owner Quality tests that alert but never gate Masking that breaks joins Agents writing dbt models with no contract

Twenty questions, your data, measured both ways.

If you want one concrete thing to test us on, that is it. It is cheap, it is fast, and the result is either an argument for the rest of the data work or a reason to spend your money elsewhere. Both are useful answers.

When data is the whole engagement → Or start with the runtime baseline