An agent is not a smarter chatbot. It is a model that has been given tools and permission to keep going until a job is done — and almost everything that matters about buying one follows from that sentence: what it costs, where it fails, and what has to exist before it is worth having.
The word has been stretched until it means nothing. Vendors call a scripted workflow an agent, and they call a chat window an agent. This post is about what the thing actually is, what running it costs after the demo, and the failures I see most often in Kuwaiti businesses that have already bought one.
What an agent is, mechanically
Take a language model. Give it a list of tools it may call — read a record, send a message, create an invoice, search a document store. Ask it for an outcome rather than a sentence. It will choose a tool, look at the result, choose again, and continue until it decides it is finished.
That is all. Both major providers document it in exactly those terms: the model returns a request to use a tool, your system runs the tool and returns the result, and the exchange repeats — Anthropic’s tool-use documentation and OpenAI’s function-calling guide describe the same loop with different names.
Three consequences fall out of this immediately, and they are the whole post. The loop is what you are paying for. The tools define what can go wrong. And the stopping rule is a design decision that somebody has to make deliberately, because the model will not make it for you.
It also explains why two products that look identical in a demo behave completely differently in your business. The visible part — a box you type into — is the least important part. What decides whether it is useful is the tool list, and what decides whether it is safe is what those tools are permitted to touch.
The loop is the product, and the loop is the bill
A chatbot answers once. An agent may call six tools to finish one task, and each pass sends the accumulated conversation back to the model. The cost of a task is therefore not the price of one answer multiplied by a few. It grows with the number of steps and with how much context each step carries.
This is why a demo is misleading in a specific direction. The demo task is short and clean, the context is small, and the cost looks trivial. Real tasks are long, carry attachments and history, and retry.
Before anybody signs anything, ask the supplier for the average number of tool calls per completed task and the average tokens per call, measured on your own data. If they cannot produce those two numbers, they have not run it on your data.
The same two numbers are what make a per-task price comparable between suppliers. A fixed monthly fee with unlimited use sounds generous until you learn that the supplier has capped steps somewhere you cannot see, and the cap is what your customers will experience as the agent giving up halfway.
What it costs to run, in the lines that appear on the bill
Four lines, and most quotations show one.
Model usage. Charged per token in and out, at published rates that differ by an order of magnitude between the small and large models. The lever here is that not every step needs the large one.
The hosting the agent runs on. Small, steady, and forgotten in every quotation I read.
The failures. Retries, abandoned runs and the loop that went round eleven times before someone stopped it are all billable. Budget them at a real percentage rather than zero.
The person who watches it. The largest line in the first six months, and the one that makes an agent look like a service you rent rather than an asset you own. Someone reads what it did, corrects it, and adjusts the instructions. That is not a defect of the technology; it is the cost of the technology.
The lever that changes the arithmetic most is caching the part of the context that never varies — the instructions, the policies, the product list — which both providers support and price differently from fresh input tokens. Prompt caching is the single technical decision with the clearest effect on a monthly bill.
Five ways agents fail, in the order I encounter them
It does the job confidently and wrongly. The tool returned something unexpected, the model interpreted it generously, and the run completed with a clean summary. Nothing raised an error. This is the failure that matters, and the only defence is a log somebody actually reads.
It loops. A tool keeps returning something the model treats as progress. Without a hard cap on steps and a wall-clock limit, this is an invoice.
It acts on a stale record. The document store was indexed in March, the price changed in July, and the agent quoted March with complete confidence.
It inherits permissions nobody audited. An agent connected with a broad service account can reach records the requesting person could never open. This is the failure with consequences outside the system.
It cannot say no. Asked for something outside its scope, an agent without an explicit refusal path improvises — which is also why some enquiries should never reach a machine first. Writing down what it may decide, and what it must escalate, is a document in its own right — the same one I describe as an authority document.
The two preconditions that are specific to agents
The general readiness questions — who owns it, what would working look like as a number, can you turn it off — apply to any AI purchase and are answered elsewhere. Two more belong to agents alone.
First, your systems must accept reversible actions. An agent that can only take irreversible steps — send the money, post the entry, email the customer — has to ask a human before every one, at which point you have bought a slow form. Where a draft can be created, a status set to pending, or an action queued for approval, an agent earns its place immediately.
Second, you need a log with enough detail to reconstruct a decision: what was asked, which tools were called with which arguments, what came back, and what was done. Most failures above are invisible without it, and it is the first thing missing in a quick build.
Sizing the first one so it can fail safely
Pick a task that runs many times a day, where being wrong is embarrassing rather than expensive, where the inputs are already digital, and where a person will see the output before a customer does. Matching a payment to an invoice, preparing a first-draft reply, checking a submitted form against a rule sheet.
Frequency matters more than importance at this stage, and for a reason people find counterintuitive: a task that runs two hundred times a week gives you two hundred chances to see how it fails, while the quarterly report gives you four. You are buying evidence about your own processes as much as you are buying automation.
Then constrain it in four ways on day one: a maximum number of steps, a maximum spend per task, a short list of tools, and a named person who receives everything it produces. You can relax all four later. You cannot add them after an incident without looking as though you are reacting.
What to measure once it is running
Not “conversations handled”, and not time saved as an estimate. Three numbers that can be read off a log by someone who does not work in technology.
Completion without a human touch, as a percentage of attempts. Cost per completed task, all four lines included, compared with what the task cost before. And the correction rate: of the runs a person did review, how many needed changing. A rising correction rate is the early signal that something upstream has changed — a form, a price list, a supplier’s format — and it appears weeks before anybody complains.
Where I would not use one yet
Anything where a mistake is not reversible and not visible for a month: payroll, tax filings, contractual notices. Anything that depends on a document set nobody maintains. Anything customer-facing in Arabic without a test set of real Kuwaiti messages behind it, which is its own piece of work. And anything where the business case rests on removing the person who would have caught the confident, wrong run.
None of that is a reason to wait. It is a reason to start where the loop is short, the actions are reversible, and the log is readable — and to treat governance as part of the build rather than a later phase, which is the position the NIST AI Risk Management Framework takes as well.
The one-line version
An agent is a loop with permissions. Buy the loop you can afford to run a thousand times, give it permissions you would give a new employee in their first week, and read the log. Where that loop needs building into systems you already run rather than bought as a subscription, Tothiq does that work across the GCC.
Frequently asked questions
What is an AI agent, precisely?
A language model that has been given tools it may call and an outcome to reach, running in a loop until it decides the job is done or a limit stops it. The model supplies the judgement about which tool to use next; the tools supply everything it can actually do. Remove the tools and you have a chatbot; remove the loop and you have a single answer.
How much does it cost to run one for a year?
The honest answer is that it depends on steps per task and context size, which is why those are the two numbers to demand before signing. What you can rely on is the shape: model usage, hosting, failed runs, and a person’s time — with the person usually the largest line in the first six months and the one nobody quotes.
Where do agents fail most often?
They complete the task confidently and wrongly after a tool returned something unexpected. Nothing errors, so nothing alerts anybody. Second most common is the loop that keeps going because a tool keeps returning what looks like progress. Both are caught by a step cap and a log somebody reads, which is why those two are not optional.
What makes a sensible first agent?
High frequency, low consequence, digital inputs, and a person between the output and the customer. Matching payments to invoices is a good one; drafting replies for approval is another. A bad first agent is rare, high-value and irreversible, because you get neither enough runs to learn from nor permission to be wrong.
Do we need to replace our existing systems to use one?
No, and doing so is usually the more expensive mistake. An agent reaches your systems through their interfaces, so what you need is a way in that can be controlled — an account with narrow permissions and an audit trail — rather than new software. If a system genuinely has no interface at all, that is a specific problem to solve, not a reason to replace everything around it.