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
Section titled “Creating a table”On the Data Tables page, choose New Table (workspace owners and admins). Define the schema up front: a name, an optional description, and the columns — 26 field types across text, numbers, dates and times, selections (select, multi-select, status, tags), media, structured data, computed fields, and linked records.
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).
Working with a table
Section titled “Working with a table”Rows appear as agents populate the table. From the viewer you can sort and filter any column, search across rows, open a row to edit its fields, delete rows, and rearrange or resize columns. 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.
When a session changes a table, a diff overlay shows exactly what that run inserted, updated, and deleted — toggle between all rows and changed-only. This is the fastest way to review an agent-maintained table: rather than rereading the whole thing, open the run’s session and look at what changed.
Agents and tables
Section titled “Agents and tables”Agents in the workspace can read and write workspace tables, so a maintenance assignment needs no extra setup. 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
Section titled “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.
For the complete site index, see llms.txt.