System Manual
How a Document Flows
The end-to-end path a piece of work takes — from arrival to resolution — through ingest, extraction, routing, action, and triage of exceptions.
The unit of work
The canonical unit of work is a document — an invoice PDF, a signed contract, a résumé, an inbound email. Each becomes a run tracked against your organization. A run always ends in exactly one of three states:
| completed | The agent acted — the output was applied through your connected tools. |
| pending_triage | A human is needed — the run waits in the triage inbox with full context. |
| failed | The harness exhausted its 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 emits a confidence score. If extraction is below the 0.85 auto-approve bar, the run goes straight to triage rather than guessing. - •
Route by rules + Center
When the target agent is explicit, the run is dispatched directly to that specialist node. When it is ambiguous, the Center decides which specialist should own it. Either way, your organization's configured 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
Routing is rule-driven, not guesswork. Most agent types are direct-capable: a caller (the dashboard, an inbound integration, or an API request) can name the exact agent and bypass the Center. Only when the owner is genuinely ambiguous does the Center make the call. This keeps high-volume, well-understood streams — like a vendor's monthly invoice batch — on a fast, deterministic 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, scoring the extraction at 0.93 — above the bar, so it routes rather than triaging.
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 confirms the invoice lines against the PO and goods receipt, finds them in tolerance, and — within its trust level — posts the invoice to the accounting connector. 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 → human review
Confidence bands · the same gate everywhere a routing decision is made
≥ 0.85
Auto — exit to integration
0.65 – 0.85
Warn — proceed with caution
< 0.50
Triage — hold for a human
The triage inbox
Every exception lands in a single inbox. Each item shows the agent type, the document, the confidence score, the rule violated or the reason it was flagged, and the agent's proposed approach — so a human decides in seconds, not from scratch. The three actions are Approve (apply the proposal), Reject (discard it), and Redirect (send it to a different agent or path). Every decision is written to the audit log.