> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vistazo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Chat

> Where charts get built, and how the agent reaches your data and your dashboards.

Chat is the authoring surface. You describe what you want to see, and the agent calls your data
sources, shapes the rows, and shows you the chart before anything is saved.

There are two places to do it, sharing one runtime.

| Surface                  | Scope                                                          |
| ------------------------ | -------------------------------------------------------------- |
| **Chats**                | Workspace-wide. Build anything, across any dashboard.          |
| The panel on a dashboard | Scoped to that dashboard. It already knows which one you mean. |

## Building a chart

Ask for a chart and you get a **preview** in the conversation, a real rendering of real rows rather
than a mockup. Ask for changes and each attempt arrives as a new preview. Earlier ones collapse to a
line with a link down to the current version, so the thread stays readable.

Nothing is saved until you say so. Press **Add to dashboard** on the preview you want.

What that press does differs by surface, and it is worth knowing which one you are on.

* **In the dashboard panel** it writes immediately. The chart lands on the dashboard you are looking at.
* **In Chats** it posts "Save this chart to a dashboard" as a turn, and the agent takes it from there.
  It will usually ask which dashboard first, and it may take a moment or commit several charts at once.

<Note>
  Building several charts at once is the efficient path. Ask for all of them, then add the ones you
  want.
</Note>

## What happens to a preview after you add it

The block in the conversation stops being a snapshot and becomes a **window onto the widget it
became**, reading from the dashboard's live data. Change the widget later and the conversation shows
the change.

It reports its own state rather than showing you something untrue:

| State                         | What you see                                              |
| ----------------------------- | --------------------------------------------------------- |
| Live                          | The current chart, and a link to the dashboard            |
| Data expired                  | The last snapshot, labelled, with **Refresh data**        |
| No access                     | The snapshot, labelled, with a **Request** button         |
| Access requested              | The snapshot, labelled, while your request is outstanding |
| Removed, or no longer a chart | The snapshot, labelled with what happened                 |

In every degraded state the last good rendering is still drawn and labelled, so the conversation stays
readable rather than filling with empty boxes.

## Mentioning things

Mentions are typed into the sentence rather than collected in a tray beside it, because where a
reference sits is part of the question. "What did @Bob change on @Global" is not the same question as
those two names in a list.

* **`@`** for dashboards and people, plus widgets when you are on a dashboard
* **`/`** for [skills](/skills/overview)

There are `@` and `/` buttons on the composer that type the character for you.

Mentioning a **person** makes them the subject of the question. It does not notify them, and nothing is
sent to anyone from a conversation. The one exception is the **Request** button on a chart window,
which does notify whoever can grant you access.

Mentioning a **dashboard or widget** hands the agent a pointer rather than a copy. It reads the object
with its own tools, which is why it can answer about charts it did not build.

<Tip>
  The same composer is used on the chat page, the dashboard panel, and discussion comments. In a
  discussion a `/skill` mention is a *reference*, a link to the skill, because no model reads a comment
  thread.
</Tip>

## Asking how Vistazo works

Vistazo AI can read this documentation, so "how do I connect Claude Code?" or "what does a viewer seat
let someone do?" are fair questions to put to it in the app. It answers from the published pages rather
than from memory, and links the page so you can read the rest.

It is not a data source, so it knows nothing about your own dashboards or numbers. Those are separate
questions and it answers them separately.

Viewer seats can ask too. Reading the docs costs nothing and needs no builder seat.

## When the agent asks first

Anything destructive or wide-reaching stops and asks. Removing a widget, archiving a dashboard,
removing a parameter, saving a skill, and changing or rolling back a library visualization other
dashboards use.

The question arrives as a card with tappable options, and **tapping the option is the confirmation**.
The check is server-side and keyed to the option you pressed, so typing "yes, go ahead" in prose
authorizes nothing. A confirmation covers the specific objects it named and is spent when used. It is
never a mode the rest of the conversation runs in.

## Runs survive the tab

A run is durable. Close the tab or reload mid-answer and it keeps going, and reopening the conversation
shows where it got to. Long conversations are compacted as they grow, so older turns are summarized
rather than dropped.

There is a cap on how many runs you can have going at once, and one live run per conversation. See
[Limits](/reference/limits).

## Chats are private

A chat belongs to the person who started it. Workspace admins do **not** get access to your
conversations. Unlike dashboards, there is no administrative override.

You can share one explicitly. Name people as viewers, open it to the workspace read-only, or create a
link. There is only ever one writer in a conversation, so sharing a chat never makes it collaborative.

Sharing and renaming are on the chat header, and also under its **Settings**. Starring, archiving and
**Download** are on the header. See [Permissions](/sharing/permissions).