Five Data Agent Routes: Compare Products by the Work They Own

One Data Agent turns a business question into SQL. Another runs queries and Python, then writes a report. A third edits a production pipeline. They share a category name, but they should not share one scorecard.

The useful unit of classification is a workflow, not a vendor. Ask four questions: What enters the system? Which part of the work does it own? What does it deliver? What is the blast radius when it fails? Those questions reveal five recurring routes.

These routes are task families, not maturity levels. A route describes what the system does. Semantic context, the agent harness, policy, and evaluation determine whether it can do that work reliably.

1. Business Q&A and semantic layers

This route serves frequent, relatively standardized questions: “How many new paying customers did we add in the East region last week?” or “Which channel explains the decline?” The agent maps business language to metrics, dimensions, tables, and joins before it generates and executes a query.

It is often described as NL2SQL, but SQL syntax is rarely the hardest part. The difficult questions are semantic: What counts as “new”? Are refunds netted out? Does revenue belong to the payment date or the fulfillment date? Without metric definitions, entity relationships, permissions, and trusted examples, a model can produce syntactically valid SQL and still return the wrong business answer.

Snowflake Cortex Analyst uses semantic models to describe business concepts and inherits Snowflake access controls; its Verified Query Repository adds trusted question–SQL pairs. Microsoft Fabric Data Agent similarly generates queries against governed Fabric data sources and executes them under the caller’s permissions. The product lesson is clear: this route is governed, read-oriented data access—not merely chat over a warehouse.

Evaluate: business-definition accuracy, executable-query accuracy, permission enforcement, and calibrated clarification or refusal. Exact string match against one “gold SQL” is too brittle for equivalent queries and too weak for semantically wrong answers.

2. End-to-end analysis and reporting

“Why did retention fall, and what should we investigate first?” cannot be answered with one query. The agent must decompose hypotheses, choose baselines, run several queries or programs, build charts, and assemble an argument.

This route compresses the analysis cycle, but it is also good at producing polished false confidence. A report may use the wrong denominator, ignore a shift in the sample, or turn correlation into causation. A production system should therefore retain the plan, queries, code, material intermediate results, chart data, and citations. A reader should be able to walk backward from conclusion to evidence.

Evaluate: coverage of plausible hypotheses, support for each conclusion, suitability of statistical methods, and reproducibility. Prose quality is the final layer, not the principal measure of analytical quality.

3. Automated data science

A data-science agent participates in exploratory analysis, feature preparation, statistical testing, model training, and evaluation. Its deliverables include executable code, data splits, model metrics, and an experiment record—not only an insight.

Google’s Data Science Agent turns a natural-language goal into a plan, code, and results in a Colab Enterprise notebook. That can remove hours of setup work, but it does not eliminate professional judgment about target leakage, temporal leakage, sampling bias, or evaluation design.

Evaluate: reproducible environments, correct train/validation boundaries, metrics aligned with business costs, and visible failure states. A notebook that runs is a starting point, not evidence that a model is ready for production.

4. Heterogeneous and multimodal analysis

Real investigations often span warehouse tables, spreadsheets, PDFs, web pages, images, logs, and sometimes audio or video. The agent’s primary job becomes retrieval, parsing, entity resolution, cross-source aggregation, and provenance.

A supplier-performance investigation, for example, may combine delivery records with contractual deadlines extracted from PDFs and causes described in support tickets. A single identity or time-alignment error can corrupt the synthesis.

Evaluate: parsing coverage, entity-linking accuracy, source localization, conflict handling, and citation completeness. “Not found,” “not confirmed,” and “inferred” should remain distinct states rather than being flattened into fluent prose.

5. Data governance and data engineering

This route covers metadata maintenance, quality rules, lineage and impact analysis, data-model development, pipeline debugging, and operations. The output may be a change proposal—or actual Dataform, dbt, or orchestration code.

Once an agent can write to a production system, the question changes from “Is the answer useful?” to “Is the change safe?” The BigQuery Data Engineering Agent can generate and modify pipelines and Dataform SQLX. Google’s documentation also states that the agent cannot execute, run, or schedule those pipelines for the user. That boundary matters: generating a change and authorizing it are different acts.

Evaluate: impact analysis, test coverage, least privilege, approvals, idempotency, rollback, and complete audit trails. A high model confidence score should never be the only gate for a high-risk write.

The shared foundation is larger than the model

Although their work differs, all five routes depend on similar infrastructure:

• Semantic and business context: metric definitions, entity relationships, lineage, domain rules, and verified examples.
• Agent harness and state: plans, tool protocols, execution state, retries, stopping conditions, and cost budgets.
• Identity, policy, and approval: caller identity, row- and column-level permissions, read/write separation, and human gates.
• Evaluation and observability: offline task suites, online feedback, traces, error taxonomies, latency, and cost.

This is why a model-only comparison rarely predicts production performance. Two systems using the same model can behave very differently because their context, tools, validators, and permission design differ.

Classify hybrid products by workflow

A product can span several routes. Classify each workflow instead of forcing the whole platform into one box:

• “Return quarterly revenue and explain the definition” is business Q&A.
• “Diagnose the decline and produce a business review” is end-to-end analysis.
• “Train a churn model” is automated data science.
• “Combine interviews and behavior data to explain churn” is heterogeneous analysis.
• “Repair the pipeline that duplicated orders” is data engineering.

Only at this resolution can a team design the right permissions, acceptance set, and human checkpoints. Different features in the same product may also operate at very different autonomy levels.

Eight questions for product evaluation

The point of the taxonomy is not to create more labels. It is to bring the conversation back to work. Decide which part of a workflow the agent should own, then discuss models, autonomy, and product architecture. In the opposite order, a precise comparison can still answer the wrong question.