Most operational data still lives in a spreadsheet. The moment a team wants software to help — classify a row, look something up, draft a reply — they export, script, and paste the results back by hand.
AgentTable removes that round trip. It is a grid where some columns are typed by people and others are filled by agents, per row, from the other columns in the same row. Agents run in place, their output lands in the cell, and every run is recorded so you can see what was produced, re-run it, or overrule it.
The problem we started from
A list of inbound leads needs a segment, a priority, the company's domain and a first outreach line. A support queue needs a category, a sentiment and a suggested reply. A vendor shortlist needs a normalised key so duplicates collapse. None of these are hard for a model — the hard part is keeping people and software editing the same table without losing each other's work.
A column is either something a person types or something an agent computes. Both live in the same row, and each knows when the other changed.
Data columns, agent columns
A data field is a typed column: text, number, checkbox, select, URL, email, date or JSON. Values are validated on save. An agent field names an agent template — Classifier, Extractor, Enricher, Summariser, Drafter, Sentiment, Translator, Deduper-key, or your own — and the input fields it reads. New agent cells start stale, which is the table's way of saying "there is work to do here".
Typed inputs
Select options, numbers and emails are validated at the edge so the agent never reads garbage.
Explicit dependencies
Each agent column declares which columns it reads. Edit one of them and the computed cell is marked stale.
Reusable templates
An agent is a prompt, an output type and an input hint. Define it once, drop it into any table.
The run loop
Runs happen per cell. You can run a whole column, only the pending cells, one row, or a selection of rows. Each run stores the input it saw, the output it produced, a confidence score, latency and token count — the receipts.
The agent reads the row's input cells as plain text.
The template runs; in the demo, a deterministic local simulator stands in for the model.
The cell becomes computed with a confidence dot; errors are recorded, not hidden.
Input → output, timing and tokens are kept per cell, forever.
The simulator matters more than it sounds. It means the whole product — 4 seeded tables, 8 agents, a few hundred runs — works offline, is fully testable, and behaves identically on every machine. Swapping in a real model is a one-interface change.
Review, pin, re-run
Agent output is a draft until a person says otherwise. Low-confidence cells and failed cells are one filter away. Clicking any agent cell opens a drawer with the live inputs, the prompt, the run that produced the value and its history. From there you can run again, or pin an override — a pinned value survives column re-runs unless you explicitly force them.
- Stale — an input changed since the last run.
- Error — the agent failed; the message is kept with the run.
- Pinned — a person overrode the agent; column runs skip it.
- Low confidence — computed, but flagged for a look.
Views and export
Saved views hold filters, sort and hidden columns. Filters understand ordinary columns and two pseudo-fields — status and confidence — so "everything stale or failed" and "anything under 80% confidence" are one click to save and share. CSV export respects the view, so what you see is what you download.
How it is built
AgentTable follows the System32 house stack: a Go backend (standard-library routing, SQLite, no CGO) with table-driven tests, and a Next.js 16 / React 19 frontend on shadcn/ui and Tailwind v4 in the shared dark/gold theme. It signs in through the System32 control plane, so one login covers it and every other product.
- Backend: tables, fields, rows, cells, agents, runs, views and an audit trail;
POST …/fields/{id}/runand…/rows/{id}/rundrive the loop; a globalGET /api/runsfeeds the run log. - Frontend: a hand-rolled grid with sticky headers, inline editors per type, a run drawer, a view bar, an agents gallery and a runs log with input/output drill-down.
- Seed: inbound leads, support triage, a vendor shortlist and a content calendar — realistic enough to demo the review flow, including a few deliberately failed and low-confidence runs.
What is next
Real model calls behind the same interface, live multi-cursor presence, and cross-table lookups. If your team keeps its real work in a spreadsheet and wants software to help without taking it away, AgentTable is built for exactly that.
AgentTable is available now in the System32 catalog. Ask us for a workspace, or read the product specification in the repository.