Config Studio
Point Config Studio at a database and it reads the schema and writes the config the agent answers from.
Config Studio is how a config gets written without anyone hand-authoring YAML. It inspects your tables, columns, and relationships, then drafts the whole thing: which tables matter, how they join, and what your team's vocabulary maps to.
Generate
Select a connection and start a generation. The run has three phases:
Profile
It introspects the schema (tables, columns, types, keys, and relationships), and samples values to understand what each column actually holds.
Adjudicate
It decides what belongs in the config: which tables are worth exposing, which joins are real, and which columns are the metrics people will ask for.
Emit
It writes the YAML and runs it through a verification gate. The gate is fail-closed: a config that does not verify is not offered to you.
Nothing is saved until you press Save. The draft is yours to read first, in plain language rather than raw YAML.
Refine
A config is not finished when it is generated. Refine improves an existing one from real evidence: the queries that came back wrong, and the thumbs-down feedback on answers.
Point it at a bad answer and it revises the config: a new version each time, so you can compare and roll back.
Custom tools
Beyond tables and metrics, Config Studio can carry tools the agent may call:
| Kind | What it is |
|---|---|
sql_macro | A named, parameterised query the agent can invoke |
pipeline | A multi-step sequence over your data |
python | Sandboxed Python for logic SQL cannot express |
Tools follow the same rule as configs: nothing publishes unless it ran. You try it, see the real output, and then it is available.
Re-run after schema changes
The agent plans from the config, not from a live schema read. When you add or rename tables, re-run Config Studio: otherwise it is planning against a database that no longer exists in that shape.