> ## Documentation Index
> Fetch the complete documentation index at: https://agno-v2-studio-tools-doc.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# What is Dash?

> A self-learning data agent that grounds answers in your business context.

Every company with 30+ people should have an internal data agent. Most AI-forward companies are already building one in-house:

* OpenAI: [Inside our in-house data agent](https://openai.com/index/inside-our-in-house-data-agent/)
* Vercel: [d0](https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools)
* Uber: [QueryGPT](https://www.uber.com/gb/en/blog/query-gpt/)
* LinkedIn: [SQLBot](https://www.linkedin.com/blog/engineering/ai/practical-text-to-sql-for-data-analytics)
* Salesforce: [Horizon Agent](https://www.salesforce.com/blog/text-to-sql-agent/)

Clone Dash and you have the same thing, in your cloud, in an afternoon.

## The system

Dash is multi-agent system with hard-enforced boundaries:

| Member       | Schema access                        | Tools                                                                                     |
| ------------ | ------------------------------------ | ----------------------------------------------------------------------------------------- |
| **Analyst**  | `public` (read-only)                 | `SQLTools(read_only=True)`, `introspect_schema`, `save_validated_query`, `ReasoningTools` |
| **Engineer** | `public` (read), `dash` (read+write) | `SQLTools` (full), `introspect_schema`, `update_knowledge`, `ReasoningTools`              |
| **Leader**   | none directly                        | Routes the request, optional `SlackTools` for posting back                                |

These boundaries are enforced by the database engine itself. The Analyst's connection physically cannot write. The Engineer's writes physically cannot touch `public`. The boundary holds even if the model goes off-script.

## Six layers of context

Every Dash query is grounded in six layers:

| Layer                       | Source                      |
| --------------------------- | --------------------------- |
| **Validated queries**       | `knowledge/queries/*.sql`   |
| **Business rules**          | `knowledge/business/*.json` |
| **Table metadata**          | `knowledge/tables/*.json`   |
| **Institutional knowledge** | MCP (optional)              |
| **Learnings**               | Dash's `LearningMachine`    |
| **Runtime context**         | `introspect_schema` tool    |

The first four are curated and stored in pgvector. Learnings are captured automatically as Dash works. Runtime context is fetched live.

## How Dash works

Every question runs through the same loop:

1. **Retrieve.** Dash pulls the matching knowledge layers and any prior learnings.
2. **Generate.** The Analyst writes SQL grounded in what came back, then runs it read-only against `public`.
3. **Answer.** Dash composes a response with the numbers and a citation to the SQL it ran.
4. **Learn.** Errors get diagnosed and the fix is saved as a learning so the same error can't recur.
5. **Materialize.** When a question repeats, the Leader asks the Engineer to build a view in the `dash` schema. The next ask hits the view directly.

After a few weeks of real use, the same errors stop happening, the right shapes sit in the knowledge stores, and the `dash` schema fills with views your team uses without writing a migration.

## Next

Setup takes about five minutes and starts you on a synthetic SaaS dataset (\~900 customers, two years of data) so you have something concrete to ask.

[Setup →](/tutorials/dash/setup)