Stop Shipping Chatbots as Analysts: The Data Agent Workflow

TL;DR

A chatbot with a warehouse plugin is still a conversation. You bring the context, you catch the bad join, and you start over when the thread gets long. A data agent is a production worker: it can reach the right systems, it knows how your team actually measures things, and it follows instructions you would give a senior analyst. I use Access + Context + Instructions. All three have to be present or the "agent" is theater.

---

Most analytics teams I work with already have ChatGPT or Claude open in another tab. That is useful. It is also not an agent.

In workshops the same pattern shows up: someone pastes a schema, asks for revenue, gets fluent SQL, and ships a number finance will not stand behind. The model did not fail at language. It failed at the job. The job is to do analytics work in your environment with bounded authority — pull from the warehouse, respect metric definitions, follow a playbook, and hand back something a stakeholder can use.

If you lead an analytics function, the test is simple: would you let this thing run a weekly sanity check on its own, with the same rules you would give a new analyst? If not, you have a chatbot.

The Problem: Why Chatbots and Directory Listings Are Not Agents

Think of a chatbot as a conversation. You remember what "active user" means this quarter. You notice when the grain is wrong. When the thread gets long, the model forgets, and you start over. That is fine for exploration. It is a terrible production process.

A tools-directory listing is the other trap. I run a directory of analytics tools and MCP servers. That catalog is for discovery: what exists, what it connects to, who it is for. A listing is not an implementation. Buying a copilot does not give you a data agent. The product can generate SQL. It cannot know that finance excludes trial accounts, that the orders table is late by a day, or that your team never uses the marketing mart for revenue. Those rules live in your stack and your team. The directory will not install them for you.

Use the directory to choose interfaces. Use an agent when you need those interfaces to behave like your analysts.

The Solution: Access + Context + Instructions

This is the same framing I teach in workshops and use in delivery. Follow it as a three-layer workflow. Skip a layer and the output looks smart while being operationally wrong.

1. Access (The Path to the Work)

The model needs a real path to data and tools: warehouse, BI, git, docs, ticketing. MCP servers, APIs, and governed query paths are how you do that without dumping CSVs into a prompt.

• Goal: The agent can reach the systems a senior analyst would open, with the same boundaries
• Action: Wire MCP or API access to the warehouse and the repos that hold definitions — not a one-off paste of schema
• Outcome: The model can query and retrieve. It still does not know which tables are allowed to answer "revenue"

Access without the other two is a security and quality problem. Reach is not judgment.

2. Context (The Desk, Not the Pile)

Context is the missing competitive layer. Table relationships, metric definitions, grain, late-arriving facts, who owns what. I have written about this as data, business, and usage context. Without it you get fluent SQL that finance will send back.

• Goal: The agent measures the business the way the team already does
• Action: Maintain metadata the same way you maintain dbt models — not a one-time paste into a chat
• Outcome: Queries respect grain, exclusions, and ownership instead of improvising a new metric each session

Context is not "whatever was in the last chat." It is memory you control.

3. Instructions (How the Work Gets Done)

Instructions are the playbook: investigation order, QA checks, "never use this table for that question," output format, when to stop and ask a human. In Cursor that looks like rules and skills. In a deployed agent it looks like a playbook the system actually follows.

• Goal: The agent does the work in the order a senior analyst would, and stops when a human should decide
• Action: Version the playbook like code — QA before storytelling, known-bad joins documented, output format explicit
• Outcome: Access + context stop improvising. Analysts do not improvise your close process. Neither should the agent

What This Looks Like in Practice

A useful first agent is boring on purpose. Three I keep coming back to:

1. SQL QA before anyone presents a number — environment-aware checks against the definitions finance already uses
2. A repeatable EDA pass — the agent already knows the schema, so you are not re-explaining tables every Monday
3. A weekly "what changed" brief — pipeline diffs that cite the same metric rules, not a fresh interpretation each time

None of those require a sci-fi autonomous researcher. They require the three layers above, wired to your warehouse and your definitions. Read the companion pieces on the three elements a copilot needs and context layers, then the analytics workflow playbook if you want the hands-on version.

If your team is stuck between "we have ChatGPT" and "we have a reliable analytics agent," that gap is the work. Stop fighting another chat window and start orchestrating the three layers.

---

Explore the Agentic Workflow Workshops or the variety of Service packages.