AI agents are coming to broadband and utility customer service, and most of them will disappoint. Not because the models are weak, but because they can't reach the systems that hold the answers.
A chatbot that can't see a subscriber's balance can only apologize. A voice agent that can't open a trouble ticket can only transfer the call. The intelligence is there; the plumbing is not.
At Camvio, we've spent the past year fixing the plumbing. Our answer is an MCP layer built directly into the OSS/BSS, which we began rolling out in early 2026 and have been expanding ever since. This post explains what that means, why it matters for Tier 2 and Tier 3 ISPs, electric co-ops and municipal broadband systems, and how it already powers five very different agents.
The Model Context Protocol (MCP) is an open standard for connecting AI agents to business systems. Think of it as a universal adapter: the system describes what it can do, and any compliant agent can use it.
A traditional REST API is written for developers. Someone reads the docs, writes code for each endpoint, and maintains that code forever. Every new chatbot or voice vendor means another integration project.
An MCP server is written for agents. It publishes a set of tools, like "check service availability" or "create trouble ticket," each with a plain-language description of when to use it and what it needs. The agent reads those descriptions and decides which tool to call, in what order, based on the conversation.
| REST API | MCP | |
|---|---|---|
| Consumer | Developer writing code | AI agent reasoning in real time |
| New channel | New integration project | Connect and configure |
| Business logic | Scattered across each integration | Lives once, in the server |
| Flow | Hard-coded sequence | Agent adapts to the conversation |
Almost every question a subscriber asks ends in the OSS/BSS. Can I get fiber at my address? What do I owe? Is there an outage? Can I have until Friday to pay? The answers live in serviceability and network inventory, billing, service orders, trouble tickets, outage events and network alarms, all of which the OSS/BSS either owns or reaches through direct, real-time integrations. The same system also holds the revenue trends management watches every month.
Putting the MCP layer anywhere else means copying that data into another system and hoping it stays in sync. Putting it in the OSS/BSS means every agent works from the same live record, under the same business rules your staff already follow.
To the customer, Camvio offers one MCP layer with three tiers of access. Architecturally, each tier runs as its own server, so the boundaries between them are enforced by design rather than by every tool remembering to check permissions:
The Public and Operational MCPs serve subscribers and the staff who help them. The Data MCP serves the people running the business: general managers, billing, support and the board. Together, these three servers are the foundation for everything that follows.
Few providers run a single-vendor network anymore, and fewer will every year. The industry is consolidating: electric co-ops, municipal systems and regional ISPs are acquiring their neighbors or being rolled up into larger platforms, and every acquisition brings its own systems. One operator can end up with Calix and Nokia OLTs, GPON and XGS-PON side by side, a fixed wireless footprint, more than one managed WiFi platform and, for co-ops and municipalities, AMI meter systems for electric and water. Each comes with its own management system, data model and alarm feed.
Agents shouldn't have to speak every vendor's language, and with an MCP layer they don't. Camvio integrates in real time with access network management systems from vendors like Calix and Nokia, as well as WiFi management platforms and electric and water meter systems. Often legacy and modern platforms run side by side: an older copper or early GPON system next to a new XGS-PON build, or legacy meters alongside a new AMI deployment. The OSS/BSS normalizes all of it alongside network inventory and GIS. A loss-of-signal (LOS) alarm looks the same to the agent whichever OLT raised it, and a meter read means the same thing whichever head-end reported it.
This matters most during an acquisition. The network can stay mixed for years, but subscribers, CSRs and agents see one service record, one outage view and one set of tools from day one. Integrating an acquired system becomes an OSS/BSS migration, not a rebuild of every customer-facing channel.
The real payoff of MCP is reuse. We built the tools once, and five very different agents now use them. None of these agents has its own copy of our business logic. Each one is a different face on the same OSS/BSS.
A chatbot on the provider's website and subscriber portal. A prospect types an address, and the agent calls the Public MCP to check availability, explain the plans actually serviceable at that passing, and capture the signup. An existing subscriber who logs in gets the Operational MCP instead: balance, payment, autopay enrollment.
A video avatar that talks face to face. We first deployed it as a kiosk at trade shows, and the same pattern fits a co-op lobby or a city hall service desk. It speaks the visitor's language, answering questions natively rather than through a translation step. Under the hood, it calls exactly the same MCP tools as the chatbot. The only thing that changed is the interface.
Most providers still answer the phone with an IVR: a menu of options, a pay-by-phone line and a long hold queue for everything else. Our voice agent replaces the phone tree, not the people. Callers simply say what they need, in their own words and their own language, and the agent resolves it or connects them to a person who already knows why they're calling. For many providers, it can also retire a separate IVR or pay-by-phone vendor, so a better experience comes with a lower cost.
It answers like a well-trained CSR and handles a growing list of use cases. Here are three examples:
After hours, during a storm, with no hold queue.
The same conversational agent works over text. This matters most during outages: a subscriber receives an outage notification, replies to it, and the agent can confirm the issue, check status and log the report. Text is also how we verify identity, by sending a one-time code to the mobile number on file.
Sample: reporting an outage by text
Provider: We're seeing a service interruption in the Oak Ridge area and crews are on it. Reply here if you're affected.
Subscriber: yeah my internet has been down since 7
Agent: Sorry about that. I just sent a 6-digit code to this number so I can pull up your account. Can you reply with it?
Subscriber: 482913
Agent: Thanks, Maria. I see fiber service at 112 Pine St. Is that the location that's down?
Subscriber: yes, the light on the box is red
Agent: Got it. I've opened ticket 48217 and noted the red light. Your address is part of the outage our crew is already working on, so you don't need to do anything else. I'll text you as soon as service is restored.
Behind the scenes, that conversation made five Operational MCP calls: verify the code, look up the account, confirm the service address, correlate it with the active LOS alarms and open outage event, and create the trouble ticket with a note. Each call runs the same native Camvio workflows that the same action in the UI would trigger, so the result is identical to a CSR doing it, and nobody waited on hold.
The first four agents face subscribers. The fifth faces your own team. The Camvio Data Agent sits on the read-only Data MCP, and staff use it to ask questions in plain English instead of waiting for a report.
A general manager can ask how take rate, ARPU and churn are trending across each new build. A billing lead can ask which accounts went past due for the first time this month. A collections lead can ask which high-risk accounts have a payment promise coming due this week. A support manager can ask which ONTs generated the most trouble tickets this quarter. Each answer comes back in seconds, with the numbers behind it, and the agent can be reached from a browser or from an AI assistant like Claude through the same MCP connection.
For a small provider without a data analyst, this replaces most of the dashboards and report-writer requests that used to queue up with IT.
For a broadband or utility provider, almost every answer depends on where the subscriber is. Camvio integrates in real time with the provider's GIS, from platforms such as VETRO and Esri ArcGIS, and every agent benefits from that through the same MCP tools.
Five agents would normally mean five integrations, five sets of rules, and five things to keep in sync. With an MCP layer, adding an agent or a channel is mostly configuration. When we improve a tool, like better address matching, every agent gets smarter at once.
Community providers are different. Co-ops, municipalities and local ISPs are trusted because they feel human: members know the people behind the service, and that relationship is worth protecting. We understand that, so we don't build agents to replace people. We build them so agents and people work together, each doing what they do best.
Two moments show why this matters:
The goal isn't fewer humans. It's making sure that when a member reaches a human, that person has the time and the context to really help.
Giving an AI agent access to billing data is only responsible if the guardrails are as strong as the ones on your human staff. We built ours into the MCP layer itself, so no agent can skip them.
If you're evaluating AI for customer service, the agent is the easy part. Ask your OSS/BSS vendor these first:
If the answers are vague, the AI will be too.
The providers who win the next decade of customer experience won't be the ones with the flashiest chatbot. They'll be the ones whose systems are ready for any agent, on any channel, with the same rules and the same live data, and whose people have more time for the members who need them most.
That's what an MCP layer in the OSS/BSS delivers. If you want to see our chat, avatar, voice, SMS and data agents working against a live Camvio instance, schedule a demo.