Tollgate
Agent idle, watching the AP inbox

How Tollgate works

The model reads and writes; code decides. A language model is good at reading messy documents and writing a clear email to a vendor. It should never be the thing that decides whether money moves. Tollgate splits those jobs.

1. Invoice arrives
AP mailbox (Gmail IMAP) or upload
The worker polls the AP inbox. A PDF is stored in object storage with its SHA-256, and a job is queued. Replies to the agent's own emails are matched back to their invoice by a tag in the subject.
2. Read, and distrust what was read
Vultr Serverless Inference: vision model
Pages are rendered to images for the vision model, so scans work. Every key value is then grounded against the PDF text layer. Separately, each text run is compared with the rendered pixels: text that is in the file but invisible on the page (white, microscopic, covered) is surfaced. Instruction-shaped text, the content-safety model (safety model) and the reader's own report of instructions it saw raise a quarantine.
3. 23 deterministic controls, then the contract
Plain Python, no model
Vendor master match, lookalike names and tax ID conflicts, verified bank account, duplicate and resubmission detection, split billing under the approval limit, line and total arithmetic, PO existence, ownership and status, currency, item on PO, price within 2% of PO, cumulative quantity against ordered and received, payment terms. Then the vendor's approved contract terms are applied: service credits from our own uptime monitoring, volume prices, price-increase caps. Money owed back is deducted, with the clause quoted in the remittance advice.
4. The agent plans
Vultr Serverless Inference: reasoning model
The model sees the findings, the PO, the vendor history and the email thread, and returns a plan: email the vendor for a corrected invoice, ask the budget owner whether goods arrived, request approval, open a bank change, hold, reject, or pay. Document and email text is passed as untrusted data.
5. A critic checks the money
Vultr Serverless Inference: a second model
Before a payment with deductions or above the auto-pay limit goes ahead, a different model recomputes what should be paid from the invoice, PO, receipts, contract and service measurements. If its figure differs, it cannot agree. Disagreement sends the payment to the CFO; concerns, to the controller. The critic can only add scrutiny.
6. A policy guard executes, or refuses
Code the model cannot change
Payment only with no open blocking findings, only to the vendor-master account, only with the approvals the amount needs (auto up to $10,000, controller up to $50,000, CFO above). Emails go only to the contact on file, never to an address printed on the invoice. Blocking findings clear only on new evidence or a person. Refusals are logged and the model re-plans.
7. People, only where they add judgment
Clerk, controller, CFO
Approvals above the limits; bank changes that need a callback to the number on file and two different approvers; contract terms the model proposed; overrides with a written justification. Every decision hands control back to the agent, which picks up where it left off.
8. The payment run
Deterministic optimiser, controller approves
Everything due within the week is paid; cash above the floor goes to early-payment discounts, best annual return first; the rest stays in the bank until due. The approved run produces the bank batch file.

Running on Vultr

  • Cloud Compute VM: Caddy (TLS), the Next.js app, the FastAPI API and the agent worker in Docker. The worker runs continuously, so follow-ups and replies are handled with no one logged in.
  • Serverless Inference: four models with separate jobs: vision extraction, planning and contract reading, an independent critic, and content safety. Invoice data stays on Vultr; no third-party model provider sees it.
  • Database: vendors, POs, receipts, invoices, findings, approvals, payments, the job queue and the hash-chained audit log.
  • File storage: original invoice PDFs and email attachments, addressed by hash.

Live configuration

Vision model
Reasoning model
Critic model
Safety model
Inference connectedno (rule-based fallback)
AP mailboxsimulated
Database
Files

Controls run on every invoice