AI Integration & Development
AI Integration & Development
Not a chatbot bolted onto the corner of your site. Language models are now good at the work that used to need a person reading something — a customer's message, a supplier's invoice, a product's specification, an enquiry — and deciding what to do with it. AI integration is putting that ability inside the store, website or system you already run, so the work happens there, with your data, under your rules.
It is the same team and the same terms as the rest of what we build: a written scope, milestones you can test, the accounts in your name at launch, and what you own of the code agreed in writing first.
If you want the vocabulary first — language models, retrieval, agents, evaluations — it is explained in plain terms in AI automation, RAG and LLMs, explained. The systems we most often add this to are our own builds: ecommerce stores, Shopify apps, MLM back offices and real estate sites. The mirror image of this work, being cited by AI assistants rather than using them, is answer engine optimisation.
What we build
The same questions, all day, from people who already bought.
Answers drawn from your own orders, policies and product data, in chat or email, with a hand-off to a person when the model is not sure. Your team keeps the conversations that need them.
Most often added to an ecommerce storeInvoices, purchase orders and forms, typed in by hand.
Paperwork read into structured data and pushed into the system it belongs in, with a person checking only the ones the model flags.
Built into the business system you runThree thousand products and no descriptions.
Product descriptions, attributes, categories and translations generated from your own data, reviewed before publishing rather than published blind.
For stores with a large catalogueEnquiries arrive at 2 a.m. and nobody qualifies them until 9.
Each enquiry read, scored and routed as it lands — right listing, right budget, right person — with the follow-up drafted for a human to send.
Built for real estate lead capture, among othersThe answer is somewhere in four hundred documents.
Ask in plain language and get an answer with the source shown, across manuals, contracts, tickets or a knowledge base, limited to what each person is allowed to see.
How retrieval keeps it honestThe software you already run, needing to understand language.
A feature added to the store, app or platform you have — a Shopify app that reads supplier emails, an MLM back office that answers distributor questions — rather than another tool beside it.
Inside a Shopify app Inside an MLM back officeHow we build it
We measure what the work costs you now — hours, delay, errors — so there is a number the result has to beat. If a rule or a form would beat it more cheaply, that is what we recommend.
A hosted model from one of the major providers, or an open-weight model on your own servers when data must stay there. Either way it sits behind one switch, so it can be swapped when the provider changes it.
Confidence thresholds, hand-offs and review queues are designed in from the start. The model handles the routine; the exceptions still reach someone who can decide.
A test set built from your real cases, measured before sign-off and kept for re-checking. Every request logged, so when something goes wrong you can see what the model saw.
Before you ask
Whichever fits the job and your data rules. Hosted models from the major providers (OpenAI, Anthropic, Google) where they are the right tool; open-weight models such as Llama, Mistral or Qwen run on your own servers where data cannot leave them. The choice is made per project and written into the scope, and the code keeps the model behind a single switch, because models change faster than software does.
Only where you have agreed it can go. If a hosted model is used, we tell you exactly what is sent to it, strip what does not need to be sent, and use the provider's business terms, under which your data is not used for training. If your rules say data stays in your region or on your own servers, we build with a model that runs there. If something you have asked for does not fit the obligations you have, we say so before building it.
You do, directly. The provider account and the API keys are opened in your name, so you see the bill and control the spend, and nothing routes through us. Before the build we estimate the monthly cost from your real volumes, and we set spending limits so a spike cannot surprise you.
Providers retire models and change prices with a few months' notice, so this will happen during the life of anything we build. The integration keeps the model behind one switch, and the test set used to sign the work off is kept, so a replacement can be checked against the same cases before it goes live. Swapping is a small piece of work, not a rebuild.
By keeping it to what it can check. Answers are grounded in your own documents and records, with the source shown. Where the model is not confident it hands off to a person rather than guessing. Anything customer-facing is measured against a set of real cases before launch and monitored after it. We do not put an unchecked model in front of your customers.
Sometimes not, and we will say so. A rule, a lookup or a well-built form solves a good share of what gets described as an AI problem, and costs nothing per use. AI earns its place where the input is language or documents that vary, such as customer messages, supplier paperwork or product descriptions, and where a person is currently reading each one.
The provider accounts, the keys, your data and the evaluation set are yours, in your name, with full access handed over at launch. The code and the prompts are yours where the contract says so, which for an integration built into your own systems is the usual arrangement. The quote states it before work starts.
Describe the work your team repeats, in plain language. If a rule or a form solves it, we will tell you that instead; it costs less and it does not need a model.
Start a conversation