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 (any workspace member can; viewers cannot). Name it, add an optional description, and define the columns with types — text, long text, number, currency, date, select, status, URL, tags, linked record, and more. Add column adds another.
Set a key column. If runs should update existing rows rather than append duplicates, pick a Key Column in the same dialog — for a competitor table, the company name or domain — then choose Create table. When the agent upserts, rows matching on the key are updated in place.
Create the maintenance assignment. On your chosen agent’s page, choose Add assignment. It opens on its own page, where the Instructions tab takes the upkeep: what sources to check, which columns to fill, and when a row counts as stale. A table created here is writable by every agent in the workspace, 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. In the Schedule tab, check Run on a schedule; a Daily or Weekly frequency usually fits. Changes save as you make them. Press 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.