Enterprise AI agents: use cases and real costs

For the past eighteen months, everyone has been talking to you about AI agents. The demos are impressive: you ask a question, the AI checks three tools, cross-references, acts, and returns a clean result. Then you try to reproduce that on your own processes, and the ground gives way.

It is not that the technology does not work. It is that the gap between a demo and an enterprise AI agent running every day comes down to things nobody discusses at the kick-off: the agent's exact mission, the edge cases, the share of the work you must never hand to a model, how you verify the result, and who gets called when the agent gets it wrong on a Friday at 6 p.m.

This article lays out what you need in order to decide: what an agent is, the method that separates a demo from a production system, what we actually put into service for our clients, and what it costs.

What people mean by an AI agent

The definition commonly accepted across the industry rests on four building blocks. An agent is:

1. A language model, which understands the request and reasons about it.
2. Tools, meaning functions the model can trigger: find_customer, read_invoice, create_ticket, send_report. Each tool is described to the model, which picks which one to call and with which parameters.
3. A loop. On each turn, the agent looks at where it stands, decides on the next action, runs it, observes the result, and starts again. That iteration is what lets it correct itself.
4. A scope: what it is allowed to do, on which data, with which limits, and possibly a budget in time or tokens.

Loading diagram…

So it is not a new kind of model. It is a model placed at the centre of a software system that frames it. The MCP protocol (Model Context Protocol) has greatly simplified the tools layer: instead of rebuilding every integration for every agent, you expose a server once and any agent can consume it. We cover that mechanism in our article on MCP and tool integration.

An agent is no smarter than the model alone. It is simply allowed to act several times, with tools. All its value comes from what you plug in at the far end.

An agent is a chatbot equipped with tools

Chatbots and agents are often presented as opposites.

An agent is a chatbot you gave tools to. The rest is a matter of degree: the nature of the tools, and what they are allowed to do. At Ask This Guy, everything is an agent. The same foundation carries the assistant answering an HR question and the one updating a customer record in your SaaS.

That table is a gradation, not a product taxonomy. An internal assistant often starts at the second level, then works its way down over the months as trust builds and tools are added.

And tools need not be generic. They can be highly specialised, and contain intelligence of their own: an extractor tuned to your contract documents, a consistency checker applying your business rules, a report generator producing exactly the format your clients expect. We build these regularly, and the code for those tailored tools belongs to you.

What really changes between the top and the bottom of the table is the nature of the risk. An agent that gets an answer wrong produces an imprecise sentence the user can ignore. An agent that gets an action wrong creates a line in your ERP or sends an email to a customer. That shift in the nature of the risk should govern the whole design, not the label on the product.

AI is never deterministic, and that is where design starts

Here is the most important idea in this article, and the one you hear least.

A language model is probabilistic. The same input twice can produce two different outputs. An algorithm is deterministic: the same input always gives the same output, and you can prove it. On any given task, conventional software will always be more reliable than a model, especially when the task is simple.

The consequence is direct: any task an algorithm can handle should be handled by the algorithm. Not by the model.

• Checking that an email address is valid, or that a postal address exists: that is a regex and a lookup against an address database, not a question for an AI.
• Computing a total, applying a rate schedule, checking that the line items match the invoice footer: code.
• Querying a database: rather than a model writing free-form SQL, use a parameterised tool with bounded queries, explicit permissions, and a set of parameters the model merely fills in. You gain in reliability, security and cost.

The model keeps what only it can do: understanding language, reading unstructured documents, choosing between paths based on context, and writing.

This discipline is not cosmetic, it is arithmetic. Picture an agent chaining ten steps. If each step succeeds 95 % of the time, the probability that all ten succeed is 0.95¹⁰, roughly 60 %. The calculation is deliberately simplistic, but the point matters: every step handed to the model multiplies the risk, whereas a step handed to code leaves it untouched. We develop that logic in our article on minimal AI automation.

The real work: defining the agent's mission

This is where success or failure is decided, long before the choice of model. A successful agent is almost always an agent whose mission was written properly.

An objective, not an intention. "Process supplier invoices" is not an objective. "For every invoice received in the accounting inbox, extract the ten listed fields, check the match against the purchase order, create the ledger entry if everything reconciles, and otherwise place it in the human queue" is one.

Edge cases, written down explicitly. What does the agent do if the document is unreadable, if the supplier is unknown, if the invoice is a credit note, if the amount exceeds a threshold, if two purchase orders match? These questions have no sensible default answer: they have your answer. An agent that was never asked them will invent a plausible average, which is worse than a clean error.

Real examples, not clean ones. We systematically ask for around twenty real cases, taken as they are, including the ugly ones: the crooked scan, the contract with a handwritten amendment, the badly filled customer record. That is what the agent gets designed against, not the ideal sample.

A verifiable expected output. For each case, someone must be able to say whether the output is right or wrong. If nobody can settle that, you will be able neither to evaluate the agent nor to let it run on its own.

Understanding the process and the expected output properly is the key. The rest is execution.

Evaluate, verify, monitor

An agent is not delivered, it is put under control. Three levels, to plan for from the design stage.

Checks inside the loop. At every sensitive step, a deterministic control: does the extracted field have the right format, does the reference actually exist in the database, does the total reconcile. When a check fails, the agent retries or hands over. That is what lifts the 60 % above back to a usable level.

Evaluation before every release. A reference set of cases with expected results, replayed on every change of prompt, tool or model. That is what lets you evolve the agent without going back to manual testing, and catch a regression before your users do.

Production monitoring. Straight-through processing rate, human fallback rate, cost per run, latency, and cases the agent itself flags as uncertain. An agent nobody monitors does not fail loudly: it quietly becomes less accurate, while your file formats change and models shift under your feet.

Add a human in the loop at the right place. Not everywhere, or the point disappears: on irreversible actions, and on cases the agent flags as doubtful.

Six agents we put into production

Here is what we actually deliver, and what keeps running.

Acting inside a SaaS from the conversation

A business tool is equipped with an agent that can modify it. The user writes "create this customer with these details" or "move the case to completed, I have just finished the intervention", and the agent performs the action in the application, with the permissions of the person speaking. You remove ten clicks and three screens, and you capture the information the moment it exists rather than three days later.

Processing specialised documents

Business documents arrive: purchase orders, administrative forms, contracts, technical files, reports, regulatory paperwork. The agent extracts the relevant information, applies your control rules, enriches it against your reference data, feeds the database, and flags anything outside the rules. This is the most profitable use case, because the volume is there and the rule is explicit. A customer purchase order or a government form is a perfect fit: the layout varies from one issuer to the next, but the expected fields are precisely defined.

Generating tailored reports from input files

Your clients or your teams drop off files. The agent analyses them, applies your calculation rules and your reading grid, produces a report in the expected format, and emails it to the right recipients. What used to take half a day becomes a twenty-minute review.

Qualifying a lead and alerting sales

It starts with an ordinary conversation on your website chatbot. A visitor asks about an offer, the agent answers from your content, and naturally extends the exchange: context, company size, timeline. Once the signals of a genuine lead line up, it does not just save the record: it immediately emails the sales team with the conversation verbatim, the qualification and the recommended next step, so the callback happens within the hour rather than two days later. We cover this mechanism in our article on qualified leads from a website chatbot.

The same pattern applies to a support ticket or an internal request: the agent cross-references the CRM or the knowledge base, classifies, prioritises, and routes to the right person with a summary already written.

Reconciliation and monitoring

Comparing two reference systems that should agree, spotting the gaps, producing the list of anomalies with a diagnosis. Nobody enjoys doing that by hand, and nobody does it as regularly as they should.

Anticipating, by combining machine learning and monitoring

Not every agent is reactive. Some exist to forecast, and that is where the complementarity between software and AI really pays off.

Take stock and flow management, in retail or manufacturing. The forecast itself belongs to classic machine learning: a statistical model trained on your sales history, your seasonality and your supplier lead times predicts demand far better than a language model, and reproducibly so. The agent adds two things the statistical model cannot do: it factors in unstructured context (a watch on your suppliers, an announced strike, adverse weather, a regulatory update, a competitor launch) and it turns the forecast into a readable action, flagging the references at risk of stockout or overstock with the reasoning attached.

This is exactly the split argued above: the deterministic side computes, the model interprets and writes.

The use cases that fail, and why

Let us be blunt: some projects should not start.

• The process is not written down. If nobody can describe it in ten lines, the agent will not invent it.
• The result is not verifiable. Without a success criterion, no evaluation, and therefore no possible autonomy.
• Low volume and every case is different. Twenty files a month, all atypical: the design cost will never be recovered.
• The action is irreversible and unsupervised. Payments, customer emails, data deletion. Technically possible, operationally unwise until the agent has proven itself.

What does an enterprise AI agent cost?

The cost of an AI agent breaks down into three items.

1. Design and development

This is the dominant item. It covers formalising the mission, building the tools, the connectors into your systems, permission handling, testing on real cases, the evaluation set, and going live.

At Ask This Guy, a production-ready agent typically lands between €2,000 and €5,000 in development. Not a demo POC: an agent wired into your systems, with its permissions, its checks, its logging and its monitoring, processing your real cases from day one. The price depends heavily on complexity, but it stays in that range because we never start from scratch: the platform already provides connectors, document ingestion, permission handling, an MCP tool catalogue, logging, monitoring, and the LLMOps foundation. The specific work goes into your business rule, not the plumbing.

Two useful comparisons:

• Rebuilding everything from scratch runs into tens of thousands of euros, most of it spent on things that carry no business value for you.
• Having your automation built on a mainstream third-party platform (the no-code orchestration tools) costs less upfront but creates a real durability problem. Those platforms move very fast. The day one of them changes how it works, your automation stops and you pay the provider again. And by construction, a provider who does not control the platform they build on cannot commit to an SLA.

2. Runtime cost

This is the token cost, and it follows no general rule: everything depends on what the agent does. An agent processing 500 files a month, at roughly 30,000 tokens per file including tool round-trips, costs a few tens of euros a month on a mid-range model. Conversely, long-context analysis, heavy reasoning or high volume change the order of magnitude entirely, and a poorly designed agent looping without guardrails can multiply the bill by ten.

So it is an item to estimate case by case, never to assume. With us it is fixed and known upfront: you know what the agent costs before it goes live, and a consumption drift is our problem, not yours.

3. Maintenance and industrialisation

The item everyone forgets, and the one that kills the most projects. Your tools change, your rules change, a supplier alters a file format, a model is deprecated and its replacement does not behave quite the same. So you need LLMOps, monitoring, a replayable evaluation set, and a watch on model obsolescence.

We build those into our offer rather than billing them case by case, because an agent delivered without them is not an industrialised agent: it is a demo with an expiry date. It is also what makes a service commitment sustainable over time, a subject we cover in our article on SLAs for enterprise AI.

ROI, calculated every time

We do not start a project without doing the maths: monthly time saved against total cost of ownership over a year. Aim for a return on investment in under six months, ideally under three. With development in the €2,000 to €5,000 range and automations that routinely save the team around twenty hours a month, that is usually very comfortably achievable. If it is not achievable on your case, better to know before you start than six months in.

Committing to the outcome

One last point, which is as much a criterion for picking a provider as it is a position of ours.

We commit to the outcome, at a fixed price. Not blindly: first we look at your real examples, we understand your process and your expected output, and only then do we commit. That is the natural order of things, and it is also the only honest way to do it.

Favour a company that works the same way. A provider selling an agent on a time-and-materials basis, without having seen your real cases and without committing to a measurable result, is transferring the entire risk to you. From the outside, a good agent and a bad one look very similar in a demo. They look nothing alike three months later.

The Ask This Guy approach

We build agents on a platform that already carries the common building blocks, which lets us spend the budget on your business instead. Three choices guide our practice:

• Start small and measurable. One workflow, a quantified gain, a fast go-live. Ambition comes after proof.
• Stay sovereign. European hosting, the option to restrict processing to European-law providers, no training on your data. The subject is covered on our sovereign AI page.
• Let you leave. The work built for you, your configurations and your connectors belong to you. Reversibility is a condition, not an option.

To see what this looks like in practice, our agentic AI and automation page details the typical workflows and their costs.

Frequently asked questions about enterprise AI agents

What is an enterprise AI agent?

An enterprise AI agent is a language model placed in a loop, equipped with tools and a business objective. It chooses the sequence of actions itself, performs those actions in your systems through its tools, observes the result, and repeats until it reaches its goal or establishes that it cannot. It is not a new kind of model, it is a model framed by software.

What is the difference between an AI agent and a chatbot?

It is a difference of equipment, not of nature: an agent is a chatbot that was given tools. A chatbot without tools can only answer. As soon as you plug in document search, a database or a business API, it can look things up and then act. The real boundary is not chatbot versus agent but read versus write: the moment the AI changes something in your systems, the requirements for reliability, permissions and traceability change scale.

Which tasks should never be handed to the model inside an agent?

Every task an algorithm can handle. A model is probabilistic, an algorithm is deterministic and therefore more reliable. Validating an email format, checking that an address exists, computing a total, applying a rate schedule, running a database query: all of that should go through code or a parameterised tool. The model keeps language understanding, unstructured document reading, contextual judgement and writing.

How much does an AI agent cost a company?

Development of a production-ready agent typically lands between €2,000 and €5,000 when building on an existing platform, and well beyond that when starting from scratch. On top of that come runtime token costs, which vary widely with the task and must be estimated case by case, and maintenance: LLMOps, monitoring, a replayable evaluation set, and handling model obsolescence. At Ask This Guy the whole thing is fixed and known before go-live.

How long does it take for an AI agent to pay for itself?

The target to set before starting is a return on investment in under six months, and it is frequently reached in under three. The calculation is simple: monthly hours saved multiplied by the loaded hourly cost, compared with development and maintenance costs over a year. If the maths does not work, the project should not start.

Can an AI agent access our sensitive data?

It only accesses what you give it. Best practice is to have the agent inherit the permissions of the user who triggers it, or to give it a service account with an explicitly limited scope, and to log every access. An agent with blanket access to your information system is a risk, not a feature.

How long does it take to get an agent into production?

A few days for a first simple workflow on an existing platform. A few weeks if connectors need building, if business rules need formalising, or if the process involves irreversible actions requiring human approval.

---

What to take away

An AI agent is not superior intelligence: it is a chatbot equipped with tools, allowed to act within a scope you define. Its value comes not from the model but from the quality of its mission, its tools and its checks.

Successful projects share the same profile: a written mission with its edge cases, real examples from the design stage, everything an algorithm can do handed to an algorithm, a replayable evaluation set, production monitoring, and an ROI calculated before starting.

Have a manual process in mind? Book a demo: in 30 minutes we will tell you whether it can be automated, at what cost, and with what expected gain.