AI Without a Rip-and-Replace: Preparing Legacy Broadband Systems for Agentic Operations - ETI
X

Want to take a Self-Guided tour?




November 5, 2026

AI Without a Rip-and-Replace: Preparing Legacy Broadband Systems for Agentic Operations

Broadband providers can introduce agentic AI without replacing every legacy system. A practical approach is to expose selected capabilities through APIs and adapters, establish consistent data definitions, and connect those capabilities to controlled workflows. The integration layer should remain separate from the AI agent, with authorization, validation, and approval controls enforced outside the model.

For smaller and regional providers, that distinction matters. Billing, customer management, provisioning, and network platforms may still perform essential jobs reliably. Replacing them all before exploring AI can turn a focused operational improvement into a costly transformation program.

The starting point is a specific workflow: identify what information an agent needs, which actions it may request, and how existing systems can support those actions safely.

What Is Agentic AI in Broadband Operations?

Agentic AI uses software agents to interpret a goal, gather relevant information, and request actions through available tools within defined boundaries. In broadband operations, an agent might investigate a service issue, assemble customer and device context, or recommend the next troubleshooting step.

That differs from a fixed automation rule. A conventional workflow follows predefined steps. An AI agent can select among permitted tools as it evaluates a situation. Reliable execution still depends on well-defined integrations, business rules, and operational controls.

For example, an agent investigating a subscriber complaint may need to retrieve an account record, check service status, review recent device information, and examine related trouble tickets. Its usefulness depends on the quality and accessibility of that information.

Why Legacy Broadband Systems Can Still Support AI

A platform’s age does not, by itself, determine whether it can participate in an AI-enabled workflow. More useful questions are whether its information is trustworthy, its interfaces can be secured, and its capabilities can be exposed reliably.

An established billing system may remain the authoritative source for account status. A network management platform may already contain valuable device information. GIS may provide the relationship between a service location and the infrastructure serving it.

The challenge is connecting those sources so software can use them consistently.

Some platforms expose modern APIs. Others require vendor-supported adapters, older interfaces, or scheduled data exchanges. These differences affect which use cases are feasible and how current the information will be.

Integration also has limits. An unsupported platform with serious security weaknesses, unreliable records, or no practical interface may require replacement. Incremental modernization gives providers a way to evaluate those decisions around operational needs.

Keep the Integration Layer Separate From the AI Agent

The AI agent should request approved capabilities through a separate integration layer. Vendor-specific connection logic, data transformations, and execution rules should be maintained independently of the agent.

Consider an agent that requests the status of a subscriber’s service. It should receive a defined result from an approved tool. It should not need embedded instructions explaining how to navigate each vendor’s billing screens or interpret proprietary device responses.

This separation provides several advantages:

  • Reusable connections: The same integration can support employee applications, conventional automation, and AI tools.
  • Simpler maintenance: Changes to a backend interface can be handled in the connector rather than repeated across individual agents.
  • Consistent information: Shared mappings help different applications interpret customer, service, and device records the same way.
  • Controlled execution: Systems outside the model enforce permissions and determine which requests can proceed.

The broader telecom industry’s architectural direction supports this emphasis on interoperability. TM Forum’s Open Digital Architecture describes modular systems, open APIs, and common models as foundations for modernization and AI-enabled operations.

Four Building Blocks for AI Without a Rip-and-Replace

1. APIs That Expose Specific Operational Capabilities

An application programming interface, or API, gives software a defined way to retrieve information or request an action.

For AI-enabled broadband operations, useful capabilities might include retrieving service status, checking order progress, or creating a trouble ticket. Each interface should define its required inputs, expected outputs, permissions, and failure conditions.

Begin with the capabilities needed for the first use case. There is little value in exposing every function of a legacy platform before proving that one workflow improves operations.

2. Adapters That Bridge Legacy Interfaces

An adapter translates between a platform’s existing interface and the format expected by the integration layer. This can make selected legacy capabilities accessible without rewriting the underlying system.

For example, an adapter could translate a standardized service-status request into a vendor-specific query, then return a consistent response.

3. Shared Data Models That Preserve Context

Connected systems do not automatically agree on what their records mean.

One platform may organize records by account number, another by service identifier, and another by device serial number. An AI agent needs reliable relationships among those records to investigate the correct subscriber and service.

A shared data model establishes consistent definitions and mappings for the information a workflow needs. It should also preserve the source, timestamp, and quality of that information.

Providers do not need to consolidate every record into one database. They do need to decide which system owns each field and how discrepancies will be resolved.

4. Event-Driven Integration That Responds to Changes

Event-driven integration allows a workflow to respond when something happens, such as an order completing, a device raising an alarm, or a ticket changing status.

An event can trigger information gathering or initiate a defined workflow. AI can then assist where interpretation is useful.

Not every connection needs to be event-driven. Immediate questions may require synchronous API calls, while background updates may use events or scheduled synchronization. The integration pattern should match the business process and the source system’s capabilities.

A Practical Example of AI-Assisted Troubleshooting

Consider a regional ISP investigating a subscriber’s intermittent connectivity complaint. With appropriate integrations, an agent could gather the subscriber’s service details, retrieve available device information, and check for related incidents. It could then prepare a summary explaining the evidence, any missing information, and a recommended next step.

A support representative reviews the recommendation. If a permitted action is approved, an established workflow executes it and records the outcome.

For example, the workflow might create a ticket containing the relevant findings. A device restart would require a separate permission decision because it can interrupt service. Where telemetry is stale, or the customer-to-device mapping is uncertain, the agent should identify that uncertainty and escalate.

The first useful result may simply be a better troubleshooting summary with less manual information gathering. That is a measurable starting point.

How Regional Broadband Providers Can Start

Choose One Workflow With a Clear Operational Cost

Look for a task employees repeat frequently: assembling troubleshooting context, checking order exceptions, or reconciling service records.

Define success before introducing AI. Useful measures include time spent gathering information, manual handoffs per case, record mismatch rates, and the percentage of cases requiring escalation.

Map Only the Systems and Data That Workflow Needs

Identify the authoritative records, available interfaces, update frequency, and permissions. Document what happens when information is missing or systems disagree.

A narrow scope helps a smaller team establish the actual integration effort before expanding the project.

Build and Validate the Integration First

Confirm that the workflow retrieves the correct records and returns understandable errors. Test timeouts, stale data, duplicate requests, and partial failures.

If conventional automation can complete the task reliably, use it. Add AI where interpretation, summarization, or selection among approved options contributes practical value.

Pilot With Human Review

Begin with a limited group and a read-only or recommendation-based use case. Review incorrect conclusions and unsupported recommendations, as well as time savings.

Expand permissions only when the evidence supports doing so. A successful summary-generation pilot does not establish that autonomous network changes are ready.

Reuse What Works

Extend proven connectors, mappings, and workflows to the next use case. This allows the integration investment to support modernization beyond a single AI pilot.

Where ETI Intelegrate Connect Fits

ETI’s Intelegrate Connect is a low-code integration solution for telecom and broadband providers, with flexible deployment options, including cloud and on-premises environments. It connects OSS, BSS, network devices, and data sources through an interoperability layer, supporting communication and automated workflows across operational systems.

For providers preparing existing infrastructure for AI, that integration foundation can make selected information and capabilities accessible without requiring wholesale platform replacement. Intelegrate works alongside legacy billing, provisioning, and operational tools.

The complete agentic solution still requires an appropriate agent platform and controls for identity, permissions, approvals, and execution. Integration supplies a foundation; the provider’s chosen use case determines the additional capabilities needed.

For a regional operator, the next step can be specific: choose one operational problem, identify the systems involved, and determine which connections will make the workflow more useful. That creates a practical modernization path while preserving investments that continue to serve the business.

Explore how ETI Intelegrate Connect can help connect your existing broadband systems and build a foundation for automation and AI.

Frequently Asked Questions

Can broadband providers use agentic AI with legacy OSS and BSS systems?

Yes, if those systems offer suitable interfaces or can connect through secure adapters. Providers also need reliable data mappings, appropriate permissions, and controlled workflows. Some platforms may require upgrades or replacement where support or security limitations prevent dependable integration.

Do ISPs need to replace their billing system before introducing AI?

No. A billing system can remain in place if it can provide the required information or capabilities securely and reliably. The decision should depend on the workflow, interface availability, and the platform’s ongoing suitability.

What is the difference between an AI agent and an integration layer?

An AI agent interprets a task and selects among permitted tools. An integration layer connects systems, translates information, and exposes defined capabilities. Keeping them separate allows connections to be reused and maintained independently of individual agents.

Does all broadband data need to be real time for AI?

No. Data freshness should match the decision. Historical reporting may work with scheduled updates, while troubleshooting or operational actions may require current service and device information. The workflow should identify timestamps and reject information that is too old for its purpose.

What is a good first agentic AI use case for a regional ISP?

A focused, read-only troubleshooting assistant is a practical candidate. It can assemble customer, service, and network context for staff review. Providers should evaluate its accuracy and time savings before allowing it to request operational changes.

How does ETI support preparation for AI-enabled operations?

Intelegrate Connect provides an integration layer linking broadband applications, network devices, and data sources. That interoperability can support AI preparation by making relevant information and workflows accessible. Agent behavior and operational controls must be designed and validated as part of the broader solution.

© 2026 Enhanced Telecommunications.

Jeffrey Boozer

About the Author

Jeffrey Boozer - VP Broadband Strategy, ETI Software Solutions

Jeff Boozer is the VP of Broadband Strategy at ETI Software Solutions, where he leads the development and market strategy for intelegrate. Jeff has played a key role in driving digital transformation for service providers with over 30 years of experience in broadband, wireless, smart grid, and utility sectors.
Throughout his career, Jeff has successfully led market launches for four global B/OSS solutions and has worked extensively with municipal utilities and broadband providers to pioneer next-generation network services. Now, with intelegrate, he is helping telecom operators accelerate service deployment, reduce integration complexity, and achieve seamless network automation through API-driven solutions.
A recognized industry thought leader, Jeff frequently speaks at broadband and telecom conferences on topics ranging from network automation to smart city infrastructure. His expertise in bridging technology and strategy makes him a sought-after voice in the evolving broadband landscape.