Beyond The Dial Tone  ·  April 2026

Mark McLeish  ·  Lead Solution Architect  ·  8 min read

What the demos skip over

I’ve sat through a lot of AI contact centre demos in the past eighteen months. They follow a pattern. The presenter shows a bot handling a billing query. It resolves without escalation. The CSAT score goes up. The handle time goes down. Everyone nods.

What the demo doesn’t show is the environment the demo was built in. A clean CRM with properly structured data. A billing API that returns a predictable schema. A single intent — one type of query — that the team spent three months building a test harness around.

That’s not a contact centre. That’s a proof of concept with stage lighting.

The bot is only as good as what it can see. And what it can see is defined entirely by integrations you probably haven’t finished building yet.

Real contact centres don’t look like that. They have seventeen CRM integrations, some of which are bespoke middleware from 2014. They have policy documents that live in a SharePoint folder nobody has audited since the last restructure. They have agents who’ve developed workarounds that don’t exist anywhere in the system of record because the system of record was never designed for how the business actually operates.

The AI agent doesn’t fail because the model is bad. It fails because the context it gets handed is incomplete, inconsistent, or contradictory. The orchestration layer — the thing that decides what data the agent gets, when, and in what form — is doing the heavy lifting. And in most vendor architectures right now, that layer is an afterthought.

The integration tax is being mis-priced

Every enterprise AI contact centre deployment I’ve been involved in has had the same conversation, usually about six weeks in. It goes something like this.

The vendor promised the integration would take two weeks. It’s taken eight. The data coming out of the CRM isn’t structured the way the agent expects. The telephony platform is emitting events in a format the orchestration layer can’t parse cleanly. The customer’s identity resolution logic — the thing that tells you whether the person calling is the same person as the account holder — turns out to be handled by a piece of custom code in a system the vendor’s team has never seen before.

Nobody mis-priced this maliciously. The vendor’s integration estimate was based on their reference architecture. Your environment is not the reference architecture. Nobody’s environment is the reference architecture.

The integration tax is real, it’s almost always underestimated, and it falls entirely on the client side of the commercial arrangement. The vendor ships the agent. You pay for the plumbing.

What “agentic AI” actually means in production

The industry has latched onto “agentic” as the current superlative. An agentic AI doesn’t just answer questions — it takes actions. It books the appointment. It processes the refund. It updates the record.

That’s a meaningful distinction. It’s also where the risk profile changes completely.

A generative AI that answers questions can be wrong. That’s recoverable — a human reads the wrong answer and calls back. An agentic AI that takes actions can cause direct harm: a refund processed to the wrong account, an appointment booked in a slot that wasn’t actually available, a record updated with data that triggers a downstream process you didn’t anticipate.

Agentic AI in a contact centre isn’t just an automation problem. It’s a process integrity problem. And most organisations aren’t treating it like one.

The architectures I’ve seen that handle this well share a common trait: they treat the agent as a proposer, not an executor. The agent identifies the action. A rules layer validates it against business constraints. The execution step is explicit and logged. Rollback is designed in from the start, not retrofitted after the first incident.

That’s not complicated. But it requires the orchestration layer to be a first-class design concern, not a thin wrapper around an API call.

The seam is closing — but not how the vendors think

The CRM and the CCaaS platform are converging. Salesforce has Service Cloud Voice. Microsoft has Dynamics and Teams. Genesys has a CRM play. Everybody is building toward the same thing: a single pane of glass where customer data and customer interaction live in the same system.

That convergence is real and it’s accelerating. But the assumption underneath it — that the seam closes cleanly because the platforms are owned by the same vendor — is one I’d push back on hard.

The seam doesn’t close because two products share a login. It closes when the data model, the event schema, and the identity resolution logic are genuinely unified. That’s an architectural problem, and it doesn’t go away just because you’re on a single vendor contract. It goes away when you’ve done the hard work of mapping your business processes to the unified model. Which, again, takes longer than anyone will tell you upfront.

What I’ll be writing about here

This site is for the people in the room when the slide deck ends and the actual architecture conversation starts. The solution architects, the CX transformation leads, the platform owners who have to live with the decisions being made in the boardroom.

I’m going to write about the vendor landscape as it actually is, not as the analyst reports say it is. I’m going to write about what post-CCaaS architecture looks like when you move past the diagrams. I’m going to write about agentic AI past the demo, integration past the estimate, and the seam as it actually closes — slowly, messily, and at significant cost to whoever isn’t paying attention.

The dial tone is gone. What comes next is more interesting — and considerably harder to sell in a forty-five minute keynote.

---