In the agent era, what does a data team actually deliver?

The old answer was tools. Data warehouses, BI and reporting platforms, self-service query tools, metrics systems: this is what most data teams have been building all along. They are useful, but they are like the ls command in an operating system: everyone depends on them, yet they don’t directly produce value.

The value of data is produced in two places: data turning into insight, and insight turning into execution. Both of these chains are now being rewritten by agents.

This post is about data architecture in the agent era.

The big picture

┌────────────────────────────────────────────────────────────┐
│  Work loop     Plan → Exec → Eval                          │
│                Eval feeds back, triggering the next Plan   │
├────────────────────────────────────────────────────────────┤
│  Line 1   Data → Insight → Solution                        │
│           packaged insights, entropy-reduced into assets   │
│                                                            │
│  Line 2   Data → Strategy → Execution                      │
│           declarative definitions, compiled into           │
│           strategies consumed by execution systems         │
├────────────────────────────────────────────────────────────┤
│  Shared base    Data Context: the 6-layer context stack    │
├────────────────────────────────────────────────────────────┤
│  Infrastructure   lakehouse / unified metadata /           │
│                   compute, storage, scheduling             │
└────────────────────────────────────────────────────────────┘

Read it bottom-up: at the bottom, the data infrastructure accumulated over the years; above it, the context base that lets agents understand data; above that, the two main lines the data team delivers through; at the top, the work loop that keeps the whole thing running.

Line 1: deliver insights, not tools

Start with what a typical business analysis looks like. Someone from the business side asks a question in a group chat. An analyst pulls the data, does the analysis, posts the conclusion. The business side takes a look, maybe nods, so that’s why, and then nothing happens. Three months later another team asks almost the same question, and the whole thing runs again. The output of analysis is one-off; the organization accumulates nothing.

That is what Line 1 changes: Data → Insight → Solution, and the deliverable shifts from query tools and reports to packaged insights. Each business line has an insight data asset matched to its own scenarios: validated signals that reliably drive strategy, key facts about the market and competitors, the context of business strategy, and so on. The granularity can go very fine, down to raw user behavior. These assets are centrally hosted and version-controlled: company-level context that both agents and humans consume directly.

The most important design principle here is entropy reduction. Traditional tag and profiling systems increase entropy: every team adds tags, the pile keeps growing, and after a few years noise drowns out signal and nobody can say which tags still work. Entropy reduction goes the other way: only signals validated by the business, ones that reliably drive strategy output, get promoted to formal assets; unvalidated ones sit in a candidate pool under observation and stay out of the execution chain. The value of the assets is not in how many there are, but in every one of them having been tested.

Line 2: from reports to execution

Line 2 is Data → Strategy → Execution.

This chain used to work like this: the data team produces an analysis report, operations reads it and translates the conclusions into a strategy document, engineers translate the document into code. Every step is a translation, every translation loses something, and end to end it takes weeks at best. The more common ending: the report is well written, and then nothing happens.

In the agent era this chain can be compiled directly: the understanding of users and the understanding of content get compiled into strategy actions that execution systems can consume. Recommendation systems, conversational assistants, and operations platforms use them as is; no human stands in the middle translating. All the business side does is declare: which signals they care about, and what conditions count as a hit. The rest, pulling data, compiling, validating, gradual rollout, is done automatically by the pipeline. The target we set for this chain: from hypothesis to live validation in one to two days.

One engineering constraint here: LLMs stay out of the online serving path. Compilation is deterministic, rules plus features, because the online path handles requests on the order of hundreds of millions a day, and latency and explainability are hard constraints. LLMs go into offline processing: content tagging, semantic extraction, data reprocessing, all running on one shared processing infrastructure, with different accuracy, cost, and freshness tiers for different scenarios. Business lines don’t each build their own LLM pipelines.

The shared base: Data Context

Both lines share one base: the context stack that lets agents understand data. It runs from table schemas and query history, to human-annotated metric definitions, to the real semantics reverse-engineered from ETL code, to organizational knowledge, to the agent’s own error-correction memory, and finally to live probing of the warehouse as a fallback. How the six layers land in practice is covered in Six-Layer Context Stack for Data Agents, so I won’t repeat it here.

Its position in the overall architecture: Line 1 depends on it to produce insights, Line 2 depends on it to drive execution. If the base is shaky, both lines are castles in the air.

The warehouse isn’t dead

“The data warehouse is dead” headlines are showing up again. The logic goes roughly: the consumers of data are now agents, so the warehouse stack built for humans is obsolete.

I agree with the first half; data gaining a new class of consumers is something I’ve written a separate post about. The second half is wrong. Look at our own architecture: Data Context is the base of both lines, but it stands on an even older layer, lakehouse storage, unified metadata, compute, storage, and scheduling systems. This traditional infrastructure sits at the bottom of the diagram not because it doesn’t matter, but because its role has changed: from the data team’s deliverable to the ground that agents consume from.

The dependency is concrete. Layer 1 of the Context is built directly on unified metadata: table schemas, lineage, and update frequency are all there already, and the more complete the metadata platform, the cheaper this layer gets. Layer 3 can reverse-engineer a table’s real semantics from ETL code because the scheduler keeps every table’s producing SQL and its upstream and downstream dependencies. Layer 2’s metric definitions come from years of accumulation in the metrics platform. Wherever a piece of infrastructure is missing, the corresponding Context layer has to be filled in by hand or probed live by the agent, and neither comes cheap.

Swapping the consumer from humans to agents does raise the bar for infrastructure; we’ve felt this firsthand. When a table description is sloppy, a human who can’t figure it out asks a colleague. An agent doesn’t; it confidently picks a wrong table and finishes the analysis anyway. Metric families like DAU, eDAU, and playback DAU carry their definitional differences in natural-language descriptions; humans can tell them apart, agents mix them up, and the problem wasn’t solved until every metric’s source table and filter conditions were fully structured. When an upstream team quietly changes a field’s definition, it used to mean a downstream report broke, someone noticed, someone fixed it. Now the agent keeps running on its stale understanding and produces wrong conclusions that look normal. Metadata coverage, structured metric definitions, change discipline: these used to be soft requirements, and they’ve all become hard constraints.

The reverse also holds: a company with bad infrastructure can’t build this architecture. Agents won’t fix messy metadata; they’ll only expose the mess faster.

The hard part: the Work Loop

Architecture diagrams are easy to draw. Whether this thing actually runs depends on the piece most often skipped: the work loop.

We define the way we work as three stages: Plan, Exec, Eval, where each stage’s output is the next stage’s input.

Plan turns a vague business problem into an explicit plan, with goals, path, resources, risks, and validation criteria all written down. Two rounds of processing happen in between: insight discovery in the data first, then narrowing the insight into a strategy. Say the business problem is “new-user retention won’t improve.” Digging into the data surfaces the crux: new users who don’t finish a single full playback on day one mostly don’t come back the next day. The strategy follows: day-one onboarding does exactly one thing, getting the user through their first full playback. Landing on the plan: roll out to a slice of new users, hold out for two weeks, exit if next-day retention improves by less than 0.5%. The plan is, of course, co-built with the business side, not started the moment a request lands.

Exec takes the plan and the tools and delivers: strategies, models, systems, things that actually run. Agents handle the 80% that can be standardized; humans step in only in four cases: the plan turns out infeasible, a business judgment is needed, a new insight shows up, or the agent hits an edge case. Reusable capabilities from execution get captured as skills, so next time nothing has to be rebuilt.

Eval is the stage most easily skipped. Traditional data work ends at delivery; nobody goes back to check results against the original plan. Eval answers three questions: did the plan hit its goals, and is the attribution clear; was the infrastructure sufficient, and what was missing from the Context; which steps could be more automated next time. From these answers: feedback flows back, updating the Context, capturing skills, training agents; and new insight discovery starts, triggering the next Plan.

Break the loop at any link, and the two main lines above can hardly deliver at scale.

Why “Harness”

I call this architecture the Data Harness. In AI engineering, a harness is the scaffolding around a model: the model’s capability is a given, and what makes it actually get work done is the structure around it. Claude Code and the bare API use the same model; the capability gap is all in the harness.

Data teams are in a similar position. The data is already there. What decides how much of its value gets realized is the structure around it: how insights get captured, how strategies get compiled, how Context accumulates, how feedback flows back.

This also answers the question of the data team’s role in the agent era. It used to be a request responder: the business asks, the team answers. With the harness built, it becomes the driver of the work loop. The evaluation changes accordingly: from request response speed to Plan completion rate and agent takeover rate. What does this shift mean for the team? I wrote about it in Why I’m Shifting My Data Team from Writing SQL to Training Agents.