Loading page…
An AI assistant is planned. Until it is genuinely useful we would rather point you at the page that actually answers your question.
Most commercial AI work today is integration rather than model training. You take a capable general model, connect it to your data and your systems, constrain what it can do, and measure whether the output is good enough to rely on. Training a model from scratch is rarely the right answer outside of research.
The categories that come up most often are retrieval — answering questions from your own documents — classification, extraction from unstructured text, and agents that carry out multi-step tasks against real systems.
The genuine value is in work that is high volume, language-shaped and currently done manually: reading documents, categorising requests, drafting routine responses, extracting fields from forms. Those tasks are expensive in staff time and well matched to what current models do reliably.
The risk is equally real and usually understated. Models produce confident, well-formed output whether or not it is correct. Deployed without evaluation, that means plausible wrong answers reaching customers at scale. The engineering that matters is not the prompt — it is the measurement around it.
Our approach
We build an evaluation set before building the feature. A few hundred real examples with known-correct answers gives a number you can track. Without it, "the AI seems better now" is the only available feedback, and it is worthless for deciding whether to ship.
We start with the simplest approach that could work and add complexity only when the evaluation shows it is needed. A well-constructed prompt against a strong model solves more problems than expected. Retrieval, fine-tuning and multi-step agents each add cost and failure modes, so each needs to earn its place.
We design for the failure case explicitly. Every AI feature needs an answer to what happens when the model is wrong — human review for consequential decisions, confidence thresholds that route to a person, and visible citation so users can verify claims themselves.
Capabilities
Answering from your own documents with citations, so users can check the source rather than trusting the summary.
Extracting structured fields from contracts, invoices and forms, with confidence scores and a review queue.
Categorising tickets, messages and records, measured against a labelled set rather than assumed to work.
Multi-step tasks against real systems, with tool access constrained and every action logged.
Test sets and scoring that run in CI, so a prompt or model change cannot silently regress quality.
Model selection, caching and routing so inference cost stays proportional to the value produced.
Stack
Process
An honest read on whether current models handle your task reliably — including when the answer is not yet.
Real examples with known-correct answers, assembled before any implementation work begins.
The simplest approach that might work, scored against the evaluation set to establish a floor.
Retrieval, prompting and model changes tried against the same score, keeping only what measurably helps.
Confidence thresholds, human review paths and logging before anything reaches customers.
Quality, cost and latency tracked after launch, since model behaviour changes with provider updates.
Use cases
Letting staff ask questions of documentation, policies and past tickets, with citations back to the source.
Classifying and routing incoming requests, drafting replies for human approval rather than sending automatically.
Extracting fields from invoices, contracts and forms, with low-confidence cases routed to a person.
Drafting, summarising and reformatting at volume, where a human still approves what goes out.
Choosing an approach
These are commonly discussed as competing options. They solve different problems, and starting with the wrong one wastes both time and budget.
| Approach | Solves | Limitation |
|---|---|---|
| Prompt engineering | Shaping behaviour, tone and output format | Cannot supply knowledge the model does not have |
| Retrieval (RAG) | Answering from your own current, private documents | Quality is bounded by retrieval; wrong context produces wrong answers |
| Fine-tuning | Consistent format or specialised style at lower per-call cost | Needs substantial labelled data; does not reliably add facts |
Outcomes
FAQ
Related