AI lab.
We embed AI into processes
that make money.
AI platforms are running, licenses are paid for, but the process still behaves exactly as it did before AI. We close that gap.
Why we are built this way
When AI starts inside a large company, everyone wants a platform. We have deployed systems in different industries and kept seeing the same thing: the process itself was never moved onto new rails, and no platform will do that for you.
No-code builders end the same way every time: six months of configuration, the original owner leaves, and nobody can maintain it. Buying a vendor platform ties you to the vendor’s delivery speed and architectural limits, and once you outgrow it the migration costs more than the whole deployment. Building everything in-house is just as wasteful: if mature open source already solves the problem, there is no reason to wrap it in yet another custom interface.
That is why we operate as a lab. We take one process, break it down to the smallest moving part, build the system, and judge it by the numbers. When an off-the-shelf solution works, we use it. When it does not, we build our own. If it still does not work, we say so directly.
Where AI breaks in large companies
Roughly 95% of deployments never reach positive ROI. It is not about weak engineering alone: AI deployment is first of all about changing the process and the operating model. What goes wrong?
The pilot lives outside the real process
AI is shown in an isolated scenario and looks impressive. Nobody embeds it into the real workflow because the real workflow contains dozens of edge cases that never appeared in the demo. The pilot remains a boardroom demo.
Nobody knows what will actually pay back
Everyone talks about quality, but as soon as you ask for the formula — what exactly is measured and what threshold counts as viable — the discussion turns philosophical. Without a formula, there is no way to distinguish a working system from a non-working one.
The data exists, but the decision logic does not
The company has documents, tickets, and chats. What it does not have is a record of why the experienced operator made a specific decision. Without that context, AI behaves like an intern who got database access but never learned the rules.
How we fix it
We start with one concrete process: its rules, data, exceptions, and the points where a human actually makes the decision.
Expertise is encoded into the system
We strengthen the operator instead of bypassing them: every correction becomes a training signal, and the system inherits human reasoning.
AI stays inside the process
The agent works inside the operator’s CRM, with the same interfaces and the same data, instead of another separate window nobody ever opens.
The first result in 2 to 3 months
We connect real data inside the client perimeter and assemble a working skeleton. Even if quality starts at 40%, it is a living system on your data that you can actually open and inspect.
The code and the knowledge stay with you
Repository, documentation, trained models. The client can keep developing the system in-house. Clients who own the system usually sign the next phase as well. That is why we are structured this way.
Platform
Across projects we kept hitting the same infrastructure problems. Out of those repetitions came six reusable modules: inference and routing, observability, guardrails, evaluation, document processing, and agents.
These modules are not equally mature: synthetic datasets and observability can move between projects almost unchanged, while document retrieval is always rebuilt for the exact task. We draw the boundary honestly: here is the open source that already works, here are our reusable layers on top, and here is the custom code that will always stay client-specific.
Inference, routing, observability, guardrails, evaluation, documents, agents — see how the platform is built →
How we start
One process, full access
We choose a process with real manual load, clear rules, and enough task volume. Then we connect directly to the client’s data and systems.
A working skeleton inside the client perimeter
We assemble the first version of the system on real data. A live route from incoming task to final outcome.
Decision by numbers
After the pilot you can see what works, where the quality ceiling is, and whether the economics justify production. If the numbers do not work, we say so directly.
Deployment examples
We work with companies where an AI project is part of the operating machine, not an experiment for a report.
Investment Division of a Large Bank
An AI agent that sells investment products inside the mobile app on its own. It watches triggers, starts the conversation, moves the client through the funnel, handles objections, and closes toward the deal. A human manager joins only if the client asks for one.
One of the Largest Telecom Operators
Operators spent 15 to 25 minutes per case, manually pulling context from three to five systems.
A cascade of three agents classifies the request, selects the scenario, gathers data from five internal systems, and drafts the response. The operator reviews instead of writing from scratch.
Operator of an Urban Transport System
One model hallucination is enough for a driver to believe the platform is broken and skip a shift.
AI support for drivers across email and Telegram. Every filter in the system appeared after a concrete production failure.
We also work with
-
Luchi Insurance A medical insurtech company in Europe’s top two, serving more than 4,000 corporate clients -
Accounting Cloud accounting and HR operations for hundreds of thousands of companies -
Integration A systems integrator delivering enterprise projects in the public sector and industry
The full engineering breakdowns live on the cases page. View cases →
Founders
Ilya Letunov
Technology
Built VK Cloud, an enterprise cloud platform inside VK. Worked with VTB, Gazprombank, X5, Magnit, Burger King, and L'Oréal. Grew from Java engineer to head of platform. MSU Faculty of Computational Mathematics and Cybernetics.
He knows how large companies buy, launch, and operate technology platforms and exactly where those efforts break down.
Dmitry Kibkalo
Business and product
Founder of Mosigra, from zero to 70 stores across 30 cities and then exit. Built companies with audiences above one million three different times. MSU Mechanics and Mathematics, Stanford GSB.
He knows how to turn a strong engineering system into an actual product and sales engine so it does not remain an internal victory for the development team.
Tell us which process you want to break down.
We will tell you whether the task fits AI agents and, if it does, outline a concrete plan.
Inquiry sent
We will reply within one business day to the email you provided.
or write directly to ilya@manaraga.ai