Three agents, each pointed at one manual job.
Same method in all three: work against your real records, print a confidence on every output, and hand anything uncertain to a person.
Invoice Parser
Nobody types header and line items into the ERP again.
Today
Invoices land in a shared mailbox and on a phone. Someone opens each one, reads the header, and keys the line items into the ERP. When the quantities don't match the PO, that person starts an email thread with the vendor.
The work is slow at month end and invisible the rest of the time. It is also where duplicate payments come from.
Flow
- 01intake — shared mailbox, WhatsApp number, or a drop folder you already use
- 02classify — invoice, credit note, statement, or something that isn't ours to read
- 03extract — header fields and every line item, each with its own confidence
- 04validate — against the PO, the vendor master, and prior invoices for duplicates
- 05review — anything under threshold queues for a person with the page beside it
- 06post — written to the ERP with the source document attached to the record
Hard cases
- Photographs and scans. Phone photos at an angle and 200 dpi scans are the normal case, not the exception. Skewed pages are deskewed before extraction.
- Multi-page invoices. Line items that continue across pages are stitched into one record; page totals are reconciled against the final total.
- Non-English vendors. We handle [CONFIRM LANGUAGE LIST]. Anything outside it is routed to review rather than guessed at.
- Duplicates. Matched on vendor, invoice number, amount and date, including re-sent copies of the same bill through a different channel.
- Confidence thresholds. Set per field with you. Below the threshold, the agent stops and asks — it does not submit a best guess.
Integrations
Questions
What accuracy should we expect on our invoices?
We don't know until we run your documents. Stage one produces a measured number on your own evaluation set, per field, before you commit to a build. If it doesn't clear the bar we agreed, we say so.
What happens to an invoice the agent can't read?
It goes to the review queue with the page, the fields it did extract, and the reason it stopped. A person completes it in the queue, and that correction becomes part of the evaluation set.
Does it post directly to our ERP?
Only if you want it to. Many teams start with the agent writing a draft record that a controller approves, then move to direct posting for vendors where the score is stable.
Do you need access to our whole ERP?
No. We need read access to the vendor master and open POs, and write access to the object we post. Scoped credentials, and we'll write the permission list for your admin.
Permissioned Knowledge Base
Nobody forwards the document that answers the question.
Today
Most internal chat tools flatten permissions. Everything the index read becomes readable by everyone who asks, so the safe move is to index only the harmless documents — and then the tool can't answer anything that matters.
Ours keeps the source system's access rules attached to the content and applies them at query time. A rep and a controller ask the same question and get different answers, both correct for them.
Flow
- 01connect — each source connected with its own service account and access rules
- 02index — content indexed with the source ACLs attached to every chunk
- 03identify — the asker's identity and roles resolved from your directory at query time
- 04retrieve — the retrieval set filtered to what that person may already open
- 05answer — generated only from those documents, with each source cited
One question, two askers
“What's the discount we agreed with Kirloskar this year?”
The current Kirloskar agreement lists a 12% volume discount on the industrial range, effective through March 2027. The commercial terms sheet is the source; pricing approvals beyond that sit with finance.
12% on the industrial range through March 2027, plus a 3% early-settlement rebate agreed in the May amendment. Realised discount across the last two quarters is 13.4% against a 12% list, driven by two off-terms approvals.
Hard cases
- Stale permissions. Access is re-checked at query time against your directory, not at index time. Removing someone from a group takes effect on their next question.
- Mixed-sensitivity documents. A file with restricted sections is treated at the level of its most restricted part unless the source system exposes section-level rules.
- The answer exists, the asker isn't cleared. The agent says the information exists and names who owns it. It does not leak the content, and it does not pretend nothing was found.
- Sources without ACLs. Anything ingested without usable access rules is either restricted to a named group or left out. We won't index it as public by default.
Connectors
Questions
How do you know what someone is allowed to see?
From your systems. Identity and group membership come from your directory; document-level and record-level rules come from each connector. We enforce the intersection of both at query time and add no permissions of our own.
Can an administrator see everything?
An administrator sees whatever their own accounts already grant them, same as any other user. The index is not a back door — there is no view in our product that returns content the asker couldn't open directly.
What if the answer is wrong?
Every answer cites the documents it came from, so the asker can check it in one click. Wrong answers are usually stale sources; the citation makes that visible instead of hiding it behind confident prose.
Does it work over records as well as documents?
Yes, where the connector exposes row-level rules — [CONFIRM WHICH RECORD SYSTEMS ARE LIVE]. A rep asking about an account gets the rows their CRM already shows them.
AI Low-Code Backend Builder
Nobody writes the same CRUD scaffolding for the fourth internal app.
Today
Every internal app starts with the same two weeks: schema, migrations, CRUD endpoints, validation, auth wiring, a place to hang side effects. The interesting part of the app starts after that.
Define the entity instead. You get generated schema and endpoints against your own database, and you keep writing normal code where the logic is actually yours.
Flow
- 01define — an entity, its fields, and its relationships — written or described
- 02schema — migrations generated against your database, reviewed before they run
- 03endpoints — REST routes with filtering, pagination and validation from the field types
- 04hooks — before/after lifecycle hooks where your logic goes
- 05extend — check the generated code into your repo and edit it like any other code
entity definition
entity PurchaseOrder {
number string @unique
vendor Vendor @belongsTo
status enum(draft, open, closed)
ordered_at date
lines POLine[] @hasMany
total decimal(14,2) @computed(sum: lines.amount)
@hook(before: create) assignNumber
@hook(after: update) syncToErp
}generated
sample response · 200
{
"id": "po_01J8F2K",
"number": "4400-1183",
"status": "open",
"vendor": { "id": "ven_884", "name": "Sundar Metals" },
"ordered_at": "2026-08-04",
"total": "486240.00",
"lines_count": 4,
"_links": { "lines": "/api/purchase-orders/po_01J8F2K/lines" }
}Hard cases
- Generated versus written. Schema, CRUD, validation and hook stubs are generated. Business rules, integrations and anything with judgement in it you write yourself.
- Escape hatches. Any route can be replaced with a hand-written handler, and raw SQL is available. The generator never owns a file you've taken over.
- Migrations. Every schema change produces a reviewable migration with an explicit down. Nothing runs against your database until you approve it.
- Versioning. Endpoints are namespaced per version; adding a field is additive, removing one requires a new version. Old versions keep serving until you retire them.
Runs against
Questions
Do we own the code?
Yes. The generated project lives in your repository and runs on your infrastructure. If you stop working with us, the backend keeps running with no dependency on our service.
Can it work against an existing database?
Yes, and that's the common case. We introspect the existing schema and generate against it; the generator does not require a greenfield database or rename your tables.
What about authentication and authorisation?
Authentication plugs into your existing identity provider. Authorisation is generated as policy stubs per entity — the shape is given to you, the rules are yours to state.
Is this a low-code platform we'd be locked into?
It generates a conventional application in [CONFIRM STACK] that any engineer on your team can read. There is no runtime of ours in the request path.