Artificial Intelligence
AI Development Services
Most AI projects die in the gap between a convincing demo and a system a business can depend on. We build the engineering that closes it: retrieval that fetches the right context, evaluation that catches regressions before your users do, and cost, latency and controls that survive real traffic.
What AI Development means in practice
Who it’s for: Teams putting AI in front of customers or into core operations, where a wrong, slow or expensive answer has a real cost and the feature has to keep working after the launch demo.
The model is rarely the hard part. Anyone can wire an API key into a chat box over a weekend and produce something that looks astonishing in a meeting. The hard part is everything around it: retrieval that fetches the right context rather than the plausible-looking wrong one, evaluation that tells you whether last week’s prompt change made the system better or quietly worse, latency and token cost that still make sense at ten thousand requests a day instead of ten, and access control tight enough that the system cannot surface a document to someone who was never allowed to see it. That surrounding engineering is the product. The model is a component inside it.
We work across the full range of that engineering. Retrieval-augmented applications grounded in your own documents, where the interesting work is chunking, hybrid search, reranking and citation rather than prompt wording. Agentic workflows that take real actions against your systems, raising a ticket, updating a record, triggering a refund, with scoped permissions, an audit trail and a rollback path, because an agent that can act is an agent that can act wrongly. Extraction pipelines that turn unstructured input into validated structured output. And conventional machine learning where it is the better tool, because a gradient-boosted model on tabular data usually beats a language model on both accuracy and cost.
Where a hosted API from OpenAI, Anthropic or Google is the right call, we use one and get on with the actual problem. Where data residency or unit economics rule that out, we run open-weight models such as Llama, Mistral or Qwen on infrastructure you control, served with vLLM or an equivalent, trading a monthly API bill for GPU capacity and operational responsibility you now own. The decision comes from your constraints rather than from what is fashionable this quarter, and we design it to be reversible, because the model that is best and cheapest today will not be the one that is best and cheapest in a year.
What you get
- An evaluation harness built before the feature ships: a golden set of real cases from your domain, scored automatically, so every prompt, model or retrieval change is measured rather than guessed at
- A retrieval layer designed as architecture rather than a prompt: deliberate chunking, hybrid keyword and vector search, reranking, and citations so an answer can be checked rather than trusted
- Guardrails at both ends: input validation and prompt-injection defences going in, schema-validated output, grounding checks and defined refusal behaviour coming out
- Token cost and latency modelled per request and monitored in production, with caching, model routing and context discipline keeping both viable at your real volume
- Human-in-the-loop and reversibility on any consequential action, with an audit trail of what the system did, on whose behalf, and how to undo it
- Permissions enforced during retrieval, so an answer can only be grounded in documents the requesting user was already entitled to read
- Observability built for AI specifically: traced requests, logged prompts and retrieved context, quality and cost dashboards, plus a handover so your engineers can run and extend it
Work like this
Real engagements, written with the client’s own facts and published as they are approved.
What AI Development does for you
You stop shipping on vibes
The difference between AI teams that improve and AI teams that thrash is whether they can measure. With a harness of real cases, a prompt change, a retrieval tweak or a model upgrade produces a number you can compare, including on the awkward cases where the right answer is "I do not know". Without one, every change is a matter of opinion, regressions are found by customers, and nobody dares touch the prompt that seems to be working.
Answers that can be checked
Grounding a system in your own content with proper retrieval and citations changes the nature of the output. Instead of a fluent paragraph the user must take on faith, they get an answer attached to its source, openable and verifiable in seconds. That property is what makes AI acceptable in most serious settings: it turns the model from an oracle into a very fast research assistant.
Unit economics that survive success
AI features have an unusual property: they get more expensive as they get more popular, and the cost sits in architecture rather than in wording. Context you retrieve but do not need, a frontier model where a small one would do, no caching on the questions everyone asks, and a chatty agent loop that takes nine turns to do a two-turn job all land on the bill. We budget cost per request in design, then route, cache and trim, so the successful version of the feature is one you can afford to keep.
Why teams choose us for AI Development
- You want engineers who will tell you when the answer is not a language model at all: a gradient-boosted model on your tabular data, a search index, a set of rules, or fixing the process that produced the mess.
- You want evaluation, guardrails, permissions and cost control treated as the core of the build rather than a second phase that never gets funded, because those decide whether the feature is still running in a year.
- You want the model to be a swappable component, so the pace of the field works in your favour instead of stranding you on whatever was current when the project started.
- You want everything in your own accounts and repositories, with no proprietary orchestration layer you must keep paying for to keep your product running.
What AI Development includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Retrieval-augmented generation done properly
Most useful AI applications are retrieval systems with a language model on the end, so we treat retrieval as the main engineering effort: chunking that respects document structure rather than cutting every 500 tokens, hybrid search combining keyword matching with vector similarity because pure semantic search misses exact identifiers and product codes, a reranking pass to put the genuinely relevant passages at the top of a short context, and citations so every claim is traceable. Usually this runs on pgvector in the Postgres you already operate; a dedicated vector database is a real option at scale but not the starting point most teams are sold.
Agentic workflows that act, safely
An agent is a model given tools and a loop, and the engineering is almost entirely in the tools and the loop rather than the prompt. We define each tool with a strict schema and validate every call against it, scope credentials so the agent can only reach what that specific workflow needs, bound the loop so it cannot spiral, and make consequential actions either reversible or gated behind a human approval step. Every run is traced end to end so you can see what it decided, why, and with what context. We are also sceptical of heavy agent frameworks: a readable state machine you can debug at 3am usually beats an abstraction you cannot.
Structured extraction from unstructured input
The least glamorous and most reliably valuable application of language models: turning contracts, invoices, emails, forms, transcripts and PDFs into validated structured data. We define the target schema first, use structured output or constrained decoding so the model returns something parseable rather than prose about JSON, validate every field, and route anything low-confidence or schema-invalid to a human queue instead of letting it flow silently into your database. Accuracy is measured against a labelled set, so you know your real extraction rate.
Model selection, fine-tuning and serving
We choose the model on your constraints and re-check the choice as the field moves: frontier hosted models where capability matters, small cheap ones for the many tasks that are really classification or reformatting, open-weight models on your own infrastructure where residency or unit economics demand it. On fine-tuning we are deliberately conservative: it is excellent at teaching a model a format or a narrow classification task, and poor at teaching it facts, which is what most people want it for and what retrieval does better. Where it genuinely fits, we do it with a proper holdout split and measure the result.
Evaluation, guardrails and safety engineering
We build the harness first: real cases with expected behaviour, automatic scoring, and regression runs on every change. Model-as-judge scoring is useful, but only once calibrated against human labels on your own cases, so we calibrate it rather than trusting it out of the box. Around the model we add prompt-injection defences (never treating retrieved content or tool output as instructions), output schema validation, grounding checks that flag claims the retrieved context does not support, PII handling, and defined refusal behaviour for questions the system should decline rather than improvise.
Cost, latency and reliability engineering
We instrument tokens and latency per request from the first week, then engineer against the numbers: exact-match and semantic caching for repeated questions, provider-side prompt caching for stable system context, routing simple requests to smaller models, streaming so perceived latency drops even when total time does not, and context discipline so you are not paying to send passages the model never uses. Reliability gets the same treatment: timeouts, retries with backoff, a fallback provider when an API degrades, and graceful behaviour when the model is unavailable rather than a broken page.
Where it fits
An assistant grounded in your own knowledge
Internal documentation, policies, contracts and historical tickets made genuinely searchable and answerable, with citations back to the source and permissions enforced at retrieval so nobody sees anything they could not already open. The effort goes almost entirely into ingestion, chunking, hybrid retrieval and reranking, plus the evaluation set proving it answers your real questions rather than the three someone tried in the demo.
AI inside an existing product feature
A summarisation, drafting, classification or triage feature added to software you already sell, where the constraints are strict: it must fit the latency budget of a page load, cost a fraction of the revenue per user, degrade gracefully when the provider has a bad afternoon, and never expose one customer’s data to another. This is where model routing, caching and tenant isolation in retrieval earn their keep.
An operational workflow with an agent doing the legwork
A back-office process where the model reads the incoming case, gathers context from your systems, prepares the action, and either executes it within tight permissions or presents it for one-click human approval. The value is the hours removed from a repetitive process; the engineering is scoped credentials, idempotent tool calls, bounded loops and a clean escalation path for cases the agent should not attempt.
A stalled proof of concept taken to production
A demo built quickly with a hard-coded prompt, a laptop’s worth of documents and no measurement, which now has to become something real. We start with the evaluation set that never existed, which usually reveals the true accuracy for the first time, then rebuild retrieval and add permissions, guardrails, caching and observability. Sometimes the honest conclusion at that stage is that the use case is not viable, and we say so.
How we approach AI Development
We start from the failure you are trying to avoid, not the model you want to use. Before any building, we agree what "good" means as a measurable set of real cases: actual questions your users ask, actual documents you hold, actual answers a knowledgeable person would accept, plus the cases where the correct behaviour is to refuse or escalate. That set becomes the harness every later change is judged against. Without it, AI development degenerates into people taking turns to feel that the latest prompt seems a bit better, which is not engineering and does not survive a model deprecation notice.
From there the model is treated as one replaceable component behind clear boundaries: retrieval in front of it, guardrails and schema validation around it, caching and a fallback provider beneath it. That is what lets you move to a newer or cheaper model in an afternoon, with the harness confirming the swap held quality, instead of rewriting the product around whatever shipped last month. It also keeps the interesting engineering where it belongs: most problems presented as model problems are retrieval problems, and most retrieval problems are data problems, so we look there first.
How the engagement runs
We open on the failure modes and the data, not the model. In the first sessions we establish what the system must do, what it must never do, who the users are, and what data grounds it: where that data lives, whether it is exportable, how it is permissioned, how often it changes and how messy it really is. This is where the awkward findings surface, and they surface cheaply. A knowledge assistant whose source documents are three years out of date is a documentation problem wearing an AI costume, and finding that out in week one is worth far more than finding it out in month six.
Next we build the evaluation harness, before the feature. We collect real cases with your subject-matter experts and define an acceptable answer for each, including the difficult ones: ambiguous questions, cases where the source material contradicts itself, and cases where the correct behaviour is to refuse. Scoring is automated where it can be, calibrated where it uses a model as a judge, and human where it must be. From here on every change is measured, which is what makes the rest of the engagement engineering rather than negotiation.
Then we build in thin vertical slices, in your infrastructure, against real data. The first slice is a narrow but complete path: ingestion, retrieval, generation, guardrails, permissions and cost instrumentation, running end to end. That is deliberately early, because it exposes the real constraints while there is still budget to respond to them architecturally rather than cosmetically.
From there we widen coverage, tune retrieval, tighten cost, and roll out gradually behind a flag, watching the harness scores, the cost dashboard and the cases users mark as wrong. Those flagged cases feed back into the evaluation set, so the system gains a memory of its own failures. We finish with a handover: the decisions written down, the harness yours to run, runbooks for a provider outage or a deprecated model, and your engineers able to take the next change themselves.
How we architect an AI system
The organising principle is that the model is a component, not the centre. Requests pass through a boundary we control, where the system assembles context, calls the model, validates what comes back and decides what to do with it. Keeping that boundary explicit is what makes everything else possible: swapping models, adding a fallback provider, caching, enforcing schemas, redacting sensitive fields, and logging what actually happened. Applications that call a provider SDK directly from a dozen places in the codebase are the ones that cannot move when pricing changes or a model is deprecated, and both of those happen more often than anyone plans for.
In front of the model sits retrieval, which deserves more design attention than the generation step. A document pipeline handles ingestion, parsing, structure-aware chunking and embedding, with incremental updates so refreshing the corpus is routine rather than a rebuild. Search is hybrid, because keyword matching catches the exact part number or clause reference that vector similarity misses, and semantic search catches the paraphrase that keyword matching misses. A reranker then orders candidates so the short context the model sees is the best material available. Permissions are applied as a filter during retrieval rather than as a check afterwards, because the safest way to avoid leaking a document is never to put it in the context window.
Around the model sit the guardrails. Every output that feeds another system is schema-validated, and a failure means a retry or a defined fallback rather than a malformed record. Where the system acts, tools are narrowly scoped, calls are idempotent where they touch anything financial or destructive, and either a human approves or the action is reversible with a recorded trail.
Underneath, the operational layer looks like any serious production system with AI-specific additions. Requests are traced end to end, including retrieved context and token counts, so a complaint about one bad answer is reconstructed exactly rather than guessed at. Cost and latency are dashboards, not surprises. Timeouts, retries and provider fallback handle the fact that model APIs have bad days. And the harness runs against the same code path as production, so what you measure is what your users get.
Data protection, access control and AI risk
The first question in almost every AI engagement is where your data goes, and it deserves a precise answer rather than reassurance. We establish which data may be sent to a model provider, under what terms, with what retention and in which region, and we design to that. For many organisations the commercial API terms of the major providers are perfectly acceptable once read properly. For others, particularly where the data is special-category personal data, legally privileged, or covered by a customer contract that forbids sub-processing, the honest conclusion is that an open-weight model on infrastructure you control is the only design that works. Under UK GDPR this is a lawful-basis and international-transfer question as much as a technical one, so it gets settled early and in writing rather than during a security review.
Access control in AI systems fails in a specific and predictable way: the retrieval layer is given a service account that can read everything, so the model grounds an answer in a document the person asking was never allowed to open. We enforce permissions at retrieval time against the requesting user’s own entitlements, so unauthorised content is never a candidate for the context window. In multi-tenant products the same discipline applies to caches and embeddings, because a shared cache keyed only on the question is a quiet cross-tenant leak.
AI systems also have their own risk surface, and we engineer for it explicitly. Prompt injection is treated as the structural problem it is: any content the system did not author, whether a retrieved document, a web page or a tool response, is data and never instruction, and tools are scoped so that even a successful injection cannot reach anything consequential. Where the system informs decisions about people, we are candid about bias, human oversight and the fact that some decisions should not be automated at all. Where the EU AI Act or sector regulation applies, we design with those obligations in view, though a formal regulatory assessment is a matter for your legal advisers rather than your engineers.
Signs it’s time
- A promising internal demo has stalled on the way to production, because the parts skipped to make it quick are exactly the parts production requires
- The system gives confident answers that are sometimes wrong, and you cannot say how often, which means you cannot say whether a change made it better
- Cost per request or latency makes the feature unviable at real volume, and the fix is being attempted by shortening prompts rather than changing the architecture
- You need AI to act on your systems rather than talk about them, which raises questions about permissions, auditability and undo that a chat interface never had to answer
Measure first, and keep the model replaceable
Two principles do most of the work in our AI practice. The first is that nothing improves that is not measured. AI systems are unusually good at appearing to work, because fluent language reads as competence, and unusually good at degrading invisibly, because a small retrieval or prompt change can shift behaviour on a class of inputs nobody happens to try that week. So the harness comes before the feature, real failures are added to it continuously, and we resist impressionistic assessment even when a change obviously seems better, because "obviously seems better" is how quality regressions ship.
The second is that the model is the most volatile component in the system and must therefore be the least load-bearing. Providers deprecate models, prices fall sharply, and a design built around one model’s quirks becomes technical debt in months. So we put the model behind a boundary, keep prompts and configuration out of scattered code, and let the harness decide whether a swap is safe. The corollary is a willingness to say that no model is needed at all: if the requirement is a forecast from tabular data, a deterministic rule, a better search index or a fixed process, we will tell you, because the value here comes from a system that earns its running cost, not from having used AI.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on AI Development?
A short call with a senior engineer, before you write a brief. If AI Development is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
Quality you can measure
An evaluation harness of real cases from your domain that catches regressions before your users do, so "is it any good" has an answer with a number in it.
Cost and latency that hold
Token spend and response time budgeted per request and watched in production, so the feature stays viable when volume arrives rather than becoming a bill nobody wants to defend.
A model you can swap
A system where the model sits behind boundaries, so a better or cheaper one is an afternoon and a test run, not a rebuild of the product around it.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- A paid discovery and feasibility engagement first, where the ambition is broad or the data is unknown: a few weeks establishing what the data can support, building a first evaluation set and testing the assumption the whole idea rests on. It can legitimately conclude that the use case is not worth building, which is a cheap way to find out.
- A fixed-scope build for a defined AI feature with an agreed evaluation target, quoted once the data, the acceptance criteria and the integration points are understood, because those, rather than the model, drive the effort.
- A monthly senior engagement where the AI capability grows with the product: retrieval tuning, expanding the harness, adapting to new models and pricing, watching cost and quality in production. Most AI systems need this shape for a period after launch, because the field moves underneath them in a way conventional software does not.
- Third-party costs are billed to your own accounts, never marked up through us. Model API spend, GPU capacity if you self-host, and cloud usage sit on your subscriptions, with you seeing the real numbers. We model expected cost per request during design and monitor it after launch, so the bill is forecast rather than discovered.
Typical timeline
- 01
Discovery, data and feasibility
One to two weeks establishing the use case, the acceptance criteria and the truth about your data: where it lives, whether it is accessible, how current and how permissioned it is. Most fatal problems in AI projects are visible here if anyone looks.
- 02
Evaluation harness and first slice
Two to three weeks building the evaluation set with your experts and delivering one complete vertical path end to end, with retrieval, guardrails, permissions and cost instrumentation in place, so real accuracy, latency and cost per request are known rather than estimated.
- 03
Build-out and tuning
Iterative widening of coverage: retrieval quality, prompt and model selection, caching and cost work, and integration with the systems the feature touches, each change measured against the harness.
- 04
Controlled rollout and handover
Gradual release behind a flag with quality, cost and latency watched in production and user-flagged failures fed back into the harness, followed by documentation, runbooks for provider outages and model deprecations, and a handover so your engineers own it.
What working with us actually means
We operate what we build
We run AI systems in production, so the parts that only matter after launch go in from the start: traces you can reconstruct a complaint from, a fallback when a provider degrades, caching before the bill arrives, and a plan for the day a model you depend on is deprecated.
Evaluation before enthusiasm
We build the measurement before the feature, which is rarer than it should be and is the main reason our systems keep improving after handover. It also keeps us honest: when the numbers say a change did not help, or that the use case does not clear the bar, we say so.
Senior engineers who will talk you out of AI
A meaningful share of what arrives as an AI request is better served by a search index, a rule, a report, a classical model on tabular data, or a fixed process. We say so before you spend a delivery budget establishing it, because we would rather build the smaller right thing than the larger fashionable one.
Your accounts, your data, your system
The code, the repositories, the cloud accounts, the provider relationship, the harness and the prompts are yours throughout. There is no proprietary orchestration layer in the middle that you must keep paying us for to keep your own product running.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Services in this practice
The specific services that make up this practice.
Related terms
Common questions
Should we fine-tune a model on our data?
Usually not first, and usually not for the reason people ask. Fine-tuning is very good at teaching a model a format, a house style or a narrow classification task, and poor at teaching it facts, which is what most organisations actually want. Facts change, and a fine-tuned model has no way to tell you it is quoting something from last year; retrieval handles that far better, because the answer is grounded in a document you can update and cite. We get retrieval, prompting and evaluation right first, then consider fine-tuning for a specific measured gap: a persistent formatting failure, a domain classification the base model handles poorly, or a cost reduction where a small fine-tuned model replaces a large general one on a narrow task. When we do it, we hold out a test set and prove the gain rather than assuming it.
How do we stop it making things up?
You reduce it substantially with engineering and manage the remainder with design. The engineering is grounding: retrieve the relevant source material properly, put only that material in context, instruct the model to answer from it, and require citations so every claim points at a passage. A grounding check can then flag output the retrieved context does not support, and a defined refusal path beats an improvised answer when the sources do not cover the question. What you cannot buy is certainty, which is why the harness matters: it tells you your actual error rate on real cases, and that number, rather than a promise, decides whether the feature goes in front of customers unsupervised, behind a review step, or not at all.
Do we need a vector database?
Usually not a separate one, at least not to begin with. If you already run Postgres, pgvector gives you vector search inside the database you back up, monitor and know how to operate, and it comfortably handles corpora far larger than most internal knowledge bases. Adding a dedicated vector service brings another system to run, another consistency problem when documents change, and another bill. There are genuine reasons to reach for a specialist store, very large corpora, demanding filtering at high query rates, or a need for features your database does not offer, and when you hit one we will say so. But the vector database is rarely the interesting part of a retrieval system. Chunking, hybrid search and reranking decide answer quality far more than the storage engine does.
Can you make an agent that just does things in our systems?
Yes, with the caveat that the engineering effort sits in the permissions and the reversibility rather than in the model. We define each tool with a strict schema, scope credentials to only what that workflow needs, make write operations idempotent so a retry does not double-charge or duplicate a record, bound the loop, and put an approval step in front of anything consequential until the measured error rate justifies removing it. Every run is traced. What we will not do is hand an agent broad credentials to your production systems and rely on the prompt to keep it well behaved, because any content it reads can carry an instruction, and the prompt is not a security boundary.
How do you keep the running cost under control?
By treating cost as an architectural property measured from the first week rather than something to negotiate later. We instrument tokens and latency per request, then engineer against the numbers: caching for repeated questions, provider-side prompt caching for stable system context, routing straightforward requests to a smaller model, keeping retrieved context tight so you are not paying to send passages the model ignores, and cutting agent loops that take nine turns to do a two-turn job. Model spend is billed to your own provider account so you see the real figure, and we alert on cost per request rather than only the monthly total, because the pattern that ruins the economics of an AI feature shows up per request long before it shows up on an invoice.
Thinking about AI Development?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether AI Development is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.