Embedded Agentic Analytics

Embedded agentic analytics is customer-facing analytics where an AI agent works inside your product: it answers questions, explores governed metrics, and returns analysis scoped to the customer asking. The key word is agentic. The AI is not just summarizing a chart or turning one prompt into SQL; it plans analytical steps, selects metrics, applies filters, and produces an answer that can be checked against the model behind it.

A working definition

Embedded agentic analytics is embedded analytics where an AI agent performs analytical work for a customer inside the host application. The customer stays in your product. The agent works over that customer's slice of data. The answer comes back in product context, with the same metric definitions and access rules that govern the rest of the analytics experience.

The embedded part is about where the analytics live and who they serve. A customer asks about their subscription usage, payment volume, claims backlog, or delivery performance without leaving the application they already use. For the broader foundation, start with what embedded analytics is.

The agentic part is about who does the analytical work. Instead of a customer opening a dashboard, changing filters, and interpreting the result, an agent decomposes the question, chooses metrics and dimensions, runs governed queries, and returns the answer in plain language. That makes this a data architecture problem before it is an interface problem.

How embedded agentic analytics works

The reliable architecture starts with the model.

First, a semantic layer defines metrics, dimensions, joins, entities, and access rules once. It sits on top of the warehouse, so the warehouse remains the storage and compute layer. The semantic layer turns product questions into governed queries against certified business definitions.

Second, the host application passes user context into the analytics layer. In a multi-tenant product that context usually includes the tenant, role, region, plan, or other attributes that decide which rows and columns the user may see. The platform applies those rules before SQL is generated, so the agent does not have to remember tenant isolation in a prompt.

Third, the agent selects from governed concepts rather than raw tables. If a customer asks, "Which accounts expanded fastest last quarter?", the agent chooses the right expansion metric, dimensions, filters, and time range from the semantic model. The platform compiles the query, applies access rules, and returns an answer that can be traced to the metric definition. That same pattern is the core of an AI-powered embedded analytics platform.

Finally, the answer reaches the product through the surface you choose: embedded dashboards, workbooks, an Analytics Chat-style experience, APIs for a custom interface, or agent access over MCP. Cube's embedded analytics product page lays out those product surfaces: drop-in iframes, Creator Mode, Core Data APIs, and custom agent experiences over the Analytics Chat API or MCP.

The grounded-answer test

The useful evaluation spine for embedded agentic analytics is the grounded-answer test:

Can an AI agent answer a real business question on this model, return the right number, under the asker's permissions, traceable back to the definition that produced it?

Each clause is load-bearing.

A real business question is not a toy prompt like "show revenue by month." Customers ask in their own product language, combine filters, and expect the agent to handle follow-ups. The model needs enough context for the agent to navigate that without inventing joins.

The right number means the answer uses certified metric definitions. If the customer-facing AI answer and the embedded dashboard disagree, the feature has taught the user not to trust either one.

Under the asker's permissions is the embedded requirement. Customer-facing analytics is multi-tenant by default. Tenant and role rules must live below the agent, in the layer that compiles the query.

Traceable back to the definition is what makes the answer supportable. Product, data, and customer success teams need to see which metric, filter, and grouping produced the answer. A wall of generated SQL is not enough when a customer asks why a number changed. For the agent-access side of that pattern, see the analytics MCP server guide.

How it differs from adjacent categories

Embedded agentic analytics overlaps with a few terms, but the distinctions matter.

AI-powered embedded analytics is broader. A product might use AI to summarize a chart, generate a query, explain an anomaly, or recommend a dashboard. Embedded agentic analytics is narrower and more demanding: the agent plans, queries governed metrics, iterates, and returns an answer it can explain.

Text-to-SQL in a product is a mechanism, not the category. It can be useful under the hood, but raw text-to-SQL pointed at customer tables fails the production test quickly. The model has to infer business logic and tenant filters on every prompt. In front of customers, that is too much trust to put in generated SQL.

Internal agentic analytics serves employees and internal workflows. Embedded agentic analytics serves customers inside your product. The audiences differ, but the strongest architecture is one governed model that serves both. The broader agentic analytics explainer covers the internal BI framing.

What production teams need before the agent

The honest tradeoff is modeling investment. You define the metrics before the agent can answer from them. That can feel slower than shipping a raw LLM demo, but it is the work that makes the feature reliable enough for customers.

Production embedded agentic analytics needs five pieces in place.

A governed semantic model. Metrics, dimensions, joins, entities, and access rules need one reviewed definition. The agent should select from that model, not infer the business from table names.

Tenant-aware security. The host application must pass a signed security context, and the analytics layer must enforce row- and column-level rules before the query runs. Prompt instructions are not an access-control system.

Embedded surfaces. Customers may need a dashboard, a workbook, an in-app authoring flow, a custom chat interface, or an API response. The important point is that every surface reads the same governed model.

Performance under concurrent load. Agentic analytics can issue multiple queries for one answer. In an embedded product, many customers may do that at once. Caching and pre-aggregations keep the experience fast without pushing every question directly to the warehouse.

Explainability. The answer should point back to the metric, filters, and dimensions behind it. That trace is how teams debug the feature and how customers learn to trust it.

Where Cube fits

Cube is the agentic analytics platform built on a semantic layer. Its open-source foundation, Cube Core, defines metrics, dimensions, joins, access rules, and caching on top of the warehouse. The Cube platform adds Analytics Chat, workbooks, dashboards, embedded surfaces, MCP access, multi-tenancy, governance, and managed performance.

For embedded agentic analytics, that means the same governed model can power customer-facing dashboards, a custom AI analyst inside your product, APIs, and internal BI. The user's security context flows through each request, so answers stay scoped to the right tenant. The agent selects from certified metrics instead of writing free-form SQL against raw tables. The answer can be traced back to the semantic-layer definition that produced it.

This is why the embedded and internal use cases should not become separate analytics stacks. If your customers and your team rely on the same business facts, one governed model is the durable path. Each metric you model improves dashboards, APIs, workbooks, and agentic answers at once.

Methodology

This explainer treats embedded agentic analytics as the agent-led version of customer-facing analytics, not as a synonym for every AI feature inside a dashboard. The criteria are weighted toward what fails in production: metric consistency, tenant isolation, answer traceability, performance under concurrent customer load, and whether the agent works from governed definitions rather than raw tables. As the publisher, Cube has an obvious interest here; the goal is to make the architectural bar explicit so readers can test any implementation, including Cube, against the same grounded-answer standard.