Build

A table is a project-scoped collection of structured rows. Tables give people, loops, and agents a shared data surface without requiring a separate database for small operational datasets.

Use a table for a work queue, triage state, account facts, lookup data, or any other durable concept that benefits from named columns and searchable rows.

Tables or agent memory?

Use a table when the data is intentionally structured, shared, and inspectable. Use agent memory for private free-form facts an agent should remember across conversations.

Design a table

Each table has a unique name, optional description and instructions, and a column schema. One required string column is the Identity column. It gives each durable concept a stable key for updates and upserts.

Keep tables narrow. One table per durable concept is easier for people and agents to understand than a catch-all table with loosely related rows.

Create a table in the app

1. Open Build > Tables.
2. Click New table.
3. Enter a lowercase name, a description, and guidance in Instructions.
4. Add the columns people and agents should use.
5. Mark one required string column as Identity.
6. Click Create.

The new table opens with its schema ready and no rows. Identity cannot change after creation because existing row keys depend on it. Other optional columns can evolve as the dataset grows.

Add and inspect rows

Open a table and click Insert rows. You can enter JSON directly or upload a JSON or CSV file. CSV headers become row fields.

The table page supports:

• Editing or deleting one row.
• Keyword search over row tokens.
• Importing several rows together.
• Opening Table settings to adjust guidance and optional columns.
• Inspecting each row's ID and identity value.

Keyword search is the predictable default. API and agent tools also support semantic and hybrid search when conceptual matches matter more than exact terms.

Give agents access

Agents reach tables through built-in table actions in their effective tool manifest. Project roles, table ownership, and the agent's toolkit decide what it can see or change. There is no separate grant list on each table.

Use project-visible tables for intentionally shared operational data. Use private ownership when the rows belong to one principal.

Row changes can start work

Inserts, updates, and deletes emit source events. A loop can use those events as a trigger or wait for one inside a run.

Next

• Automate row access with the Tables API.
• Use table commands from the CLI command reference.
• Control an agent's table tools with toolkits and skills.
• React to row changes with triggers.