The manual workflow in the previous docs (build a Metric Block, build an Explore, attach it to a report) is only half the story. Because Content is enabled alongside AI agents, an agent can do the same work for you: find the right metrics view, query it, define a new one, and build a chart, all from a chat. The chart renders inline in the conversation, and the agent can email or Slack it when you ask. And an Agent Step inside a report can do it unattended, on a schedule.
There are two ways this plays out, and they answer two different needs.
How agents see your Content
Metric Blocks are workspace-wide, so any agent in the workspace can see and use them. The agent doesn't write SQL from scratch against your tables. It works through the same metric definitions you do, which keeps its answers consistent with everyone else's.
These agent tools are available when the Content permission is on:
| Tool | What it does |
|---|---|
list_metrics_views |
Lists every Metric Block the agent can access, with their measures and dimensions. |
query_metrics |
Pulls numbers from a Metric Block. The agent picks measures, dimensions, filters, a time range, and a grain, and the SQL is generated and run for it. |
save_metrics_view |
Defines a new Metric Block: a model query plus measures, dimensions, an optional time grain, parameters, and thresholds. |
create_explore_block |
Builds a saved Explore: a query against a Metric Block with a chart. The chart_type accepts bar, lines, area, and pie (scatter is also accepted but currently renders as a bar chart). The chart renders inline in the chat as soon as it's created. |
export_explore |
Renders a saved Explore to a file (PNG, PDF, CSV, or XLSX) and returns its URL, so the agent can attach the chart image to an email or Slack message. |
Because measures and dimensions have names, a question like "how many new cars did we sell in March, by make" turns into a single call: pick the new_cars_sold measure, group by car_make, set the time range. The numbers come back the same way every time.
Metrics first, raw SQL as the fallback
An agent with database access can also write raw SQL — but with Content on, that's not its first move. For any data question, the agent follows a built-in workflow (a skill named AnswerADataQuestion): check what the semantic layer already defines with list_metrics_views, answer through query_metrics when a Metric Block covers the question, and fall back to raw SQL only when nothing does. If it reaches for raw SQL while matching Metric Blocks exist, the platform reminds it to check the semantic layer first. And when raw SQL genuinely is the right tool — a one-off exploration, a table nobody has modeled yet — the agent is instructed to say so in its answer, so an ad-hoc number never masquerades as a governed one.
In a chat session
Open a chat with an agent and just ask. A few things you can say:
- "What metrics views do we have?" The agent calls
list_metrics_viewsand shows you what's available, with the measures and dimensions on each. - "Total revenue last 30 days by car make." The agent calls
query_metricsagainst the right Metric Block and gives you the numbers. - "Build a metrics view for the orders table." The agent inspects the table, drafts measures and dimensions, and calls
save_metrics_view. It lands as a draft for you to review. - "Make a bar chart of revenue by month and save it." The agent calls
create_explore_blockand the chart renders right inside the chat, plus a link to open the saved Explore in Content, tweak it, or drop it into a report. - "Email that chart to the team" / "send it to #revenue on Slack." The agent renders the Explore to a PNG with
export_exploreand attaches it to the email or Slack message.
Two things worth knowing:
- AI-created Metric Blocks start as drafts. Anything the agent saves with
save_metrics_viewshows up in Content with the yellow "needs review" banner. Review it and click Approve before it's used in production. See the approval workflow for details. - The agent verifies its own work. After creating a Metric Block, a well-configured agent runs
query_metricsagainst it to confirm the measures return sensible numbers before handing it back to you.
The chart shows up in the chat
When the agent builds an Explore, the chart shows up inline, right under the agent's message. You don't have to open anything to see it. It's the real Explore, not a screenshot, so it matches what you'd get at its Content page. Click through and you can adjust the time range, switch the chart type, or add a dimension.
Sending a chart to email or Slack
Ask the agent to send an Explore somewhere and it renders the chart to a file first with export_explore (PNG, PDF, CSV, or XLSX), then attaches that file to the message. So "build a closed-tickets-per-day chart and Slack it to #support" is one request: the agent queries the metric, builds the chart, renders it, and sends it.
On a schedule
The same tools run unattended when you put an Agent Step inside a report. Instead of asking in chat, you write the instruction once, and the report runs it on whatever schedule you set.
This is the difference from a plain Explore attachment:
- An Explore attachment re-runs a fixed query and renders the same chart every time. Great when the question never changes.
- An Agent Step runs an instruction. It can pick the right metrics view, decide the time range, query the numbers, and build or refresh a chart, then write up what it found. Great when the work needs a little judgement each run.
A typical setup:
The Agent Step block has its own page with the full set of options. See Agent Step Block.
Where the number came from
When an answer drew on the semantic layer — the agent queried a Metric Block with query_metrics, or built an Explore from one — it ends with a small source footer:
— Source: semantic layer (revenue)
The footer names the Metric Block the answer was computed from (or just "semantic layer" when several were involved), so anyone reading the answer — in a chat, or in a report an Agent Step produced — can tell a governed number from an ad-hoc one at a glance. It's added by the platform, not written by the agent: it's derived from the tool calls that actually ran, so the agent can't claim a source it didn't use.
If the agent had to answer from raw SQL instead — a question no Metric Block covers yet — there's no semantic-layer footer to earn. The agent is instructed to flag that in the answer itself (something like "computed directly from raw_events, not a defined metric — verify before relying on it"). That's your cue to double-check the number, or to ask the agent for a Metric Block so the next answer is governed.
When to use which
Related
- Content & Metric Blocks covers building and approving the metrics the agent reads from.
- Building Charts with Explore covers the chart the agent creates with
create_explore_block. - Agent Tools lists the full tool set, including the metrics tools.
- Agent Step Block covers running an agent inside a scheduled report.