Ship something new
Take the AI demo to production
The model is not the hard part. We build the durability, the permissions and the evaluation around it, and put the thing in front of real users.
It works in the notebook and nowhere else
The prototype convinced everyone. Then somebody asked three questions and the project stopped.
What happens when it times out
A run that takes two hours and calls six systems has no answer for a deploy in the middle of it, so it starts again, or worse, half-finishes.
What is it allowed to see
It got a broad service account because that was quickest. Its access is now wider than any person's and nobody has reviewed it.
Is this version better
The prompt changed. Whether the thing improved is decided in a meeting by whoever is most confident.
None of these are model problems and a better model fixes none of them. They are all properties of the system around it, and that system is what does not exist yet.
The shift
Three ways a demo becomes a product
Two of them are the demo again, with more infrastructure.
Ship the prototype
Fast, and it breaks in public
Rebuild it properly, later
Correct, and it never starts
Build the system around it
In production, and explainable
What we build around the model
The half nobody demos, which is the half that decides whether it survives.
Durable runs
The work is a workflow. A restart, a crash or a deploy mid-run resumes rather than starts over, and a retry does not repeat what already happened.
Grants, not prompts
The system reads through the same permissions a person would. An agent reaching a table it has no grant for fails the way any principal fails.
Retrieval that cites
Every answer carries the documents behind it, so checking it means reading the source rather than trusting the summary.
An evaluation suite
Ground truth you own, deterministic scorers, and model-based judges where correctness is a matter of degree.
Human approval where it belongs
The actions that warrant a person stop and wait, and the approval is recorded against the exact operation.
Cost you can see
Model spend, retrieval infrastructure and the review time it still needs, instrumented at build time rather than discovered on an invoice.
2
Of our own products running on it, in production
The same work we did on our own
Fabric and Canvass are both in production and we are on the pager for both. Every part of this list exists because one of them needed it before a client did.
Clients we have done this for
AI systems · Our own product
Fabric
Fabric is a context store, memory and agent runtime built on Databricks, and it is the clearest evidence of what we build: across our clientele, work that took a team of ten now takes three.
Automotive / Fintech
Auto Approve
Auto Approve connects consumers to a nationwide lender network to refinance vehicle loans. TechFabric built an automated approval engine that doubled monthly loans processed and replaced more than four manual workflows.
FAQ
AI features to production: common questions
We have a prototype already. Do you start over?
Almost never. The prototype proved the idea, which is the expensive part to be wrong about. What is usually missing is everything around it, and that gets built underneath what you have.
Do we need to be on Databricks?
No. It is where we are deepest, and this work runs on Azure, AWS and Google Cloud too. What matters is whether the thing has to be governed and explainable.
How do you know it is working after we hand over?
The evaluation suite is yours and it runs on every change. That is the point of building it: the answer stops depending on who is in the room.
If your problem is shaped differently
Build an agentic software factory
Launch a product in a regulated vertical
Move off the warehouse without a Friday night
Make the estate answer for itself
Modernise the estate that outgrew itself
Keep people in charge of the agents you already run
Leave your team able to do it without us
See what production is doing, and be allowed to act