An agent can navigate a semantic model, choose dimensions and metrics, and generate a query at processing time, which is a powerful way to explore a warehouse.

However, it is not always the right way to run a business workflow.

When an agent supports a recurring process—reviewing accounts, checking order status, preparing a renewal brief, or flagging an operational exception—the team often wants to give it a small set of direct tools instead:

get_customer_health
list_accounts_needing_attention
get_order_history
get_renewal_summary

Those tools might be ordinary HTTPS calls or MCP tools, but the transport matters less than how the operation is defined: each tool represents a known operation with defined inputs, outputs, permissions, and failure behavior.

The difference is not whether the agent can access data, but whether it is free to define the operation every time it runs.

Exploration and execution are different jobs

A semantic model gives an agent a map of the business data. It can describe customers, orders, revenue, regions, relationships, and metric definitions. The agent can use that map to answer a question it has not seen before.

That flexibility is valuable for analysts, but it is also a source of variability. The agent may choose a different join, filter, aggregation, or interpretation from one run to the next. Even when each generated query looks reasonable, the workflow may be difficult to reproduce and audit.

A production workflow usually starts with a different requirement:

Given the same approved inputs and the same data version, perform the same business operation and return a result in the same shape.

That is a request for determinism.

Determinism does not mean the underlying business data never changes; it means the operation itself is stable, so the team knows which model supplies the data, which joins and definitions apply, which parameters are allowed, and what the consumer will receive.

Narrow tools make intent explicit

Consider an agent helping a customer-success team. It could receive broad warehouse access and be asked to find accounts that deserve attention. Or it could call:

list_accounts_needing_attention(
  renewal_window_days = 60,
  minimum_usage_decline = 0.20
)

The second interface says something important about the organization because it encodes an approved definition of “needing attention,” including which signals matter and how the data team has chosen to combine them.

The agent still has room to explain the result, compare accounts, and decide what to say to the customer-success manager without rediscovering the company’s metric logic before every response.

That separation keeps business meaning in a reviewed data definition while leaving interpretation and communication to the agent.

Predictability is a product feature

An open-ended query can be correct and still be operationally inconvenient. Teams also need to reason about:

A curated endpoint can make those properties explicit: its inputs are typed, its response size is limited, its credentials can be scoped to the operation, its query can run against a controlled serving artifact or approved model, and its errors can be named and tested.

That predictability matters when the result feeds another system. A workflow that creates a task, sends a notification, updates a case, or prepares a customer-facing document should not depend on an agent improvising a new SQL plan on every run.

Repeatable workflows need repeatable evidence

Suppose a company reviews renewal risk every Monday. The company may need more than the final summary and should also know:

  1. which endpoint was called;
  2. which parameters were supplied;
  3. which data version was active;
  4. which result was returned; and
  5. what action followed.

A defined tool makes that chain easier to observe because the organization can test the endpoint independently, compare results across weeks, investigate a change, and determine whether the workflow improved an outcome.

With unconstrained query generation, the audit trail has to preserve the generated SQL and enough model context to explain why the agent chose it. That may be possible, but it is a heavier operational burden—and it still leaves the question of whether the query represented the intended business rule.

This is not an argument against semantic models

Semantic models and direct tools serve different layers.

Semantic access is well suited to questions such as:

Which product categories grew fastest in the Northeast last quarter, and what other dimensions should I investigate?

The agent needs to explore because it may not know the answer shape in advance.

A purpose-built tool is better suited to:

Give me the accounts that match our approved renewal-risk definition.

The answer is part of a repeatable operating process, so the organization wants the definition to stay stable even as the agent, prompt, or consuming application changes.

The best systems will use both: let agents explore when exploration is the job, and give them curated tools when execution is the job.

There is also a useful feedback loop between the two.

Semantic access is a way to explore upstream. It shows which questions people are asking, which concepts they cannot find, and which joins or calculations agents keep having to rediscover. When a pattern emerges, that question should not remain an improvised query forever. The team can extract the logic into a tested dbt model and publish it as a new deterministic tool.

From recurring questions to published tools

Imagine a process that runs every week or month and reviews the questions being asked across the company’s agents. It identifies the small set of lookups that account for most of the usage:

top customer questions
        ↓
repeated query patterns
        ↓
tested dbt models
        ↓
production endpoints with response limits
        ↓
faster, repeatable agent workflows

Historically, the data team has often been the bottleneck in this process. It has to notice recurring demand, reconcile definitions, build the model, test it, expose it, and then maintain the interface. That work is valuable, but it does not all need to remain manual.

In a more autonomous data environment, agents could help identify the Pareto distribution of questions: the small number of query patterns that account for most requests. They could propose the ideal query plans and candidate models for review, while the data team retains ownership of definitions, tests, permissions, and publication.

Once approved, those models can become endpoints instead of repeated exploration tasks. The result is not only better data utilization and more consistent answers, but also a direct cost control: a dedicated query surface does not need a frontier model with a large context window to rediscover the same joins and metric logic every time.

The model can still handle the explanation, comparison, and judgment around the result without spending its most expensive reasoning on a query plan the organization has already learned and approved.

Turning trusted models into production tools

The distinction is especially important when warehouse logic crosses into software. A semantic model helps an agent understand what the data means. A production endpoint determines what an application or workflow is allowed to depend on.

Qry starts with that production interface. It turns trusted SQL and dbt models into secure, read-only production APIs with explicit parameters, response limits, controlled refresh, and stable interfaces.

Those endpoints can be called directly by an application or exposed as tools through MCP, so the agent can still reason about the result without owning the query plan for every recurring operation.

The goal is not to make agents less capable but to turn their exploration into infrastructure the organization can reuse: deterministic enough to test, predictable enough to operate, and repeatable enough to improve over time.