Chapter 3 walkthrough from The AI Contact Center Handbook by Sho Shimoda. Available on Amazon.
Ines at Gate B14
The customer's name is Ines Martel. She's standing at Gate B14 in Atlanta's Hartsfield-Jackson airport at 3:41 PM on a Thursday, watching a screen tell her that her flight to Toronto is delayed twenty-two minutes. Her connection through Toronto to Halifax boards in ninety-three minutes. The walk between the two gates in Toronto Pearson, if she recalls correctly, is not short.
She opens the airline's app and types into support chat: "my connection is going to be tight and I'm worried about missing it."
A chatbot answers. An agent acts.
What "agentic" actually means
The word arrived in AI research in late 2023, spread through Twitter in 2024, and by mid-2025 was on every enterprise slide deck. Like most words in technology, it started with a specific meaning and got softer as it traveled. The specific meaning is worth holding on to.
| # | An agent, in the technical sense that matters, can do four things |
|---|---|
| 1 | Accept a goal expressed in natural language — not a click, not a menu selection, but a sentence. |
| 2 | Reason about how to achieve that goal — decompose it, plan a sequence of steps. |
| 3 | Call tools — external functions, APIs, databases — to actually do things in the world, not just talk about them. |
| 4 | Observe the result and adjust — read what came back, notice when things went wrong, try a different path. |
In plain English: An "agent" is what you get when you give a language model hands (tools it can call) and a memory (a place to write down what it has done), and let it decide, for itself, which tool to reach for and in what order. The loop is the key thing. Chatbots respond once. Agents keep going until they get the goal done, or decide it's out of reach and hand off.
The trap in this whole conversation is that vendors have discovered the word and are applying it to products that don't clear the bar. A rules-based IVR is not agentic. A workflow engine that calls three APIs in a fixed order is not agentic. A chatbot with retrieval-augmented generation — a bot that looks things up in a knowledge base before answering — is not agentic either. Those are all useful. They are not agentic.
If you're evaluating a system that claims to be agentic, the test is simple. Ask the vendor: what happens when the goal can't be achieved in a single API call? A truly agentic system will make a second call, and a third, and it will decide for itself whether to. A non-agentic system will apologize and offer a human.
The three ingredients — model, tools, memory
Traditional chatbots were built on decision trees. A conversation designer drew a large flowchart in IBM Watson Assistant, Google Dialogflow, or Rasa, mapping every question the bot might get to a set of answers. A classifier matched incoming text to one of the pre-defined intents. If the classifier hit, the bot walked down the tree. If it missed, the bot said "I'm sorry, I didn't quite catch that." A well-tuned bot might get 65% of customer questions right the first time — a respectable number in 2019, embarrassing in 2026.
Agentic systems throw away the flowchart. They run on three ingredients.
In plain English — MCP (Model Context Protocol): A shared vocabulary that lets any AI model talk to any tool, without custom integration. Anthropic proposed it in late 2024. By mid-2026 it's the de facto standard — adopted by OpenAI, Google, and every major enterprise vendor that ships an agent integration. Think of MCP the way you think of USB. Before USB, every peripheral had a different plug. After USB, they all worked with everything.
Multi-agent — a team, not a super-brain
The moment you build a working agent, you discover a specific problem: you do not want one giant agent that does everything. A single agent that handles billing, tech support, retention, scheduling, and account changes has to hold a very long tool list, a very long system prompt, and a very complicated set of guardrails. It will be slower, more expensive, harder to test, and more likely to make mistakes than five specialists.
This has led to what practitioners in 2026 call multi-agent architectures. Three patterns dominate.
A design principle has emerged in the last eighteen months worth stating clearly: do not build an agent for a job unless a human at your company is already doing that job well. If your billing dispute process is a mess in the hands of your human team, it will be a mess in the hands of your agent. Agents scale processes that work — they don't fix broken ones.
Specialists beat generalists
There is a widespread instinct, when a company first starts building agentic AI, to reach for the biggest general-purpose model and let it do everything. It's intuitive. If GPT-5 or Claude Opus can pass the bar exam, surely it can handle a customer's billing question.
The instinct is wrong. Customer service is structurally the opposite of a bar exam. The bar exam is broad, one-shot, no consequences. Customer service is narrow, repeated, and every mistake has a cost. The measure of a customer service agent is not how impressive its best interaction is; it's how few of its ten thousand interactions have to be recovered by a human. Reliability at scale is the game.
General-purpose LLMs are optimized for the wrong thing. They're optimized to be impressive on any question. That optimization creates a specific failure mode: on the 3% of interactions where the model is uncertain, it does not refuse — it confabulates. It says something plausible but wrong. It tells the customer their refund will process in three business days when your actual policy is five. It offers a discount that doesn't exist.
The one-line takeaway: In customer service, a scalpel beats a Swiss Army knife. The specialized agent wins because reliability compounds over ten thousand interactions and impressiveness does not.
The fix is not to make the LLM smarter. It's to narrow the LLM's job. A domain-specific agent has a tight scope, a specific set of tools, a specific knowledge base, and a specific policy layer. Its job description is not "help the customer with anything." It's "handle billing questions for T-Mobile postpaid customers, using these five tools, referring to these three policy documents, escalating anything outside this scope." That narrower agent is easier to build, easier to test, easier to guardrail — and hallucinates less because it has less room in which to hallucinate.
The seven design principles
The design principles that separate the pilots from the production systems are not exotic. Every well-built agentic system in production in 2026 does all seven. Every failed one skipped at least one.
| # | Principle | Why it matters |
|---|---|---|
| 1 | Start narrow | One thing well: refunds under $100, password resets, shipping status. Every successful production agent started narrow. Every high-profile failure (Air Canada's chatbot inventing a bereavement policy; the DPD parcel bot swearing at a customer) started too broad. |
| 2 | Guardrails first, features second | Before you ship the agent's ability to take an action, ship the mechanism that prevents the wrong one. Input guardrails, output guardrails, action guardrails, review guardrails. In an agentic system, the guardrail is a load-bearing element of the architecture. |
| 3 | Design the handoff | No agent handles 100%. The handoff moment is where your customer feels the seams — or doesn't. A well-designed handoff transfers full context, the agent's own summary, and a specific reason. A bad one drops the customer in a queue with no context. |
| 4 | Instrument everything | Every action logged. Every tool call recorded. Every hallucination a human catches → tagged, added to the eval set. Mature centers run "agent observability" — replaying real interactions to detect regressions (LangSmith, Braintrust, Anthropic evals, OpenAI evals). |
| 5 | Human-in-the-loop for high-stakes | Anything with money, legal weight, or compliance implication should not be fully automated in 2026. Refunds over $500, contract changes, credit adjustments — the agent proposes, a human signs off in five seconds. That's the difference between efficient and liability. |
| 6 | Cost per resolution, not tokens per query | The metric that matters is the fully loaded cost of resolving one issue end to end. Teams that optimize for tokens build systems that look cheap and produce bad outcomes. Teams that optimize for cost per resolution actually save money. |
| 7 | Transparent when asked | EU AI Act (in force in 2026) requires disclosure. Most US states are moving the same way. Build so that "am I talking to a bot?" gets answered honestly — and if the customer doesn't ask, the interaction is high-quality enough that the question doesn't come up. |
An eighth, informal principle experienced practitioners keep repeating: the agent is a new employee. Give it the same onboarding you would a new hire. Explain the job. Give it the tools. Watch it work for a while. Coach it when it makes mistakes. And do not, ever, let it near a customer on its first day.
A concrete example — a domain-specific agent inside Microsoft Teams
The abstract principles land harder with a working example. Consider an enterprise running internal IT and HR support inside Microsoft Teams — where employees already work — rather than in a separate ticketing portal. When an employee messages the support channel asking to reset a distribution list, or check the status of an equipment order, or find the current PTO policy, an agentic assistant reads the request, invokes the right internal tools (Active Directory, procurement, HR knowledge base), returns the answer, and — if the action is authorized — takes it.
This is what AB Support — ActionBridge's AI customer service product for Microsoft Teams — is designed to do. It's narrow (internal support, in Teams). It uses the model + tools + memory pattern from Figure 3 (LLM + connectors + persistent context across the conversation). It hands off cleanly (exceptions escalate to human support with full transcript). And it lives where the work already happens — no new portal, no context switching. It is one working example of the seven principles applied to a specific enterprise workflow.
What to take with you from Chapter 3
Agentic AI is what happens when the software stops answering questions and starts completing tasks. The change from a 2020 chatbot to a 2026 agent is not a difference of degree — it's a difference of category. The 2020 bot matched an intent and returned a response. The 2026 agent takes a goal, reasons about it, calls tools to change the world, observes what happened, and adjusts. That loop is the whole story.
Specialists beat generalists because customer service rewards reliability, not raw capability. The domain-specific agent that only handles refunds is easier to build, easier to test, easier to guardrail, and less likely to hallucinate than the general-purpose one that tries to do everything. The 2026 deployments have bifurcated: buy specialized products for the common cases, build custom agents on general-purpose platforms only for the workflows that give you a real competitive edge.
Multi-agent architectures — a team of specialists coordinated by a supervisor, or handing work to each other in a swarm — are the shape most production systems are converging on. They map onto how contact centers already think about work, and they let each agent stay narrow enough to be reliable.
The design principles that separate the pilots from the production systems are not exotic. Start narrow. Ship guardrails before features. Design the handoff. Instrument everything. Keep humans on the high-stakes decisions. Measure cost per resolution. Be honest when asked. Onboard the agent like a new employee. Every well-built system in production in 2026 does all of these. Every failed one skipped at least one.
If Chapter 3 was about the machine, Chapter 4 is about the person on the other side of the handoff. When the agent handles the first 80% of interactions, what is left for the human? The answer is more interesting than the industry expected.