Language & Agents

Language models made a new class of software possible: systems that read, write, decide and act on unstructured input. They also made a new class of demo possible: the kind that impresses everyone in the room and then never ships, because nobody can say how often it is wrong.

We build the kind that ships, and the difference is not the model but everything around it.

What we build

Evaluation is the deliverable

Ask a vendor how good their LLM feature is and you get a demo. Ask how often it fails and you get silence. That gap is where these projects die, so we invert it: the evaluation harness is built first, and the system has to earn its way through it.

1. 1

   Define failure

   Together with your experts we work out what wrong looks like here, whether a hallucinated citation, a missed extraction or an action taken without grounds, and make it concrete before any prompt is written.

2. 2

   Build the eval set

   The set is built from real cases in your domain, labelled once and versioned permanently. Every prompt change, model swap and retrieval tweak reruns against it.

3. 3

   Measure, then ship

   We report failure rates per category, and the system ships when those numbers clear the bar you set. The numbers are yours to keep.

4. 4

   Watch it in production

   Sampled review queues and drift checks keep running, because the distribution of real questions drifts away from the eval set over time.

This is the same discipline as the rest of our method, applied to systems whose raw material is language: behaviour is measured, confidence is calibrated, and failure announces itself. When the model is uncertain, the system should be able to say so and hand off to a person, in the same way our vision and tabular deployments flag their hardest cases.

Private by architecture

Scientific and industrial language data, such as lab records, process documentation and support tickets, is usually the most sensitive text an organisation holds. Where it runs is an architecture decision, and we make it deliberately:

• EU-hosted APIs with contractual data-processing terms, for work where managed frontier models earn their cost.
• Self-hosted open-weight models on your infrastructure or ours, for data that must not leave. On well-shaped tasks, smaller models close most of the gap.
• No training on your data, whichever path is taken, and we verify this in the terms.

Deployment, monitoring and the serving infrastructure follow the same patterns as everything else we run, because an LLM endpoint is a model endpoint.

Built to be attacked

Every system on this page takes instructions from text, and some of that text will eventually be hostile. We treat prompt injection through retrieved documents, leakage through patient questioning and agents talked into misusing their tools as design constraints from day one. In practice that means output validation at the trust boundary, tool permissions scoped to the task, and untrusted content treated as data rather than instructions.

We also red-team these systems professionally, including ones we did not build. Building and attacking the same class of system is why we are reasonable at both.

Where to go next