Today it is easy to get something with AI that seems to work: a demo, a prototype, a surprising first result. The hard part comes later, when it has to work with real data, unexpected cases and everyday work. That is where many projects stall.

The reason is simple: AI is exceptional at the well-bounded task, but the value, and the risk, lie in the whole.

We work precisely on the whole. We combine a scientific understanding of how models work with solid engineering experience.

We start from your processes, not from the technology. We design the entire intervention, prove feasibility with criteria set in advance and compared with the results you achieve today, then introduce AI gradually and monitor it over time.

We build architectures that don't depend on the model of the moment, and the code, the data and the documentation remain yours.

An example: we ask an agent to add a feature that doesn't fit well with the existing system. The agent will find a way to make it work, perhaps with a special case or a shortcut. The task is done. A good engineer, instead, would stop and say: “If this feature doesn't fit the design, maybe the design needs rethinking.”

Whoever designs a system holds an overall vision of it, and every decision moves in its direction. This vision can be written down, and it should be. What cannot be delegated is responsibility for the goals, and therefore for changing the vision when reality proves it wrong.

This is why the engineer's role shifts: less code writing, more design. The engineer defines the structure and breaks the work down into well-defined tasks. Each agent gets the context it needs: the information for its task, the design constraints that must not be violated, and a way to flag when something doesn't add up.

This is how good teamwork has always been organized. The method stays; what shifts is where the weight falls.

The gap between demo and production is not bridged by adding code, but by design. Without a solid architecture, the demo will not adapt to real cases and cannot be maintained over time. Every new case becomes an exception to handle separately, until the system is no longer sustainable.

It is the same pattern as the agent that completes its task with a shortcut: the immediate result is there, the overall vision is missing. You cannot foresee every case a system will face. But you can decide from the start which parts will stay stable and where the system must be able to change.

There is also a real difference from traditional software: AI-based components are not deterministic. The same input can produce different results, and an error can look entirely plausible. This is why a system with AI is not tested just once. It must be verified continuously, actively looking for the errors nobody would report.

Programming languages that were once popular and technologies that were once widespread have become obsolete. The architectures that had separated tasks from technologies were able to replace them, and they survived. Technology is a tool: it serves to implement the components of an architecture, not to define it.

In today's AI landscape the same pattern repeats, only faster. New technologies and new language models keep emerging and seem to sweep away the “past”, a past that is often only a few months old. Just think of prompt engineering: hailed as the skill of the future, within a year it changed nature. Newer models understand instructions without special formulas, and what matters today is giving them the right context. The skill did not disappear, it transformed.

Understanding the technology in depth is precisely what lets us tell what remains true when the tool changes. An example: in the early days many people handed mathematical calculations to AI agents, which a language model cannot perform reliably. Our principle is: deterministic where possible, probabilistic where needed. Calculations, rules and checks go to code; interpretation and language go to AI.

This is why we don't design around a model or a tool. We design architectures in which every component has a clear task, and the technology that implements it can be replaced when a better one comes along. The value lies in the design, not in the tool of the moment.

If we work on AI, it is not to chase it. It is because today AI is exactly where architecture is most often neglected.

The same applies to company knowledge. A company that over the years has organized and catalogued the information it produced holds a valuable asset: documents, decisions, procedures, the reasons behind past choices.

A company that hasn't done so runs into difficulties today. Its knowledge lives only in people's heads, or is scattered across emails, chats and shared folders. The AI agents it introduces give generic answers, because they don't know the company's specific reality. Or they fill the gaps with plausible but wrong assumptions, which is the worst case, because the error goes unnoticed. The result disappoints, and people often conclude that “AI doesn't work”, when the problem lies upstream.

To us, knowledge that can be written down should not live only in people's heads. Adopting AI is an opportunity to put things in order: to catalogue knowledge, make it accessible and keep it up to date. It is an investment that pays off twice, because what makes information usable by an agent also makes it usable by people.

Within a process, AI agents are like specialized people: each one has its own task. And like a person, an agent works best when it receives all and only the information its task requires. Superfluous information doesn't help, it confuses.

Cataloguing all knowledge doesn't mean giving all of it to everyone. It means it is accessible, and that each agent or person receives what they need.

The minimum context always includes two things: the constraints that must not be violated, and a way to flag when the task doesn't add up. A good specialist doesn't force a result: they alert whoever is coordinating. An agent must be able to do the same.

This isn't a new idea either. It is the principle by which good software systems have been designed for decades: each component knows only what it needs.

An adoption that respects the way people work is more readily embraced and delivers results sooner. The code, the data and the documentation belong to the Client: adopting AI leaves the company stronger, not more dependent.