Vertical AI agents: Why analytics agents need domain context
Ask ChatGPT or Claude to analyze last quarter's pipeline. Oftentimes you’ll get a confident, structured answer that misreads your company's definition of "qualified," joins the wrong customer table to billing, and pulls a metric from a deprecated column nobody deleted.
The model lacks domain context: the definitions, data structures, and judgment rules that separate a plausible answer from a correct one. Vertical AI agents provide that context. They pair a general reasoning engine with a domain's corresponding vocabulary, systems, and rules.
What are vertical AI agents?
A vertical AI agent is an AI agent purpose-built for a single industry, function, or workflow. It ships preconfigured (or gets builder-configured) with the domain knowledge, compliance rules, proprietary data models, and system integrations the work requires.
General-purpose agents like ChatGPT and Claude are built for cross-domain breadth and rely on whoever prompts them to supply the expertise. A vertical agent starts constrained: it knows the terms, systems, and guardrails from the first prompt, so the user doesn't have to hand-feed context every turn.
Vertical agents vs general-purpose agents in business intelligence
A general-purpose agent can summarize a spreadsheet or describe a chart. Point it at an enterprise warehouse with thousands of tables and inconsistent definitions, and it can fail silently in ways that never surface as errors.
The domain context a vertical agent runs on
A vertical agent's value lives in the context loaded into it, and that context is explicit, machine-readable, and specific to the domain it serves.
- A vertical agent for medicine might carry structured clinical vocabulary, EHR schemas, coding standards like ICD-10, and rules governing what can and can't be written back to the patient record.
- A vertical agent for law might carry firm-specific templates, precedent libraries, billing codes, and compliance rules about what data can leave the firm's environment.
- A vertical agent for finance might carry formal entity definitions (Annual Recurring Revenue = MRR × 12), reporting hierarchies, benchmark ranges, and governance constraints on which reports can be published without review.
That context compounds over time. Real usage generates correction signals, and the agent develops specialized judgment the general-purpose model never had access to.
The limits of general-purpose agents in BI tasks
General-purpose agents can fail at enterprise BI in predictable ways, and each mode can hide inside a query that runs successfully.
- Schema linking fails at scale. On the Spider 2.0 benchmark, which tests enterprise warehouses with more than 3,000 columns and multiple SQL dialects, GPT-4o's success rate is only 10.1%. Most execution failures trace to picking the wrong tables, joins, or columns.
- Missing definitions get substituted silently. When a term like "qualified lead" or "active user" isn't defined, the model tends to fall back on the most statistically likely interpretation from its training data. Your company's specific definitions aren't in that data.
- Certified metrics aren't easily distinguishable from deprecated columns. Without governance signals, the model often can't tell which fields are authoritative and which are stale.
- Limited permissions awareness. Unless permissions are wired in explicitly, a general agent has no built-in understanding of row-level security or which users should see which data.
The query runs, the chart renders, and the number can be confidently wrong. Nothing in the output signals that the model guessed at a definition or picked the wrong join, so the answer flows downstream into dashboards, decks, and decisions before anyone questions it.
What enables vertical agents to deliver value in BI
A vertical BI agent is only as good as the context, data access, and permissions wired into it.
- Governed metric definitions. Terms like "qualified lead" and "certified revenue" resolve to the logic the business already established rather than a plausible guess.
- Warehouse structure and lineage. The agent knows which table to join, which field is authoritative when tables disagree, and which columns are deprecated.
- Inherited permissions. Row-level and column-level security apply at query time when configured correctly, so the agent doesn't return data the caller isn't allowed to see.
The supporting evidence is direct: on Snowflake's internal BIRD-SQL benchmark, adding a semantic model to Cortex Analyst lifted the same LLM from 57% to 78%.
Where vertical AI agents show up in business intelligence
Vertical BI agents are already running inside narrow, well-defined workflows across the enterprise, and the narrowness is the point. Limiting the data, definitions, and actions in play is what makes the agent reliable enough to trust with real work.
- Finance agents reconcile spend against certified budget tables and draft variance narratives against known account structures.
- Reporting agents roll forecasts forward, refresh recurring management reports, and flag exceptions before the next review cycle.
- Sales agents qualify pipeline against a defined stage model instead of guessing what "qualified" means.
- Pipeline agents score account fit, prioritize outreach, and surface deals that have gone quiet against a defined engagement threshold.
- Operations agents flag inventory exceptions against warehouse thresholds. Unilever, for example, uses AI-driven weather and demand analysis to improve forecast accuracy in specific categories.
- Supply chain agents monitor supplier performance, predict lead-time slippage, and route reorder decisions against negotiated terms.
How to build vertical AI agents for business intelligence
Building a vertical BI agent is a sequence of design decisions before it's an engineering effort. Five practical steps get you from idea to a working agent a team will use.
- Define the workflow, then the metrics. Pick one workflow (variance commentary, pipeline qualification, inventory exception triage) and document every metric, filter, and business rule the agent needs to reason with. Write these down somewhere the agent can reference at runtime.
- Select the model. Decide whether you'll use a foundation model through an API (OpenAI, Anthropic, Google), a warehouse-native model (Databricks foundation models, Snowflake Cortex), or an open-source model you host yourself. For many enterprise BI use cases, warehouse-native models provide a practical starting point because they keep data inside one governance boundary.
- Wire up governed data access. Connect the agent to the warehouse tables the workflow needs, and nothing else. Row-level and column-level security should propagate from the warehouse where the architecture supports it, so the agent inherits the caller's permissions rather than running as a privileged service account that sees everything.
- Scope the actions. Enumerate exactly what the agent can do once it concludes: write to a specific input table, post a message to a channel, trigger an approval, call a downstream system. Log actions with the prompt that triggered them, the query that ran, and the caller's identity so a reviewer can replay a run.
- Test, log, and iterate. Run the agent against a set of known-good answers before rollout, including edge cases and refusal cases where it should decline to act rather than guess. Log prompts, queries, and actions so you can inspect what happened when a user challenges a result, and feed the corrections back into the agent's instructions or the underlying definitions.
Best practices for keeping vertical AI agents reliable over time
Building vertical AI agents is one part of the work. The agents that stay accurate in production are the ones maintained as the warehouse, the business, and the model ecosystem shift underneath them.
- Review permissions and instructions on a set cadence. Schema changes can reduce execution accuracy when tables get added, split, or merged, and a quarterly review catches drift before a stakeholder does.
- Keep metric definitions in one authoritative place. When a definition changes, every agent that reads it should update in the same step, so no two agents present conflicting numbers a week after a policy change.
- Sample outputs on a schedule, including runs users haven't challenged. Users tend to challenge results only when the number looks off, which means confidently wrong answers can sit unreviewed for months. Include runs nobody flagged in your sample.
- Retire agents that stop being used. Unused agents accumulate stale scope and outdated definitions, and they become the ones someone runs during a fire drill and trusts by default.
Treat these as ongoing hygiene rather than one-time setup.
How Sigma supports vertical AI agents for business intelligence
In Sigma, a vertical BI agent is a custom agent that a builder scopes to one domain's data, definitions, and actions, running on live warehouse data under the permissions already in place.
Custom agents scoped to a domain
Sigma Agents start narrow by default, and builders should review their scope as requirements change. A builder configures a Sigma Agent with plain-English instructions defining its role and behavior. Each agent operates within a single workbook and reads configured tables and columns under workbook and warehouse permissions.
Scope is what makes each agent vertical. An FP&A agent might read only general ledger actuals, budget, and forecast tables, with instructions that spell out how the finance team calculates variance and which accounts roll up to which cost centers, then draft variance commentary for the monthly close. A sales-call agent in the same organization might read only Gong call transcripts landed in the warehouse and joined to opportunity data, with instructions that define a competitor mention, a pricing objection, and a buying signal. Each agent reads only its own domain's tables and answers in that team's vocabulary. Agents can run conversationally or on a schedule, with human-in-the-loop approval when the workflow requires it.
Domain context from your semantic layer
Instructions tell an agent how a team works, and the semantic layer tells it what the numbers mean. Sigma Agents can use governed metrics and Sigma data models as context, so terms like “qualified pipeline” and “active customer” resolve to the definitions the data team already certified. Teams on Snowflake can bring Snowflake Semantic Views into Sigma natively, with metrics, dimensions, and joins already defined in the warehouse, so an agent works from the same definitions as your Sigma workbooks and Snowflake Cortex Analyst.
Governance inherited from the warehouse
Once an agent knows the domain, governance keeps its answers inside the right boundaries. Sigma Agents inherit governance from the warehouse and apply five layers of control: warehouse governance from the cloud data warehouse, Sigma data model governance, roles and permissions in Sigma under the running user's identity, workbook-level grants, and in-agent scoping.
When configured this way, AI runs through the customer's stack, using external language models or warehouse-native models through the connected warehouse, so it processes answers within the customer's governance and lineage path.
Scoped actions for writeback, notifications, and approvals
Sigma Agents can act on their conclusions through configured, logged Sigma Actions. Builders can configure Sigma Actions for an agent: steps that write to Input Tables with an audit trail, send notifications, trigger sequences, or call external systems. With human-in-the-loop review, the agent proposes, and the user approves before anything is written or sent, so a review agent can surface its top recommendations and write the ones a person selects back as prioritized to-dos.
Build vertical AI agents for business intelligence with Sigma
A vertical BI agent is only as accurate as the domain knowledge behind it. In Sigma, that knowledge comes from the definitions your data team already maintains in Sigma data models and Snowflake Semantic Views, plus the instructions a builder writes for one team's workflow. Warehouse permissions and workbook-level grants then apply on every query. The result is an agent business teams can use with confidence, and IT can audit, running on live warehouse data rather than a copy that drifts out of sync.
