// build
AI Integration: Ship AI Features Inside the Product You Already Have
An AI feature is easy to picture as a model problem. It is mostly not one. Calling a provider and getting a good answer back is close to free. The work is everything that has to hold before that answer reaches a paying customer. A way to tell whether Thursday’s prompt edit helped. A rule about which untrusted text may reach the prompt. A check that the output is the shape you claimed. A number for what a single click costs. A defined behaviour for the hours your provider is down.
This page covers features your customers touch, inside the product you already ship. Internal operations work that removes repetitive tasks from your own team is our AI automations service. Autonomous systems acting on their own across your stack are agentic integrations. Three different buyers, three different ways of failing.
Five things that break, in the order they break
You cannot tell whether a change helped
A prompt edit is a deploy with no test. Somebody rewords an instruction on a Thursday, the demo looks better, and nobody discovers the regression until support volume moves. The fix is unglamorous. A few hundred real inputs from your own logs, and a written definition of a correct answer. Then a scored run in CI that blocks the merge when quality drops. Build that before the feature, not after the incident.
Untrusted input is now part of your prompt
A support ticket, a PDF, a web page, a customer’s own text. The moment any of them reaches a prompt, that text is closer to code than to data. OWASP lists prompt injection as LLM01, the first entry in its Top 10 for large language model applications. It is the failure that keeps appearing in shipped products. There is no filter that solves it. What works is a smaller blast radius. Separate the untrusted content from the instructions. Give the model the narrowest set of tools and data it can do the job with. Require a human confirmation for anything that writes, sends, pays or deletes.
The output is a string until you make it something else
Models return text, including when you asked for JSON. Every integration needs schema validation on the way out and a defined behaviour for a malformed response. It needs a refusal path for the cases where abstaining is the correct answer, and escaping before anything model-generated reaches a template. Rendering raw model output into a page is how a prompt injection becomes a cross-site scripting bug.
Nobody knows what a request costs
Token spend is a variable unit cost hiding inside a fixed-price product, and it is usually discovered through a bill. We instrument cost and latency per request and attribute both to a feature and a customer. The useful questions are which feature is unprofitable and which account is consuming a tenth of the budget. Retries, long contexts and chatty conversations are where the money goes, and none of them are visible in a provider’s monthly total.
The provider will be down
Rate limits, timeouts, latency spikes and outright outages are all normal operating conditions. Every model call therefore needs a timeout it actually respects and a bounded retry with backoff. It also needs a decision about what the user sees when the call fails. Usually the right answer is a smaller product for an hour: the form still submits, the draft is empty, the page says so. The wrong answer is a spinner that never resolves.
Where this sits next to the neighbouring services
The distinction is about who acts and where the work happens. AI integration is a feature inside your product, used by your customers, measured by whether they adopt it. AI automations run in your own back office and are measured in hours removed. Agentic integrations are systems that plan and act over several steps in your tools. They are measured by how many actions they take without an incident. A project can involve all three, but they are scoped, priced and governed separately. The risk profile of a summarise button is nothing like that of something with write access to your CRM.
There is a fourth boundary that catches a different buyer entirely. Suppose the product was built with an AI coding tool, so there is already a model call in it. The live questions are then whether the credential is server-side, whether the spend is bounded, and whether it is safe to let strangers sign up. That is triage on something that exists, not design of something that does not. It is a bounded, time-boxed pass, and it is our vibe-coded app launch service.
This page is the other half of that split. We design and build the feature that is not there yet. It comes with the eval set, the trust boundary and the degraded mode that make it survivable. When a launch pass finds that the feature itself needs rethinking instead of fencing in, it hands over to this one.
Lines we hold
A model does not go in front of a problem that a database query already solves. Nothing ships without an eval set, because the next person to edit the prompt deserves a way to know what they broke. If a model can write, send or spend, there is a confirmation step and an audit log in front of it. A feature that cannot carry both is one we decline. Fencing it is not on offer. You will not hear us claim that a first version is right every time.
What we hand over is not a wrapper around a provider’s API with a platform’s name on it. That is the cheapest thing to build in this category and the easiest to sell. It was not the thing missing from your product.
What you get
- An eval set from your traffic, wired into CI, so a prompt or model change that regresses quality fails the build instead of reaching users
- The feature itself, delivered as pull requests against your repository and reviewed by your engineers
- A written trust boundary naming which untrusted inputs reach the model, what it may do with them and what is stripped beforehand
- Output validation at the edge, with a schema, a refusal path, and a defined fallback for every response shape the model can return
- Per-request cost and latency accounting, broken out by feature and by customer, in a dashboard your finance team can read
- A degraded mode that ships with the feature, so a provider outage becomes a smaller product, not a 500
- A model-swap runbook, so moving provider or version is a config change plus an eval run, not a rewrite
How it runs
- 01
Decide whether the feature needs a model at all
Some of what arrives written as an AI brief is solved better by a query, a rule or a search index. All three are cheaper and deterministic. Ruling that out first is what stops you paying per token for work a WHERE clause already does.
- 02
Build the eval set before the prompt
Without a labelled set of real inputs and an agreed definition of a good answer, nobody can say whether a change helped. Skip it and you are shipping on impressions. The regression is silent by construction, and the thing that finally reports it is a support ticket.
- 03
Draw the trust boundary
The moment untrusted text reaches a prompt it behaves more like code than like data. What the model may read, and what it is allowed to trigger, is a design decision made up front. A filter bolted on after an incident is the other thing.
- 04
Ship behind a flag, failure path first
We write and test what happens during an outage, a rate limit, a timeout and a malformed response. That work lands before the happy path reaches a single user. Your provider's bad day becomes your bad day on the day you depend on it.
- 05
Watch adoption and unit cost together
A feature that is loved and unprofitable and a feature that is cheap and ignored are both failures, and both are cheap to fix early. We report usage and spend against the same release so the tradeoff is visible.
Questions we get asked
- How is this different from the AI automations you sell?
- AI automations run inside your own company and remove repetitive work from your team. This page is about a feature your customers use, inside the product they already pay for. The third case, systems that take multi-step actions across your stack under governance, is our agentic integrations service. Different buyers, different measurement, different ways of going wrong.
- Can you just write us a good prompt?
- We can, and it is the least valuable thing we would do for you. A prompt that looks excellent in a playground and has no eval set behind it is a liability. The next person who edits it has no way to know what they broke. If a prompt is genuinely all you need, write it yourself and keep the money.
- What will this cost to run every month?
- We will not guess before we have seen your traffic shape. The monthly figure comes from input length, output length, retry rate and how chatty your users turn out to be. The last three are not knowable until the feature meets real traffic. What we commit to is a dashboard. By the time it is behind a flag you will have cost per request, per feature and per customer. The number comes from measurement, never from an estimate.
- Our data is sensitive. Does it leave our infrastructure?
- That is your decision, made explicitly and written down, not one we make quietly in a config file. We list exactly which fields go into a prompt, which provider receives them, and under what retention terms. Where that is unacceptable we will scope a self-hosted or on-region model instead and tell you honestly what quality you give up.
- What happens when the model gets it wrong in front of a customer?
- It will, so the design assumes it. Structured outputs are validated against a schema before rendering. Low-confidence cases abstain instead of improvising. Anything that writes to your database goes through a confirmation step, and every response is logged with its inputs, so a complaint can be reconstructed. Nobody has to argue about what the model said.
- Does this lock us into one model provider?
- Partly, and we would rather say so. Calls sit behind an interface and the eval set makes switching testable, so a swap is a day of work, not a quarter. But prompts are tuned against a model family, and quality does shift when you move. Measuring that shift before you commit is exactly what the evals are for.
- We have our own engineers. Why would we bring you in?
- Has your team already shipped an evaluated, cost-instrumented AI feature to production? Then you do not need us, and we will say so on the call. Otherwise what you are buying is exposure, not ability. A strong team doing this for the first time pays for its education in production. The tuition arrives as the eval set nobody built and the injection path nobody drew.