Choosing the right AI workflow in Lightdash

Lightdash exposes multiple AI surfaces, and the right one depends on who is asking, what they are trying to do, and how much governance you need. This guide helps you decide which workflow to use for which task, and how they fit together. The common foundation across every surface is the Lightdash semantic layer: governed metrics, joins, descriptions, permissions, project context, verified answers, and evaluations. Investing there pays off no matter which AI surface a user picks.

​

Quick decision tree

Pick the first item that matches what you are trying to do:

• Want business users to ask governed questions in natural language? Use Lightdash AI agents in the app.
• Want the answer to happen in a shared team conversation? Use Lightdash AI agents in Slack.
• Want Claude, Cursor, Codex, ChatGPT, or a custom agent to query Lightdash? Use Lightdash Data MCP.
• Want your AI coding tool to understand Lightdash docs and YAML syntax? Use the Lightdash Docs MCP together with agent skills.
• Want to create or edit saved charts and dashboards interactively? Use AI agent content editing or MCP content tools where enabled. (Beta)
• Want bulk or reviewable dashboard edits? Use dashboards as code with lightdash download and lightdash upload.
• Want to change a core metric, dimension, join, model, or description? Edit dbt / Lightdash YAML, review through Git, and validate before deploy — or use AI writeback where enabled. (Beta)
• Did the agent get something wrong? Improve descriptions, AI hints, project context, verified answers, evaluations, or Reviews findings. (Reviews is Beta.)

​

Comparison

​

Use AI agents for governed self-serve

Lightdash AI agents in the app and in Slack are the managed experience for business users. They ask questions in natural language, and the agent answers using your saved dashboards, metrics, dimensions, joins, descriptions, and visualizations — all defined in the Lightdash semantic layer. Key points:

• Agents respect project permissions, space access, and user attributes, so users only see data they are allowed to see.
• Scope each agent to a subset of models and tags so it stays focused on a domain instead of the whole project.
• Use Slack when the answer belongs in a team conversation; use the in-app experience when the user wants to iterate on charts and threads.
• Reinforce the agent with descriptions, AI hints, verified answers, and evaluations rather than expanding scope.

See Using AI agents, Data access, and Best practices.

​

Use MCP when the user wants to stay in another AI tool

The Lightdash Data MCP server lets external AI clients — Claude, Cursor, Codex, ChatGPT, or a custom agent — talk to Lightdash. It is best for power users, developers, and external AI clients, not as the primary end-user product for business teams. MCP supports:

• OAuth login with the user’s Lightdash identity.
• The same permissions and user attributes as the rest of Lightdash.
• Model and metric discovery, metric queries, and content discovery (dashboards, charts, saved queries).
• Reusing agent context, so an MCP client can benefit from the same tags, hints, and verified answers as a Lightdash AI agent.

MCP clients are not the same as the managed Lightdash AI agent UI. They give an external tool a governed pipe into Lightdash, but the UX, memory, sharing, and moderation live in whatever AI client the user chose. See Lightdash MCP, AI router, and the AI overview for how the pieces fit.

​

Use Git and YAML for durable definitions

Changes to metrics, dimensions, joins, model SQL, business logic, and descriptions should live in dbt or Lightdash YAML. Route those changes through:

• Git review — PRs, code owners, and diffs.
• Previews — validate on a preview project before merging.
• Validation — lightdash validate, dbt tests, and CI checks.
• Dashboards as code — use lightdash download and lightdash upload for bulk or reviewable dashboard changes.
• AI writeback (Beta) — let an agent propose YAML changes, but keep them behind the same review and validation gates.

Ad-hoc agent edits are great for exploration; durable definitions belong in version control.

​

Use feedback loops to improve agent quality

If an agent gets something wrong, resist the urge to widen its scope. Instead, close the loop:

• Improve descriptions and AI hints on the underlying models, metrics, and dimensions.
• Add project context and refine the agent’s tag scope.
• Save good responses as verified answers so the agent reuses them.
• Add evaluations to catch regressions when you change context or prompts.
• Use thumbs up / thumbs down and Reviews (Beta) findings to prioritize fixes.
• If routine questions keep needing SQL, fix the semantic layer, not the prompt.

​

Important cautions

• MCP is a power-user / developer surface. It is not the main end-user product for business teams — direct most business users to Lightdash AI agents in the app or Slack.
• Raw SQL and the SQL Runner should be an escape hatch. If routine questions require SQL, improve the semantic layer instead of relying on the agent to write SQL.
• Keep writeback and self-improvement controlled. AI writeback, content editing, and Reviews are Beta — use previews, PR review, and validation before anything reaches production.
• Broad agents usually perform worse than focused ones. Prefer several domain-specific agents scoped to a small set of tags and models over one project-wide agent.
• Do not upload sensitive context as knowledge documents unless the entire agent audience is allowed to see it. Agent knowledge is visible to everyone who can use the agent.

​

Related docs

• Using AI with Lightdash (overview)
• AI agents
• Using AI agents
• Getting started with AI agents
• Data access
• Best practices
• AI router
• Content tools (Beta)
• AI writeback (Beta)
• Reviews (Beta)
• Verified answers
• Evaluations
• Lightdash MCP
• Slack integration
• Agent skills
• Dashboards as code
• Editing dashboards with agents