Book a diagnostic

AI automation and agents for operations teams

Verne builds AI that reads documents, answers routine requests and moves work between your systems. Each step has a confidence threshold you set: anything below it, or anything that moves money, goes to a named person first. Our engineers build it inside your tools and hand it to your team.

Bring one workflowTry the example below

A supplier invoice, read field by field

The threshold decides how much work reaches a person. Move it and watch fields change lists, then approve or reject what is left.

Supplier invoice, as it arrives
0.90

Posts on its own 0

    A person checks 0

      Reading the invoice: 0 of 9 fields found.

      Work AI automation takes off your team

      • Document processing

        Invoices, orders, claims and forms read into fields, checked against your records and filed.

      • Support and operations agents

        Routine requests answered or drafted from your own knowledge base, with hard cases passed to a person.

      • Internal knowledge search

        Answers from your policies and manuals that cite the page and respect who may read it.

      • WhatsApp and voice agents

        Orders, bookings and status questions handled on the channels your customers already use.

      • Approval steps

        Payments, refunds and record changes wait for a named approver, on a screen the AI cannot reach.

      • Evaluation

        A test set built from your own cases runs on every change, so you hear when quality slips.

      For your engineers

      Stack

      Python and TypeScript services, PostgreSQL with pgvector, OCR and layout models for documents, and hosted or open-weight language models chosen per task on cost and measured accuracy.

      Architecture

      Models propose; only a reviewed decision record writes to your ERP. Each agent calls tools through a gateway with an allow-list and its own scoped identity. Writes carry idempotency keys, so a retry after a timeout never posts twice.

      Retrieval

      Permissions and effective dates filter inside the retrieval query, never in the prompt. Answers cite the passage they came from or decline to answer.

      Evaluation and security

      Labelled test sets per task, calibration checks on confidence scores, and paired comparisons across model versions. Retrieved content can shape an answer and never authorises a tool call. Every call is logged with identity and decision.

      How approval works

      Every automated step has two settings: a confidence threshold, and a list of actions that always go to a person. Confidence sorts the routine cases. The list covers anything where one mistake costs more than the time saved.

      A payment to a changed bank account should reach a person even at 0.99, because the one error in a hundred costs far more than a misfiled support ticket. Reviewers see the source beside each field, and every decision they make becomes a test case for the next release.

      How quality is measured

      Before anything goes live, your team labels a sample of real documents and requests. We measure accuracy per field and per task on that sample before quoting any figure.

      The same test set runs on every model or prompt change. Scores move between identical runs, so we compare item by item before calling a change a regression.

      What it costs to run

      Running cost has three parts: model calls, hosting, and the people who review exceptions. The model is the cheap part of this system: the human queue is the cost, and the threshold sets its size. We size all three on your volumes during the diagnostic.

      After handover, a run-and-improve retainer from US$800 a month covers monitoring, evaluation and model updates.

      The pilot that read invoices well and almost paid the wrong account

      A UK building-supplies distributor ran an AI pilot on its accounts-payable inbox. It read invoices accurately enough that the finance team stopped checking. Then a supplier's “new bank details” letter went through like any other invoice, and only the bank's payee check stopped the payment.

      The pilot was switched off. The finance director still wanted the hours back, and nobody wanted to be the person who switched AI on again.

      1. Every field earns its own thresholdEngineers scored 600 past invoices field by field. Amounts and dates cleared the bar. Bank details never would, so they never post on their own.
      2. A change is a different jobA new IBAN, payee or remittance address becomes a change request, compared with the supplier record and sent to a named approver with both versions side by side.
      3. Prove it on last yearBefore go-live the system re-read twelve months of invoices. Every disagreement with what finance had actually paid was explained or fixed.
      4. Switched on by the person accountableThe finance director approved go-live after reading the evaluation report.
      extract/INV-20391.json
      {  "supplier": "Hallam Timber Ltd",  "invoice_total": { "value": 18420.60, "confidence": 0.99 },  "due_date": { "value": "2026-12-04", "confidence": 0.98 },  "iban": { "value": "GB29 NWBK 6016 1331 9268 19", "confidence": 0.97 },  "iban_on_file": "GB82 WEST 1234 5698 7654 32",  "route": "approval_required"}
      1. AI extractionIBAN read with 0.97 confidence. It does not match the account on file for this supplier.
      2. EngineerRule: any change to payee or bank details goes to a person, whatever the score.
      3. Your finance approverCalled the supplier on the number in our records. Change confirmed, payment released.

      Sectors

      Questions about AI automation

      What happens when the AI is unsure?

      The field or request goes to a person, with its source shown beside it. You set the threshold for each field, and some actions, such as a payment to a new bank account, go to a person whatever the score.

      Which AI models do you use?

      We choose per task, on cost, accuracy on your test set and where your data may be processed. The system is built so a model can be swapped and re-tested without rebuilding the rest.

      Will our data train someone else’s model?

      We use providers and settings that do not train on your data, or open-weight models on infrastructure you control when data must stay with you. The choice is written into the design before the build starts.

      Can it work in more than one language?

      Yes. We build the test set from real messages in the languages and spellings your customers use, and report accuracy for each language separately.

      Bring one workflow and a month of its documents

      In the diagnostic we run a sample through extraction and show you what would post on its own and what would reach a person.

      Bring one workflowChoose another practice