The easiest Data Agent market map to draw incorrectly is a wall of logos that mixes cloud platforms, BI applications, internal systems, open-source frameworks, and research projects. They may serve different jobs, occupy different layers, and accept different production responsibilities.
A useful map has two axes: system position and delivery model. Find peers first, then compare them.
Axis one: position in the system
Data platforms
Snowflake, Databricks, Google BigQuery, Microsoft Fabric, and AWS Redshift already own data, compute, permissions, and governance entry points. A native agent can reuse those control planes, but its workflow is often shaped around the platform ecosystem.
Snowflake Cortex Analyst builds on Snowflake semantic models and access controls. Microsoft Fabric Data Agent queries Fabric data sources under user permissions. Google exposes different agent entry points for analysis, data science, and data engineering.
Semantics and governance
This layer manages metrics, entities, relationships, lineage, quality, and policy. It may not use the name “Data Agent,” yet it determines whether an agent understands revenue and customer. Ask whether BI, agents, and other applications share the semantic assets and how versions and owners are governed.
Agent platforms
These platforms supply models, connectors, tool protocols, runtime, state, evaluation, and governance for custom workflows. OpenAI’s Data agent in ChatGPT Work, announced in September 2026, is an enterprise product. It has a different delivery boundary from the bespoke internal Data Agent described in January. An internal case study provides architectural lessons; it is not automatically a purchasable SKU.
Analytics applications
BI, notebook, and analytical workspaces place the agent inside an interface already used by business users or analysts. They may provide a more complete experience for Q&A, exploration, code, visualization, and reporting while relying on external platforms for semantics, policy, or execution. Follow the call chain instead of judging only the front end.
Data engineering and operations
These agents target metadata, quality, dbt/Dataform, pipelines, cost, and incident work. They may create code or production changes. Tests, approval, idempotency, and rollback matter more than a Q&A accuracy score.
Axis two: delivery model
| Model | Best fit | Responsibility retained by the buyer |
|---|---|---|
| Internal build | Unique data and workflows; strong platform team | Architecture, evaluation, security, operations, and iteration |
| Platform-native | Core data concentrated on one platform | Verify ecosystem lock-in, cross-source limits, and regional availability |
| Independent application | Cross-platform experience or specialized workflow | Clarify connectors, identity propagation, and data egress |
| Open-source framework | Controlled deployment, research, or deep customization | Production semantics, policy, maintenance, and support |
| Research project | New methods, benchmarks, and capability boundaries | Paper results are not an SLA or support contract |
A vendor can span several layers, and one product can offer several delivery models. These are not mutually exclusive market-share boxes.
Put every candidate back into one workflow
Use the same task card and ask:
- Which work does it own—Q&A, analysis, modeling, cross-source research, or engineering?
- Where does business meaning come from, who versions it, and how are conflicts clarified?
- Whose identity accesses data, and do retrieval, execution, cache, and export share one boundary?
- Which tools may run, can they write, who approves, and how does failure stop and recover?
- How is the result verified, and can material claims trace to data, queries, and definitions?
- On the enterprise task set, what are success, human takeover, p95 latency, and total cost?
- Is the capability GA, preview, planned, or an internal case study—and in which region and support contract?
These questions distinguish products more effectively than the underlying model name.
A dynamic market needs dated evidence
Names, regions, preview status, and feature boundaries move quickly. Dynamic examples in this article were checked on 2026-10-06; procurement should still recheck official documentation, pricing, licensing, data-processing terms, and release status. A year-old announcement or screenshot is not a current commitment.
A good vendor map does not identify one universal winner. It narrows candidates to the same job and system position, then compares them under the same tasks, identities, and budgets. Product labels may converge; responsibility boundaries should not.