Agentic Analytics Explained: A Guide to Analytical Workflows Using AI Agents

When you give an experienced analyst a question about gross margin, they bring a lot more than SQL to the task. They know which definition of gross margin should be used, which data sources are trusted and up to date, where the grain changes and which joins are likely to distort the result. Much of this knowledge resides only in the mind of the analyst.

An AI agent tasked with that analysis doesn't automatically have the same knowledge, so context must be provided explicitly. And in an agentic analytics workflow, the agent draws on that context repeatedly as the investigation unfolds: to decompose the question, choose among sources and tools, interpret intermediate results and decide what to examine next. This raises practical questions: What does the agent need from the data layer? Whose permissions apply when it calls a tool? How will teams determine whether the resulting analysis is sound?

Agentic analytics uses AI agents to plan and execute multistep analytics workflows, choosing among available data and tools as intermediate results shape the investigation. A typical analytical loop includes several stages:

Resolve context → plan → call a tool → inspect the result → revise the plan → validate → stop

Natural-language-to-SQL may handle one query step, while search, semantic retrieval, procedures and APIs give the agent other ways to gather evidence or act on what it finds. Orchestration controls which tools are available, what context is passed into each call and how intermediate results influence subsequent steps.

That control over next steps is what separates agentic analytics from other forms of AI-assisted analytics. Augmented analytics uses AI to help with parts of a human-directed workflow, such as preparing data, surfacing patterns or generating explanations. In an agentic workflow, the agent takes on more of the coordination itself.

The agentic model places more analytic decisions at runtime. The agent may need to resolve terminology, select among sources, determine an appropriate query path and decide whether an intermediate result warrants another step — which means the reliability of the output depends on the context and constraints surrounding those decisions.

See how Cortex Agents orchestrates SQL analysis, search and AI reasoning across structured and unstructured enterprise data:

The agentic analytics workflow is iterative. The agent has to resolve the question against business context, choose which tools and data to use, evaluate what comes back and decide whether to continue, branch, stop or act.

Consider the gross-margin question again. Before issuing SQL, the agent has to establish what the question refers to. Gross margin may have an approved calculation with defined revenue and cost measures, aggregation rules and valid dimensional relationships. EMEA may map to an organizational hierarchy rather than a literal region field. Last quarter may require fiscal-calendar logic.

Once those elements resolve, the agent connects them to physical data. This includes selecting the appropriate tables or semantic views, determining the required grain and following valid relationships among facts and dimensions.

Tool selection shapes the investigation itself. A semantic query might establish where margin changed, while a search over contracts or sales notes could supply context for why. If several tools could answer the same sub-question, the planner needs enough metadata to choose among them based on scope, source authority and expected output. Tool definitions and orchestration instructions need to be specific enough to guide selection without hard-coding every analytical path.

Before an intermediate result feeds the next step, the workflow needs some way to test whether it's usable. The check depends on the type of result: a generated query might be evaluated for valid grain and relationships, whereas a returned metric might be reconciled against a known reference or expected range.

The agent can also compare the result with the question it was intended to answer. If a query intended to explain a margin decline returns only aggregate revenue, for example, the result is valid SQL but insufficient evidence for the next analytical step. The planner should revise the query rather than treating successful execution as successful analysis.

These checks are especially important because intermediate errors propagate. An unsupported join, stale source or incorrect entity resolution early in the run can shape every query that follows, producing a coherent investigation built on the wrong premise.

The agent then has to decide whether the evidence is sufficient. It may need another query, a different tool, clarification from the user or an approved downstream action.

Those decisions also affect workload behavior. One request may produce several SQL statements, searches and tool calls, with retries or parallel branches as the investigation develops, so query budgets, concurrency, timeouts and stopping conditions belong in the operating model too.

Customer story: Fireblocks

Fireblocks uses Cortex Agents with semantic views to make analytics accessible through natural language. Its internal agent lets teams investigate product and customer metrics directly, while its customer-facing Fire Genie delivers personalized analytics — extending governed data access to both employees and customers.

Read the full case study >

Analytical accuracy depends on more than model capability. In enterprise environments, many errors come from forcing the model to infer business logic that could have been supplied explicitly.

At minimum, the analytical context should include:

• Metric and business definitions: approved calculations, filters, time logic and aggregation behavior
• Entity relationships: how customers, accounts, products, orders and other business objects relate
• Declared grain: what one row represents in each relevant object
• Supported join paths: relationships the system should use when combining data
• Synonyms and entity mappings: alternate terminology and domain-specific meanings
• Source fitness: freshness, ownership, deprecation status, completeness and other signals relevant to source selection
• Policy and provenance: who is permitted to use the data and where it came from

A schema tells an agent where data lives, but usually not how the business expects that data to be interpreted. For example, "customer status" might depend on several fields, or "gross margin" may only be valid across certain dimensions or aggregation levels.

A semantic model makes that logic explicit. Metrics, dimensions, calculation rules, relationships and synonyms give the agent a governed representation of the business concepts in the question, reducing how much it has to infer while constructing a query. Those definitions also need to be reusable beyond a single analytical interface. If business logic is recreated separately in a dashboard, agent and application, the organization still has several versions to govern. A shared semantic model gives those experiences a common set of definitions and relationships.

A 2024 Snowflake internal evaluation revealed how much the surrounding analytical system affects accuracy. On a 150-question benchmark designed around real-world BI tasks, single-prompt GPT-4o reached 51% accuracy, while Cortex Analyst, which uses a semantic model to supply business definitions and context, achieved more than 90%.

Semantic definitions cover only part of the analytical path, however. An agent can resolve the correct measure and still produce the wrong result if it chooses an invalid join or combines data at incompatible grains.

Suppose the system resolves revenue correctly, then joins an order-level fact to an order-item table without accounting for the change in grain. Revenue is duplicated before aggregation, even though the SQL executes successfully and the metric formula itself remains unchanged.

Chasm joins create a related problem when multiple fact tables are joined through shared dimensions and combinations multiply records unexpectedly. Many-to-many relationships, bridge tables and semi-additive measures introduce additional cases where a seemingly reasonable join produces the wrong analytical result.

For agentic systems, grain, cardinality and valid join paths need explicit representation. Leaving those relationships implicit pushes structural decisions back into runtime inference, where the model may or may not make the correct choices.

Enterprise language often maps imperfectly to data objects. A request for "enterprise customers," for example, might refer to an account segment in CRM, a product tier or a finance classification.

The agent needs enough entity metadata and domain context to select the intended business object before it builds the query. Where several interpretations are plausible, the workflow should preserve the ambiguity and ask the user for clarification rather than simply choosing one.

A catalog may expose several objects that technically contain the requested information, but that doesn't mean they're equally appropriate for the analysis.

Experienced analysts routinely account for context such as whether a source is current, whether an upstream transformation changed recently, whether a table is deprecated or whether coverage differs by geography. Unless those characteristics are machine-readable, an agent sees a set of available objects without the institutional knowledge that helps the analyst choose among them.

Freshness, lineage, ownership, quality indicators, certification status, usage patterns and deprecation metadata all contribute to source fitness.

An agent introduces an authorization question: whose permissions apply when the agent calls a tool or runs a query? For interactive sessions, delegated end-user identity keeps query execution aligned with the permissions of the person asking the question. Existing role-based access control, row access policies and column masking then continue to govern the underlying data.

Scheduled or unattended workflows require a different identity model. Without an interactive user to delegate from, the agent needs a dedicated execution identity scoped to the data and tools required for its job. A broadly privileged shared service account expands the risk of every tool call and forces additional authorization logic into the application layer.

The relevant authorization context extends beyond the initial agent request. Every tool call and underlying resource in the workflow has to be evaluated under the intended identity and permissions.

For each tool call, the authorization model needs to answer:

• Which identity is executing?
• Which role or entitlements apply?
• Which underlying objects does the tool access?
• Do row- and column-level policies continue to apply?
• Does the tool execute with caller's rights or elevated owner's rights?
• What happens if one required resource is unavailable?

Fail-closed behavior is particularly important for analytical workflows. If the agent can't access a required tool or data set, it should fail visibly rather than produce an answer from only the information it could reach.

Prompt-level restrictions can't replace identity-based access controls, row access policies, column masking or other permissions enforced by the data platform. An instruction telling an agent not to access compensation data is subject to interpretation by the model, and it can be bypassed through prompt injection. Strong authorization limits what a successful manipulation of the model is able to retrieve.

As Snowflake Chief Security and Trust Officer Mayank Upadhyay puts it, "The biggest mistake organizations can make is thinking AI security is only about securing the model. The real challenge is governing everything the model touches." For analytical agents, that extends security into identity, permissions, tool access and the actions an agent is authorized to take.

And if the agent can take action, additional safeguards are needed. Consequential changes should require approval, and the audit trail should identify what was executed, under whose authority and against which resources.

Agentic workflows complicate the usual idea of reproducibility. The same question doesn't necessarily generate identical SQL or follow the same sequence of steps on every run. One plan might segment by geography first, for example, while another begins with product. Different SQL statements may also produce analytically equivalent results.

The better test is that the run be reconstructable and that equivalent executions resolve to the same governed meaning and materially consistent result.

This requires an execution trace with enough information to determine:

• Which semantic objects and definitions were resolved
• Which sources and join paths were selected
• Which tools were called and in what order
• Which SQL statements or other operations executed
• Which identity and permissions applied to each step
• Which intermediate results influenced later decisions
• Why the planner continued, branched or stopped
• Which validation checks ran before the result was returned

Snowflake's Josh Klahr and Rajhans Samdani describe the target as preserving "the trace behind an answer, including sources used, transformations applied, lineage of data sources and why competing sources were accepted or rejected." That trace gives data teams somewhere to start when an answer is questionable.

Agent evaluation needs to distinguish among different failure classes. A result might be wrong because the agent resolved the wrong metric, selected the wrong entity interpretation, used an unsupported join path, aggregated at the wrong grain, selected stale or incomplete data, lost access to one of its required tools, stopped before testing an alternative explanation, generated SQL that was syntactically or semantically incorrect, or interpreted a correct query result incorrectly.

Grouping all of those outcomes under "hallucination" makes diagnosis difficult. Each failure originates in a different part of the analytical system and points to a different remediation.

Evaluation should operate at several layers:

• Semantic resolution: Did the question map to the expected measures, dimensions, entities and time logic?
• Query correctness: Did the generated SQL preserve grain, follow supported relationships and produce the expected result?
• Source selection: Were the chosen objects authoritative and sufficiently current for the question?
• Authorization: Did every tool call execute under the intended identity and policies?
• Plan quality: Did the workflow pursue relevant follow-up steps, avoid unnecessary fan-out and stop with sufficient evidence?
• Result quality: Did the answer reconcile with a known-good result or fall within an accepted tolerance?

Research on agent evaluation supports looking beyond the final answer. In Snowflake AI Research's Agent GPA benchmark study, evaluators that assessed an agent's goal, plan and actions detected 95% of human-annotated errors, compared with 55% for a baseline LLM judge. They also localized 86% of errors to the specific part of the execution trace where the failure occurred.

Existing reports, analyst-reviewed SQL and certified calculations provide useful starting points for the evaluation set. Verified or golden queries pair representative business questions with known-good SQL or expected results. They give teams reference cases for testing changes to the model, semantic layer, schema or orchestration logic.

The test set should also include the failures most likely to survive a superficial review: join fan-out, ambiguous entity values, alternate phrasings, restricted data, source changes and questions that require several semantic views.

Running those evaluations exposes regressions. A query that passed before a semantic-model revision and fails afterward provides a much more actionable signal than a broad decline in user satisfaction, for example. Regression testing reruns known-good cases after updates, showing whether behavior changed and giving teams a starting point for tracing the cause.

Snowflake's agentic analytics architecture maps these requirements across the semantic, execution, governance and evaluation layers.

Semantic Views represent metrics, dimensions, relationships and other business logic as governed Snowflake objects that can be reused across SQL, BI and AI workflows. Snowflake Horizon Context, within Snowflake Horizon Catalog, adds broader business and technical context, including metadata about definitions, relationships, provenance and governance.

Cortex Analyst handles natural-language-to-SQL over Semantic Views, while Cortex Agents plans and orchestrates tools across structured and unstructured data. Execution stays subject to Snowflake's privilege model. Custom procedures retain their caller's-rights or owner's-rights semantics.

Verified queries and Cortex Analyst evaluations provide reference cases for testing accuracy and detecting regressions as models, schemas or semantic definitions change. For business users, Snowflake CoWork provides a conversational interface for analyzing governed enterprise data, following up on findings and creating reusable analytical outputs.

These capabilities enable teams to keep the major control points close to the governed data: semantic resolution, authorization, query execution, provenance and evaluation. The agent has flexibility in how it investigates a question, while definitions and policy remain part of the system it operates within.

As analytical agents take on broader investigations and more downstream actions, the number of decisions the agent makes independently will keep growing. More tool calls, more source selection and more branching create more opportunities for an error in context, permissions or execution to propagate through the workflow.

For data leaders, the best response is to push as much certainty as possible into the surrounding system: explicit business logic, governed relationships, enforceable access controls and evaluation tied to real analytical work. With those constraints in place, teams can give agents more room to investigate and act without giving up visibility into how the work was done.

Dashboards remain useful for standardized monitoring, recurring metrics and workflows where the analytical path is intentionally predefined. Agentic analytics addresses questions whose decomposition or follow-up steps are determined during execution. Both work more consistently when they resolve against the same governed metrics and analytical relationships.

Accountability remains with the organization operating the system and the people responsible for the decisions its output informs. For consequential uses, teams should define ownership and review requirements while retaining enough execution history to reconstruct the semantic resolution, data sources, queries and authorization context behind the result.

Agentic Analytics: Building a Data Foundation for AI Agents — Blog

From Insight to Action: Agentic Analytics with Sigma and Snowflake — Guide

The Next Era of Analytics Is Agentic — Webinar

Build Agentic Analytics with Semantic Views — Guide