An enterprise data agent is an AI-enabled analytics system that can translate a business question into a governed plan, discover relevant definitions and data, generate and execute queries through controlled tools, inspect results, perform analysis, create explanations or visualisations and cite the evidence used. It can shorten the path from question to decision, but it must not bypass semantic definitions, permissions, data quality or analytical review.

The reliable design combines a semantic layer, metadata and lineage, governed query tools, a stateful orchestration loop, deterministic validation, execution limits, evaluation and human escalation. Start with a bounded domain whose metrics are owned and whose answers can be checked. Measure resolved questions, decision time, correctness, adoption and total cost—not the number of prompts.

Why dashboards alone leave an analytics gap

Dashboards are excellent for recurring questions known in advance. Business decisions also create follow-up questions: why did renewal fall in one segment, which products caused margin variance, what changed after a campaign, and whether the pattern is statistically meaningful. These requests enter analyst queues, wait for clarification and often produce another static extract.

A data agent can explore this long tail interactively. It asks clarifying questions, finds relevant governed metrics, creates a query, checks the result and explains limitations. Analysts spend less time on repetitive retrieval and more on metric design, complex analysis, experimentation and decision support.

The agent does not fix a fragmented data estate. If revenue has four definitions, customer identifiers do not reconcile and ownership is absent, conversational access makes inconsistency easier to reach. Treat the agent as a product built on data foundations, not a substitute for them.

Define the data product and user decision

Select a user group, decision and domain. A sales leader may need pipeline, conversion and account risk; a supply-chain manager may need stock, lead time and fulfilment exceptions. Avoid a first release that promises every employee access to every dataset.

Interview users about the decisions they make, questions asked, current evidence, delays, workarounds and consequences of error. Capture representative questions ranging from simple lookup to comparison, diagnosis, forecasting and recommended next action. Mark which require specialist judgement.

Define a service contract: supported domains, freshness, expected response time, citation behaviour, uncertainty, access controls and escalation. Explain what the agent cannot answer. Trust grows when boundaries are visible.

Build a governed semantic foundation

Business terms must resolve to controlled definitions. Define metrics, dimensions, entities, filters, time logic, currencies, fiscal calendars and ownership. A semantic layer can expose reusable measures such as net revenue, active customer or on-time delivery so the model does not reconstruct logic from raw tables.

Store synonyms, descriptions and examples because users and systems speak differently. “Bookings” may mean signed contract value to one team and invoiced order value to another. The agent should ask when intent could map to several valid measures.

Version definitions and record effective dates. Historical analysis may require the definition valid at the time, while management reporting may restate history under the current definition. Make that choice explicit. Every important answer should expose the metric and filters applied.

Metadata, lineage and data discovery

Create a catalogue containing datasets, fields, owners, sensitivity, quality status, freshness, lineage and usage. Technical schemas alone are insufficient. The agent needs to know that one table is an intermediate load, another is certified and a third excludes a geography.

Use lineage to explain where a result came from and assess impact when a source changes. Connect reports and metrics to upstream transformations. When the agent cites a result, users should be able to inspect the approved definition and source path.

Rank sources by authority. Certified domain models should outrank ad hoc exports. If two governed sources conflict, the agent should surface the discrepancy and owner rather than silently choose the convenient answer.

Reference architecture

A robust data agent has an experience layer, identity, orchestrator, model gateway, semantic and metadata retrieval, query-planning tools, governed compute, analytical tools, visualisation, evaluation, observability and feedback. Keep the language model separate from data execution.

The orchestrator classifies the request, resolves identity and domain, retrieves definitions, forms a plan, validates it, invokes a query tool, inspects the result and decides whether to refine, explain or escalate. Limits on iterations, scan volume, duration and spend prevent runaway exploration.

Expose narrow tools: list certified metrics, inspect a model, preview a query plan, run a read-only query, calculate a statistical test or create a chart. A general shell or unrestricted warehouse credential is unnecessary for most analytics questions.

From a question to a verified answer

Clarify

Resolve ambiguous metric, population, time range, comparison and intended decision. Ask one concise question when different interpretations could materially change the result.

Plan

Identify the approved metric, dimensions, datasets, joins, filters, grain and calculations. Show the plan for high-impact or expensive requests before execution.

Validate

Check schemas, permissions, sensitive fields, join cardinality, allowed functions, estimated scan and policy. Reject unbounded or cross-domain queries that exceed the user’s authority.

Execute

Run through a read-only service identity or policy-aware query layer. Apply timeouts, row limits, cost limits and caching. Record the exact query and data version.

Inspect

Test completeness, duplicates, unexpected nulls, totals, outliers and plausible ranges. Compare with trusted aggregates when available. A syntactically valid query can still answer the wrong question.

Communicate

Lead with the answer, then show evidence, definition, period, filters, caveats and links. Use a visual only when it clarifies comparison, trend or distribution. Separate observed facts from interpretation and recommendation.

Text-to-SQL requires more than SQL generation

Text-to-SQL quality depends on schema complexity, semantics and context. Restrict generation to curated models or views. Supply relevant schema and examples rather than the whole warehouse. Prefer semantic APIs for common metrics and SQL for controlled exploration.

Validate joins at the expected grain. Joining orders to order items and payments can multiply revenue. Check primary keys, many-to-many relationships and aggregation order. Encode known join paths so the model does not infer them from similar names.

Parse generated SQL before execution. Enforce read-only statements, approved functions, dataset allow-lists, partition filters, row and byte limits. Run a dry plan where the warehouse supports it. Never rely on an instruction such as “do not modify data” as the only control.

Return query evidence to the agent: columns, row count, execution statistics, warnings and sample shape. The model can revise a failed query, but repeated or expensive attempts should stop and escalate.

Data quality as part of the answer

Attach quality rules and status to data products. Freshness, completeness, uniqueness, validity and reconciliation may have different thresholds by use case. A delayed marketing feed might be acceptable for a weekly review but not for live budget allocation.

The answer should communicate material quality limitations. If a region’s data is incomplete, calculate only when policy allows and label the exclusion. Do not hide warnings in a technical appendix after presenting a confident recommendation.

Use agent interactions to improve the estate. Unanswered questions, repeated manual joins and disputed metrics reveal missing data products. Route them to owners with frequency and business impact.

Security and privacy

Use the requesting person’s identity and entitlements. Row-, column- and object-level controls must be enforced by the data platform or a trusted policy layer, not inferred by the model. A user who cannot open salary data in BI must not retrieve it through natural language.

Minimise result data sent to the model. Aggregate inside governed compute and pass only the fields needed for explanation. Mask direct identifiers, protect small cohorts and apply export restrictions. Define retention and regional processing for prompts, results and logs.

Defend against prompt injection in metadata, documents and free-text fields. Retrieved content cannot change system policy or grant tools. Keep instructions separated from data, label untrusted content and restrict agent actions. Test cross-tenant and inference attacks.

Audit who asked, what definition and data were accessed, the query executed, output delivered and any export or share action. Protect the audit store itself and align retention with investigation and privacy needs.

Evaluation framework

Build a benchmark from real user questions with expected definitions, filters, acceptable queries, answer facts and escalation conditions. Include ambiguity, unavailable data, conflicting metrics, complex grain, sensitive fields and adversarial content.

Score each layer: intent resolution, semantic selection, source choice, SQL validity, result correctness, analytical reasoning, citation, uncertainty, policy compliance and communication. An attractive narrative cannot compensate for a wrong metric.

Use deterministic checks for exact totals and policy, specialist review for analytical quality, and user evaluation for usefulness. Track prohibited failures separately because an average score can hide one serious disclosure.

Run regression tests for changes to models, prompts, semantic definitions, transformations and tools. In production, sample conversations, monitor corrections and compare important answers with certified reports. Provide a simple way to challenge an answer.

Human review and decision accountability

Not every analysis should be automated. Require analyst or domain-owner review for executive reporting, external disclosure, regulated decisions, forecasts with material commitment and questions outside validated domains. The agent should package the query, evidence and caveats for efficient review.

Make responsibility visible. The agent supplies analysis; the business owner makes the decision. If the system recommends an action, define who can approve it and what record is retained. Do not let conversational convenience erase decision rights.

Reviewers need time and expertise. If every answer requires reconstruction, the system has not created self-service. Improve definitions, evidence and evaluation until routine cases can be trusted within the agreed service boundary.

Visualisation and narrative

Choose charts by analytical relationship: line for trends, bars for category comparison, scatter for association and distributions for variability. Avoid decorative dashboards and truncated axes that exaggerate change. Include units, population, period and source.

Generate narrative from computed results rather than letting the model invent numbers. Provide structured values and derived comparisons to the explanation step. Mark correlations as correlations and distinguish observed data from causal claims.

Offer drill-down links and downloadable governed data according to permission. A decision-maker should be able to inspect the result without reading raw SQL, while an analyst can reproduce it.

Production operations

Monitor question volume, resolved rate, escalation, correction, query failure, latency, scan cost, model cost, freshness warnings, policy denials and user satisfaction. Segment by domain and question type. A global average hides weak areas.

Define service objectives and fallback. If the model or warehouse is unavailable, the agent may direct users to certified dashboards or create an analyst ticket. Version models, prompts, semantic assets and tools so incidents can be investigated.

Set an incident process for wrong high-impact answers and disclosures. Contain access, preserve evidence, identify affected users, correct decisions where possible and add benchmark cases. Analytical reliability needs operational ownership.

Adoption and change management

Launch with a defined community and real decisions. Train users to ask clear questions, inspect definitions, understand caveats and provide feedback. Teach that natural language is an interface to governed analytics, not an oracle.

Work with analysts rather than positioning the agent as their replacement. They should own metric quality, advanced methods, evaluation and data-product improvement. The agent expands reach while escalating novel or high-consequence questions.

Publish supported examples and known limitations. Office hours and answer reviews reveal product gaps. Celebrate decisions improved, not chat volume.

Economics and ROI

Baseline time to answer, analyst effort, decision delay, repeated requests, dashboard creation and error cost. Calculate benefits from resolved questions, reduced queue, faster action and wider governed access. Subtract integration, modelling, catalogue, compute, model, evaluation, review and support.

Track unit economics per resolved question or decision. A cheap answer that is wrong or unused has negative value. Cache repeated governed results, route simple retrieval to lower-cost methods and limit expensive exploration.

Many benefits arise from the foundation. Cleaning definitions and access can improve BI and planning beyond the agent. Attribute value honestly while recognising shared capability.

A phased roadmap

Phase 1: domain readiness

Select a decision domain, name owners, baseline questions, curate metrics and data products, define access and assemble evaluation cases.

Phase 2: read-only analyst copilot

Answer bounded questions with citations and show generated queries. Require analyst review, capture corrections and improve semantic coverage.

Phase 3: governed self-service

Open validated question classes to business users, enforce permissions, automate regression evaluation and route exceptions to analysts.

Phase 4: decision workflows

Connect approved analysis to planning or operational workflows with explicit review and action controls. Expand domains only when ownership and evaluation are ready.

Scenario: a commercial-performance data agent

A consumer-products company spends days reconciling weekly sales questions across ecommerce, retail and distributor data. Revenue, gross sales and net sales are used inconsistently. Analysts repeatedly rebuild channel comparisons while leaders work from different spreadsheets.

The first release covers net sales, units, returns and promotional discount for two countries. Finance owns definitions; data engineering publishes certified models and quality tests. The agent can compare periods and channels, identify contributors and create charts, but it cannot forecast or expose customer-level data.

A benchmark includes late distributor files, currency changes, returns after period close, sparse product launches and ambiguous “growth” questions. The agent asks whether growth means value or units and cites the selected metric. If freshness fails, it explains the missing source and opens an analyst request.

After adoption, routine turnaround falls from two days to minutes while analysts review a sampled set and focus on pricing and forecast work. Expansion to margin waits until cost allocation is governed. The boundary grows with semantic readiness.

Build, buy or partner

Buy when an analytics platform already provides governed conversational capabilities aligned with your stack. Build when proprietary metrics, workflows, user experience or multi-platform orchestration create value. Most enterprises combine vendor models and data platforms with company-owned semantic assets, controls and evaluation.

Use a data and AI partner when modelling, platform engineering, retrieval, application experience, security and change management must progress together. A credible engagement begins with one domain and leaves reusable definitions, tests, governance and trained owners.

Project Supply can assess data readiness, design the architecture, build semantic and governed query layers, implement the agent experience and evaluation, and launch a measured production pilot across data engineering, AI, cloud, quality and cybersecurity.

How to choose a data-agent partner

Ask the provider to demonstrate how it prevents a wrong metric, unsafe query and unsupported conclusion. Review its approach to semantics, lineage, identity, cost limits, evaluation and analyst ownership before model selection.

Use a representative question set and anonymised schema in a paid discovery. Evaluate clarification, query grain, evidence, caveats and failure handling. Confirm client ownership of metrics, code, tests, accounts and logs.

Structure delivery around domain readiness, benchmark performance, controlled launch and adoption outcomes—not a chatbot demonstration.