Agent output that dies in a chat window isn't work — it's a transcript. And automations pointed at a shared spreadsheet write with no permissions, no attribution, and no way to tell which robot wrecked which column. A table is the system of record the workforce reads and writes under rules: per-verb permissions on every agent, an author on every write, and triggers that fire the next agent when the data changes.
In a pack, these tables arrive pre-wired: schema, triggers, and agent permissions already set.
See Solution Packs →
The failure mode has two halves. Half one: the agent's result scrolls away in a chat window and a human copy-pastes it into the real system. Half two: you wire the agent into a shared spreadsheet, and now software with no judgment holds the same unrestricted grid access as your most senior person.
Tables close both. Results land as typed rows next to the records they concern — durable, queryable, shared. And every agent writes under per-verb permissions enforced at runtime, with its name on every write. The grid is governed the way the rest of the platform is: least privilege, attribution, and an audit trail that writes itself.
Pick a job. Each one is the same idea — durable state humans and agents share, with verbs granted per agent and an author on every write.
A candidate pipeline lives in a spreadsheet three automations and eight recruiters all write to. Nobody can say which robot changed which column. Moved into a table, the same grid works — under rules.
The screening agent holds Read + Update on the score columns; the scheduler holds Update on interview fields; Delete is off for every agent. Grants are per verb, enforced at runtime.
A score changes and the activity feed says which agent set it and when — next to the note a recruiter typed. No more spreadsheet archaeology.
When Status changes to shortlisted, a trigger runs the outreach agent with the row's columns mapped in. The chain runs off the data, not off glue code.
A currency column is suddenly wrong across two hundred rows. In a shared sheet, that's a day of guessing. In a table, the answer is already written down.
The audit log shows every change to the column: the agent that made it, the rows it touched, the timestamps — bracketing the exact run.
That agent held Update on two columns and no Delete — the damage stops where its grants stop. Other tables were never reachable.
Filter to the affected rows, correct them in a batch, and the corrections are attributed too. The record shows the break and the repair.
A new row shouldn't wait for someone to notice it. When a row lands or a value changes, the table fires the next agent itself.
Row created, row updated, a specific column change, or a cron tick — optionally gated by a condition on the row's values.
The row's columns map into the agent's inputs; its output maps back to a column when it finishes.
That output column is watched by the next trigger. Chains of work run off data changing — versioned, audited, no scripts between.
Marketing captures leads; sales works them. Rather than a weekly hand-off email, one shared table is the interface — each side's agents holding only their own verbs.
Marketing's agents hold Create + Update on the intake columns and write scored leads in.
Sales' agents hold Read on the intake and Update on the Stage column — least privilege on the same rows.
No export, no reconciliation, and every write from either side is attributed. The hand-off is a table, not a thread.
Applicants apply through a public form. Each submission should be scored the moment it arrives, with no one watching an inbox.
A data-collection form lets people outside the workspace submit straight into the table — they see only the fields meant for them.
A row-created trigger runs the screening agent on each new row the moment it lands.
The agent writes a score back under its Update grant, attributed like every other write. The pipeline fills itself.
Pull your data in from anywhere; every agent, team and employee reads context from it and writes results back — permission-scoped and attributed.
Six things the grid does that a shared spreadsheet never will.
Agent output that lives in a chat window is a result someone has to go find. A table makes it state: typed columns — Text, Number, Date, Select, Boolean, URL, Email, File, a relational Foreign Key, an agent-computed AI Enrich — with a primary key every relation and every write resolves to. Humans and agents read and write the same validated rows, so a screening agent's score sits in the column next to the note a recruiter typed.
A shared spreadsheet gives every robot the whole sheet. Here, access is granted per agent, per table, per verb: Read, Create, Update, Delete — four independent switches, enforced at runtime on every operation. Write verbs are off by default, and Delete stays off unless someone deliberately turns it on. A bad run can't drop rows it was never allowed to touch. This is the same posture as the rest of the governance layer: least privilege, enforced where the action happens.
When an automation wrecks a column in a shared spreadsheet, the investigation is archaeology. Here every write — human or agent — lands in an audit log with the author attached. Open a row and its activity feed reads like a ledger: which agent set the score, which person changed the status, at what time. An AI-computed field carries its provenance and a re-run control, so 'where did this value come from' is a glance, not a meeting.
The grid is also the event bus. A trigger watches for a row created, a row updated, a specific column changing, or a cron schedule — optionally gated by a condition — and runs an agent when it fires, mapping the row's columns into the agent's inputs and the agent's output back into a column. That write can trip the next trigger, so a chain of work runs itself off the data changing.
An automation that quietly changed last month is an automation you can't audit. Trigger configuration here is immutably versioned, and runs are pinned to the version they executed under — so when a trigger's behavior is questioned, you can see exactly what mapping and condition were in force at the time, not what they are today.
A table is the hand-off point between your existing systems and the workforce, so both directions are first-class. Import a CSV or Excel file with headers mapped before anything commits, sync from Google Sheets, take rows from the API, or open a public data-collection form. Export the other way — CSV, Excel, JSON, PDF — and both directions leave an import/export history, so even bulk moves are on the record.
A mid-market staffing firm moves its candidate pipeline out of a shared spreadsheet and into one table. Here's what the system does as candidates flow through — not a setup guide, the runtime behavior.
Read, Create, Update, Delete — granted per agent, per table, enforced at runtime. Write verbs off by default.
Every change logged with its author — agent or human — its field and its timestamp, in the row's own activity feed.
Columns validate on save; Foreign Keys relate tables; a primary key anchors every write and relation.
Row created, row updated, a watched column, or a cron schedule — with conditions — runs an agent with mapped inputs.
Trigger configuration is immutably versioned; each run pins to the version it executed under.
A column an agent computes per row — score, category, summary — with provenance and re-run attached.
Filter to a segment, select it, and run an agent across the batch — re-score a backlog in one pass.
CSV, Excel, Sheets, API and public forms in; CSV, Excel, JSON, PDF out — all of it on the record.
Sales pipeline tracking all active and recently closed deals.
Sales research table for ranking target accounts, summarizing ICP fit, and surfacing buying signals before outreach.
Partner-imported table template with sample rows and AI-enriched research summary.
Sales preparation table for discovery calls, objection forecasting, and meeting-specific briefing.
