No industry has thought harder about orchestration than telecom. Operators have standards for it, maturity levels for it, and an entire vendor category selling it. A tier-one operator can retune tens of thousands of antennas during a winter storm with almost nobody in the loop.
The same operator still runs its billing cycle on a scheduler bought in the 1990s. It provisions servers through tickets. It coordinates a fibre migration campaign across millions of lines with spreadsheets, email, and a handful of people who know how the sequence works.
Telecom orchestration maturity is deep and narrow. It is excellent inside the network domain and absent everywhere else. Autonomous network frameworks govern the radio and the core. They say nothing about the invoice run, the partner settlement, the data platform, or the GPU cluster the operator now sells to enterprise customers.
This post maps unified orchestration in telecom. It starts with what the industry already calls orchestration and the four silos underneath that vocabulary. It covers the tools inside each silo and the flows that cross all four: the billing cycle, copper switch-off, and governed AI agents in network operations.
Before mapping anything new onto telecom, it helps to be precise about the words already in use. Orchestration in telecom is not one discipline. It is at least half a dozen, each with its own standards body, tooling, and team.
Business Support Systems (BSS) own the commercial side: product catalog, pricing, eligibility, customer orders, charging, and invoicing. Operations Support Systems (OSS) own the network side: activating those services, assuring their performance, and managing inventory and resources.
Over-the-Top (OTT) services are third-party digital offerings such as video, messaging, and cloud applications that an operator sells and bundles alongside its own connectivity. They add a third coordination problem. A customer expects a streaming bundle to activate in the same minute as the SIM, which means BSS, OSS, and a partner platform all have to agree.
I covered this split in detail in Telecom OSS Modernization with Data Streaming and, years earlier, in Telco-OTT services with OSS and BSS integration.
Inside the OSS, the word orchestration carries several meanings at once:
Each of these is a real capability, and none of them was designed to coordinate work outside the network.
The TM Forum measures progress on a scale from Level 0, fully manual, to Level 5, fully autonomous. Most operators sit between Level 2 and Level 3 as of 2026. Validated Level 4 results are arriving in specific domains such as fault management and energy optimization, and roughly four in five operators target Level 4 or above by 2030. I wrote about the direction of travel after TM Forum Innovate Americas.
Read the scope of those levels carefully. They describe the network, not the operator. A validated Level 4 fault-management domain says nothing about whether the monthly invoice run recovers cleanly from a failed step, or whether a partner settlement dispute has an audit trail. That work is orchestration too, and it lives in a different part of the company.
Strip away the vocabulary and the same structure appears in a telco that appears everywhere else. Unified orchestration means one control plane for data, infrastructure, applications, and business processes. Agentic AI is governed across all four by the same control plane.
Mediation feeds usage records into rating and billing. Radio and core telemetry lands in the data platform for performance and capacity work. Customer data feeds churn models, next-best-offer engines, and the care desk. Regulatory extracts leave on a schedule because the regulator expects them on a schedule. Data teams coordinate all of it with pipeline schedulers built for that job.
Cloud-native network functions run on Kubernetes across central sites and edge locations. Firmware and configuration campaigns roll across thousands of devices in maintenance windows. Landing zones, certificates, and capacity are provisioned by one team and consumed by everyone.
Operators are also becoming infrastructure providers in their own right. Sovereign cloud offerings and GPU capacity are products now, sold to enterprise customers. Deutsche Telekom and NVIDIA opened an industrial AI cloud in Munich in 2026, operated by T-Systems. Around ten thousand accelerators are available to enterprise customers. An AI factory needs orchestration nobody in the OSS world ever scoped: tenant onboarding, job admission, quota enforcement, and teardown.
Order to activate is the classic multi-step operation. Validate the order, reserve inventory, call the activation system, update charging, confirm to the customer, and compensate cleanly when a step fails halfway.
Network APIs added a new one. Open Gateway and CAMARA moved from pilots to commercial volume in 2026. Identity and anti-fraud APIs lead the revenue, and aggregators distribute them globally. Exposing a network capability as a product means partner onboarding, entitlement, consent handling, usage capture, and settlement. Every one of those is a coordinated multi-system operation.
Some flows have people in them by design. An engineer visits a site. A porting request waits on another operator. A complaint escalates toward an SLA credit. A wholesale dispute goes to a commercial review. These processes have deadlines, escalation paths, and audit requirements, and they historically live in BPM suites or in the order management module of a BSS vendor.
Telecom already has names for the flows that matter, and all of them cross every category. Lead to cash starts in a shop or an app and ends in the ledger. Trouble to resolve starts with an alarm and ends with a customer notified and a ticket closed. Concept to market ends with a product live in every channel.
No silo owner has ever been accountable for one of those flows end to end. The seams between the silos are where the coordination code lives, and that code is usually somebody’s homegrown framework.
The orchestration market served each silo very well, which is how the fragmentation happened. Each category has a strong incumbent, and each is a reasonable choice for a real set of problems.
Apache Airflow dominates data pipeline orchestration, with Dagster, Prefect, and the cloud providers’ pipeline services alongside it. In a telco it typically runs the analytical work: telemetry aggregation, model feature pipelines, reporting loads. Its limits appear at the edges of that scope. Python-defined DAGs create a bottleneck when engineers outside the data team need to contribute, and coordinating infrastructure tasks or human steps works against the grain of the tool.
Model-driven network orchestration is its own mature market. Cisco NSO and Crosswork, Nokia NSP, Itential, Red Hat Ansible Automation Platform, Terraform, and the open-source MANO projects each solve a well-defined part of network and infrastructure automation. They are strong where the target is a network element or a cloud resource. They were never meant to wait for a credit check, call a partner API, or route a task to a field engineer.
BMC Control-M, Broadcom Automic, IBM Workload Automation, Redwood, and Stonebranch run the overnight core of the operator’s IT: the billing cycle, the general ledger, the extracts, the file handoffs. They are reliable, well understood, and expensive, and they were designed for a world with a quiet window at night.
Temporal, Restate, AWS Step Functions, and Orkes Conductor give developers durable execution: long-running stateful code that survives crashes and retries safely. An activation service or a charging integration benefits from exactly that, as I described in the rise of the durable execution engine. These engines orchestrate code inside an application boundary. Stretch one into a company-wide control plane and the team writes the glue itself.
Camunda, Pega, Appian, ServiceNow, SAP, and open-source engines such as Flowable own the human-centric processes. The BSS vendors ship their own order management and fulfilment engines inside Amdocs, Netcracker, Comarch, Blue Planet, and Salesforce Communications Cloud. They are strong where the process is the product and business analysts co-own the model. None of them is a data pipeline tool or a network automation tool.
The four-silo argument does not require an operator to start with all four, and in practice many do not. Teams typically adopt a unified orchestration platform for one category and stay there for a while: a data team replacing cron jobs and a Python scheduler for telemetry pipelines, a platform team sequencing change windows, a billing team moving job chains off a legacy scheduler. The platform earns its place in that one category on its own terms. The question is only whether it can grow when the second category shows up, without paying for that breadth up front.
Four properties decide whether a platform can grow from one category to the next without that up-front cost:
A platform with those properties costs a single team nothing extra on day one. When the second category shows up, and in a telco it always does, it plugs into a control plane that is already running instead of into new glue code.
Airflow, Cisco NSO, Temporal, and Camunda each earn their place, and none of them is the problem. The problem sits in the seams between them, where a flow leaves one tool and arrives in another through code somebody wrote once and now maintains forever.
Unified orchestration platforms address this gap. The category is young and the market is still small. Kestra is the platform I use to make the concept concrete here. I wrote separately about why this category is worth the move. Adoption in telcos follows the pattern above: one team, one category, one scheduler or pile of scripts replaced, and the control plane grows from there. What matters for a telco is the shape of the project rather than the company behind it. The core is open source under the Apache 2.0 license, the same license model that put Kafka, Kubernetes, and ONAP into operator stacks. Flows are declared in YAML that any team can read, schedules and event triggers run in one engine, and the workers run wherever the operator needs them.
What makes it unified is the task reach on top of that. One flow can run a pipeline step, provision infrastructure, call an activation API, wait for a partner confirmation, and hold for a human approval, in one definition and one audit trail.
Unified orchestration does not re-model every BPMN diagram and does not take work away from the network orchestrator. It adds one layer above, where nothing was accountable before. The next section draws the boundary precisely.
With the control plane on the table, the first question every network architect asks is which paths it may enter. In telecom the answer is unusually clear, because the network has hard timing requirements that nobody argues about.
These are three different jobs, not three speeds of the same job. I made the same boundary argument for data streaming years ago in Apache Kafka is NOT real real-time data streaming, and for the shop floor in unified orchestration in manufacturing.
Being specific here builds more credibility with network architects than any feature list.
A unified orchestrator does not replace NFV MANO or the O-RAN SMO, does not run a sub-second closed loop, and does not take over the catalog-driven decomposition logic inside an OSS service orchestrator. Nor does it move high-volume data: Kafka, change data capture, and the integration middleware around them stay exactly where they are. I mapped that tooling space in the Data Integration Landscape.
What it does own is the coordination around all of those systems, on a timescale of seconds to days, across teams that do not share a tool today.
The architecture argument only counts if it survives contact with what an operator actually runs. Three places decide that: the billing cycle, legacy network retirement, and regulated deployment.
Conference talks cover 5G, AI, and autonomous networks. Nobody presents their bill run, yet it is where a large share of telecom revenue is actually produced. Mediation, rating, invoicing, dunning, revenue assurance, interconnect and roaming settlement, and wholesale reconciliation all run on cycles with hard dependencies and hard dates.
Charging itself moved to real time years ago. The cycle around it did not. A convergent charging system rates a session in milliseconds and still feeds a monthly process that takes hours and must not be rerun casually. The dependency graph of that process, the calendars, the reruns, and the operator interventions are an orchestration problem, not a data movement problem.
Modernization here follows the same route as anywhere else. The Strangler Fig pattern applies to scheduler migration exactly as it applies to applications. Move job chains to a modern orchestrator incrementally while the legacy scheduler keeps running what it still owns.
Every operator in the world is retiring something large right now. Copper and PSTN lines, 2G and 3G radio, legacy platforms with a decade of accumulated dependencies.
The dates are real. In the UK, the PSTN is scheduled to shut down permanently on 31 January 2027, after one delay. Exchange-by-exchange stop-sell already covers millions of premises. The UK is one regional example of a global pattern. The proposed EU Digital Networks Act would add conditional copper switch-off deadlines across the bloc. Operators would have to file switch-off plans, get regulator approval, and report progress.
No single-silo orchestrator covers that sequence. Multiply it by millions of lines over several years, with parallel branches, exception paths, and a regulator watching the progress reports, and the coordination layer stops being a detail.
In telecom, deployment constraints shape the platform decision before any feature comparison begins.
Hybrid execution belongs here too. Core systems stay in the operator’s own data centers for years while analytics and AI workloads run in the public cloud. Both sides need to be coordinated by the same control plane and land in the same audit trail.
Telecom is further along with operational AI agents than most industries, because it has the telemetry, the cost pressure, and a standards community pushing in the same direction.
The agent use cases with traction are operational. A fault triage agent correlates alarms and proposes a root cause before an engineer opens the ticket. An assurance agent enriches an incident with topology and change history. An energy agent proposes which cells to put to sleep and when. A care agent drafts the response and the credit calculation.
The governance requirement follows directly. An agent step needs the same operational rigor as any other step: inspectable runs, the ability to replay from a specific input to understand a decision, alerting when behavior drifts, and a human approval as a first-class step before anything consequential happens.
On a live network, consequential means irreversible. A wrong configuration change pushed at scale is an outage with a regulatory reporting obligation attached. The approval gate is not ceremony.
Governance extends to the platform’s own AI features. Operators routinely require the ability to restrict or disable functions that call external model APIs, down to specific roles, because subscriber data going to an external model provider is a compliance event regardless of which feature sent it.
A pattern I see repeatedly in operators and telco IT service providers: every team that wants an agent starts by hand-building its own tool server. One for incident management, one for provisioning, one for reporting. Each one re-implements access control badly or skips it.
Exposing governed flows as tools removes that work. An agent calls a flow, the flow runs under the platform’s existing permissions, and every invocation lands in the same audit trail as a scheduled run. The engineering effort moves from building agent infrastructure to defining which flows an agent may call.
The industry arrived at the same conclusion independently. The TM Forum’s AI-native extensions to its Open Digital Architecture, launched in 2026 as part of the Race to 2030, add a governed execution layer for AI agents inside the existing architecture. Policy control points and Model Context Protocol support are part of it. The industry chose a governed layer inside the operations platforms over a parallel agent stack beside them.
An agent that reads network data, calls application APIs, and hands work to an engineer crosses all four categories like every other flow. Bolting a separate agent platform next to the existing orchestrators creates the next generation of glue code, this time with a non-deterministic component inside it.
Unified orchestration is not a pillar of its own. It sits inside process intelligence. The Trinity of Modern Data Architecture has three layers: process intelligence, event-driven integration, and trusted agentic AI.
Process intelligence covers three capabilities. Process mining shows how order to activate or trouble to resolve actually runs, including the rework nobody documented. Orchestration executes and governs what happens next. A decision gate keeps automation and agents inside auditable boundaries. The Process Intelligence Landscape maps the vendors across both halves.
Event-driven integration moves network and customer events in real time. Data streaming with Apache Kafka and Flink, event brokers, and the messaging middleware around them turn telemetry, mediation records, and OSS events into a shared backbone that OSS, BSS, and OTT partners can all consume. Process intelligence coordinates the work around those events, from the bill run to the migration campaign. Trusted agentic AI acts inside the boundaries that layer sets. A fault triage agent is only as good as the telemetry beneath it and the gate above it.
To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.
The Industrial IoT Landscape Q4 2026 maps vendors and open source from edge to cloud…
Jev by TypeSafe AI returns a calibrated probability instead of text. In a workflow that…
Jev by TypeSafe AI returns typed decisions with calibrated probabilities in a few hundred milliseconds.…
System One models such as Jev by TypeSafe AI answer typed questions with calibrated probabilities…
A working Python cron job moved to Kestra, the open source workflow orchestration platform, without…
The Q3 2026 edition of the data streaming trends names ten trends through 2027, grouped…