An AI assistant at a large operator worked out the fix for a business billing dispute in about four seconds: apply a credit, correct the rated plan, reissue the invoice. A person then spent two days executing it. The credit needed an approval the system could not record, the plan change had to be re-keyed into a second catalog, and the invoice could not be reversed without a manual ticket. The model was not the constraint. The operating environment was.
That gap between deciding and executing is where BSS/OSS transformation is now heading. In August 2026 Liberty Latin America signed a ten-year engagement under which Amdocs will manage and transform its end-to-end IT ecosystem, running it through an agentic operating system with the stated aim of moving from traditional IT operations to an AI-driven model. In the same quarter, Amdocs disclosed a multi-year managed services agreement with a leading South American provider covering a full OSS stack with AI-driven application management. Neither is really a vendor story. Both point at the same shift: large operators have stopped buying AI features and started buying an operating model.
The question is no longer whether AI can assist telecom teams. The question is whether telecom operations are ready for AI agents to act safely across systems those agents do not own.
Why telco operations resist automation
A single customer request rarely stays inside one system. Take a residential subscriber moving from a 300 Mbps broadband plan to a converged bundle with a mobile line. The request passes through CRM and customer identity, the product catalog and pricing rules, order management, billing and online charging, provisioning, network and service inventory, assurance, at least one partner system for the mobile leg or the device financing, notification services, and in several markets a regulatory record.
Each of those systems has its own state model and its own idea of what "active" means. They also fail in different ways. Automating any one step is straightforward, and most operators already have. The chain is the hard part, because it has no single owner. Where the systems are loosely coupled, an AI layer can propose a correct action and still be unable to complete it. What looks like an AI limitation is usually an integration limitation.
From copilots to agents: execution changes the risk model
Three things are routinely described with the same word, and they carry very different exposure.
A copilot recommends; a human executes and absorbs the error. A workflow automates a predefined path with a fixed decision tree, and its behaviour is known before it runs. An agent selects a path at runtime within a scope somebody has to define.
The moment execution moves from the human to the agent, the cost of a wrong decision changes scale. A copilot that misreads a tariff wastes a minute of an advisor's time. An agent with write access that misreads a bulk suspension rule can put tens of thousands of lines into the wrong state before anyone notices, and in a prepaid environment the customer notices first.
Agentic AI shortens operational cycles. It also shortens the distance between a bad decision and its consequences. That is why the practical agenda for agentic operations is unglamorous: permissions, allowed action sets, approval thresholds, audit trails, rollback paths, observability, exception handling, and a defined blast radius per action type.
API readiness: agents should call business capabilities, not databases
The architectural decision that matters most is what an agent is allowed to touch. An agent must never write to a billing table, a subscriber record, or a network inventory object directly. It should invoke governed business capabilities: create order, change plan, suspend service, apply credit, trigger provisioning, open an assurance case, request a settlement report.
The difference matters because a capability carries everything the raw write does not. "Apply credit" checks eligibility and the policy limit, records who authorised it, notifies the customer and creates the accounting entry. A direct database update does none of that and leaves a discrepancy for somebody to reconcile at month end.
Capability APIs built for agents need more discipline than APIs built for a portal. The agent needs a catalog to know what exists, and role-based access control so its scope is enforced outside the prompt rather than inside it. Contracts need versioning, because an agent that learned one signature will keep calling it. Idempotency keys matter more than usual here: a retry after a gateway timeout must not issue the same 50 EUR credit twice. Then validation and policy checks at the capability boundary, structured logging tied to a correlation ID, and rate limits. An agent stuck in a loop repeats a mistake faster than any human operator ever has.
Data consistency: agent-ready operations need a shared operational truth
Automation amplifies whatever the data already says. Most operators carry known inconsistencies that human teams have quietly learned to work around: CRM shows a service as active while provisioning still has it pending; billing charges one tariff while self-care displays another; inventory does not reflect the access resource actually in use; a partner system has not confirmed activation; assurance sees a live fault on an order that order management has already closed.
An experienced advisor recognises these for what they are and calls the right team. An agent takes them at face value. Given a pending provisioning record on a service the customer is actively using, an agent may reopen a fulfilled order, re-trigger activation, and generate a second charge. Nothing failed, technically. Every system did what it was told.
The precondition is a shared operational truth. Master data with clear ownership per attribute, a canonical product model that catalog and billing both resolve to, a service inventory that matches what is actually connected. Around that, event streams that publish state changes instead of forcing systems to poll each other, reconciliation on a schedule rather than at month end, and one view that shows a customer's state across all domains at once. AI cannot orchestrate operations reliably if each system describes the customer, the product and the service differently.
Cross-domain orchestration, not an AI layer on top
Agent-ready BSS/OSS is three layers with clear responsibilities: the AI and agent layer decides, the orchestration layer executes and controls, and the BSS, OSS and partner systems remain systems of record.
Inside a governed loop the agent understands the context, selects a permitted action, calls the correct business capability, verifies the result, writes the audit trail, and hands exceptions to a human with enough context to act. The orchestration layer owns what agents are bad at: sequencing across domains, timeouts, and compensation. If provisioning fails after charging has already applied, something has to reverse the charge, restore the previous plan, and close the order with the correct reason code. That is transactional design, not a better prompt.
Human-in-the-loop: where autonomy should stop
Some actions should never be fully autonomous, regardless of model quality. Mass tariff or price changes, credits and refunds above a defined threshold, suspension of an enterprise or wholesale account, changes to settlement terms with partners, emergency network actions during an incident, and anything with a regulatory or tax consequence.
The workable pattern is graded autonomy. Credits below 20 EUR execute automatically; between 20 and 200 EUR they need supervisor approval; above that, finance. A cumulative cap limits how much an agent population can issue in an hour, so a systematic misreading is contained rather than discovered in the monthly report. In practice these thresholds get written after the first incident. Writing them before is considerably cheaper. Agent-ready does not mean fully autonomous. It means every action has an appropriate level of autonomy, approval and control.
Why multi-market operators need this first
Groups operating across several countries hit this earlier. Different legacy stacks per OpCo, different catalogs, different regulators and consumer protection rules, different currencies and tax treatments, different partner ecosystems, and local process variants that exist for good reasons.
The value of an agent-ready layer in that setting is not unification. It is the ability to scale one governed practice without rebuilding every local system. A capability contract for "suspend service" can be defined once at group level and mapped to seven different implementations underneath, with the same permissions, the same audit format, and the same approval thresholds. The mapping layer absorbs the differences the agent should not have to reason about.
What to modernise before deploying agents
The preconditions that separate a pilot from an operating model:
- BSS/OSS capabilities exposed as governed APIs, not screens or database access
- a unified product catalog, or an explicit mapping layer between catalogs
- consistent customer, product and service data with defined ownership
- event-driven integration between domains rather than batch reconciliation alone
- an orchestration engine that handles sequencing, retries and compensation
- role-based permissions for machine identities, not only for people
- immutable audit logs that record intent, actor, approval and outcome
- tested rollback and compensation procedures per action type
- exception workflows that route to a human with full context
- observability across the customer journey, not per system
- integration standards for partner and wholesale interfaces
None of this is exotic. It is ordinary BSS/OSS transformation work, which is exactly why it gets postponed in favour of the AI pilot, and why the pilot then stalls at the moment it has to write to something.
AI readiness is integration readiness
The operators that win in AI-driven telecom operations will not necessarily be the ones with the most advanced model. They will be the ones whose BSS and OSS environment allows safe, governed, cross-domain execution, where every automated action is permitted, logged, reversible and observable.
That is an architecture decision, and it is being taken now, in ten-year engagements. At Avante we see the same order of operations in every serious programme: the integration layer first, the agents second.