Tool and function calling
The model proposes actions; your code validates the arguments, enforces permissions and asks a person to confirm anything that writes, sends or pays.
LLM development · UK
LLM Development and Integration in the UK
For CTOs and product leads who need a language-model feature to behave like the rest of their software: tested, observable, affordable at volume and careful with data. We integrate GPT, Claude, Gemini or open models such as Llama and Mistral into products and internal tools, with retrieval, tool calling and evaluation built in from the first sprint.
- Evaluation suite runs on every change
- Any model, behind one swappable interface
- UK and EU data residency options assessed
Who this is for
From a prompt that works to a feature you can ship.
Getting a language model to do something impressive takes an afternoon. Getting it to do that reliably for every user, on every odd input, within a latency budget and at a cost your finance team will sign off, is an engineering project — and it is the part most teams underestimate.
We work with CTOs, engineering leads and product teams who have reached that point: a prototype in a notebook, or a feature behind a flag, that now needs to become production software. We can own the LLM layer end to end, or pair with your engineers inside your repositories and CI so the patterns stay with your team after we step back.
Either way, we treat model output as untrusted input, every prompt as code and every change as something to measure. That is most of the difference between an LLM feature that quietly degrades and one you can keep improving.
- Retrieval, tool calling and structured outputs
- An evaluation suite wired into your CI
- Latency and cost budgets for each feature
- Guardrails, PII redaction and audit logs
The engineering
What goes into a dependable LLM feature.
The model call is one line of code. These are the parts around it that decide whether the feature holds up for real users.
Retrieval (RAG)
Chunking, embeddings, hybrid keyword and semantic search, re-ranking and citations — with document permissions enforced before anything reaches the model.
Retrieval and knowledge search
Structured outputs
Responses constrained to a JSON schema and validated against typed models in TypeScript or Python, with a retry when output does not parse.
Evaluation suites
Test sets drawn from real examples, scored by rules, by a grading model where it agrees with people, and by human review of a sample — run in CI before every release.
Prompt and version management
Prompts versioned alongside the code, model versions pinned, and changes rolled out behind feature flags with a quick way back.
LLM integration in practice
Guardrails and PII redaction
Personal data stripped or masked before it leaves your systems, checks on inputs and outputs, and defences against prompt injection hidden in user content or documents.
Models and tooling
The models and tools we integrate.
Chosen per feature on accuracy against your evaluation set, cost, latency and data terms. Using more than one model in the same product is common, and often cheaper.
Hosted models
OpenAI GPT modelsAnthropic ClaudeGoogle GeminiProvider data controls
Open models
LlamaMistralSelf-hosted in your cloudUK region deployment
Retrieval
EmbeddingsVector search in PostgreSQLHybrid keyword and semanticRe-ranking
Integration
Tool and function callingJSON schema outputsStreaming responsesQueues for long jobs
Cost and latency
Prompt cachingModel routingBatch processingToken budgets
Quality and safety
Evaluation suites in CITracing and loggingPII redactionOutput validation
Provider features, prices and regional options change often. We confirm current terms and availability for your chosen models during design, and record the decision so it can be revisited.
Retrieval or fine-tuning?
Retrieval first. Fine-tuning rarely.
When a model “does not know our business”, the fix is nearly always retrieval: find the right documents, records or policies at question time, and give them to the model with instructions to answer from them and cite them. Content can change daily, permissions are respected, and you can see exactly why an answer was given.
Fine-tuning changes how a model behaves, not what it reliably knows. Preparing the training data is expensive, the work has to be repeated as base models are replaced, and any facts baked in go out of date. It earns its place in a narrow set of cases: a format or tone that prompting cannot hold, a high-volume classification task where a small tuned model is cheaper and faster than a large general one, or specialist language the base models handle badly.
So we exhaust prompting and retrieval first, measure the remaining gap against your evaluation set, and only then consider tuning — with an honest estimate of what it will cost to maintain.
- Retrieval for knowledge that changes
- Prompts and examples for behaviour
- Fine-tuning for narrow, stable, high-volume tasks
- A measured gap before any tuning spend
Latency and cost
Engineering for speed and spend.
Slow responses and large token bills are design problems more than pricing problems. These are the levers we use, measured against a budget agreed for each feature.
Caching
Provider-side prompt caching for long, repeated instructions and context, plus response caching where identical questions recur.
Model routing
Simple requests go to a small, fast model and hard ones escalate to a larger one. The router itself is tested against the evaluation set.
Tighter context
Better retrieval means fewer, more relevant passages in each prompt — which cuts cost and often improves accuracy at the same time.
Streaming
Answers start appearing as they are generated, so users wait for the first words rather than the last.
Batch processing
Work that is not urgent — overnight classification, bulk summaries — runs through providers’ batch interfaces, which are priced lower than live calls.
Budgets and alerts
Cost and latency tracked per feature and per customer, with alerts and limits, so one heavy user or a runaway loop cannot surprise you.
UK and EU data residency
Where your data goes is a design decision.
There are three broad routes, and the right one depends on the data. Hosted provider APIs are the simplest and give access to the most capable models. Under business terms, the major providers do not train on API data by default, but processing may happen outside the UK, which your DPO will want covered by the right transfer safeguards.
Some providers and cloud platforms offer processing in UK or EU regions for certain models and plans. Availability changes often and varies by model, so we check it for your shortlist rather than assume. For data that must not leave your control at all, open models such as Llama or Mistral can run in your own cloud account in a UK region — at the cost of running and scaling that infrastructure yourself.
Whatever the route, the model receives only what it needs: personal data is redacted or pseudonymised where the task allows, retention settings are configured deliberately, and the data flow is documented for your DPIA.
- Hosted APIs under business data terms
- UK or EU regional processing where offered
- Self-hosted open models in your own cloud account
- Redaction, retention settings and a documented data flow
How we work
How we ship LLM features.
Our standard seven stages, run the way an engineering team would expect: decisions recorded, quality measured, and releases you can roll back.
- 01
Discovery
We review your current prototype or design, the data it needs and the user journey around it, then collect real examples to seed the evaluation set.
A first evaluation set and technical brief
- 02
Strategy
Model shortlist, retrieval approach, hosting route and latency and cost budgets, each written up as an architecture decision record your team can challenge.
Architecture decisions and a fixed quote
- 03
UX & architecture
Streaming, citations, loading and failure states, feedback controls, and confirmation steps for any action the model proposes.
Interaction design for uncertain output
- 04
Development
Two-week sprints in your repositories or ours. Prompts, retrieval and tool code change together, and every change is scored by the evaluation suite in CI.
A working feature on staging
- 05
Testing
Regression runs on the evaluation set, adversarial tests for prompt injection and data leakage, and load tests against the latency budget.
Evaluation and security test report
- 06
Launch
Rollout behind a feature flag to a slice of users, with tracing, cost dashboards and a rollback path in place before traffic grows.
A monitored production release
- 07
Optimisation & support
When providers update or retire models, we rerun the evaluation suite, compare cost and quality, and switch only when the numbers say so.
Model upgrades made on evidence
Engagement models
Ways to work with our LLM engineers.
A defined feature is usually a discovery sprint followed by a fixed-price build. Teams with an ongoing AI roadmap can add dedicated engineers to their own sprints, and flexible hours suit reviews and fixes to features that are already live.
Discovery sprint
From £2,000 fixed fee
You have an idea or a problem, but not yet a scope you would trust a quote against.
- Workshops with your team
- Prototype or technical spike
- Written scope, plan and estimate
Fixed-scope project
Quoted after discovery
A defined build — an MVP, a rebuild or a feature set — with milestones and a fixed budget.
- Agreed milestones and deliverables
- Milestone-based billing
- A demo at the end of every sprint
Dedicated developers
From £2,900 per developer / month
Ongoing roadmap work where you want named engineers inside your own sprints.
- Named, senior engineers
- Work inside your tools and sprints
- Scale up or down as the roadmap changes
Flexible hours
From £20 per hour
Fixes, small features and support where the work comes in bursts rather than sprints.
- Billed weekly for time used
- Daily written updates
- No long-term commitment
Prices are in GBP and show where engagements start, not a quote; every estimate is confirmed in writing after a discovery call. Model and API usage is billed separately by the provider, on your own account.
Why Techsleight
What working with us is actually like.
No inflated numbers — just how we run projects, and what you can hold us to.
Product engineering, not ticket-taking
We ask what the software is for before we estimate it — and we will tell you when something should not be built, or should be bought instead.
AI where it earns its place
LLM features, retrieval and automation built with evaluation, guardrails and cost controls, and plain software where that is the better answer.
Full-stack under one roof
Design, frontend, backend, mobile, cloud and QA in one team, so nothing falls between suppliers.
UK-focused delivery
UK business hours, estimates in pounds, and a contract with a UK company. Our engineers are based in the UK and India.
Flexible engagement
A fixed-scope project, dedicated developers or a monthly retainer — and you can move between them as the work changes.
You own everything
Code, IP, cloud accounts and documentation are yours from day one. We sign an NDA before discovery if you need one.
Support after launch
We stay on for fixes, upgrades and new features, or hand over cleanly to your in-house team with the documentation to match.
FAQs
Technical questions, answered plainly.
Straight answers on scope, cost, timelines and how we work. If yours is not here, ask us directly.
Which LLM should we use: GPT, Claude, Gemini or an open model?
The one that passes your evaluation set at the lowest cost and an acceptable latency, within your data constraints — an empirical question rather than a brand preference. We test a shortlist side by side on your examples. It is common to use a small model for routing or extraction and a larger one for the hard reasoning steps.
When is fine-tuning worth it instead of RAG?
Rarely as a first step. Retrieval handles knowledge that changes; prompts and examples handle most behaviour. Fine-tuning makes sense for a narrow, stable, high-volume task where a smaller tuned model beats a large one on cost or speed, or for a format or tone that prompting cannot hold. We measure the gap on your evaluation set before recommending it.
Can our data stay in the UK or EU?
Often, depending on the model. Some providers and cloud platforms offer UK or EU processing for certain models and plans, and open models can run in your own cloud account in a UK region. We check current availability for your shortlist and document the chosen route for your DPO.
How do you test an LLM feature?
With an evaluation suite built from real examples: rule-based checks for format and facts, a grading model where it reliably agrees with people, and human review of a sample. It runs in CI on every change to prompts, retrieval or model version, and a subset runs against production traffic to catch drift.
How do you keep API costs and latency under control?
By setting a cost and latency budget per feature and engineering to it: prompt caching, routing easy requests to smaller models, tighter retrieval, streaming, batch processing for non-urgent work, and per-feature dashboards with alerts. We report cost per task, which is the number your business case needs.
How do you protect against prompt injection?
We assume it will be attempted. Model output is treated as untrusted, tools run with least privilege, anything that writes, sends or pays needs confirmation, retrieved content is kept separate from instructions, and we test with adversarial inputs. The OWASP Top 10 for LLM Applications is our checklist. No defence is complete, so the architecture also limits what a compromised prompt could do.
Can you work alongside our in-house engineers?
Yes, and it is often the best arrangement. We work in your repositories, follow your conventions, code review and CI, and pair with your engineers in TypeScript, Python, C#/.NET or Java, so the LLM layer is understood and owned by your team when we step back.
How are prompts and model versions managed?
Prompts live in version control next to the code that uses them, with tests. Model versions are pinned rather than floating, changes ship behind feature flags, and each output can be traced to the prompt and model that produced it. When a provider retires a model, we run the evaluation suite on the replacement before switching.
Do we need a dedicated vector database?
Not always. For many products, vector search inside PostgreSQL — which you may already run — is enough, and it keeps permissions and data in one place. A dedicated vector database earns its place at larger scale or with specialised search needs; we decide on measured retrieval quality and load, not fashion.
Do you build agents, or single LLM calls?
Both, but we use the simplest design that does the job. A single well-structured call or a fixed workflow is easier to test and cheaper to run. Agents that plan their own steps suit genuinely open-ended work, and we build them with step limits, full logging and human approval for consequential actions.
Start a project
Taking an LLM feature to production?
Tell us what the feature should do, the stack it lives in and where it is now — idea, prototype or live and misbehaving. An engineer will reply with questions and a suggested next step.
What happens next
- 1A senior engineer reads your brief within one working day, and replies with questions or a first view.
- 2A 30-minute call to understand the goal, constraints and what good looks like — no sales script.
- 3A written proposal with scope, milestones, team and a GBP estimate you can take to your board.
Techsleight Labs is a trading name of Krapton IT Consultancy.
Explore