LLM & retrieval systems for business processes
Your company already knows the answer. It's just buried in six years of documents, tickets and threads.
I build retrieval and LLM systems that put that knowledge in front of the person who needs it, at the moment they need it — and the evaluation that tells you when the system is wrong. Not workflow automation. Production engineering.
Ask the company something
Retrieved to answer it
Illustrative: a 2-D picture of something that happens in about 1,500 dimensions. Nothing here is keyword matching — "time off" finds the leave policy without sharing a single word with it.
The problem
The demo always works. That's the trap.
Nearly every stalled LLM project I've seen failed in the same four places — and none of them are the model.
Nobody defined "right"
The pilot was judged by whether the answers felt good in a meeting. There was no test set, so there was no way to tell whether the next change made it better or worse.
The data was never prepared
Documents went in whole, or split at arbitrary lengths. Retrieval returns something plausible from the wrong page, the model writes confidently around it, and trust is gone after two bad answers.
It was built as a demo, not a system
No permissions model, no cost ceiling, no latency budget, no logging of what was retrieved and why. Fine for a prototype; impossible to put in front of a customer.
Nothing watched it afterwards
Documents change, models get deprecated, question patterns drift. Without monitoring, quality decays quietly and the first person to notice is the person it embarrassed.
Every one of those is an engineering problem, not a prompting problem. That's the whole reason I'm useful here.
What I build
Four shapes of system, and the processes they fix
Most business problems worth solving with an LLM are one of these four, or a chain of two of them.
Answering from your own knowledgeRetrieval-augmented generation
Your policies, contracts, runbooks, past tickets and internal wikis become searchable by meaning rather than by keyword — and a model answers from them, with citations back to the source paragraph so anyone can check it.
Typical case: a support team where the answer to 60% of tickets already exists in writing, and the cost is the fifteen minutes it takes to find it.
Underneath: chunking strategy, embedding model choice, vector store, hybrid keyword + semantic retrieval, reranking, citation enforcement, permission-aware filtering.
Sorting and routing what arrivesClassification & triage
Inbound work — tickets, emails, applications, invoices, incident reports — read, categorised, prioritised and sent to the right queue, with a confidence score that decides what a human still needs to see.
Typical case: an ops team spending the first hour of every day deciding what the day is, before doing any of it.
Underneath: label taxonomy design, few-shot vs fine-tune decision, confidence calibration, human-in-the-loop thresholds, drift monitoring on the label distribution.
Turning documents into dataStructured extraction
Contracts, invoices, forms, reports and PDFs converted into validated structured records that land in your database — with the fields the model wasn't sure about flagged rather than guessed.
Typical case: a finance or legal process where someone re-types information that already exists in a file, and the error rate is invisible until it matters.
Underneath: schema-constrained output, validation rules, confidence per field, exception queues, reconciliation against the source document.
Doing multi-step work reliablyAssisted & agentic workflows
Processes with several steps and real judgement in the middle — draft this, check it against that, look up the account, escalate if the numbers disagree. Built with hard boundaries on what the system is allowed to do on its own.
Typical case: a repeated internal process that takes a skilled person forty minutes and is 80% the same every time.
Underneath: tool/function design, deterministic control flow around the model, retries and idempotency, cost and latency budgets, full audit trail of every step.
The part most people skip
How you'll know it works — and keep knowing
An LLM in a business process is a system that runs unattended and makes decisions. I've spent eight years building exactly that, and the alerting that proves it worked.
The difference between a demo and something you can put in front of a customer is almost entirely measurement. Every engagement includes it — it isn't a phase you can drop to save budget, because without it nobody can tell whether the next change helped.
A golden set, built with your team
A hundred or so real questions with agreed correct answers, written by the people who currently do the work. This is the definition of "right", and it's the first deliverable.
Retrieval scored separately
Did the right document come back at all? Most bad answers are retrieval failures wearing a generation costume, and separating the two tells you which half to fix.
Regression on every change
Prompt edits, model upgrades, new documents — all run against the golden set before they ship. Improvement stops being an opinion.
Monitoring in production
Answer rates, refusals, retrieval scores, cost and latency per request, and sampled human review. The same instinct as any pipeline: if it can fail quietly, it will.
How we'd work
Small, measured, and yours at the end
I'd rather prove one process works than plan a transformation. The first engagement is deliberately small enough to kill cheaply if the answer is no.
Map
1 week
Find the process actually worth doing first, and audit whether the data it depends on can support it. Sometimes the honest output of this week is "not yet, and here's why".
Prototype
2–3 weeks
A working system on your real data, plus the golden evaluation set built with your team. You see a number, not a demo.
Harden
3–6 weeks
Retrieval quality, permissions, guardrails, cost ceilings, latency, logging, monitoring and the deployment pipeline. The part that makes it a system.
Hand over
1 week
Runbook, evaluation harness and a working session with your engineers, so your team can change it without needing me. That's the point.
Where this comes from
I came to this from the infrastructure side, which turns out to be the side that matters
For eight years I built backend systems that had to keep running when nobody was watching: an automated trading platform placing orders on the Texas wholesale power market, a US equities trading platform, a national payment gateway I helped break out of its monolith, and the Kubernetes clusters and data pipelines underneath all of it.
That work was never really about the code. It was about knowing what to do when something drifts. Metrics on every stage, alerts tuned to catch an anomalous run rather than a merely slow one, and enough logging to explain afterwards what happened and why.
An LLM inside a business process is the same problem in new clothes. It runs on a schedule or on demand, it makes decisions, it fails in ways that don't raise an exception, and its quality decays silently as the world moves underneath it. The people who find that intuitive are the people who've operated production systems — not the people who found a good prompt.
So: I'm not the cheapest way to get a demo. I'm the person you call when the demo has to become something the business can actually depend on.
Production track record
Python, Go, Kubernetes, Docker, AWS, GCP, PostgreSQL, MongoDB, Redis, RabbitMQ, Celery, Prometheus, Grafana — and 76 technical posts on DEV, several of them on database and retrieval fundamentals.
Reasonable questions
The ones I get asked first
How is this different from Zapier, n8n or Make?
Those tools move structured data between apps according to rules you write in advance. They're genuinely good at that, and if your problem is "when a form is submitted, create a row and send a Slack message", you don't need me.
What I do starts where the rules run out: unstructured company knowledge, judgement in the middle of the process, and answers that have to be checked rather than assumed. That needs a retrieval layer over your own content, a way to measure whether the answers are right, permissions so the system can't reveal what a user shouldn't see, and monitoring for when quality drifts. None of that is a node you drag onto a canvas.
Why not just give the team ChatGPT and let them get on with it?
Do that too — it's cheap and people learn fast. But a general assistant doesn't know your refund policy, can't see last quarter's tickets, can't be held to a measurable accuracy bar, and can't be embedded in a process so the work simply happens without someone remembering to ask.
The value isn't the model. It's the model connected to your knowledge, inside your workflow, with evidence that it's right.
Do we need to fine-tune a model?
Almost certainly not, at least not first. In most business processes the problem is that the model doesn't have your information, not that it lacks capability — and that's a retrieval problem, which is faster, cheaper and far easier to keep current than training.
Fine-tuning earns its place for consistent formatting, a narrow classification task at high volume, or squeezing cost out of something already proven. It's an optimisation, not a starting point.
What happens to our data?
It's decided deliberately, early, and written down. Depending on your requirements that means enterprise API tiers with no-training guarantees, a cloud region you specify, self-hosted embeddings and vector storage inside your own infrastructure, or fully local models where the data genuinely cannot leave.
Access control matters as much as storage: retrieval has to respect the permissions your documents already have, or the system quietly becomes a way to read things you couldn't open directly.
Won't this all be obsolete in six months?
The models will change — that's the point of building so they can be swapped. What doesn't go obsolete is the work around them: knowing which process is worth automating, preparing the data, defining what "correct" means for your business, and the evaluation harness that lets you upgrade a model on a Tuesday and know by Wednesday whether it helped.
That harness is the durable asset. Everything else is replaceable on purpose.
How do we start without committing to a big programme?
The one-week assessment, or a single prototype on one process. Both are small enough to stop cheaply, and both end with something concrete — a written recommendation, or a working system with a number attached to how well it performs.
I'd rather tell you in week one that your data isn't ready than take four months of budget to arrive at the same place.
Start here
Tell me about one process that eats more time than it should
A 30-minute call is usually enough for me to say whether this is worth doing, and to be specific about why if it isn't.
Useful in a first message
- The process, and roughly how many hours a week it costs you.
- Where the knowledge lives today — wiki, tickets, drive, someone's head.
- Whether the data can leave your infrastructure.
- Whether you have engineers who'd own this afterwards.