AI agents, what they are and what they do for your company

Not all agents decide the same way, and that accounts for much of the price difference, both what one costs to build and, above all, what it costs to keep running. Three categories will place almost anything you are offered.

That third kind deserves a warning of its own, because “it learns from your data” is one of the most repeated phrases in this industry and it almost never means what it sounds like. An agent in production does not improve on its own. It improves when a person changes its instructions, tidies the data or adds cases to the test suite. Somebody always carries that change out.

If you are told it learns on its own, these are the three questions worth asking: what exactly changes, who carries it out, and how anyone checks that nothing else got worse. They work just as well put to the supplier who is going to build the thing as asked of yourself, to understand better what is being built.

Almost any proposal you receive fits one of these five shapes. It is worth knowing which one you are being sold, because what really drives the cost of testing it, watching it and fixing it when it breaks is the shape, more than the type of agent inside. The first two carry no agent at all. The last three are what the market calls agentic AI.

“It works for everything” is the answer that helps nobody. In practice, almost everything running inside a company today falls into a handful of uses. The five below are in production and they are ours, so we can tell you how they work inside and what it took to get them running.

You will notice the same shape in all of them. There is a text somebody had to read and a piece of data or a system on the other side. When one of those halves is missing, there is almost always a cheaper way to solve it than an agent.

None of this is plug and play. The gap between a good result and a disappointment is almost always in the scope, rather than in the model. Too broad and the system risks being mediocre at everything and earning trust for nothing. Too narrow and the wiring costs more than the work it saves. The projects that go well pick one task with a clear boundary around it, prove it, then widen it.

What these systems are genuinely good at is reading what arrives without a fixed shape, understanding a request written twenty different ways, following a procedure step by step and acting within a closed set of actions someone approved. That list is new, and it is why processes that survived every earlier wave of automation are in play now.

What they do not do is invent knowledge nobody wrote down, guarantee an outcome without code checking it first, or improve on their own while nobody measures. Part of our job is telling you when you do not need an agent. Sometimes a rule, a well-built form or a redesigned process is enough, because a model sitting on top of a broken or badly framed process only makes the mess arrive sooner.

There is a risk almost nobody budgets for. A system with AI in it can get worse on its own, without anyone touching it. The provider updates the model without changing its name, your documentation grows and your data drifts. Chen, Zaharia and Zou, at Stanford and Berkeley, measured this on the same commercial model in March and in June of 2023. Its behavior changed so much that on one task accuracy went from 97.6% to 2.4%, with nothing touched on the customer side. Gartner calculated in June 2025 that more than 40% of agentic AI projects will be canceled before the end of 2027. In our experience that mortality lives in the upkeep, not in the launch.

Models are not deterministic, they do not always return the same thing, so checking one answer on one day guarantees nothing. The only discipline that works there is statistical and dull. Before any change ships, a suite of real annotated cases has to pass. If quality drops, the change does not go out.

After launch the watching does not stop. Once a week we replay a real conversation end to end against the live system. In the plant assistant, routing accuracy was measured on real cases and went from 72% to 91%. We also knew when to stop. Chasing a hundred percent ends with you tuning the tests until they pass rather than improving the system. In Wazzy, for instance, we started with an architecture of agents with tools at their disposal and have rebuilt it three times before landing on the one that genuinely raised the share of conversations that end well.

None of these figures appears by itself. They exist because the system was built from the start to measure itself, with its test suite and its weekly watch inside the budget. When you evaluate any provider, ours included, ask for theirs. What it takes for a system to get past its sixth month has an article of its own.

A project does not start with a platform that will do everything, it starts with a process that hurts and a figure that ought to move. And everything this guide describes, the tests before each change, the watching afterwards and the control over who sees what, goes into that first case from day one, because adding it later is the expensive version.

Our method has four named steps and each one hands over something you can hold.

Not every task deserves an agent. This is the sieve we run before accepting a project, in that order. You can run it yourself with your list of processes in front of you.

With a candidate process in mind, three questions separate the project that pays from the one that makes a headline. You answered the first two in the sieve above and here they get said out loud. The first is about numbers. How many times a day does it happen, and how long does it take each time. Multiply the two and you have the minutes a day this project could save you at the very most, which is worth knowing before commissioning anything.

The second is about the kind of work. What does the person handling it today actually do, look or decide. If they only check that a field is where it should be, yours is a rules problem and the model is surplus. If they have to read, understand and choose between options that are not always the same, that is where agent territory starts.

The third is the one almost nobody asks and the one that saves the most money. What happens if the system gets it wrong one time in twenty. If the answer is that it is fixed in a minute, you can automate with light validation and move fast. If the answer is a wrongly issued invoice, a lost customer or a fine, the project is still viable but it changes shape, with more validation in code, more cases escalated to a person and a bigger budget. Error tolerance does not decide whether you do it, it decides what doing it properly costs.

And before all three, a hygiene check. If the process came to mind because of how good it would look in a demo rather than because of what it is costing you, there is a trap waiting for you and it has a name: the shiny toy.

The build-or-buy question has an unhelpful reputation as a technology choice. It is a variety choice. Where your process is standard, a proven product will beat a custom build on speed and price, and pretending otherwise would be selling you hours. Where your process carries your particular judgment, your data model and your exceptions, off-the-shelf tools flatten exactly what makes the process yours, and the subscription that looked cheap starts costing workarounds.

The pattern that works is unglamorous. Buy the standard pieces, the ticketing, the calendars, the accounting software, and build the thin layer of intelligence that reads, decides and connects them the way your operation actually runs. That layer is where agents live, it is small enough to afford and it is the part no vendor can ship in a box, because the box has never seen your business.

One caution from the buying side. If a proposal only makes sense with every process migrated onto someone’s platform, you are not buying automation, you are buying a dependency. Ask what remains yours the day the contract ends. Our answer is everything, repository, infrastructure and data, and it is in writing.

Projects rarely die of technology. They die of first-month decisions nobody revisited. These are the ones we run into most.

With this guide read, these six questions let you see inside any proposal, ours included.

If you deploy in Europe, two regulations frame the work. The GDPR governs the personal data inside the system, and the EU AI Act sorts systems by the risk of their use, with its heaviest obligations applicable since August 2026. Neither forbids what this guide describes. Both reward the same architecture, records, oversight and restraint designed in from the start.

We keep a full page on each, written for the person who has to defend the project in front of legal.

The terms that will turn up in any proposal you receive, one line each.

A custom single-job build starts around €2,500, systems that touch several of your tools approach €10,000 and monthly operation runs between €150 and €500. Large multi-agent systems are quoted per project. What moves each figure, where the monthly fee goes and what you own at the end has its own guide, with the full detail.