Built for When the Agent Asks Next

We were always the technical outliers in a sea of polished dashboard companies.

For years, BI was judged on what happened on the screen: the range of visualizations, the richness of the data model, how easily an end user could build a dashboard. Architecture barely entered the evaluation. Neither did APIs, analytics as code, or open standards.

Key Takeaways

• AI agents generate a different kind of traffic than people: one task can turn into tens or hundreds of short-lived queries, and a few hundred agents turn occasional human demand into continuous machine demand.
• Traditional BI is squeezed between AI above and warehouses below. What stays valuable in the middle is serving analytics under real operating conditions: consistent definitions, enforced boundaries, and predictable latency and cost.
• Warehouse-native semantic layers define meaning only inside their own platform. Enterprises running several engines and applications need a neutral layer that keeps metrics consistent everywhere.
• An agent's authority should usually be narrower than that of the person who asked, and the system should refuse to answer rather than produce a plausible number when a question falls outside its boundaries.
• The Agentic Serving Plane is the architecture of GoodData.AI. It extends capabilities already in production, such as dimension-independent metrics, FlexQuery, multitenancy, and column-level permissions, rather than replacing them.

At GoodData, our team kept getting pulled into the engineering underneath. Scale. Performance. Security. Serving analytics through APIs. Managing definitions and deployments as code. Building on open standards.

The market saw the dashboard. But the dashboard was the interface, not the platform. Underneath it we built a governed system for serving data to applications: semantics and certified metrics, query planning and caching, permissions and tenant isolation. With AI, those stop being engineering details. They become the product.

Analytics inside someone else's product

Much of that engineering came from one kind of customer: companies serving analytics inside their own products. Many of their customers share the same platform, each with different data and permissions. Requests arrive together. Response times become part of the product's user experience. Query costs become part of its economics.

A customer's data boundary has to hold on every request. A calculation has to keep its meaning across every analysis. The system has to stay usable as the workload grows [to N tenants / N requests a day].

These were the problems we chose.

What that looked like in practice

A metric should mean the same thing whether you look at it by region, product, or quarter. [In 20XX], our analytical engine made that possible: a metric defined once could be reused as the dimensions of an analysis changed, without rewriting it for each report. That separated business meaning from whatever view someone wanted to build. GoodData's Extensible Analytics Engine

Fast answers shouldn't come at an unpredictable price. We built FlexQuery on Arrow, Iceberg, and DuckDB so it can read a customer's lakehouse in place, without another proprietary copy, and serve heavy traffic without routing it through the customer's production compute. This year we added validity periods to caching: caches now expire on a schedule instead of waiting for an API call after every ETL run, and recomputation spreads out over time instead of spiking all at once. GoodData FlexQuery

Tenants share a platform but never each other's data. Our multitenant architecture enforces that boundary on every request. AI Lake, our managed lakehouse on open Iceberg storage, was designed for the bursty, simultaneous queries that embedded applications, dashboards, and agents generate, with storage and compute scaling independently. GoodData Analytics Lake

Most recently, column-level permissions moved access control down to individual fields in the semantic layer. An AI agent working in a workspace operates under the same rules as the person in that seat, the same way row-level security already works.

Squeezed between two layers

The stack is changing around us. Above, AI increasingly handles the interaction with data: interpreting a question, investigating an answer, deciding what to look at next. Below, Snowflake, Databricks, and the engines built on open table formats like Iceberg keep absorbing more of the compute.

Traditional BI sits between them. When the agent draws its own chart and the warehouse runs its own query, a BI product that was mostly a UI has nothing left to offer.

What stays valuable in the middle is serving analytics under real operating conditions.

Why not go straight to the warehouse?

Because agent traffic has a different shape. A single task can turn into tens or hundreds of small, short-lived queries. A few hundred agents turn occasional human traffic into continuous machine demand. Pointing that directly at production analytical compute is an availability decision before it is a cost decision.

Warehouses now ship semantic layers of their own, and that's good for everyone. But each defines meaning inside its own walls. Most enterprises run more than one engine and more than one application, and many serve [thousands of] customers of their own. Something neutral has to keep a metric consistent across all of them, isolate one workload from another, and enforce who may see what, wherever the data lives. A single-platform vendor is the wrong party to play that role.

An agent investigating revenue

Consider an agent asked why revenue is declining. It compares regions, examines product lines, follows up on particular accounts. One task becomes a chain of requests, each result deciding the next.

Throughout that chain, revenue has to mean the same thing whether the agent slices by region, product, or account. That is the problem our engine solved when we made metrics independent of the dimensions they're viewed through. Every request has to stay inside the requester's boundary, the same one our multitenant architecture enforces for every tenant. And the whole chain has to finish within limits on time and cost, which is what FlexQuery is for.

The agent's authority should usually be narrower than that of the person who asked. It may read the governed regional revenue metric but not the customer rows behind it. It may start a reforecast but not change a price. And when a question can't be answered inside the semantic, policy, or data boundary, the system should say so instead of producing a plausible number.

Someone reviewing the answer needs to see which definitions, sources, and filters produced it. If a definition changes, the team needs to test the consequences before they reach reports, applications, and agents.

A person opens a dashboard and picks a filter. An agent keeps asking until the task is done.

What we're building now

The Agentic Serving Plane is the architecture of GoodData.AI. It extends what we already run in production; it doesn't replace it. Each part of it starts from something our customers already use.

Data stays where it is. Iceberg lets us work on data in place, and we're adding Trino as a native data source so customers can query across the systems it federates, with user identity passed through so the source's own security still applies.

Meaning is defined once. Date parameters and semantic switchers let one governed definition serve many views, which keeps the catalog small for people and unambiguous for agents. A semantic quality agent already flags definitions that confuse AI, such as duplicate or unclear titles. Next, it will propose the fix and apply it on approval.

Authority follows the object. After column-level permissions, object-level permissions extend the same control to metrics, visualizations, and dashboards. Agents inherit the same per-object rules as human analysts, enforced in the semantic layer.

Inference runs close to the data. Local inference runs core AI features on GoodData-hosted GPUs, with no third-party model provider in the data path. Next, each task is routed to a model sized for it, so customers stop paying frontier-model prices for routine work.

Agents can call it from anywhere. Analysts increasingly work in Claude, Cursor, and ChatGPT. Through MCP, governed metrics and dashboards appear inside those tools with tenant scoping and access control intact.

The system watches itself. Usage analytics already shows how AI is used across an organization, including failures and timeouts. Next, an observability agent watches the agents customers build on GoodData and names the specific change that fixes a failing pattern.

Where we're going

Dashboards, embedded applications, assistants, copilots, and autonomous agents all run on the same foundation: reusable definitions, enforced access, inspectable results, and predictable execution. Analytics isn't a legacy business we're defending. It's the first mature way people consumed this foundation, and years of proof that it holds up in production.

It continues the work that has occupied our team for years. The next question may come from an agent instead of a dashboard. It still has to use the right definition, respect the right boundaries, and return on time.