How the analytics workflow is changing, and how to get ready

We used to build a dashboard, teach people where to find it, and try to anticipate every question they might ask. Agents give people a way to keep investigating when they reach the edge of what we built.

Start by capturing business definitions and analytical context in a form the business owns and can use across tools. Then choose a focussed, high value domain and prepare the related questions and metrics for people and agents to analyze together.

The question can lead the workflow

I spent years helping people navigate dashboards. We built landing pages, wrote explanations, and trained users on which report to open. Even someone who knew their own dashboard well could struggle when a question moved into another team's data.

Take a renewal review. An account manager sees recurring revenue fall and uses a waterfall chart to identify which customers drove the decline. To figure out what happened, they need product usage, renewal terms, and account notes. That can mean exporting a list and asking colleagues to help piece together records from several systems.

With an agent, the account manager could start by asking what changed. The agent can bring up the waterfall and query an approved product usage source as the investigation moves to individual accounts. The visual still matters. It shows which movements are large enough to warrant a closer look.

If churned customers used the product less, the agent can compare them with customers who renewed and surface dated account notes. The account manager can then weigh whether usage helps explain the departures and which customers might need attention now.

Put the business's knowledge where it can be reused

An agent needs the knowledge we used to supply through training and analyst intervention. Which revenue measure fits the question? Does a canceled product count as a lost customer? Can one customer have several product workspaces?

Trace each answer to the data model and definition the domain owner trusts. Record when to use it and which exceptions could change the interpretation. In a renewal review, falling usage might mean a customer is disengaging or that activity moved to another workspace. Keep the account mapping needed to check that alongside the explanation and add the case to your tests.

I recommend keeping models in dbt and the context explaining how to use them in the client's own project. Link to the authoritative metric definition so a change can reach every tool that uses it. A formal semantic-layer product may help if several tools need governed metric queries. For a smaller workflow, tested models and readable context may be enough. Compare the options against the questions, operating effort, cost, and response time you actually have.

Anthropic found that generating definitions from raw tables and query logs carried existing ambiguities into its own analytics system. Its team recommends having a person own each definition even when AI helps write the documentation. Anthropic's self-service analytics write-up

Give the team enough AI literacy to choose what to build

Take a real question into a product evaluation. Ask to see which source the agent chose and what it executed. Change the wording, remove a required field, and try a user with narrower access. Ask how your team would find a wrong answer later and fix the underlying cause.

Then decide what you want to own. You might buy the interface and maintain the context, or connect an existing AI application to governed data. A coding agent can help build models, visuals, and tests. Your team still needs to review those changes and maintain the software. In my Tableau Dashboard Q&A tests, the work needed to adapt existing dashboards mattered as much as the conversational interface. My Tableau Dashboard Q&A testing

Build and test one business domain before expanding

Choose a focussed, high value domain with an owner and people who can verify its answers. For ARR and revenue analytics, map the questions about ARR movements, retention, expansion, contraction, and churn. Walk through how the team analyzes those questions today and keep the reports it trusts available during the pilot. Test a representative range of analyses and follow-up questions, comparing the answers with approved sources and checking whether people can use them in their work.

Build expert-checked cases for ambiguous questions, missing evidence, restricted data, and false premises. Hold some cases back from tuning and test permissions with the roles people actually use. For each answer, check the source, calculation, and explanation. Record failures and rerun the affected cases after a fix. Once people start using the system, sample apparently successful responses too. A plausible answer can be wrong without anyone flagging it.

Before adding another domain, have someone on the client team update a definition, diagnose a failed refresh, and take a new question through the process. Ask them to find the context and tests they'd need if the interface changed. What they struggle to find or fix tells you where to spend the next round of effort.