AI engineering

AI is a feature in your product, not a product on its own.

We integrate AI into software people already use: a summarise button, an assistant that knows your own knowledge base, a workflow that drafts the reply and waits for a human to send it. Any of those will demo in an afternoon. The engineering is everything after the demo, which is where the answers come from, what it costs you per user, and what happens when the model is confidently wrong. That is the part we build.

Talk through a use case Read the glossary

If the terminology is doing more to obscure than explain, start at the glossary. It is written for the person signing off on the work rather than the vendor pitching it.

What we build

Four shapes this work usually takes.

Almost every AI project we are asked about is one of these, or two of them joined together. If yours is not, describe it and we will tell you whether it is something we can do well.

01 / integration

AI inside the product you already have

Adding AI-powered features to a live application: the provider integration, the interface around it, and the cost and failure handling that keeps it boring to operate.

Most of this work is not a new product, it is a feature in an existing one: a summarise button, a draft reply, a smart search box, a support widget. We integrate the model provider properly, stream the response so the interface feels quick, cap what a request is allowed to spend, and make sure a provider outage degrades the feature instead of taking the page down with it.

Claude, OpenAI and other provider APIs
Streaming responses and interface states
Cost, rate and token limits per user
Fallbacks when the provider is down

02 / assistants

Assistants and chat over your own data

A model that answers from your documents, tickets and database rather than from the open internet, with citations back to the source.

This is retrieval-augmented generation, usually shortened to RAG. Your content is indexed, the relevant pieces are pulled in at question time, and the model is asked to answer from those pieces only. It is the difference between an assistant that quotes your refund policy and one that invents a plausible-sounding refund policy.

Document ingestion and chunking
Vector and keyword search, combined
Answers with citations to the source
Permissions carried through to retrieval

03 / agents

Agents and tool use

Models that call your APIs to actually do the work, with the same permissions, rate limits and audit trail as any other caller.

An agent is a model in a loop that can call tools: read a record, send a draft, open a ticket. The engineering is not the prompt, it is the boundary around it. Every tool gets a typed contract, destructive actions get a confirmation step, and the whole run is logged so you can see what it did and why.

Typed tool contracts and MCP servers
Approval steps before destructive actions
Full run traces and audit logs
Budget and rate limits per run

04 / evaluation

Evaluation and monitoring

A test suite for behaviour that is not deterministic, so you find out a change made things worse before your users do.

Models are not stable the way code is. The same prompt can drift when a provider ships a new version, and a prompt change that fixes one case often breaks three others. We build an eval set from real examples, score every change against it, and keep watching cost, latency and failure rates in production.

Eval sets built from real traffic
Regression scoring on every change
Cost, latency and token dashboards
Fallback models and graceful degradation

Terminology

The words, in plain English.

This vocabulary is used loosely, often by people selling something. Here is what each term actually means and when it matters to your project.

The basics

ModelLLM, large language model: The trained system that turns your input into output. You do not install it, you call it: it lives behind a provider's API and your application is a client of it, the same as any other third-party service you integrate.
Token: The unit models read and write in, roughly three quarters of a word. It matters because you are billed per token in and per token out, so token count is the unit of cost.
Context window: How much text the model can consider at once, counted in tokens. Everything the model knows about your problem during a request has to fit inside it, which is why large documents get retrieved in pieces rather than pasted in whole.
Inference: One run of the model to produce an answer. Training is building the model; inference is using it. Almost all of what a business pays for is inference.
System prompt: The standing instructions that sit above the conversation: what the assistant is for, what it must not do, what format to answer in. It is configuration, and it belongs in version control like any other configuration.

Getting your own knowledge in

RAGretrieval-augmented generation: Search your content first, then hand the relevant extracts to the model and ask it to answer from those. It is how an assistant answers about your business without the model having been trained on your business.
Chunking: Splitting your documents into pieces small enough to retrieve and fit in a context window. Where the splits fall decides what the model gets to see, so it is a design decision rather than a default: cut through the middle of a table or a clause and the extract arrives missing the part that mattered.
Embedding: A numeric representation of a piece of text that puts similar meanings near each other. It is what makes search find the paragraph about "cancelling a subscription" when someone asked how to "stop being charged".
Vector database: Where those embeddings are stored and searched. Often a dedicated service, though for most projects a PostgreSQL extension does the job without adding another system to operate.
Hybrid search: Running meaning-based search and ordinary keyword search together, then merging the results. Vectors alone miss exact strings like an order number or an error code, and keywords alone miss anything phrased differently, so the systems that hold up in practice do both.

Making it do things

Tool callingfunction calling: Letting the model ask your code to run something: look up an order, check stock, send a draft. The model chooses and fills in the call; your code decides whether it is allowed to happen.
Agent: A model that runs in a loop with tools, deciding its next step from the result of the last one, rather than answering once and stopping. Useful for multi-step work, and worth bounding with limits on steps, spend and permissions.
MCPModel Context Protocol: An open standard for exposing your tools and data to a model in a consistent way. Write the integration once as an MCP server and different assistants can use it, instead of rebuilding the plumbing per vendor.
Structured output: Forcing responses to match a schema you define, so the result is a typed object your application can validate, not prose it has to parse and hope about.

Keeping it honest

Hallucination: A fluent, confident answer that is simply wrong. It is a property of how these systems work, not a bug to be patched out, which is why the design question is always what happens when it occurs.
Evalsevaluations: The test suite for a system that will not give the same answer twice. A scored set of real examples that every prompt or model change has to run against before it ships.
Guardrails: The checks around the model rather than inside it: validating output, filtering what goes in and out, capping what a tool is allowed to do, and requiring a human before anything irreversible.
Human in the loop: A deliberate approval point where a person reviews before an action lands. The correct answer for anything that spends money, sends communications on your behalf, or cannot be undone.

Words you will hear in a pitch

AI-powered: Marketing language rather than a specification. It tells you a model is involved somewhere, and nothing about where the answers come from or what happens when they are wrong. Both are worth asking.
Trained on your datayour own custom model: Almost always describes retrieval rather than training: your content is searched at question time and handed to a general model, which is the right design for nearly every case. Worth asking which is meant, because the two differ in what they cost to run, how quickly new information shows up in answers, and who ends up able to see what.
Copilot: An assistant that suggests while a person stays in control and approves. A useful shape for most business features, and a much safer default than one that acts on its own.
Prompt engineering: Writing and refining the instructions given to a model. Real, and roughly ten per cent of the job. The other ninety is the retrieval, the data, the validation and the evals around it.
Multimodal: A model that handles images, audio or video as well as text. Relevant when what your users give you is not typed text.

How we use it ourselves

Yes, we build with AI tooling. Here is exactly what that means for you.

It is a fair question to ask any engineering company right now, so we would rather answer it before you have to.

We use it, and we review everything it writes

AI coding tools are part of how we work: scaffolding, tests, refactors, reading unfamiliar codebases. Nothing reaches your repository that an engineer has not read, understood and taken responsibility for. The name on the commit is a person's.

It buys speed on the boring parts

Less time goes on boilerplate and more on the design decisions that actually determine whether the system holds up. Types, tests, reviews and deployment practice are all unchanged.

Your code and data stay yours

The tooling we use is configured not to train on client work, and we keep client code out of anything that would. If your organisation has rules about which tools may touch its codebase, tell us at scoping and we will work inside them.

We will tell you when AI is the wrong answer

Plenty of problems described as AI problems are better solved with a query, a rule or a form. When that is the case we will say so, because a feature that is right nine times in ten is a liability in most of the places people want to put one.

Describe the job it has to do.

Tell us what someone currently does by hand and how often they do it. We will tell you whether a model is the right answer, what it would cost to run, and what it would take to trust the output.

Start a project [email protected]