9io.ai / AI engineering
The demo was the easy part. Then it meets users.
A working prototype takes an afternoon now, which is exactly why so many AI projects stall at 80% and never ship. The distance between something that impresses in a meeting and something you can put in front of a customer is engineering — and it's almost never about the model.
None of these are fixed by a better model.
It works in the demo, not in the wild
The happy path is convincing. Then come the badly scanned document, the question phrased sideways and the request that should have been refused — and nothing handles any of them.
Nobody can tell if a change helped
Someone edits the prompt, it looks better on the three examples they tried, and it ships. Two weeks later a different case has quietly broken.
The answers are confident and wrong
With no grounding, no citation and nothing to validate against, the system invents. Users catch it once and stop trusting the feature — which is worse than never shipping it.
The bill is a surprise
Context grows, every request calls the biggest model available, nothing is cached, and spend per feature is invisible until finance asks.
It's a notebook, not a system
The intelligence lives in a script on one laptop, with prompts pasted into strings, no deploy path, no tests and no owner. There's nothing to put behind a login.
Nobody decided what it may touch
The moment a model can call tools, it can send, spend or delete. Without permissions, an approval step and an audit trail, your first security review will say so.
The parts that make it survivable.
Which of these apply depends on what you're building — including, sometimes, the recommendation not to use a model at all.
A test set that runs on every change
A fixed set of cases taken from your real inputs, including the failures found in production, scored automatically. A prompt edit or a model upgrade produces a number instead of an argument.
Retrieval that earns its keep
Ingestion, chunking, keyword and vector search together, reranking, and a citation back to the source — tuned against measurements rather than assumed to work because the library example did.
Guardrails and a human in the loop
Outputs validated before anything is shown or acted on, refusal behaviour that's tested rather than hoped for, permissions on every tool, and a person in front of consequential actions.
A cost and speed budget
The right size of model for each step, caching where work repeats, streaming where waiting is the problem, and spend tracked per feature — with the provider behind an interface, so switching is configuration rather than a rewrite.
The product around the model
The interface, the data store, sign-in, the release pipeline and the alerting. An AI feature is a product feature, and it needs everything a product feature needs before anyone will use it twice.
An architecture you can act on
How data flows, what leaves your boundary and what doesn't, which providers you depend on, and the trade-offs behind each choice. What's included as standard →
Three steps, no surprises.
Tell us what it should do
Describe the product, the data you have and what the AI is supposed to do for a user. You'll get a straight read on whether it's worth building.
Get a proposal with names on it
Who'd do the work, how many hours, and the rate — plus what we'd build first to find out if the idea holds.
Measured, then shipped
A baseline and a test set early, so quality is a number from the start. Then the product around it, released in short stages.
We run an AI system of our own, every day.
9io Alpha reads thousands of companies a day and writes up the ones worth a second look. Several AI passes argue the case from different angles, and a final pass reconciles them into one write-up with its reasoning intact.
It never acts on its own: every conclusion is put in front of a person, and every rule underneath it is tested on data it has never seen. That's a test set by another name, and it's why we insist on one for your build.
Take a look →- GroundedEvery conclusion tied back to the evidence that produced it.
- CheckedTested on data the rules never saw, so nothing is tuned to look good.
- Human-firstThe system presents; a person decides. Nothing is executed automatically.
Questions we get a lot.
How do you stop it making things up?
You can't reduce it to zero, and anyone who tells you otherwise is selling something. What you can do is make it rare, visible and contained: ground answers in real source material and show the citation so a user can check it, force outputs into a shape that can be validated before anything is shown or acted on, measure that behaviour in the test set rather than by spot-checking, and put a person in front of any action that spends money, sends a message or changes a record.
Where the system doesn't know, the right answer is to say so — and we test for that explicitly.
How do you know a change made things better?
Because there's a test set, and it runs on every change. It holds a fixed set of cases drawn from your real inputs, including the failures found in production, and scores each version — so a prompt edit or a model upgrade produces a number rather than a feeling. Without one, an AI product is edited by vibes and quietly gets worse. Building it is usually one of the first things we do, and it's yours in your repository from the first commit.
Should we fine-tune a model, or is retrieval enough?
For most products, retrieval plus careful prompting gets you further, faster, and stays cheaper to change. Fine-tuning earns its place when you need an output format that prompting keeps drifting away from, when cost or latency has to come down at high volume, or when you have a genuinely proprietary task with enough labelled examples.
The honest test is whether the test set shows the fine-tune beating the simpler version by enough to justify maintaining the pipeline. We build the baseline first, so that question has an answer rather than an opinion.
What does it cost to run, and where does our data go?
Inference cost is a design decision, not a bill that arrives: it depends on how much context you send, how often, which model handles which step, and how much can be cached or served by something smaller. We set a cost and speed budget per request at the start and track spend per feature.
Your data stays in infrastructure you own, under accounts you control, and what leaves that boundary is a decision written down rather than a side effect. You hold the provider keys, so the meter is always in your name.
When is the honest answer that we don't need AI?
More often than the market admits. If the task has a correct answer that a rule, a query or a well-designed form can produce, a deterministic version will be cheaper, faster and easier to trust — build that instead.
AI earns its place where the input is genuinely unstructured, where the range of valid answers is too large to list, or where the alternative is a person doing something repetitive and slow. We'll tell you when a feature you've asked for doesn't need a model.
Tell us what you're building.
Describe the product, the data you have and what the AI is supposed to do for a user. You'll get a straight read on whether it's worth building — including when a model is the wrong tool for it.
Replies come from the person who'd do the work.