What agentic delivery changes in telco
Telco engineering is split down the middle: a network side where change windows are measured in months, and a digital side that ships daily. Agentic delivery lands very differently on each, and conflating them is the standard mistake.
Ask two engineers at the same operator whether their organisation can adopt agentic development and you will get contradictory answers, both correct. One works on the network: element management, provisioning, the OSS stack, systems where a bad change degrades service for a region and where change windows are scheduled in advance and defended. The other works on the app, the account portal, the billing front end, and ships several times a week.
These are not two teams in one industry. They are two industries sharing a logo, and the mistake almost every operator makes is writing one policy for both.
Two estates, two answers
The split is worth drawing precisely, because the correct adoption posture differs on nearly every axis.
Network and OSS side
- Change windows scheduled months out
- Failures are regional, visible, regulated
- Vendor-supplied systems, limited source access
- Testing needs equipment or a credible simulator
- Throughput is not the constraint and never was
Digital and BSS side
- Continuous deployment, ordinary rollback
- Failures are recoverable and contained
- Your own code, your own repositories
- Testable with conventional suites
- Behaves like any consumer software estate
The practical consequence: adopt aggressively on the right, and on the left treat the work as comprehension and tooling rather than modification. That is not a compromise, it is where the value actually is on each side.
Configuration is the real change surface
The defining technical fact about network operations is that most behaviour-changing work is not a code deployment. It is configuration: parameters on network elements, provisioning rules, routing policy, service definitions in an orchestrator.
This breaks the central premise of everything in this series. Deriving ground truth from source control assumes the work lands in source control. A parameter changed through an element management system does not, and a delivery record built only from repositories is confidently incomplete in an environment where configuration is where the incidents come from.
There is a genuine opportunity here and it is not an agent one. Bringing network configuration under version control, with the same review, criteria and provenance as code, is the highest-value structural change available to most operators, and it is worth doing whether or not an agent ever touches it. Once configuration is diffable, everything else in this series becomes applicable to the part of the estate that actually causes outages.
Where the volume actually is
Telco has an unusually large amount of work that is voluminous, well-specified, tedious, and non-critical, which is the exact profile agents handle well.
Integration and mediation code between systems that were never designed to talk to each other. Data pipelines feeding reporting, regulatory returns and analytics. Adapters for partner and roaming interfaces. Migration work, of which there is always some, because there is always a platform being retired.
This is not glamorous and it is where the throughput is. An operator that points agentic delivery at its integration and data estate will see a real effect within a quarter without touching anything that requires a change window.
Testing is the binding constraint on the network side
The reason network work resists this is not governance, it is verification.
To know a change to a provisioning flow is correct, you need to exercise it against something that behaves like the network. Either real equipment in a lab, which is scarce and contended, or a simulator, which is expensive to build and always partial. Either way, verification capacity is fixed and small.
Everything in this series about verification becoming the constraint applies here in its most acute form. Generating provisioning changes faster does nothing if each one waits for a lab slot. Any operator serious about extending agentic delivery into the network estate should be investing in simulation and test capacity first, because that is the actual limit, and no amount of generation capability moves it.
What obligations actually attach
Operators carry duties that most software organisations do not: service availability commitments, lawful intercept obligations, emergency call handling, number portability, and reporting to a national regulator when service is disrupted at scale.
These matter for agentic delivery in a specific way. They define a set of paths where the question is not “is this change correct” but “does this change touch a statutory function”, and a machine can answer the second question if somebody has marked those paths.
That is the same pattern as the filed-rate surface in insurance and it is worth copying. Mark the statutory paths in the codebase, attach a criterion requiring the position to be stated explicitly on any change touching them, and route those changes to review by someone who knows the obligation. The machinery does not decide the regulatory question. It guarantees the question gets asked on every change rather than depending on someone recognising the module.
Where this breaks down
Vendor-managed network functions limit what you can see or change. A substantial share of the estate belongs to equipment vendors under contracts that constrain modification and visibility. That is a commercial boundary, not an engineering one, and no delivery tooling crosses it.
Configuration under version control is a multi-year programme. I have recommended it as the highest-value structural move and it is also the hardest, touching operational practice, vendor tooling and years of habit. It is worth starting and it will not be finished before your agent pilot needs to show something.
Lab capacity is a capital problem. Recommending investment in simulation is easy to write and expensive to act on, and the business case competes with spectrum and equipment. It should still be made, because it is the honest answer to where the constraint is.
And the two-estate split is a simplification. Real operators have a spectrum, with billing and charging sitting awkwardly in the middle: high change volume, real financial consequence, and often the oldest systems in the building. That middle deserves its own treatment and gets neither policy cleanly.
The takeaway
Telco is two industries under one roof, and the single most useful thing an operator can do is stop writing one policy for both. Adopt normally on the digital and BSS side, where the estate behaves like ordinary software and the throughput is immediate.
On the network side the constraint is verification capacity and change windows, neither of which faster generation touches. Treat agents there as a comprehension and tooling asset, mark the statutory paths so a machine can flag them, and put the real investment into simulation, because that is what is actually limiting you.
If you take one thing into next week: work out what share of the changes that caused your last ten incidents were visible in a repository. In most operators the answer is uncomfortable, and it tells you where the coverage work has to start.