At 2:40am on a Tuesday, a support queue in Rotterdam got its first ticket from a customer in Osaka. It was answered in ninety seconds, in Japanese, with the correct refund amount and a return label attached. Nobody on the team was awake. That is not a launch-day demo. It is an ordinary night for a growing number of operations teams running AI agent software in production.
The category has grown fast and gotten muddy along the way. Vendors now slap the word “agent” on anything with a chat box and an API key. So here is a working guide: what these systems genuinely do, where they pay for themselves, and the parts that still bite.
What separates an agent from a chatbot
A chatbot answers. An agent finishes. That is the shortest useful definition, and it explains why budgets moved so quickly.
Take a customer who emails to cancel an order that shipped yesterday. A chatbot drafts a polite reply and hands it back for a human to send. Agent software checks the order status through your commerce API, applies the return policy for that product category, issues a prepaid label, writes the reason code into the CRM, and replies with the label attached. No one clicked anything.
If you want the longer backstory on how software learned to get things done on its own, it is worth twenty minutes. The practical version is simpler: an agent has tools, a goal, and permission to use those tools in whatever order the situation demands. That last clause is where all the difficulty lives.
The loop running underneath every agent
Strip away the branding and most systems run the same cycle. The agent reads the current state of the world, decides on a next step, calls a tool, looks at the result, and repeats. Tools are the interesting part: a REST endpoint, a browser session, a shell command, a database query, a calendar.
Two ingredients determine whether that loop behaves. The first is memory, which can be as simple as a scratchpad of prior steps or as involved as a vector store of past cases. The second is guardrails, meaning hard limits on which tools exist and what they can touch. A refund agent that can call refund.issue but cannot call refund.issue_unlimited is a very different risk profile from one with full admin access.
This is the shift people mean by agentic AI, software that does the work rather than describing it. The loop is not glamorous. It is also the reason these systems can handle a case nobody wrote a script for, and the reason they can spiral.
Where teams are actually deploying it
The hype covers a hundred use cases. The deployments that stick cluster in a handful of places, usually ones with clear success criteria and an existing audit trail.
- Software engineering. Triaging flaky tests, bumping dependencies, fixing lint failures, opening pull requests for small tickets. Useful, though it is worth remembering that more generated code is not the same as more working software. Review capacity becomes the bottleneck fast.
- Customer support. Refunds, address changes, subscription pauses, order lookups. Anything with a written policy the agent can be held to.
- Revenue operations. Enriching inbound leads, deduplicating CRM records, drafting follow-ups that a rep approves with one click.
- Back office. Matching invoices to purchase orders, chasing missing receipts, reconciling line items across two systems that were never meant to talk.
- Research and analysis. Pulling numbers from a dozen sources into a first-draft brief. A human almost always rewrites the final third.
Notice what these have in common. Repetitive volume, a defined definition of done, and a paper trail if something goes wrong. Agents struggle in ambiguous, political, relationship-driven work, which is most of the interesting work.
Multi-agent setups and the orchestration question
Single agents hit a ceiling around step twenty or so. The context gets noisy, the plan drifts, and quality drops. One response is splitting responsibilities across specialised agents with an orchestrator routing between them. Frameworks such as MetaGPT assign roles like product manager, architect, and engineer to separate agents, and the results can be surprisingly structured for greenfield projects.
The trade-off is arithmetic. Two agents each failing 5% of the time do not average out to 5%. Errors compound, token spend multiplies, and debugging becomes an exercise in reading three interleaved transcripts. Multi-agent designs earn their complexity when subtasks genuinely need different tools and different instructions, not just because the diagram looks impressive in a pitch deck.
The failure modes nobody puts in the demo
Demos happen on happy paths. Production is mostly edges. The recurring problems are consistent enough to plan around.
Prompt injection remains the big one. An agent that reads emails will eventually read one containing instructions, and a model that cannot reliably tell data from instructions will try to follow them. Over-permissioning makes this worse: the agent that can send email, read the CRM, and issue refunds has combined three risks into one blast radius. Silent loops are the quiet killer. A retry loop against a paid API can burn through four figures overnight if nobody capped spend.
There is a fuller catalogue of what actually goes wrong when software starts acting on its own, and it is worth reading before you grant anything write access. The short version: assume the agent will do something stupid, and design so that the stupid thing is cheap, reversible, and visible.
How to vet a vendor in a single call
Most evaluation decks look identical. A few questions cut through quickly.
- Show me the audit log for a real customer run, not a mock-up. Can I see every tool call and its arguments?
- What happens when a tool returns a 500? Does the agent retry, escalate, or quietly give up?
- Where are the credentials stored, and can I scope them to a single tenant or a single endpoint?
- What is the hard spend cap per run, and who gets paged when it trips?
- If I disable the agent mid-task, is the state recoverable by a human?
A vendor who answers all five without flinching has probably run these systems in anger. A vendor who pivots to the roadmap has not.
Pricing, honestly
Three models dominate, and they behave very differently at scale. Per-seat pricing is predictable and usually wrong, because value scales with tasks completed rather than headcount. Per-task pricing aligns better but punishes you for retries you did not cause. Outcome-based pricing sounds elegant and is a nightmare to define, since a “resolved ticket” can mean five different things to five departments.
Budget for the token bill separately from the subscription. A single agent run doing research across twenty sources can cost anywhere from four cents to two dollars depending on model choice and how much context gets re-sent each turn. At ten thousand runs a month, that difference decides whether the project survives its first quarterly review.
The unglamorous work that decides whether this pays off
The teams getting real returns from AI agent software are not the ones with the most ambitious roadmaps. They are the ones who picked one workflow, wrote down what a good outcome looks like, and built an evaluation set of fifty real cases before switching anything on. They scoped credentials narrowly, capped spend, and gave a human the ability to approve anything irreversible for the first month.
That is slower than a two-week pilot that ends in a slick slide. It also tends to be the difference between a system that quietly handles a few thousand tasks a week and one that gets switched off after a spectacular failure in front of a customer. Start with the boring workflow, log everything, and expand the permission list only after you have watched it behave badly once and recover on its own.