// 04 — ai automation
Automate the typing,
not the judgement.
The AI projects that succeed are unglamorous. They take a task somebody does forty times a day by hand, do the mechanical part reliably, check their own arithmetic, and hand anything doubtful to a person. That is what we build.
// worked examples
What the work
actually looks like.
Four real shapes of automation we build, each shown as a before and after. Messy input on the left, the structured record on the right, and the check that stops a wrong answer reaching your database.
// input — what actually arrives
// output — structured & checked
These are pre-prepared worked examples, not live model calls, and contain no client data. They illustrate the shape of the output and the validation layer — which is the part that decides whether automation is safe to trust.
// what we build
Four patterns that
pay for themselves.
Almost every automation we ship is one of these, or two of them joined together.
-
01
Document data extraction
Invoices, purchase orders, lab reports, shipping documents, KYC packs and forms turned into structured records your systems can consume. The extraction is the easy half; the validation layer that catches a wrong answer is what makes it usable.
- OCR + LLM
- Field validation
- Confidence scoring
- Human review queue
-
02
Classification and routing
Inbound messages, tickets, emails and enquiries sorted by intent and urgency, then routed to the right person with a draft response attached. Cuts the delay between a customer writing and somebody who can help reading it.
- Intent detection
- Urgency scoring
- CRM sync
- Draft replies
-
03
Retrieval-augmented answering (RAG)
Question answering grounded in your own documents — policies, manuals, product data, past tickets — with citations back to the source paragraph so an answer can be checked rather than trusted blindly.
- Vector search
- Citations
- Freshness control
- Access scoping
-
04
Multi-step agents
Workflows that read something, decide, call your APIs and write a result back, with a bounded set of allowed actions and a full audit trail. Used where a rules engine would be too brittle and a human too slow.
- Tool use
- Guardrails
- Audit trail
- Bounded actions
// how we keep it honest
Why our AI work looks boring on purpose.
The model is never the last step. Everything it produces passes through deterministic code before it reaches your database. Line items get re-added. Tax gets recomputed. Check digits get validated. Dates get range-checked. If the arithmetic disagrees with the model, the arithmetic wins and the record goes to a human.
We evaluate against your data, not a demo. Before anything goes live we build a labelled set from your real documents and measure accuracy per field. Not one aggregate number, because 95% overall can still mean a critical field is wrong one time in five. You see the per-field table before you decide to trust it.
Confidence routes the work. High-confidence records flow straight through. Anything below threshold, or failing a check, lands in a review queue where a person confirms or corrects in seconds. Corrections feed back into the evaluation set, so the threshold can be tightened with evidence rather than optimism.
Everything is logged. What went in, what came out, which version produced it, who approved it. When somebody asks in eight months why a record says what it says, there is an answer.
We will tell you when not to use AI. Plenty of the problems described to us as AI problems are a database query, a regular expression, or a form somebody should have been given three years ago. Those are cheaper, faster and do not drift.
// straight answers
Questions we get
every week.
How accurate is document extraction, really?
It depends entirely on the document and the field. Clean, consistently laid out documents with printed text reach very high accuracy on core fields; handwriting, poor scans and unusual layouts are meaningfully harder. Rather than quote a number we cannot stand behind, we measure it per field on a sample of your real documents during a paid pilot, and you see that table before committing to a full build.
Will our data be used to train a model?
Not by us. We use enterprise API tiers where the provider contractually does not train on submitted data, and we can run open-weight models entirely inside your infrastructure where policy or regulation requires it. Data handling and retention are written into the scope before work starts.
Can this run on our own servers?
Yes. For regulated data or strict policies we deploy open-weight models on infrastructure you control, with no data leaving your network. Accuracy is typically somewhat lower than the largest hosted models and the hardware costs more, and we will be direct about that trade-off for your specific documents.
What does a first project usually look like?
A narrow paid pilot on one document type or one workflow, with a labelled evaluation set and a measured accuracy report at the end. It gives you a real number to decide on rather than a demo, and it is deliberately small enough that walking away costs you little.
What happens when the model gets something wrong?
It is caught by a validation check and routed to a human, or if it passes every check and is still wrong, it is visible in the audit log and becomes a new case in the evaluation set. We design on the assumption that it will sometimes be wrong, because it will.
// next step
Tell us what is actually broken.
A short message is enough to start. The first scoping call is free, and you will be talking to the person who would write the code.