Custom Data overview

Custom Data is a table you define and fill with your own rows, which your agents can read while they’re talking to someone. A store list, a price book, a table of discount codes, eligibility rules — anything an agent needs to look up by name or filter by value. You define the columns. The platform builds the agent’s tools from that definition, so you don’t write a tool per table.

​

When to use one

Use Custom Data when:

• The agent needs to look something up during the conversation — “what’s the price of the Pro plan in the EU?”, “where’s my nearest store?”
• The answer is structured: rows and columns, not prose
• You want exact answers, not the closest-sounding passage

Don’t use it for:

• Prose your agent should paraphrase — policies, FAQs, manuals. Use a knowledge base; it’s built for meaning-based search, and Custom Data is not.
• Live data owned by another system — today’s order status, a live inventory count. Call that system with an HTTP step in a workflow.
• Per-call state — the caller’s name, what they said two turns ago. That’s conversation context.

​

How it works

Two optional extras, once the basics are working:

• Stored queries — write SQL when filters aren’t enough. Distance calculations, bucketed totals, anything with arithmetic.
• Claiming rows — hand out one-time values like discount codes, with a guarantee that two simultaneous conversations never get the same one.

​

An example

A table called plans: plan_id is the row key — the column that identifies a row. From that definition the platform generates two tools:

• lookup_plans — fetch one row by its plan_id
• search_plans — filter by any column, sort, and return several rows

An agent asked “what does Pro cost in Europe?” calls search_plans with name = Pro and region = EU, and gets the row back. You wrote no code.

​

What it is not

Custom Data is deliberately narrow, and it’s worth knowing the edges:

• One table at a time. There are no joins. If you need a store’s country name and the country’s tax rate together, put both on the store row.
• Flat columns. Text, numbers, yes/no, dates. No nested objects or lists.
• Agents read; they don’t write. The one exception is claiming a row, which is narrow by design.
• Not a database you connect to. It’s reached through agents, workflows, and the API — there’s no connection string.

​

Limits

​

Permissions

Stored queries have their own permission because writing SQL that runs during a live call is a different act from editing reference data — the people who may do one aren’t automatically the people who may do the other.

​

Next