Data Tables

Data tables give agent work a structured home: typed columns, one shared table, no copy-pasting between documents. Agents write the rows; you and your team query, refine, and act on them.

The alternative is what usually happens without them: a recurring assignment produces a fresh document every week, and the knowledge you actually care about — which competitors shipped what, which deals moved, which candidates advanced — is scattered across a pile of one-off reports. A data table inverts that. The assignment’s job becomes maintain this table, and the table is always current, always queryable, and always one place.

Creating a table

On the Data Tables page, choose New table. Give it a name, an optional description, and its columns — 26 field types across text, numbers, dates and times, selections (boolean, select, multi-select, status, tags), media, structured data, computed fields, and linked records. Agents create tables the same way from a conversation, and a CSV or JSON list of records an agent produced in a session becomes a table with Save as data table, where you confirm each column’s type before the rows are copied in.

A concrete example: a competitor-tracking table an agent updates every Friday might look like this.

Column	Type	Notes
Company	Text	Key column — one row per competitor
Latest release	Text	What shipped most recently
Release date	Date
Pricing change	Select	None, Increase, Decrease, New tier
Threat level	Status	Watch, Active, Critical
Source	URL	Where the agent found it
Last checked	Date	Stamped every run

Set an optional Key Column if runs should update existing rows rather than append duplicates: “When set, upserts will update existing rows matching on this column.” In the example above, keying on Company means the Friday run refreshes each competitor’s row in place — the table stays one-row-per-competitor no matter how many times the assignment runs. Without a key column, each run appends, which is what you want for a rolling log (one row per week of metrics, one row per incident).

Settle the key first

Columns can be added and removed later, but the key column is fixed once the table exists, so settle it before pressing Create table. The two questions that decide most designs: what is one row (a company? a week? a ticket?), and should runs update rows or add them?

Working with a table

Rows appear as agents populate the table. From the viewer you can sort and filter any column, search across rows, add a row or open one to edit its fields, delete rows, add or remove columns, and rearrange or resize them. The table is a shared surface, not an agent-only one — if you correct a row by hand, the correction is simply the new state of the table.

The menu beside the table’s name holds the rest: export to CSV, copy a link, rename, duplicate (the copy is private to you and carries the rows but not the original’s sharing), star it to keep it at the top of the list, and archive or delete it. Share sets who can see the table and what the people you add can do: Can view, Can edit rows, or Can edit, which also covers columns.

When a session changes a table, the session shows a card for it, and opening the table from that card overlays exactly what the run inserted, updated, and deleted — toggle between all rows and changed-only. This is the fastest way to review an agent-maintained table: open it from the run’s session and read only what changed.

Agents and tables

By default every agent in the workspace can read and write a workspace table, so a maintenance assignment needs no extra setup. To narrow who writes rows, open Share, then the settings gear, and set Agent write access to Workspace agents, Creating agent only, or Selected agents.

The instructions just name the table and describe the discipline, for example:

Each Friday, review the ten companies in the Competitor Tracker table. For each, check their changelog, pricing page, and recent announcements. Update the row: latest release, release date, any pricing change, and your assessment of threat level. Always stamp Last checked. If a company did nothing this week, still stamp the date — an untouched row should mean “not checked,” never “nothing happened.”

Because tables are readable as well as writable, they also work as an input: one assignment maintains the table, and another — a Monday briefing, say — reads it and summarizes what changed. See the agent-maintained data table guide for the pattern end to end.

Patterns that work

• Living tracker — one row per entity, keyed, refreshed on a schedule: competitors, open deals, key accounts, hiring pipeline. The table answers “what’s the current state?” at any moment.
• Rolling log — no key column, one row appended per run: weekly KPIs, incident history, published-content log. The table answers “what happened over time?” and is ready to chart or export.
• Triage queue — rows appended by a webhook-triggered assignment as items arrive, with a status column a human (or a second agent) advances.