Build an Agent-Maintained Data Table

Data tables give agent work a durable, structured home: instead of a fresh document each run, the agent maintains one table the whole team can query. This guide builds a competitor-tracking table, but the pattern fits any living dataset — candidate pipelines, renewal risk, content calendars.

Create the table. Open Data Tables and choose New Table (workspace owners and admins can create tables). Name it, add an optional description, and define the columns with types — text, long text, number, currency, date, select, URL, tags, and more.
Set a key column. If runs should update existing rows rather than append duplicates, pick a key column — for a competitor table, the company name or domain. When the agent upserts, rows matching on the key are updated in place.
Create the maintenance assignment. On your chosen agent, add an assignment whose instructions name the table and describe the upkeep: what sources to check, which columns to fill, and when a row counts as stale. Agents in the workspace can read and write workspace data tables, so no extra setup is needed for access.

For the competitor tracker, the instructions might read:

Each Friday, review every company in the Competitor Tracker table. Check each one’s changelog, pricing page, and recent announcements, then update its row: latest release, release date, any pricing change, and your assessment of threat level. Stamp Last checked on every row you review — an untouched row should mean “not checked,” never “nothing happened.”
Schedule it. Daily or weekly usually fits. Save and Run now to seed the table, then let the schedule take over.
Work with the result. The table is live for everyone in the workspace — sort it, edit cells, add rows by hand. The agent’s next run picks up from the table’s current state.

Variations

The competitor tracker is a living tracker: one keyed row per entity, refreshed on a schedule. The same setup bends several ways:

Rolling KPI log. Skip the key column and each run appends instead of updating: a weekly assignment that pulls the numbers from Google Analytics or Amplitude adds one row of metrics per week, and the table becomes a history that is ready to chart or export.
Candidate pipeline. Key on the candidate’s name, connect Greenhouse, and run daily — each candidate keeps one row whose stage and status columns the agent refreshes, so “where is everyone in the process?” has a current answer.
Triage queue from a webhook. Swap the schedule for a webhook trigger: each incoming item — a ticket, a form submission — appends a row with a status column that a person (or a second agent) advances.
A second assignment that reads the table. Tables are readable as well as writable, so one assignment can maintain the table while another — a Monday briefing, say — reads it and summarizes what changed.

For schema design in depth, including the per-run diff view that shows exactly what each session inserted, updated, and deleted, see data tables.