1. What an agent is and what it is not
The word has been stretched so far that it no longer distinguishes anything, so it is worth pinning down. The difference is not in the model: it is in whether the system can do something or can only say something.
It answers with what the model knows or with what you pasted into the message. It does not query your systems, does not execute anything and leaves no trace of why it answered what it answered. When it gets something wrong, there is no way to audit what happened.
It queries your real sources, uses tools — create a ticket, look up an order, draft a reply —, decides when to stop, and logs what it consulted, what it decided and with what confidence.
Put another way: a chatbot is a conversation, an agent is a step in a process. And because it is a step in a process, it gets designed, measured and supervised like any other.
2. What we actually solve
The four briefs that reach us most often:
- “The same twenty questions every day.” Internal queries — where is this order, what does the procedure say, what is this customer’s price — that tie up the person who knows most, who is precisely the one least available.
- “Nobody can find anything in our documentation.” Hundreds of documents where the answer exists but the search only looks at the file name.
- “First contact with the customer takes too long.” Requests waiting for somebody to read them, classify them and decide who handles them.
- “Qualifying a lead takes us half an hour of digging.” Searching the web, cross-checking the CRM, deciding whether it is worth a call.
3. How it works
A useful agent is built on four decisions, and all four are taken before any code is written:
- What it can access. It is given access to specific sources — a folder, some tables, a mailbox — and not to everything for convenience. What it does not need, it does not see.
- What tools it can use. Every available action is declared one by one: query the ERP, create a ticket, draft a reply. The ones that write to a system are kept separate from the ones that only read, and they usually ask for confirmation.
- Where the limit is. What it must never do on its own, what requires approval, and what happens when it is not sure. An agent with no written limit ends up having one anyway, but discovered in production.
- What gets logged. What it was asked, what it consulted, what it decided, with what confidence and what it executed. Without that log you cannot audit an error or notice that quality is degrading.
On the model: it is chosen according to the case and the data it will handle, and it is not a permanent decision. What is permanent is the design above, and that is what lets the agent change model without being rebuilt.
4. Typical cases
Our clients are currently in manufacturing — discrete and process: automotive, food and drink — which is where our track record is. The others are patterns that repeat in any sector.
Manufacturing: automotive, food and drink
The shop floor and the engineering office ask about specifications, tolerances and procedures held in the document system. The question always ends up with the two people who know, and when they are away it stops.
The agent answers with the document reference and its version, and escalates to those two people only what it cannot find.
Customer service
The inbox mixes orders, incidents, returns and marketing. The first response depends on who opens the mailbox and at what time.
The agent classifies, routes by type and urgency, and proposes a draft for the frequent cases that a person approves or corrects.
Sales
Qualifying a lead means digging through the web, cross-checking the CRM and deciding whether it deserves a call. Half an hour per lead, done by the person who should be selling.
The agent gathers the information, checks it against what is already in the CRM and hands over a sheet with its recommendation and the sources.
5. What you need before we start
- A source of truth. Documentation, tables or systems where the correct answer exists. An agent does not invent what the company has not written down somewhere.
- That source reasonably up to date. If the documentation has three contradictory versions, the agent will pick one and it will look as though the agent is the one getting it wrong.
- A verifiable definition of correct. Somebody has to be able to say whether an answer was right, or there will be no way to detect when it starts to degrade.
- A person reviewing at the start. In the first weeks the threshold is tuned with real cases, and that needs somebody watching.
- Deciding what we do not want it to do. It matters more than deciding what we do want it to do.
6. When this is NOT the answer
- The process is deterministic. If the rules are clear and stable, ordinary automation is cheaper, faster and perfectly predictable. Putting an agent in there only adds cost and uncertainty.
- There is no source of truth. If the knowledge lives only in somebody’s head, it has to come out of there first; that is a different project and it should be called by its name.
- The error is not tolerable. In decisions with serious and irreversible consequences, the agent can propose, but a person decides.
- An agent is wanted in order to show it off. It is the most expensive reason of all and the one that ages worst.
7. Transparency and regulation
An agent that interacts with people falls squarely under the transparency obligations of Article 50 of Regulation (EU) 2024/1689: the person has to know they are talking to an AI system, and generated content has to be marked as such. That is what applies to most business agents, and it is a level well below high risk.
There are exceptions that do escalate: an agent involved in recruitment or in worker evaluation falls under high risk, with considerably greater obligations. We classify it before development, not afterwards.
The application timetable and the detail of each level are on the AI compliance page, which we keep up to date every time the regulation changes.
8. How the return is measured
- Queries resolved without human intervention, as a share of the total. It is the metric that governs and the one that rises over time.
- Time to first response, before and after.
- Hours freed from the people who answer those queries today, with their equivalent cost.
- Accuracy rate on reviewed cases, watched in order to catch degradation.
The full measurement framework is in how the return is measured in the guide.
Note: this page is for information only; it is not legal advice nor a guarantee of results. The figures quoted are usual ranges in real projects, not contractual commitments, and they depend on the scope and the starting point of each company.
9. Frequently asked questions
What is the difference between a chatbot and an AI agent?
A chatbot answers with what the model knows or with what you pasted into the message: it does not query your systems, does not execute anything and leaves no trace of why it answered what it answered. An agent queries your real sources, uses tools — create a ticket, look up an order, draft a reply —, decides when to stop and logs what it consulted, what it decided and with what confidence. Put another way: a chatbot is a conversation, an agent is a step in a process.
Can the agent get things wrong and do something bad?
It can get things wrong, which is why it is designed on that assumption. Actions that write to a system are kept separate from the ones that only read and usually ask for confirmation; every case carries a confidence level and anything below the threshold goes to human review; and everything it decides is logged, so what happened can be audited. An agent with no written limits and no log is not a saving, it is deferred risk.
Is it trained on our data? Does that data end up with a third party?
Your data is not used to train third-party models. The agent consults it at the moment of answering; it does not fold it into the model. If your case requires it, the solution is deployed on your own infrastructure. And access is granted to specific sources — a folder, some tables, a mailbox — not to everything for convenience.
Can it deal with end customers directly?
Yes, and that is where Article 50 of the European AI Regulation applies: the person must know they are talking to an AI system and generated content must be marked. In practice we recommend starting internally — internal queries, drafts a person approves — and opening up to end customers once the accuracy rate has been stable for weeks.
What legal obligations does an agent that talks to people carry?
The transparency obligations of Article 50 of Regulation (EU) 2024/1689: making clear that this is an AI system and marking generated content. That is where most business agents sit. Specific cases such as recruitment or worker evaluation escalate to high risk, with considerably greater obligations. We classify the use case before development, not afterwards.
How long until it is in production?
An agent scoped to one specific domain is usually running with supervision in three or four weeks. What stretches the timeline is almost never the development: it is the state of the documentation or the data it has to consult.
Does it work with our internal documentation?
Yes, that is the most common case, with one condition: the documentation has to be reasonably up to date. If there are three contradictory versions of the same procedure, the agent will pick one and it will look as though the agent is the one getting it wrong. When we find that, we say so before starting: tidying up the documentation is a different project and it is worth calling it by its name.
Services that usually go with this one: process automation · systems integration.