The stack
Four layers, top to bottom
Agentic analytics is usually discussed as though it were a model choice. It is four layers, built by different people, failing in different ways, replaceable on different timescales. Being able to name which one is at fault is the difference between fixing a system and swapping models and hoping.
Worked question: why did net revenue fall?
A realistic agent needs more than a plausible sentence.
- Resolve the metric: fetch the governed definition of net revenue, allowed dimensions, calendar, and the caller’s access scope.
- Plan the query: compare the last complete month with the prior month by region, using only approved tables and joins.
- Execute and check: run parameterized SQL, validate row counts and null rates, and compare the sum of regional values with the overall metric.
- Answer with evidence: return the two periods, difference, top contributing regions, metric version, query reference, and Iceberg snapshot identifier. If permissions or data freshness prevent a reliable answer, say so.
The agent, in three parts
A model reasons. A harness runs the loop, decides what the model sees, and handles failure. Interfaces carry the request out to the world. Collapse the three and you have bought a product rather than built a capability.
- 04The agentic stackThree separable layers, model, harness, and open interfaces, each with its own failure mode. Most agent problems are misattributed across them.
- 05The modelWhat the reasoning layer actually contributes, what it cannot know, and why treating model choice as the whole architecture leads people astray.
- 06The harnessThe program that runs the loop. It decides context, tools, retries, memory, and when to stop, which is where most agent behaviour actually comes from.
- 07Open interfacesThe four contracts an analytics agent speaks through, why each should be a specification rather than a product, and what a closed one costs later.
Underneath all three
Governed semantic data
The layer that decides whether the answer is right. One definition of each metric, one copy of each dataset, one place access is enforced, and enough history to reproduce an answer after the fact.
Five Apache projects settle five separate questions here, and the reason to care that each is an open specification is that agents multiply readers. Formats one engine can read cannot serve many readers.
The substrate, entry by entry
Why the open lakehouse holds up under agents, and the semantic contract on top of it.
- Why an open lakehouseAgents multiply the number of readers and the number of questions. That pressure breaks architectures that assume one engine, one copy, and predictable queries.
- The semantic layer as an agent contractThe place where a business writes down what its terms mean. Without it, an agent guesses at definitions, and a fluent guess is worse than an error.
- Apache OssieAn incubating project defining a vendor-neutral standard for semantic metadata, so a metric definition is portable rather than trapped in one tool.
The Apache projects underneath, and why leaders should care
Each one settles a separate question. The definitions live with the network's lakehouse references; here is what each means for the people deciding on agents.
- Apache Parquet: Agent questions become many small queries; Parquet statistics are why each one reads a fraction of the data and costs less.
- Apache Iceberg: One copy of each table that every engine and agent can share, with history that lets you reproduce the answer an agent gave.
- Apache Polaris: One place where access is decided, so an agent cannot reach data its user cannot, whichever tool it runs in.
- Apache Arrow: Results move between engine, tool, and agent without conversion, which keeps latency low when agents ask many questions.
- Apache Ossie: Metric definitions you can take with you, so the semantic layer does not become the next lock-in.