Native Tables
Your data. Its proposals.
Tables are Aghata's home for operational records — leads, vendors, inventory, pipelines. The agent queries them exactly, cites them row by row, and when it wants to change something, it asks. Every record knows where it came from.
The change set
The agent asks before it writes. Every time.
There is no code path for an AI to mutate a record directly. A write is a proposal: the operations, the rows and fields affected, and the reasoning — parked until you apply it.
Rows and fields, named
A proposal shows exactly which records and which fields move, value by value. You review a diff, not a paragraph claiming things were updated.
Rationale attached
Every change set carries the agent's written reasoning and a link to the session that produced it. A wrong proposal is a findable mistake, not a mystery.
Stale proposals refuse to apply
If the data moved after the proposal was filed, it flips to stale and won't apply until re-reviewed. Your table never gets clobbered by an out-of-date opinion.
Exact, attributed
Counts are counts. And every cell has a byline.
Tables are typed and indexed underneath, which is what makes agent answers exact rather than impressionistic — and every record carries its origin.
No 'roughly' from a file skim
Fields are typed and indexed, so filters, counts, and sums run against the data itself. When a report says 6 exceptions, that's a query result — not a language model's impression.
Who made this row
Every record is stamped with its creator — you, an import, or an AI session — and keeps the link. Two months later, a strange value still has a findable origin.
Field-level history
Every change is logged with actor, before, and after, down to the field. The answer to 'who changed this and from what' is a lookup, not an investigation.
Tables are sources
A table can back a deliverable with record-level citations — the report links the exact rows it used, and the rows know which reports used them.
A real surface
A product you work in, not an export you email around.
The same table the agent queries is the one you edit by hand — with the views and structure you'd expect from a real data product.
Ten field types
- Text, number, date, checkbox
- Select and multi-select
- URL and email
- Files on records
- Linked records across tables
Three views
- Grid with keyboard navigation and filters
- Kanban boards by any select field
- Calendar from any date field
Three ways in
- CSV with preview and live progress
- Airtable base snapshots, links preserved
- Task outputs turned into tables
Related tables group into collections; imports report failed rows with reasons instead of truncating silently. And a routine on a schedule can query a table every morning and leave a reviewed change set waiting — real rows in, proposals out.
Questions
The parts people ask about first.
How is this different from handing a spreadsheet to a chatbot?+
A chatbot skims your file and approximates. Tables are indexed and queried exactly — counts are counts, sums are sums — and when the AI wants to change something, it files a proposed change set for your review instead of silently mutating your data.
Can the AI ever write to my table directly?+
No. Every AI write arrives as a change set: the operations, the affected rows and fields, and a written rationale. You apply or reject it. If the data changed underneath the proposal in the meantime, it's marked stale and nothing applies until it's re-reviewed.
Can I just edit cells myself?+
Of course. Tables are a full product surface — grid, kanban, and calendar views, keyboard navigation, filters. You and the agent work on the same data; only the agent goes through review.
Does an Airtable import stay in sync?+
No, by design. An Airtable import is a durable one-time snapshot: Aghata imports the base tables you select into a collection, preserves linked records between them, and creates a fresh dated snapshot if you import again. Your working data lives here, not in a sync pipeline.
What happens while an import runs?+
You watch it: total rows, processed, failed — live. Rows that fail to parse are listed with the reason. No silent truncation, no mystery gaps.
Can scheduled work use a table?+
Yes. A routine or schedule can query a table and file proposed updates on every run — a Monday-morning pipeline review that reads real rows and leaves a change set waiting for you, not an email of guesses.
Chapters of one system
Give it the outcome. Keep the control.
Start free in the product, or talk to us about how your team would use it.