Autonomous networks need more than automation. They need a common foundation.
- Automating more individual tasks has not made networks simpler to run. Real autonomy needs a shared foundation that connects data, decisions and action.
- What decides how far you can automate is the platform layer — not the number of tools you add. Here is what that foundation has to do.
Head of Network Management, Ericsson Americas
Head of Network Management, Ericsson Americas
Head of Network Management, Ericsson Americas
Most networks do not have an automation shortage. They have an automation coordination problem.
Over the past decade, operators have automated a huge number of individual tasks. Provisioning scripts, optimization tools, domain controllers and rules engines have all taken repetitive work off human hands.
Yet ask most operations teams how it feels day to day, and you hear the same thing. The network is more automated than ever, and still hard to run.
Isolated automation creates hidden complexity when systems collect the same data across separate silos — a change in one team quietly breaks another, and coordination reverts to manual. A shared platform fixes this at the root: collect once, use many, so data isn't duplicated and action stays coordinated.
That is the paradox worth confronting before you invest in the next wave of automation. Automating tasks is not the same as building an autonomous network.
The reason is structural. Automation usually grows up around individual domains and individual problems. Data ends up in different systems, and workflows still depend on people to move between them.
Separate automation loops, each optimizing for its own goal, can even make decisions that work against each other. In multivendor networks, every new tool is one more integration to maintain.
The result is familiar. Complexity does not disappear when you automate a task in isolation. It moves from the network into your operating model.
What does an autonomous network actually need?
An autonomous network is not defined by how many tasks it automates. It is defined by five capabilities working together:
- Observability — reliable access to network data, and the insight to see what is happening across domains.
- Intelligence — the ability to read conditions, predict outcomes and recommend the right action.
- Controlled actuation — a safe, governed way to turn decisions into coordinated network changes.
- Intent management — a single function that translates business and operational intent into policy, and arbitrates between automations so they don't work against each other.
- Closed-loop operation — the ability to watch the result and keep adjusting.
Nothing alone delivers all five. Together they need a shared foundation that links data, intelligence and action, and keeps them coordinated as you scale.
Why the platform layer matters more than the tools
This is the role a platform is built to play. The Ericsson Intelligent Automation Platform (EIAP) is one example of the pattern: a common environment where network data can be accessed and exposed, applications can run, actions can be coordinated, and conflicts between applications and agents can be controlled.
Two things make that foundation work. It has to be open, able to take in data and applications across vendors, radio technologies and cloud environments, not just its own stack. And it has to provide the governance and coordination to make those applications work together instead of against each other.
As you add automation, the risk is not too little capability. It is too many disconnected islands making local decisions with global consequences — which is exactly what governance and openness together are built to prevent.
Why openness decides whether a foundation lasts
A shared foundation only works if it matches how real networks are built. They will keep including different vendors, radio technologies and cloud environments.
So the answer cannot be a closed automation stack that assumes a single supplier. Open, standards-based interfaces are what keep a foundation from becoming just another silo.
EIAP, for instance, is built on standard interfaces and an open architecture for multivendor, multi-technology operations. It is already used by operators including AT&T, Swisscom, Telstra and Vodafone, is the #1 RAN automation ecosystem in the industry, and now counts more than 2,300 application developers building on it — up from 1,400 a year earlier.
From RAN automation to a foundation for the whole network
Most of this started in the Radio Access Network (RAN), where platform-based automation is furthest along. The more interesting shift is what happens when the same foundation extends beyond it.
In 2026, Ericsson extended EIAP from the RAN to the 5G core — the same foundation reaching a new domain, rather than a second stack to run in parallel.
That opens a more consistent approach across domains, the ability to combine RAN and core information, and new ways to coordinate action across a wider footprint.
The applications that run on that foundation — rApps in the RAN, and now cApps in the core — are the next two parts of this series.
The journey to autonomy will not be finished by one application, one use case or one transformation program. It starts by building a foundation where intelligence can be introduced, trusted and scaled, step by step, on top of what you already run.
Read more:
See how a common automation platform supports the move to autonomous networks: