Every AI agent soars in the demo. The question that matters is whether it survives its third month in production, with ten thousand support conversations a week, seven connected systems, and an annoyed customer switching topics in the middle of the conversation. Most don't survive. And it's almost never the fault of the AI model behind it. It's the engine running around it.
This piece explains, in business language, the five gears that decide whether your agent becomes a real operation or becomes an internal joke by the end of the quarter. If the person selling you the agent can't answer you on these five, you're paying for a well-made demo, not for an operation that can handle real customers.
1. The gap between demo and production
In the demo, the conversation has three messages. The customer asks something simple, the agent answers, everyone applauds. All idealized, a single system, no topic switches, no upset customer, no integration going down mid-conversation.
In production, the conversation has forty messages. The customer starts by asking for a duplicate invoice, halfway through complains about a charge from two months ago, then wants to switch plans, then goes back to the invoice. Five systems need to be queried, two of them are slow today, and one will go down at some point. This is where the agent breaks. Not because the AI is dumb. Because what surrounds it wasn't built to handle this.
The five gears below are what separate one from the other. It's not a technical detail, it's a business decision: whether the agent will scale or become your problem in the board meeting.
2. How the agent decides what to do with each incoming message
When the customer sends a message, the agent doesn't simply answer. It enters an invisible loop: it thinks about what was asked, decides whether it needs to query some system (CRM, inventory, order status), makes the query, receives the response, thinks again about whether it has enough, decides whether it needs one more query, and only then talks to the customer.
Think of a waiter: takes the order, goes to the kitchen to check if the dish is available, comes back to ask if you want the sauce on the side, goes to the bar to order the drink, comes back with the dessert menu. Only then does the customer get the full meal. If the waiter forgot a step, the dish would arrive wrong or half done.
Why this matters for your business: an agent that leaves the loop too early delivers an incomplete answer to the customer (\"I'll check and get back to you\" has become a meme for bad AI support). An agent that gets stuck in an endless loop burns money querying the same systems ten times for the same answer. The engine needs to know the right moment to stop thinking and talk to the customer, and that's an engineering decision, not the model's.
3. Why the conversation gets slow and expensive as the customer talks more
Every time the customer sends a new message, the agent has to reread everything already said in the conversation to answer with context. On message one, it rereads two lines. On message thirty, it rereads two hundred. The cost scales with it, and so does the latency. The support that cost two cents at the start of the conversation can cost forty cents when the customer is on the thirtieth exchange.
It's like having an accountant who, every time you call to ask something about November, opens the file from January and rereads everything before answering. It works. It breaks when you call every week and the year is ending.
A serious operation solves this in three ways: summarizing the old part of the conversation into a few lines (without losing the essentials), storing customer data in external memory (and not in the conversation), and trimming information that clearly no longer matters. Whoever promises an agent \"with infinite memory\" without explaining how they charge for it won't deliver margin or speed in support. They'll deliver a bill that grows every month without you understanding why.
4. Several actions at once, without tripping over each other
To answer a question like \"what's the status of my order and when does it arrive,\" the agent needs to query at least the CRM, the order system, and the carrier. If it does one at a time, it takes three seconds. If it does all three at once, it takes one second. That difference, multiplied by ten thousand conversations, becomes a real bottleneck or real breathing room.
The risk: not every action can run in parallel. Some depend on the result of another (you can't cancel an order before confirming it exists). And two actions on the same record at the same time can trip over each other, leaving inconsistent data (the customer gets two confirmation emails because two parts of the agent each thought they needed to send one).
Think of a kitchen serving a table with five dishes. The chef prepares everything in parallel, yes, but can't serve the dessert before the main course, and can't use the same pan for fish and sweets at the same time. A well-built engine knows exactly what can run together and what has to wait. A poorly built engine either does everything in a line (slow and expensive) or does everything at once (fast and wrong).
5. When an external integration goes down mid-conversation
One hundred percent of systems fail at some point. Bling will go down some day, the payment gateway will time out, the CRM will have emergency maintenance, the postal service API will respond in forty seconds. It's not if, it's when.
A poorly built agent does one of three things when this happens, all of them bad: it freezes and says nothing (the customer is left hanging), it answers with made-up information (\"your order arrives Thursday,\" without having checked anything), or it silently ignores the failure (you only find out later through customer service).
An agent that can handle production does three things, in this order: it detects that the integration failed (doesn't mistake an empty response for success), retries with judgment (once, twice, with a short pause, without flooding a system that's already in trouble), and if it persists, it tells the customer honestly: \"our inventory system is down right now, I'll confirm the timeline in fifteen minutes over WhatsApp.\" And most importantly: it logs the error with enough context so nobody on your team wakes up at 3 a.m. hunting for what happened.
6. The agent you can't audit is a time bomb
Here's the part nobody wants to hear, but it's the most expensive when ignored: an AI agent will make mistakes. It will suggest the wrong discount, it will talk to the wrong customer, it will promise an impossible deadline, it will accept a complaint that has no basis. There's no such thing as an \"agent that never errs,\" there's an \"agent that errs less and we know when it did.\"
The real question isn't \"how do I prevent it from erring one hundred percent of the time\" (you can't). It's: \"when it errs, can I find where it happened, in how many minutes?\" That depends on the engine logging, for each conversation, everything that happened: the customer's message, the agent's reasoning, each query made to each system, each response received, how long each step took, how much each turn cost, and which version of the agent was live at that moment.
A plane doesn't have a black box because it's going to crash. It has a black box because when it crashes, someone needs to understand why in hours, not weeks. An agent without this kind of auditable history is like hiring a salesperson who takes no notes on any conversation: you only find out they promised something wrong when the customer complains, and there's no way to prove it or fix it.
7. What to ask before signing a contract with any agent
Forget \"which AI model do you use.\" That part is a commodity today, everyone uses something similar. Ask these five questions, and see whether the answer is concrete or evasive:
- Show me a real production conversation with thirty messages. If all they have is a screenshot of a short demo, it's a short demo.
- How much did that conversation cost from start to finish? If they can't tell you in cents, they don't control cost.
- What happens when the customer switches topics in the middle? If they answer \"the AI understands,\" they're selling magic.
- Show me a real case where an integration went down and how you handled it. If it never happened, it's because it never really ran.
- Show me the dashboard where I can see what the agent did yesterday. If all they have is a weekly spreadsheet report, there's no way to audit anything.
If a concrete answer comes back on all five, it might survive production. If they dodge any of them, forget it. No matter how pretty the interface or how fluent the demo, in three months it'll cause problems, and you'll be paying the bill without understanding why.
Why this is a business decision, not an IT one
An AI agent isn't magic and it isn't just \"plugging ChatGPT into WhatsApp.\" The model part (ChatGPT, Claude, Gemini) is today the cheapest and most solved part of the problem. What separates an operation from a demo is everything around it: how it decides what to do, how it handles a long conversation, how it queries several systems without tripping over itself, how it deals with failure, and how you oversee all of it.
That \"around it\" has a boring technical name in English, but the translation for your business fits in one sentence: does it survive the third month, or not? If you can't have this concrete conversation with whoever is selling the agent, you're buying an expensive demo. If you can, and the answer convinces you, you're hiring an operation.