Skip to main content
Every project contains tables, and tables are typed. The type determines what a table is for, what operations it supports, and how the agent uses it. Start with the one that does the work.

​
Reconcile tables

A reconcile table is where a process runs. Each row is one case: an event came in, the agent worked it following your SOP, and the row holds the result — output fields, the reasoning, the actions taken, and a review status. An order arrives as a PDF. That’s one row. The agent reads the document, queries your customer master, applies the match rules, fills customer_number and match_status, notes why, and hands the case to review. What you configure (in the table’s Configure view): Input. A case can carry files (documents to work from), structured data (a JSON payload), or both. Reconcile tables take files directly — you do not need an extraction table in front of them. Statuses. A case moves Running → Agent Done, then through review to Approved, Needs review, or Rejected. See Review & approvals. Unit of work. Usually one reconcile table per process. If your process has distinct steps that each deserve their own record, model the steps as tasks in one shared table rather than splitting into many tables.

​
Storage tables

A storage table holds reference data: your customer master, item master, price lists, PO headers, carrier codes, GL mappings. It’s the “against what” of every matching process. The agent queries storage tables directly with SQL from its environment — it is not handed a pre-filtered slice. That means it can look up, join, count, and check candidates the way an analyst would, but only in the tables you granted under Data Access. Make your columns legible. The agent reads your schema to understand your data. postal_code and vendor_item_number are useful; col_7 and f3 are not. Add a description to any column whose name isn’t self-explanatory. Keeping it fresh. Load a CSV by hand, or sync from a source system on a schedule with a workflow.

​
Extraction tables

An extraction table turns documents into structured rows at volume. One row per file, one column per extraction task, a schema you define. It’s a helper, not a process: it structures, it doesn’t decide. When it earns its place: high document volume with a stable shape, where pre-structuring is cheaper and faster than having the agent read every file from scratch — or when structured rows are the deliverable themselves. What it gives you:
  • Nested output: a header record plus its line items in one row.
  • A side-by-side source view — every value next to the page it came from.
  • Run AI on selected rows only, so re-running after a schema change is cheap.
  • Optional Review mode (a human approval gate before rows are considered final).
Settings: pipeline (see Extraction pipelines), review mode. See the extraction quickstart.

​
How they chain

The common case — files straight into the process:
The reconcile table takes the files, the agent reads them, queries master data, and produces the case. Two table types, no pre-processing step. Adding extraction, when volume calls for it:
Extraction structures the documents first; the reconcile table receives rows instead of raw files. Same process, less work per case — worth it once you’re running thousands of similar documents.
Start without the extraction table. Add it when per-case latency or cost tells you to, not before.

SOPs

The procedure the reconcile agent follows.

Review & approvals

Statuses, evidence, assignment, and approval gates.

Extraction pipelines

Model configurations for extraction tables.