Back-office work, done by agents you can audit.
Documents come in. Fields are extracted, checked and matched against your records. Someone with the right role approves. The result is posted to accounting, once, and every step is recorded. Supplier invoice processing is the first workflow.
Runs without a GPU for evaluation, using a built-in demo model.
Each step is a building block configured in YAML. The approval step is where a person decides.
The clerk prepares. The approver decides.
A clerk submits an invoice and the agent does the reading, checking and matching. The run pauses for approval, and the clerk cannot approve their own work. An approver corrects what needs correcting and approves, and the bill is posted.
- Fields shown on the approval card come from the workflow definition
- Low-risk invoices can be approved by policy; changed bank details always reach a person
- Refusals leave the approval open, with a clear reason
Configuration you can review, behaviour you can prove
Everything that decides behaviour is a file under version control, validated before the server starts. Every decision is attributed to a person or to a named policy, and the audit chain can be verified at any time.
- A workflow cannot reach a payment without passing an approval
- Exactly-once posting, with a documented reconciliation path
- Only allow-listed keys of a run's state ever reach the browser
Built for documents that move money
Back-office Agents is a Rust application on Loco.rs with a CopilotKit web front end, PostgreSQL with pgvector, and a licence gate that keeps every dependency and model open source.
Behaviour is YAML
Workflows, prompts, extraction schemas, connectors, roles, policies and per-customer overrides are definition files. Change a threshold or add a workflow from existing steps without writing code.
A mistake stops boot
A typo, an unknown step, a dangling reference, a disallowed model licence, or a payment reachable without an approval: each refuses to start the server and names the file.
Real approvals
Who may decide is a role. The person who started a run cannot approve it. Only the fields the workflow marks editable can be changed, and a waiting run survives a restart.
Posted exactly once
Calls to accounting are guarded by an idempotency key reserved before the call, so a replayed decision, a second worker or a retry never posts twice.
Every step audited
Run starts, step outcomes and decisions go to a hash-chained audit log per customer. Tampering with any entry breaks the chain from that point on.
Multi-tenant by design
Each customer's data is isolated by the application and by database row-level security, and a tenant file changes rules, connectors and auto-approval for that customer alone.
Open models, your hardware
Models are any OpenAI-compatible endpoint, such as vLLM serving open-weight models, and documents are parsed by docling. A licence allow-list is checked at boot.
Open protocols
The web app speaks AG-UI 1.0 over server-sent events through CopilotKit, so any AG-UI client can drive a run, pause for approval and resume.
What ships now
- Supplier invoice processing, from document to posted bill
- Web app with sign-in by token and an approval card
- Webhook connector with signed, idempotent calls
- Document upload with deduplication, parsing and embeddings
- Per-tenant overrides and auto-approval policies
What comes next
- Native connectors for accounting systems
- Sign-in through your identity provider
- Collections and further back-office workflows
- Per-tenant rate limits and trace redaction
Put an agent on your invoice queue
We will run your own invoices through the workflow and show you each step, from extraction to the posted bill.