Why AI Agents Need an MCP Layer in the OSS/BSS

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.

What MCP is, in plain terms

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.

Why the MCP layer belongs in the OSS/BSS

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:

• Public MCP. Tools anyone can use without logging in: check availability at an address, view plans, register interest, sign up for service, see current known outages and scheduled maintenance, and read public announcements.
• Operational MCP. Tools that touch an existing account: take a payment, report an outage, check a ticket, enroll in autopay and, for staff, send bulk communications. It is built for subscribers, CSRs and support staff alike, and every caller or user must prove who they are first.
• Data MCP. A read-only server over the provider's complete operational, billing and network data. Staff ask any question in plain English, such as "which accounts on this feeder had more than two outages this quarter, and what's their average balance?", and get the answer with the numbers behind it.

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.

One layer over a multi-vendor network

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.

Five agents, one layer

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.

Chat agent

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.

Live avatar agent

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.

Voice agent

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:

1. Sign up for service, or register interest where service isn't available yet.
2. Take a payment, then immediately offer autopay.
3. Report an outage: confirm the service address, capture what the caller is experiencing, open the trouble ticket and add a note.

After hours, during a storm, with no hold queue.

SMS agent

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.

Data agent

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.

Location makes every agent smarter

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.

• Serviceability. When a prospect gives the chat or voice agent an address, it is matched against the provider's actual service locations on the map, not a static list. The agent knows whether fiber passes that home, what plans are available there, or that the area is in an upcoming build, so it can register interest instead of saying no.
• Outages. In the text sample above, the agent knew Maria's address was inside the outage because the outage area and her service location sit on the same map. One outage on a feeder instantly identifies every affected subscriber, so the agent can confirm it in seconds instead of opening a duplicate ticket.
• Planning and growth. Staff can ask the Data Agent spatial questions in plain English, such as "which homes passed in the new build area haven't signed up yet?" or "which neighborhoods had the most outages this year?", and target marketing or maintenance where it matters most.

What this means for a small team

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.

AI that keeps service human

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:

• Calls that never get answered. One customer told me they simply don't have enough staff to answer every call. Some go unanswered, and some of those were people trying to sign up for service. A voice agent picks up every call, handles the signup or the payment, and passes anything complex to a person. Calls that used to be lost become new revenue the provider can reinvest in its community.
• The outage spike. When a storm hits, call volume can multiply within minutes, and no small team can staff for that. Agents absorb the surge: they confirm the outage, log the report and keep subscribers informed, so staff can focus on the callers who truly need a person.

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.

Guardrails come first

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.

• Authentication before account access. Matching caller ID is not enough. The caller either confirms a one-time code sent to their verified mobile number or passes a CPNI-compliant, multi-factor knowledge check against the account.
• Business rules stay in the OSS/BSS. Should this account get a payment extension? The decision uses each account's risk level, which the OSS/BSS already calculates and applies across many workflows, plus the same account history your team relies on. The agent never decides on its own.
• Least privilege. Public tools can't see accounts. Operational tools see only the verified subscriber's account, or what a staff member's role allows. The Data MCP is read-only and scoped to each provider's own data, so analysis can never change a record.
• Everything is logged. Every tool call leaves a trail: tickets, notes and payments land in the OSS/BSS like any other transaction.
• Predictable cost. AI usage is metered with clear monthly limits and early warnings, so a busy outage day never becomes a surprise invoice.

Six questions to ask your OSS/BSS vendor

If you're evaluating AI for customer service, the agent is the easy part. Ask your OSS/BSS vendor these first:

1. Can an AI agent read and write to your system in real time, or only through nightly exports?
2. Do you support MCP, or will every new channel be a custom integration?
3. How do you verify a caller's identity before an agent touches their account?
4. Do your business rules (payment extensions, credit, serviceability) apply to agents automatically?
5. How is AI usage metered and capped?
6. Can you normalize alarms, inventory and service status across every access, WiFi and metering vendor we run today, and every one we might acquire?

If the answers are vague, the AI will be too.

The bottom line

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.