Skip to main content
The Data Model is the foundation of your agent’s knowledge — every other entry point in this section (System Prompts, Golden Assets, Skills, Knowledge Base, User Memory, and MCP) builds on top of it. It controls two things: what data the agent can access, and what context it has to interpret that data correctly. A well-configured data model is the difference between an agent that writes plausible SQL and one that writes the right SQL for your business. See The Workspace Data Model for the page itself.

​
Selecting tables and columns

Not every table in your database is relevant to every question your agent will answer. Narrowing the schema down to what matters reduces ambiguity, improves query accuracy, and avoids the agent making inferences across data it shouldn’t touch.
Table selection panel showing checked and unchecked tables
From the Tables tab on your workspace’s Data Model page, select the tables you want to expose to the agent. By default all tables from the workspace’s connection are listed — check only the ones that are relevant to the use case you’re building for. Within each table, you can further control which columns are included. Expand a table to see its columns, then uncheck any that are unnecessary, sensitive, or likely to confuse the agent. The column list shows the name, data type, and any description you’ve added.
Less is more here. An agent scoped to 5 relevant tables with clear descriptions will significantly outperform one with access to 50 tables it has to guess about.

​
Adding table and column descriptions

Descriptions are how you encode institutional knowledge directly into the schema. The agent reads these when generating SQL — they’re the mechanism for telling it what your data actually means, not just what it’s called.
Column list showing descriptions and selectable toggles
Table descriptions provide context for the whole table — what it represents, how it’s populated, any important caveats. Click into a table and use the Table Description field at the top of the column panel to add this. Column descriptions sit inline next to each column. Click the description field for any column and add a plain-English explanation. Useful descriptions answer the question a developer would have when first looking at the column: what does this value represent, what are the units, is there anything non-obvious about how it’s calculated? For example:
  • contact_name → “Name of the customer’s point of contact for this order”
  • owner_name → “Name of the sales rep (seller) who owns this account”
  • arr → “Annual Recurring Revenue in USD, calculated as MRR × 12. Excludes one-time fees.”
The more specific your descriptions, the more reliably the agent will apply the right column to the right question.

​
Marking columns as selectable

The Selectable toggle controls whether the agent can scan a column’s distinct values at query time to inform how it builds SQL.
Column row showing the Selectable toggle in the on and off states
When a column is marked selectable, the agent can run DISTINCT() over it to extract its unique values, and then use those values in two ways:
  • Categorical filtering in SQL writing — the agent knows the valid filter values before it writes a WHERE clause. It knows that region contains “North America”, “EMEA”, and “APAC”, so it filters on real values rather than guessing at spellings or inventing categories.
  • Text grep search — the agent can search across a selectable column’s values to find the exact entry a user referred to loosely (e.g. matching “acme” to the customer_name value “Acme Corp (US)”).
Think of it as giving the agent the ability to power a select-style filter: it knows the possible values and can use them precisely. Mark a column as selectable when:
  • It contains categorical values users would naturally filter by (region, product, owner, status)
  • The distinct values are finite and meaningful to business questions
  • You want the agent to be able to enumerate or search options rather than guess at valid values
Leave it off for high-cardinality columns (IDs, free-text fields, timestamps) where scanning distinct values would be noisy or meaningless.

​
Beyond the schema: the Knowledge Base

The Data Model page carries Tables and Global Data Security. Descriptions on tables and columns cover what your data means, but some context isn’t about any one column: business policies, company background, definitions of terms users use loosely, and known caveats about the data. Those live on the workspace’s own Knowledge Base page as searchable markdown documents that publish with each workspace version.

​
Saving your changes

Changes to the data model autosave to the workspace’s draft — there is no separate save step. Click Publish on the version bar when you’re ready to checkpoint the schema together with the agent’s context, and promote the version to production to make it live.
The schema and the agent publish together, as one workspace version. What an embedded deployment serves is always the workspace’s production version — publishing stages a new version, and promoting it to production is what makes it live.

​
Next steps

System Prompts

Encode business rules, terminology, and behavioral guardrails into the agent.

Golden Assets

Add example queries and charts the agent can reference when answering similar questions.

Knowledge Base

Store reference documents the agent searches on demand to interpret your terms.

Skills

Package procedures and conventions the agent loads when it needs them.

User Memory

Let the agent record and apply each end user’s preferences automatically.

MCP as Context Source

Connect external tools and live systems as additional agent context.