Applied AI and agents
AI models open up considerable possibilities. But they are never the starting point.
The starting point is the business: the problem to solve, the decision to improve, the use case to make possible, and the constraints that come with it. The choice of a model, an agent or an architecture comes after.
That is particularly true of LLMs. A convincing demo can fit inside a good prompt. A system that has to work every day, on real data and with real consequences, asks for a great deal more: an architecture, guardrails, a way to measure its mistakes, and clear accountability for what it produces.
A practice of AI that predates LLMs
Our experience with models does not start with ChatGPT.
We were already working with the first transformers — GPT-1, GPT-2 and GPT-3 — and with NLP models such as spaCy, Word2Vec or Sense2Vec, trained or adapted for highly specialised business problems.
Part of the Vezero team also comes from the original technical team at Owkin, where machine learning models, product and data were already tightly entangled. That experience shaped the way we approach systems built around AI: a model is only worth what the system around it makes of it, and what decision it allows someone to take.
Since then we have kept working on very different problems: specialised language models, conversational experiences, agents, real-time interfaces, data analysis, internal tools and decision-support systems. Vezero engagements span medtech, industry, energy, cosmetics, food and B2B software.
Fourteen projects running AI models are in production today.
The business before the model
We rarely start by asking which model to use.
We start by understanding what actually has to work: which information is available, what the user is trying to obtain, which errors are acceptable, which decisions can be automated and which must stay under human control.
Only then do the technical choices follow.
A more powerful model is not always a better answer. An agent is not always preferable to a deterministic workflow. A multi-agent system is only worth building if the problem genuinely calls for several capabilities that cooperate, or select themselves as it runs.
From demo to production
An AI system that works in a demo and an AI system that holds up in production are two different objects.
A demo mostly sets out to show that a behaviour is possible.
Production has to answer other questions: does the system always produce something acceptable? Can we understand why it fails? Can we measure the impact of changing a model or a prompt? What happens when the data is incomplete? Which information may be sent to which provider? How much autonomy can the system really be given?
These questions shape the way we work.
| Demo | Production |
|---|---|
| A convincing prompt | An architecture |
| A handful of cases tested | Continuous evaluation |
| Prepared data | Real data |
| A visible error | An observable error |
| A human in front of the screen | Guardrails |
| Negligible cost | Cost at scale |
Data and context
A model only knows what it is given.
So we have to know where the data comes from, whether it is reliable and fresh enough, how it is selected, what each user is allowed to see, and how the context sent to the model is assembled.
Sometimes that means RAG, sometimes specialised models, business tools, or simply a more rigorous preparation of the information.
The right architecture depends on the problem.
Evaluation
With a probabilistic system, “it works well” is not a measurement.
We set out to define representative business cases, expected behaviours and the errors that matter before letting the system evolve.
That is what makes it possible to compare versions, models or prompts on something other than an impression.
The more the output influences an important decision, the more central that ability to evaluate becomes.
Guardrails and autonomy
The question is not only what a model can do, but what it should be allowed to do on its own.
Some tasks can be fully automated. Others call for explicit validation, a deterministic rule, or a hand back to the user.
We match the level of autonomy to the consequences of a mistake.
An agent that suggests a turn of phrase and an agent that modifies a critical business record should not be designed the same way.
Observability
When a system relies on external or probabilistic models, it has to be possible to understand what happened.
Prompts, responses, tool calls, errors, latency, cost, model versions: all of it has to be observable when the context demands it.
Without that, improving a system quickly turns into a series of hunches.
Performance and cost
The quality of the answer is only part of the problem.
An interaction can become unusable if it takes ten seconds to respond. A very capable model can be out of all proportion to a simple task. An agent can multiply calls, and with them latency and cost.
So we arbitrate between model, parallelisation, caching, streaming, tools and architecture according to the experience expected and the real economics of the product.
Agents, when the problem calls for them
We do not build an agent when a plain workflow will do. And we do not build ten agents when one will do.
An agentic architecture becomes useful when a system has to interpret a situation, choose among several capabilities, use different tools, or adapt its trajectory to intermediate results.
Every degree of autonomy, though, adds execution paths, and with them more to test, observe and secure.
We saw it first-hand building a real-time conversational platform. It led us to work on the dynamic orchestration of many specialised agents, on selecting them according to context, and on the latency constraints required to keep a conversation feeling natural. That technology has since been integrated into several client products.
Downwards: more autonomy, more uncertainty, more cost, more observability required
What we have already built
Our projects fall into several families of problem.
Models applied to specialised trades
We work with Predicity on tools for the perfume and cosmetics industry, embedding specialised language models in demanding business environments. Other engagements cover food, industry and medtech.
Orchestration and conversational experiences
Gustav and Generous led us to design experiences where several AI capabilities take part in a single interaction, under real-time and interface constraints.
AI and real-time interfaces
Projects such as Kyutai or Aircall confronted us with problems where the quality of the model is not enough: latency, the readability of a recommendation, trust and interaction with the user matter just as much.
AI inside one specific product
On Decante, AI is deliberately confined to the uses where it brings clear value. The rest of the product rests on classic deterministic mechanisms. That too is how we think about applied AI: use a model where it genuinely improves the product, not because it is available.
Machine learning under hard business constraints
The experience gained at Owkin, and on projects such as Deeplife, taught us that a model cannot be separated from the data, the interface and the operational consequences of its output.
From models to products
We work with proprietary and open-source models, generalist and specialised ones, and with the various building blocks needed to embed them in real products.
The choice of technology comes after the choice of architecture and of the level of autonomy expected.
Our work is therefore not about defending a vendor, a framework or one single way of building AI systems.
It is about choosing the components suited to the problem, then making sure the whole stays observable, maintainable and workable over time.
How we frame, arbitrate and commit is set out in detail in the Vezero Method.