AI that reaches production, not just the demo
73% of enterprise AI projects never reach production, and MIT measures 95% mortality in pilots. We design, measure and operate the ones that make it: three years of continuous operation of a RAG architecture serving two million active users across ten countries.
Key takeaways
- 73% of enterprise AI projects never reach production, and MIT measures 95% mortality in pilots: the sector's problem is not adopting AI, it is sustaining it.
- Quarl designs, measures and operates AI systems in production — agents, RAG and language-model applications — plus custom software, mobile apps and integrations.
- The track record is a RAG architecture operated for three years serving two million active users across ten countries, at 99%+ sustained availability.
- Eleven services in two groups, with fixed scope, price and date in a proposal that arrives 48 hours after a free 15-minute call.
Operating track record
Three years operating the system in production — not one delivery and an exit.
The most frequent failure in RAG architectures, solved with structured metadata at ingestion.
The proposal arrives within 48 hours with fixed scope, price and date. If scope changes, it is quoted separately and approved first.
A lot of AI gets bought. Very little reaches production.
These numbers are not ours — they are the market’s. And they explain why most implementations disappoint.
Building the demo takes a weekend. Sustaining it is a different craft.
A prototype that answers five rehearsed questions takes two days. The problem shows up in month three, with questions nobody anticipated and information that changed: the assistant answers about the wrong entity, invents what it does not know, the model bill climbs, and nobody has a number that says whether it got better or worse.
That distance — between the Jupyter notebook and the system that survives eight months — is where the 73% die. You do not cross it by reading documentation. You cross it by having been on the other side when the knowledge base grew fourfold and the failures no tutorial mentions started showing up.
We measure what everyone else promises
- An evaluation set from day one. Real questions from your users with the correct answer validated by your team. Without it there is no way to know whether a change improved or degraded the system.
- Retrieval and generation measured separately. recall@k, MRR and NDCG on one side; groundedness, faithfulness and relevance on the other. Two different diseases, two different treatments.
- Explicit refusal. When retrieval comes back empty, the system says so and escalates to a person. An assistant that admits it does not know is worth ten times one that improvises.
- Cost per query under control. Task-based model routing and context trimming, so the bill does not make scaling impossible.
- Observability from deployment. Step-level traces, hallucination detection and alerts. A system that fails silently is worse than no system.
A RAG system in production: three years, two million users
We built and operated the assistant for a FEMSA loyalty platform — Mexico’s largest company by revenue — serving more than two million active users across ten countries.
We owned the full pipeline: document ingestion and normalization, chunking, embedding generation, vector store on Azure AI Search and Pinecone, retrieval and grounded generation on LangChain.
The failure that took the most work to solve: the system returned the correct passage about the wrong product, because "Premium plan pricing" and "Basic plan pricing" sit almost on top of each other in vector space. We fixed it by extracting structured metadata at ingestion time and filtering by entity before ranking, instead of trusting semantic similarity. It is the number one failure mode of RAG systems and almost nobody mentions it.
It held above 99% uptime for three years.
Fixed scope, fixed price, fixed date
- A 15-minute call, freeYou tell us what you want to build or what stopped working. If it does not make sense to do it with AI, we say so on that call. Booked online, with no back-and-forth.
- Proposal within 48 hoursFixed scope, price and date. If scope changes later it is quoted separately and approved first — it never shows up as a surprise on the invoice.
- Weekly working incrementsYou see something running from week one. No disappearing for a month and returning with a surprise.
- Handover, documentation and a month of supportThe code, the documentation and the evaluation set are yours, so your team can maintain and verify the system without depending on us.
What we build with
Frequently asked questions
How is this different from an agency charging a monthly subscription?
They sell access to a tool; we hand over a system that is yours, with its code and documentation. Subscription platforms work well for a simple FAQ bot — if that is what you need, hire them, they are cheaper. The difference appears when your information is large, changes often, or when a wrong answer costs you a customer: that is when you need to measure answer quality, and that is engineering, not configuration.
How is an AI project quoted?
With fixed scope, fixed price and fixed date, in a proposal that arrives 48 hours after the first call. Price is driven by three things: the volume of information, how many systems have to be integrated, and how much precision the case demands. If scope changes mid-project it is quoted separately and approved first — it never shows up as a surprise on the invoice. The diagnostic call is free and the range comes out of it.
Do you work with companies outside Colombia?
Yes. We are in Medellín (UTC−5), with full overlap with US Eastern and Central hours and all of Latin America. Most of our work in recent years has been remote with teams in Mexico, the United States and Colombia.
Is our data used to train models?
No. We use enterprise plans where data sent through the API is not used for training. When the case requires it we deploy on Azure OpenAI or Amazon Bedrock inside your own subscription, so information never leaves your infrastructure, and we filter personal data before anything reaches the model.
What if we already built something and it does not work?
That is the most common case that reaches us. Start with a diagnostic rather than a rebuild: the language model is almost never the problem — how the information was prepared and retrieved is, and that part can be rebuilt without throwing away the rest. In a week you know whether it can be rescued or should be rebuilt, with numbers behind the recommendation.
Do you work with agencies and product teams?
Yes, in two formats: fixed-scope projects with a defined deliverable, or a retainer embedded in your team, your process and your repository. For agencies we work white-label and only speak to your client if you want us to.
How long until we see something working?
An automation, two to three weeks. An assistant over your information, three to six. A system integrated with your business systems, six to eight. In every case you see something running from the first week, not at the end.
What happens when the project ends?
Everything is yours: code, documentation, infrastructure and the evaluation set so you can verify quality without us. We include a month of support to adjust whatever real usage surfaces, and after that maintenance is optional and quoted separately.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.