Document and data extraction
PDFs, scans, faxes and email attachments turned into structured fields your systems can use. Low-confidence extractions are flagged for a person rather than guessed at and written in.
Services
AI agents and LLM features.
Applied to work people are doing by hand today. Built into the software you already run, not sold to you as a separate AI product — and left out entirely where ordinary code does the job better.
Where this usually starts
Somebody on your team spends a large part of the week reading documents and typing what they contain into another system. Or answering the same question from the same twelve files. Or sorting a queue by hand because the sorting rule lives in their head. It is slow, it is repetitive, it scales only by hiring, and it is where the hours go.
What this is
We build LLM features into software rather than selling an AI product. The distinction matters: a feature has a specific job inside a workflow you already have, it can be measured against the manual process it replaces, and it can be switched off without taking anything else with it. An AI product has to be adopted, learned, integrated and paid for before anybody finds out whether it helps.
An agent, in practice, is an ordinary program with a model inside it: a narrow job, a fixed set of tools it is permitted to use, explicit limits on what it may do without approval, and a complete record of everything it did. Most of the code in a good one is not the model call. It is the validation, the retries, the fallback when the model is unavailable, and the queue where a person picks up the cases it was not confident about.
What we build
Six things, each with a person at the end of it.
Narrow jobs with a clear right answer, high volume, and somebody available to check the cases the software is unsure about.
Classification and routing
Incoming work sorted, prioritised and sent to the right queue or the right person, with the reason recorded next to it so the routing can be questioned later.
Drafting and summarisation
First drafts of replies, letters and summaries, following your templates and your tone. A person reviews and approves before anything is sent or committed. Always.
Retrieval over your own documents
Questions answered from your policies, manuals and past cases, with a citation back to the source passage so the answer can be checked rather than believed.
Multi-step agents across your systems
The job somebody currently does by hand across three applications and a spreadsheet, carried out through those systems' own APIs, with each step logged and reversible.
LLM features in software that already exists
Added to the application you already run, behind your existing permissions and audit logging, rather than as a separate tool with its own login and its own copy of your data.
How we build it
What separates a demo from something you can run.
A convincing demonstration takes an afternoon. The distance between that and something you can put in front of your operation is almost entirely engineering, and this is what it consists of.
Grounded in your data, not model memory
Answers are retrieved from your documents and quoted back with a citation. A model asked to recall something from training will produce a fluent answer whether or not it knows, which is the failure mode that embarrasses people in production.
Structured output, validated against a schema
The model returns data in a defined shape and the shape is checked before anything downstream sees it. Output that does not validate is retried or queued for a person; it is never passed along and hoped for.
An evaluation set, built before the feature ships
A collection of real cases with known correct answers, scored automatically. It tells you how the feature behaves before it is switched on, and it is re-run whenever a prompt, a model or a document source changes. Without it, "we improved the prompt" is an opinion.
Guardrails and refusal behaviour
Defined limits on what the feature will attempt, and a designed response for input outside them. Refusing clearly is a correct outcome and is treated as one.
Every model call logged
Input, output, tools called, cost, latency and the version of the prompt in force. When somebody asks in six months why a particular item was handled the way it was, the answer exists.
Cost and latency budgets
Set before the build, measured during it, and reported per run. A feature that works but costs more per item than the person it replaced is a failure, and it is better to discover that in week two.
Graceful degradation
Model providers have outages and rate limits. The surrounding software queues work, retries sensibly, falls back to the manual path, and tells somebody — rather than losing the item.
Human in the loop
What the software never decides on its own.
This list is agreed with you at the start and written into the design. It is the part of an AI engagement most worth being specific about, so we are.
- Anything that moves money, or changes a figure that money is calculated from.
- Anything sent outside your organisation — to a patient, a payer, a customer or a regulator. The draft is automatic; sending it is not.
- Any change to a record of consequence, where the previous value matters.
- Any case the model reported low confidence on, or that falls outside the distribution the evaluation set covers.
- Any clinical judgement. Diagnosis, treatment and the triage of a patient rather than a document stay with clinicians, without exception.
- Anything a person has asked to review. An operator override is always available and is never routed around.
Restraint
When not to use a model at all.
If a rule, a lookup table, a database join or a regular expression does the job, that is the better engineering and we will tell you so. Deterministic code is faster, costs a fraction as much, behaves identically every time, and can be reasoned about by whoever maintains it after us. Most of the automations we build are mostly ordinary code with a model doing the one part that genuinely needs judgement.
The question worth asking about any task is not whether a model could do it. It is whether the task involves judgement that cannot be written down. Sorting by a field is not judgement. Deciding which of nine denial reasons a paragraph of free text is describing usually is. We would rather spend the first week working out which parts are which than assume the answer either way.
What you get
Everything on this list is a deliverable, not an extra.
- The feature or agent itself, running against your systems
- The evaluation set, and the scores, owned by you and re-runnable without us
- Prompt and retrieval configuration in your repository, versioned like any other code
- A review interface for the cases the software flags rather than decides
- Full logging of every model call — input, output, tools, cost, latency, prompt version
- Cost and latency figures per run, and a plain account of what drives them
- Source code in your repository, with no dependency on us to operate it
- Documentation covering how to change the behaviour when your process changes
Fit
Whether this is us.
Most unhappy projects were mis-scoped at the start rather than badly built. It costs nothing to be straight about this now, and it saves us both a call.
Best suited to
- High-volume repetitive work that currently scales only by hiring
- A backlog of documents or queue items that never quite clears
- Reading and re-keying between systems that do not talk to each other
- Work with a clear right answer that a person could verify in seconds but takes minutes to produce
Probably not us if
- You want an AI strategy. We build specific things that remove specific work, and we are not the right firm for a strategy deck
- The task has no right answer anybody can check. If nobody can tell whether the output was correct, nobody can tell when it stops being correct either
- It happens twice a month. Building and maintaining the automation will cost more than the work it replaces, and we will show you that arithmetic rather than take the project
Related
Next to this.
Systems integration and modernisation
Two systems that do not talk, so somebody re-keys between them. Or an application that still works and nobody dares touch. Both are fixable without betting the business on a rewrite.
Healthcare product engineering
The same engineering, done by someone who already knows that a file which parses cleanly can still be wrong. You stop paying a vendor to learn the domain on your time.
Healthcare software
Where this work goes deepest: claims and billing workflows, data exchange, reconciliation, audit trails and the formats healthcare actually runs on.
Tell us what you are trying to build.
Describe the problem in your own words. If we are not the right firm for it, we will say so.