AI Built In, Not Bolted On: Sonar's AI Vision for ISPs

Most Operators Haven't Adopted AI, and It's Not About the Technology

When you hire a new Tier 1 network support agent you don't assign super admin roles on their first morning, no matter how good their resume looks. You give them read access to the records they need, a senior tech on the escalation path, and a handful of actions they can take without asking. Everything else gets earned.

I think that's the right way to bring AI into an ISP's operations too, and it's the argument I made at our recent AI Roadmap session. Most AI demos I've sat through are capability demos. They show you what the agent can do, and never what it's allowed to do or how you'd know what it touched.

Here's something I don't think gets said enough at industry events: most of the technical, capable people running ISPs haven't brought AI into their daily operations. It's not because the technology isn't there yet. It's because the accountability lands on the operator. The agent itself isn't the hardest part anymore. Knowing what it read, whose authority it acted under, and how that shows up in a record you could hand to an auditor six months from now is left for you to build.

If your team is still in the "exploring" phase with AI, that's not a knock on them. That's where most of the market actually is. The gap between AI existing and AI fitting your operation isn't a capability gap. It's fit and trust, and trust is the harder of the two to close.

Picture the person on your team who's handled provisioning exceptions by hand for twelve years. They don't trust a system to take that over, and honestly, they shouldn't, not on blind faith. The job isn't convincing them AI is magic. It's giving them a way to verify what it did, watch it work, and hand over more control only once it's earned.

The Test I Run on Every AI Vendor, Us Included

Here's a test worth running on anyone showing you AI: ask a question that has to cross two systems at once. Billing and the network, say. A bolt-on sees one slice of your operation, so the answer can't exist, no matter how good the model behind it is.

There are two halves to getting that right, and we built for both.

“Only the system of record can be a true system of action.

Where Sonar is already the system of record, there's no seam to cross. The agent works inside one system that already holds the answers to various areas, so nothing has to be stitched together at query time.

Where we're not the system of record, we don't pretend otherwise. That's what Extend is for. MCP is designed to let an agent work across Sonar and whatever else you run, so Sonar joins your workflow instead of insisting on owning it.

That's why we made a call before shipping a single AI feature: build the platform to hold agents as well as people, instead of bolting a chat window onto software that was never built to be acted on programmatically. Sonar is the system of record for ISPs, and the system of action built on top of it. The first half is what makes the second one possible.

I'll hold us to that same test. None of Ask, Automate, or Extend has fully shipped as I'm writing this, and I'd rather say that plainly than have you find out in a demo. MCP is the closest, in closed beta with an initial release that's primarily read only. Ask and Automate are further back, in various states of build.

Two Lanes, Built in Parallel

Serving people and serving agents are not the same build. A person needs an interface: screens, defaults, somewhere to notice that something looks wrong. An agent needs a programmatic surface, an identity of its own to act under, and an activity record that sits apart from the humans'. Those are different design and engineering problems, and we've been working both at once.

Most of the industry has built the first one and put a chat window in front of it. That's what bolted on looks like in practice: the agent acts as the user, so your logs show a person touching records they never touched.

That second lane is the part that's hard to add later. Not one Sonar customer is still running Sonar v1, and we'd spent years rebuilding the platform's plumbing well before AI gave us a reason to, so building for agents meant extending a modern platform rather than retrofitting an old one.

The openness is the same story. The GraphQL API we develop against is the same one we hand to customers. There's no private version we keep and a thinner one we publish. Agents are the newest kind of user that surface was built to serve.

Trust in Stages: Ask, Automate, Extend

A purposeful adoption journey structured into stages an operator can actually move through, instead of one all-or-nothing switch. Think of it the way you'd bring a new hire up to speed.

Ask, day-one access: Plain-language questions against your own data, nothing acted on. Runs through a verified-query model with the same role-based permissions a human has. When it doesn't know, it says so instead of guessing.

Automate, supervised work: AI helps you build the workflow, and what it builds runs deterministically by default. Drop in an AI block where you want reasoning rather than rules, and a human-in-the-loop step where someone should approve before it continues. You decide where each one goes.

Extend, earned autonomy (closed beta): Agents of your own reach Sonar data through their own access tokens, with activity logged separately from your people's. The initial release is primarily read only, on purpose.

Underneath all three, it's the same secure agent interface doing the work, not three different bolt-ons stitched together after the fact. Every agent, whether it's answering a question or running a step in a workflow, acts through its own identity and only ever inherits the access the person it's working for already has. That's not a detail we're saving for the fine print. It's the reason we're comfortable handing any of this to an agent in the first place, and it's the same foundation whether you're on Ask today or Extend a year from now.

Why Open Beats Closed When You're Handing Over Real Work

None of this works if the platform underneath it is a black box. A publicly documented API, webhooks, the ability to bring an AI tool you already trust instead of getting locked into someone else's: that's not a compliance checkbox. It's the actual mechanism that lets you verify what an agent touched, when, and on whose authority. For an industry that answers to regulators and has to get billing right every month, "just trust us" doesn't hold up well in an audit.

That's the whole idea behind Extend, too: open, not a walled garden. If you've already got an AI tool you trust, you shouldn't have to abandon it to get value out of Sonar.

When Sonar's native agents are introduced they'll come in the same way yours do: same interface, same identity, same audit trail. That's the real test of whether this was built right. Our agents shouldn't get a private door.

You Wouldn't Hand a New Hire the Keys on Day One

So back to where I started. You don't hand a new hire the master keyring on day one, so don't skip that step just because the new hire runs on a model instead of a paycheck. Ask first, because there's no real risk in it. Automate next, with a human-in-the-loop toggle you control. Extend when you're ready, with the telemetry and audit trail to earn more autonomy over time. None of that is possible on a bolt-on. With a chat window you turn it on or you don't, and the trust question never gets asked.

If you want the full session, including the parts that don't translate well to a blog post, the recording is linked below. And if you're an operator who's already tried to bring AI into a NOC or a billing team, I'd like to hear about where the trust question showed up for you.

Virtual Scale SummitProduct Roadmap & AI, with Rick SeemannThe full session this post is drawn from, live polls included.