Agentic analytics

Most data teams we talk to have tried a chat-with-your-data prototype. The demo works on three clean tables. In front of real users it stalls, and rarely because of the model:

• -Users get a number but cannot see where it comes from, so they ask the data team to check it.
• -The same metric has several definitions, and the agent picks one without saying which.
• -Security will not open the warehouse to an agent that ignores the access rules already in place.
• -Each team builds its own prototype, and the next team starts from zero.

• Context and evaluation go together. Context tells the agent what the data means; evaluation measures whether its answers are right. We build both from day one.
• We extend your governance to agents instead of rebuilding it. The agent queries with the user's identity, so the permissions, classifications and audit you already have apply to it as they do to a BI tool.
• Trust comes from what users can check. Every answer opens down to the SQL, the tables, the filters and the assumptions. Numbers come from the warehouse, never from the model.
• Data quality is part of the answer. When a source failed its tests or is out of date, the agent says so.
• One platform, many domains. Each team works in its own space with its own data and context, and what one team builds can be shared with the others.

1. 01

   Context layer

   Table and column descriptions, metric definitions, profiling, the queries your analysts already run, and the documents that explain the numbers. For those who don't know it, the semantic layer is the part where 'revenue' or 'active customer' is defined once, in code (dbt or your warehouse's semantic views), so every tool computes it the same way.

2. 02

   Evaluation

   For each domain, the questions its users ask, with the expected answers. The test set runs on every change to the context or the prompts, and a sample of live questions is scored in production.

3. 03

   Governance & guardrails

   The user's identity goes down to the warehouse, so existing row and column rules and audit apply. Guardrails cover sensitive data and out-of-scope questions. Outside the defined metrics, the agent writes SQL on approved tables only and shows the query.

4. 04

   Observability & data quality

   Every question, query, cost and score is traced. Quality checks and freshness are visible in the answers, and the data team sees which questions fail, which data is missing and what each team asks most.

5. 05

   Domains & shared artefacts

   One workspace per team, isolated by your access rules. Answers become artefacts (reports, charts, saved analyses) that are versioned and shared, and a team can query another team's agent under controlled access.

• -A 2-hour discovery on your warehouse, your metric definitions and one candidate domain.
• -A 2-week proof of concept on that domain, measured on its own test set.
• -The domain in production, then the next one on the same platform, reusing what the first one built.