Case studies

What we build,
and how.

The real kinds of system and architecture we work in — anonymised, with illustrative figures rather than a verified scorecard. Open any one for the problem, the full architecture, and the systems involved.

PH
Healthcare
0 data to public models

Patient context, surfaced automatically — without a byte leaving their cloud.

A health-tech startup needed to pull patient context out of incoming emails the moment they arrived. The hard constraint: patient data could never touch a public AI model.

Azure (private)RAGVector DB
LX
Legal
Thousands of pages indexed

Every document in a case, searchable and cited — across thousands of scanned pages.

A law firm runs cases with dozens of documents each — many of them scanned PDFs. Lawyers had no way to ask a question and get an answer grounded in the actual filings.

OCRChunkingEmbeddings
IV
Inspection
Automatic defect detection

Cracks, spalling, and paint failure — spotted by a model, not a person on a ladder.

A client was inspecting structures by eye from photos — slow, inconsistent, and easy to miss a defect.

Computer visionImage modelsDefect scoring
GS
Finance ops
Hours of chasing removed

Mark a row paid or unpaid — the right email drafts itself.

A client chased payments by hand from a Google Sheet — re-typing the same reminder emails over and over.

Google Sheets APIApps ScriptTemplating
OI
Distribution
2 systems → 1 screen

Two systems, one screen — approve, sort-to-zero, and the follow-ups send themselves.

A US distributor ran orders in one system and inventory in another, checking them side-by-side by hand, then manually approving, adjusting, and emailing clients and the warehouse.

Dual-system integrationCustom portalRule engine
IG
Healthcare
Many EMRs, one integration

Many EMRs, one pipeline — an integration layer in the spirit of Iguana.

Connecting to many different EMR systems is a fragmented mess — every vendor speaks its own dialect.

Interface engineHL7-style routingTransformation

The anatomy of a
production system

reference architecture

A linear A→B→C is a demo. Real systems look like this: an autoscaling edge, a durable queue, an orchestrator that routes every step to the right kind of worker — and a retrieval layer that decides, per step, whether the answer needs an agent, a tool, or a plain function. Every case is a specialisation of this.

How we engineer
the hard parts

under the hood

The decisions that separate a system that survives production from a demo that doesn't.

Right tool, per step

We don't force everything through one model. Each step gets the right tool — a retriever, a classifier, an OCR pass, a deterministic script — chosen for the job, not for the hype.

Orchestration & state

Steps hand off through a durable workflow that checkpoints state, retries on failure, and resumes where it left off instead of restarting from zero.

Temperature, tuned per task

Near-zero for extraction, matching, and compliance where there's exactly one right answer; higher only where drafting genuinely needs range. Never a single global setting.

Grounded in real context

Retrieval (RAG / Context7-style) grounds every answer in the client's actual documents and systems — never the model's guess from training data.

Hand-off: agent ↔ agent ↔ human

Agents pass work to one another and escalate the genuinely ambiguous cases to a person. Nobody — and no model — is left guessing who owns the next step.

Runs on your cloud

Deployed in the client's own Azure or AWS — using their credits where it helps — so sensitive data and the bill both stay with them.

Your problem is
probably on this list.

If it isn't, it's close. Tell me the slow, manual, expensive thing — I'll show you the architecture to kill it.

Start a build →