System Manual
How a Document Flows
The path a piece of work takes from arrival to resolution: ingest, extraction, routing, action, and triage for the exceptions.
The unit of work
The unit of work is a document, such as an invoice PDF, a signed contract, a résumé or an inbound email. Each becomes a run tracked against your organization. A run ends in one of three states:
| completed | The agent acted, and the output was applied through your connected tools. |
| pending_triage | A person is needed. The run waits in the triage inbox with its context. |
| failed | The harness ran out of retries. The run is recorded with the last error. |
The lifecycle, step by step
- •
Ingest
The document enters through an upload, an inbound email or webhook, a connected tool, or the public/v1API. A run record is created against your organization and a status of running. - •
Classify & extract (Reader)
The Reader extracts structured data (line items, parties, amounts, dates) and gives it a confidence score. If the score is below the 0.85 auto-approve bar, the run goes to triage. - •
Route by rules and the Center
When the caller named an agent, the run goes directly to that specialist node. When it didn't, the Center decides which specialist should own it. Either way, your organization's rules for that agent are loaded and handed to it. - •
Act
The specialist runs under the harness, applies your rules, and produces an output. If it is confident and its trust level permits, the run proceeds to the integration step and acts through your connected tools. - •
Triage exceptions
Routing rules & direct dispatch
Most agent types are direct-capable: a caller (the dashboard, an inbound integration or an API request) can name the agent and skip the Center. The Center only decides when no agent was named. That keeps high-volume work you already understand, like a vendor's monthly invoice batch, on a short and predictable path.
Worked example: an invoice flowing through
Example · Invoice #4471 from a known vendor
Ingest: the vendor emails a PDF to the org's inbound address. A run is created with status running and the document stored in Supabase Storage, scoped to the org.
Extract: the Reader pulls the vendor, PO number, line items and a total of $47,230, and scores the extraction at 0.93. That is above the bar, so the run is routed on.
Route: because a PO is present, the run is dispatched to invoice_matcher with the org's three-way-matching rules attached.
Act: the matcher checks the invoice lines against the PO and the goods receipt, finds them within tolerance, and posts the invoice to the accounting connector, which its trust level allows. The run completes.
The exception path: had the total exceeded the PO by more than the tolerance, or the trust level required approval to submit, the run would instead have entered triage with the mismatch highlighted and the proposed posting shown for a human to approve, reject, or redirect.
Ingest
Upload · email · webhook · /v1
Classify & extract
Reader → structured data + score
Route
Rules + Center pick the specialist
Act
Specialist runs under the harness
→ Integration / act
Confident & in-trust
→ Triage inbox
Exception, held for a person
Confidence · the same 0.85 bar at every routing decision
≥ 0.85
Can exit to integration
0.50 – 0.85
Triage: below the auto-approve bar
< 0.50
Triage: below the minimum
The triage inbox
Every exception lands in a single inbox. Each item shows the agent type, the document, the confidence score, the rule broken or the reason it was flagged, and what the agent proposes to do. You can Approve (apply the proposal), Reject (discard it) or Redirect (send it to a different agent or path). Each decision is stored with who made it.