Prajakt Deotale

Tag: AI in telecoms

Rethinking how telecom builds and deploys AI with Microsoft Decision models

About 35 times lower median latency. $0.042 per million input tokens. No output-token charge. These are the numbers that caught my attention in Microsoft’s Decision-1 announcement. Its benchmark comparison puts median latency at approximately 85 milliseconds for MD1 against 3,010 milliseconds for GPT-6 Sol. (1)

For telecom, the interesting question is what those numbers let us build. In network operations, an application may need to interpret equipment logs, establish whether customers are affected and choose an approved response while the situation is developing. In customer care, it may need to recognise a service complaint and an explicit cancellation threat in the same message, then route the case with the right priority. Both involve understanding changing, often untidy information and making a decision the business has already defined.

Microsoft Decision-1, or MD1, gives us another way to handle that work. The application supplies the context, decision criteria and permitted answers, and MD1 scores those answers in a single pass. The result is numerical and ready for software to use.(1 5)

That design also helps explain the economics. Microsoft built MD1 by post-training Qwen3.5-9B, a 9-billion-parameter model, for decision scoring. It processes the input and returns compact scores, without generating a prose answer or a long reasoning trace token by token. Microsoft prices that service at $0.042 per million input tokens, with outputs free.1 Scoring a bounded set of answers avoids the repeated token generation that can make a reasoning-model response expensive.

For perspective, standard API output prices are $50 per million tokens for GPT-6 Astra, $50 for Claude Fable 5.1, and $20 for Claude Opus 5.5.2 3 Those models can earn their place when an incident needs investigation or a recovery plan needs careful thought. The architecture question is which decisions need a reasoning model, and which can go straight to MD1?

How the football demonstration brings the architecture to life

Artur Zielinski’s football match engine makes this easy to understand. Twenty-two players respond to a live game, choosing whether to pass, shoot, press an opponent or move into space. MD1 handles those immediate choices, using the match state, each player’s situation and the team’s current tactics. The demonstrator reaches 22 player decisions per second, with median decision times around 250 milliseconds.(4)

The two coaches operate on a different clock. A Luna reasoning model reviews the match and decides whether the team should change its formation, pressing or tempo. The documented football loop reviews every 30 match seconds, also reacting to events such as a goal, half-time or an opponent gaining control. After a tactical change, a cooldown gives the plan time to work. The revised tactics become part of the context for the players’ next MD1 decisions.8

This is how the game keeps moving while its strategy evolves. The model does not have to reconsider the whole team’s approach every time a player receives the ball. At 44:29 on the match clock, the demonstration’s running model-cost counter is $0.060. The dashboard’s cost accounting includes the decision and coaching layers.(4 8)

What the match looks like. Watching it play out, the effect is striking. The players never pause: passes, runs and challenges follow one another at the pace of a real game. Every so often the coaches step in, tighten the press or change the formation, and within seconds the players’ choices start to reflect the new plan. Fast decisions and slow strategy run side by side, each on its own clock.

Credit to Artur Zielinski and the Microsoft GBB team for the football engine. Artur’s original post and the think-slow-act-fast project are well worth exploring.

What appeals to me is how naturally the work is divided. Frequent decisions follow the current plan, while the reasoning model considers whether that plan should change. Telecom has workflows that fit this pattern, alongside others where the policy is already clear and MD1 can handle the decision without a reasoning layer.

How a decision model turns context into an actionable result

An MD1 request starts with a state, which is the evidence to evaluate, supplied as text or JSON. It can include unstructured logs or a customer message together with relevant business context. The application sends that state alongside preconfigured questions, instructions and answer criteria; several questions can travel in one API call.(5)

MD1 evaluates the evidence against those criteria and assigns probability to the allowed answers. For a choice, software can check the probability of the selected option before proceeding. A score expresses position on the supplied scale. Any separate API confidence field is distinct from an option’s probability; the workflow should be explicit about which value its policy checks.(5 7)

State and preconfigured questions enter MD1; the harness checks the numerical answers and executes a permitted action.

The harness turns the result into an action. This surrounding code and configuration checks thresholds, confirms that the evidence is still current, validates permissions and calls the appropriate tool. The questions and possible actions are configured in advance, so the workflow runs automatically as fresh context arrives.

A focused input and a compact numerical response keep the inference task small, and single-pass scoring avoids generating an explanation for every decision. The model still processes the context we send it, so assembling relevant evidence remains part of good engineering.

AT&T’s work provides a useful telecom example of this approach. Farbod Tavakkoli and Mark Austin have shared their OTel-2.0-Decision model, an open-weight model supporting classification, yes/no questions and ordered levels, with decisions read from answer-label probabilities. In this announcement, the team describes transcript classification as a high-volume application, alongside earlier work on a separate classifier for network root-cause analysis. Credit to Farbod, Mark and the AT&T team for sharing their models and implementation work with the industry.

For operators, this also expands the deployment choices. A managed decision service such as MD1 can be evaluated alongside an open-weight model that the operator hosts and operates itself. The choice will depend on accuracy for the task, latency, workload volume and the cost of running the service. In either case, the harness still needs to supply relevant telecom context, define the permitted answers and check the result before taking action. This is why the surrounding architecture matters: it gives operators a practical way to evaluate new decision models within workflows they have already built.

Applying decision models to telecom operations

Much of a telecom workflow consists of repeated judgements against an established operating policy. Logs vary, customers express the same problem differently, and service context changes, but the available destinations or approved responses are often limited. MD1 could make those judgements economical enough to run as the workflow unfolds, with a reasoning model available when the situation needs a new diagnosis or plan. I would start with decisions whose inputs, permitted actions and outcomes the operator can already describe clearly.

Responding to a deteriorating backhaul connection in the OSS

Consider two cell sites whose primary backhaul connection is deteriorating. The link remains up, but equipment logs show rising transmission errors, queues are building and voice and data services are suffering. A link-down alarm alone would not describe what customers are experiencing.

The OSS needs to connect those signals to the affected equipment, the sites it serves and the services that depend on it. This is where the network ontology matters. It provides the relationships that turn separate observations into useful context. My colleague Alberto Manuel explains this well in The Case for an Ontology Layer in Telecoms. I would recommend it to anyone looking at how agents can work more reliably with telecom data. (6)

Once the events have been correlated, the state (the input to the decision engine) combines the relevant log bundle, service impact and the facts about an alternative route:

Backhaul A: link UP, CRC errors rising and sustained degradation. Sites 047 and 048: voice and data impaired; queue building. Route B: healthy and approved, with projected load of 62% against an 80% operating limit.

The incoming state is evaluated against three questions already configured in the MD1 request:

The severity value follows from the ordered levels: 0 × 0% + 1 × 2% + 2 × 11% + 3 × 87% = 2.85. It is a priority signal against this operating rubric, rather than a percentage confidence. (5)

The harness checks impact probability against 0.95, the Route B choice against 0.90, and severity against 2.50. With those checks satisfied, it confirms that B remains approved and has sufficient capacity, then asks the network controller to apply it. MD1 selects an operating response; the controller executes the reroute. As traffic moves to B, the queue drains and calls and data recover.

Picture it on the operations console. CRC errors climb on Backhaul A. Alarms from Sites 047 and 048 are correlated into a single incident. MD1 returns its three answers in about a quarter of a second, the harness checks them against its thresholds and the capacity of Route B, and the controller moves the traffic. Moments later the queue drains and both sites recover. No engineer has had to assemble the evidence by hand, and every step leaves a record that can be audited afterwards.

The walkthrough uses a 250 ms response-time assumption and a 1,200-input-token request budget. At the published MD1 rate, that request costs $0.0000504, with no output-token charge. These are the assumptions behind the walkthrough.

This is an MD1-only application when recovery options and policy are established. Existing network protection mechanisms continue to handle their own time-critical functions; the OSS layer interprets incident evidence and selects among responses the operator has prepared. If the evidence conflicts or no suitable alternative exists, escalation is an explicit option.

Routing service complaints with the right customer context

On the BSS and customer-care side, a customer might write through an app, SMS or web form:

My data connection is crawling at 0.5 Mbps in central London, and I pay for 5G premium. Fix this or I’m cancelling.

The application needs to preserve both parts of that message: the network-performance problem and the expressed intention to cancel. Two preconfigured questions can make that distinction in the same request.

With a cancellation-intent threshold of 0.85, the workflow routes the case to priority technical support, attaches the original complaint and adds a retention flag. The 0.91 result identifies cancellation language in the message; predicting whether the customer will actually leave would need account history and a different decision task.

A reasoning model is unnecessary in this routing step because the policy and destinations are known. Investigation can follow with the technical team, with the reason for priority preserved in the handoff.

Artur’s telephone demonstrator takes the same idea into a conversation. MD1 evaluates partial speech for a permitted human handoff, while application code checks whether the transfer can proceed. Once it can, the application plays an approved acknowledgement and skips the final generated reply. In Artur’s example, the acknowledgement becomes ready 7.81 seconds into a 9.4-second utterance, so the handoff can begin before the caller finishes. (7)

For the caller, the difference is small but noticeable. Instead of finishing a sentence, waiting while the system composes a reply and only then hearing that they will be transferred, they hear a short, approved acknowledgement as they stop speaking, with the handoff already under way. The pause at one of the most frustrating moments of a service call simply disappears.

Credit to Artur Zielinski and the Microsoft GBB team. The early-handoff guide explains the partial-speech decision and application-controlled transfer.

When a reasoning model should join the workflow

Now imagine several backhaul incidents appearing together, with evidence that does not agree. A recent software change, a shared transport dependency and equipment faults are all plausible explanations. The operator needs an investigation that can gather evidence, compare explanations and revise the recovery plan.

A reasoning model can work across topology, change records and diagnostic results to develop that plan. The harness makes the approved plan and its permitted next steps available to MD1. As fresh event bundles arrive, MD1 can decide whether to attach them to the existing incident, request the next approved diagnostic or escalate because the evidence no longer supports the working diagnosis.

That is the hybrid pattern: a reasoning model develops or revises the plan, while MD1 handles frequent, bounded decisions within it. The reasoning model returns when a review is due or new evidence warrants a rethink. This is the relationship between coaches and players on the football pitch, applied to network operations.

Opportunities across the telecom business

The strongest candidates combine a high volume of varied inputs with a limited set of meaningful decisions. This matters in B2B sales as much as in operations: a stream of market signals can be screened for relevance without asking a reasoning model to develop an account strategy for every item. I would choose the architecture for each decision step, using these workflows as starting points.

For B2B qualification, the operator might define relevance as a potential need for managed connectivity, private networks or cloud interconnection. A new-site announcement could be relevant; an unrelated corporate announcement might not be. MD1 classifies against those criteria, and the sales workflow decides which qualified signals deserve further research.

The common requirement is a contextual judgement with clearly defined possible answers. Where a deterministic rule already answers the question reliably, the harness can continue using it. MD1 is useful when interpreting the evidence is the part that makes a simple rule difficult.

Keeping the architecture in the harness as models evolve

This brings me back to harness engineering: the code and configuration around the models that make the system useful. The harness assembles context, holds the decision criteria, checks thresholds and permissions, invokes tools and records what happened. It also decides when to involve a reasoning model or a person.

The harness owns the workflow. The reasoning loop is used when a plan needs to change.

In the backhaul example, the harness connects inventory, service impact, route eligibility and the network controller. In customer care, it connects the message, account context, routing policy and available queues. Those integrations and policies should keep their value as the models improve.

A faster decision model can be evaluated against the same labelled incidents. A stronger reasoning model can take over investigation while the tools, permissions and service workflow continue to work. The operator can adopt a better model after evaluation without discarding the system it has already delivered.

That is how I would measure flexibility and innovation here: how quickly can we introduce a better model and improve an operating outcome? Alongside model latency and inference spend, I would track time to the right team, missed incidents, recovery time, customer resolution and the effort required to introduce the next model.

Understanding the cost of each architecture

At Microsoft’s announced price, one million routine decisions using 400 effective input tokens each cost $16.80 in MD1 inference. A workflow with an established policy may need no other model calls. The richer backhaul request uses a separate 1,200-token budget; the web companion calculator starts with a smaller routine decision so that each assumption is visible.

For the hybrid example, add 10,000 planning reviews and 20,000 escalations to those one million decisions. At the selected rates and token budgets, planning costs $120, escalations cost $90, and the total becomes $226.80. Using the comparison model for every routine decision costs $900. That makes the hybrid inference bill 74.8% lower under these assumptions.

Illustrative model inference costs; token budgets and rates are listed below.

Calculation inputs: 400 input tokens per routine decision; comparison model $2/M input and $10/M output, returning 10 output tokens per routine decision. Planning: 10,000 calls at 4,000 input / 400 output tokens. Escalation: 20,000 calls at 1,500 input / 150 output tokens. Comparison rates are adjustable assumptions, separate from the named models in the introduction. Equal effective batching; no cache discounts. Infrastructure, retrieval, speech, tools, retries and integration are outside this inference calculation.

If escalations rise to 20%, the hybrid total becomes $1,036.80. That tells us something useful about the design: a workflow that repeatedly needs a second investigation may be better served by a different split of work. The web companion calculator lets us examine that decision before choosing an architecture.

What interests me about Microsoft Decision-1 is the room it creates to improve an existing service. We can make a recurring judgement faster and cheaper, call on deeper reasoning when the situation needs it, and retain the telecom context and integrations we have already built. With those decisions held in the harness, each new model becomes something we can evaluate and adopt against a business outcome.

Sources and demonstrations

1. Microsoft Decision-1 announcement, 9 October 2026. Model basis, benchmark comparison and MD1 pricing. The latency figures describe Microsoft’s published comparison; MD1’s median is measured through Foundry in the same region.

2. OpenAI GPT-6 Astra pricing. Standard API output rate for the regular context tier.

3. Anthropic model pricing. Claude Fable 5.1 and Opus 5.5 standard API rates. Prices checked 15 October 2026.

4. Artur Zielinski’s football-engine post. Player throughput, latency and running cost from the MD1 demonstration recording. The six-cent figure is partway through the match.

5. Microsoft Learn: Decision-1 API and question types.

6. Alberto Manuel: The Case for an Ontology Layer in Telecoms, 16 June 2026.

7. Microsoft GBB: early human handoff. The example uses the 7.81-second readiness point; the guide distinguishes readiness, playback and adviser connection.

8. Microsoft GBB: football reference and planner loop. Review cadence is in match seconds; the documented change cooldown is eight match minutes.

Football and telephone demonstrations by Artur Zielinski, Microsoft GBB, described from the recordings he shared. Telecom walkthrough response-time and token assumptions are stated with the scenario; its cost is calculated from the published MD1 input rate.

This article was first published on LinkedIn on October 15, 2026.

October 15, 2026
What the next generation of AI, like Astra, could change in telecom

When I look at the harder operational problems in telecom, the challenge is rarely that information is unavailable. It is that the information needed to understand one incident is scattered across systems and often tells an inconsistent story. An enterprise customer may report intermittent application degradation even though the alarm view shows no clear fault; the service inventory may point to a path that is no longer current, while a recent network change appears suspicious without proving that it caused the problem. The engineer therefore cannot simply follow the most visible signal. Before deciding what to test or change, they must reconstruct the actual service path, separate useful evidence from coincidence, and develop an explanation that continues to hold as new information arrives.

This is the context in which I have been looking at the recent progress around GPT-6 Astra. I am less interested in Astra as a product announcement than in what its results tell us about the direction of frontier AI. Models are becoming better at entering an unfamiliar environment, learning how it works and building a useful representation of the problem as they go. As I wrote in my recent LinkedIn article on ARC-AGI-3, Astra’s result gives us unusually clear evidence of that progress, although I would expect other frontier models to move in the same direction.

For telecom, this matters because many valuable workflows are not difficult simply because they need a better answer. They are difficult because the facts emerge over time, the next action depends on what has already been learned, and a wrong action can affect customers. That is where world models, persistent task state and a well-designed harness become relevant.

Why world models matter

The most interesting part of Astra’s ARC-AGI-3 result is not the final score. It was placed in unfamiliar, abstract environments without being given the rules. It had to try actions, observe what changed, infer how different components were related and keep revising its plan. ARC Prize found that it created compact symbolic representations of the objects, relationships, rules and unfinished plans that mattered. In one maze-like environment, it built separate tools for navigation, combat, moving patrols and checking whether its predictions still matched the actual state. [1]

This is what researchers mean by a world model. The phrase sounds more elaborate than it needs to be. In practical terms, the model creates a temporary map of what exists, how the pieces interact and what is likely to happen if an action is taken. In a service incident, it would not simply list alarms or match them to a runbook. It would reconstruct the affected service path, connect each symptom to the network elements and recent changes that could explain it, and choose the diagnostic result that would support or rule out each suspected cause. As new telemetry arrives, it would update that picture. This is not a full digital twin. It is a temporary, evidence-based model of this incident.

The difference from existing AI is one of degree rather than a clean dividing line. Today’s frontier models can already reason and use tools. What Astra makes more visible is the ability to keep developing an explanation as the environment changes, rather than treating every interaction as a fresh question.

Why this is relevant to telecom

In telecom, the evidence needed to resolve a problem is usually spread across several systems. A service incident may require alarms, topology, performance counters, configuration, change records, inventory and customer symptoms. An order fallout has a different trail: the customer order, product configuration, network design, inventory reservation and provisioning status. In both cases, the difficulty is reconstructing one reliable picture from records that may be incomplete, stale or contradictory.

This is also why I think recent work from NGMN and TM Forum is relevant. NGMN describes higher network autonomy as the handling of routine and complex faults within human-set policy bounds, while stressing gradual trust, traceability, simulation, human approval and fail-safe controls. TM Forum argues that reaching Level 4 autonomy requires moving beyond fragmented data towards contextual knowledge that agents can reason over and act upon. [3, 4] The model matters, but so do the context it receives and the controls around what it can do.

Today’s AI systems already do more than classify and summarise. In well-defined workflows they can run diagnostics, retry failed steps and execute approved actions. The more interesting test is what happens when the case no longer follows the known path. The table below sets out that distinction in telecom terms.

These are areas I would test, rather than claims about current deployments. The point is to see whether the full workflow improves, not whether the model produces a more polished answer.

Why the harness changed the result

A world model is only useful if the system can preserve and update it throughout the task. With ARC Prize’s standard harness, Astra could carry forward the notes it chose to retain. The provider-adapted harness also preserved its opaque reasoning state between requests and compacted long conversations so that earlier work could be reused. At the same maximum reasoning effort, Astra’s ARC-AGI-3 Semi-Private score rose from 62.7% to 98.6%. The widely quoted 99.9% result came from the provider adapter at a different, high reasoning setting. [1]

The clearest analogy for me is a difficult incident passed between engineers. The standard harness is closer to each engineer receiving only the notes that the previous person remembered to write. The adapted harness is closer to the same engineer staying with the incident and retaining why one hypothesis was rejected, which observation changed the plan and what remains unresolved. The model did not suddenly acquire more knowledge. It was simply better able to carry its learning forward.

Figure 1. Model capability, harness design and human accountability work as one system. Benchmark figures from ARC Prize. [1]

In a telco, the harness would therefore do much more than remember a conversation. It would supply permitted topology, telemetry, change history and service context; preserve an evidence-linked incident state; expose read-only diagnostics and sandboxed analytical tools; define identity, permissions, time and cost limits; and record each action. The model develops the working picture, while the harness helps preserve it and keeps the work within agreed boundaries.

Foundry is relevant here because Astra is available within an environment that provides Microsoft Entra identity, role-based access, network isolation options, tracing, evaluations, model guardrails and governance across models, agents and tools. [5, 6] A telco would still need to decide which evidence is authoritative, which diagnostics are permitted, what requires human approval, and how to stop or roll back. Some agent guardrail, intervention and monitoring experiences remain in preview, so the exact feature readiness would need to be checked for the chosen design. [7]

Where I would start with an unfamiliar service incident

Imagine an enterprise customer reporting intermittent application degradation after a planned network change. Access alarms are clear, transport latency varies, and inventory lists an outdated service path. Routing, congestion and an application-side issue are all plausible. A fixed runbook struggles because the next useful check depends on what the investigation discovers.

Today, an AI assistant could summarise the incident, retrieve related procedures and suggest likely causes. What I would want to test next is whether a model can assemble the service path, build a temporary causal picture, expose contradictions, maintain several hypotheses and choose the authorised diagnostic that best separates them. If a result is unexpected, it should revise its explanation rather than force the evidence into its first answer. The final recommendation should set out the likely cause, affected services, remaining uncertainty, recovery options and rollback requirements.

Figure 2. Proposed human-in-the-loop experiment for an unfamiliar service incident.

Human approval would be a genuine decision point, not simply a line in the process. The engineer should see the evidence, uncertainty, expected impact and rollback plan, then approve, reject or escalate. I would begin with historical incidents and live read-only observation. Supervised execution should follow only when the team has agreed acceptance criteria and the operational tooling can enforce the exact approved action. Stopping when the evidence is insufficient should count as a correct outcome.

I would measure diagnostic accuracy, time to a testable hypothesis, evidence coverage, engineer verification effort, unsafe proposals and total cost per accepted outcome. If supervised action is introduced, add service recovery, rollback and repeat incidents. This keeps the test anchored in what the customer experiences: faster restoration, fewer hand-offs, clearer communication and fewer avoidable changes.

What I think telcos should do next

My conclusion is fairly simple. Telcos should not reorganise around Astra, but neither should they wait for a claim of fully autonomous operations. I would identify one valuable workflow in which the bottleneck is investigation rather than information retrieval, test it first on historical cases, and then move into live read-only work. Authority should expand only when the operational evidence justifies it. Astra has made the direction more visible, but the opportunity is broader than one model. The useful question is whether AI can now build enough working understanding of a changing situation to help an engineer resolve it more quickly and safely. That, in my view, is the test worth running.

Sources

[1] ARC Prize, Astra on ARC-AGI-3 | [2] OpenAI, GPT-6 Astra | [3] NGMN, Network Automation and Autonomy Phase III, 11 August 2026 | [4] TM Forum, Building knowledge planes to scale autonomous networks, 1 July 2026 | [5] Microsoft, Astra in Microsoft Foundry, 3 September 2026 | [6] Microsoft Learn, What is Microsoft Foundry? | [7] Microsoft Learn, Foundry feature readiness

This article was first published on LinkedIn on September 9, 2026.

September 9, 2026
For Telcos, the Autonomous Network Is Within Reach

Executive summary

I spend most of my working life in rooms with network CTOs and chief digital officers, and over the past year the shape of the autonomous networks conversation has changed. The technology question is close to settled. Operators know which use cases work, they can point to validated results, and several have Level 4 certifications on the wall. The question they cannot answer as easily is why the second deployment costs almost as much as the first.

That is the argument of this paper, and it is the reason I think the destination is genuinely within reach for the first time. The equation has changed on three fronts at once. AI has arrived with enough capability to matter. Cloud-native foundations are finally in place at scale. What has not kept pace is the third front, which is the operating model: how an operator builds the engineering underneath, governs it, and makes it reusable. That is the binding constraint on progress today, and it is the one an operator can close itself.

Five points follow. First, this cycle is materially different from earlier automation waves, because the digital foundations are stronger while the capital envelope has tightened. Second, the industry is earlier on the journey than the headlines suggest, with most operators at Level 2 and only a small minority at Level 4. Third, the highest-value use cases are proven, and the industry has converged on a clear order of priority. Fourth, autonomy consistently stalls at the same place, which is the point of action rather than the point of insight. Finally, the route through that constraint is a Network Harness that connects Network IQ, Customer IQ and shared workflows, so that engineering is built once and applied many times.

1. Why this cycle is different

Figure 1. Stronger foundations, steeper demand and a tighter capital envelope

Two things separate this moment from earlier automation waves. The first is technical. By March 2026, 95 operators had launched 5G Standalone, and 86 operator groups representing more than 300 networks and around 80% of global mobile connections had aligned to the GSMA Open Gateway framework. Cloud-native cores continue to expand, even if maturity remains uneven across domains and markets. The programmable substrate that automation needs is finally arriving in volume.

The second is economic, and it is the more uncomfortable of the two. Total mobile network data traffic, including fixed wireless access, reached 210 exabytes per month in the first quarter of 2026, up 22% year on year, and Ericsson expects it to reach 515 exabytes per month by 2031. At the end of 2025, 5G carried 48% of mobile data traffic. Set against that, PwC expects global telecom service revenue to rise from 1.15 trillion dollars in 2024 to roughly 1.32 trillion in 2029, which is under 3% a year, with average revenue per user continuing to decline. Capex intensity has already stepped down from 26.9% of revenue in 2022 to 22.9% in 2024, and Dell’Oro expects operator capex to remain broadly flat through the second half of the decade.

The arithmetic is unforgiving. Traffic is compounding across networks that are increasingly software-defined, multivendor and multi-domain, while the capital available to absorb that complexity is flat at best. Operators cannot build their way out of demand. They have to extract more from every asset already in the ground, and that is an operations problem before it is an engineering one.

AI is what changes the quality of the opportunity rather than the nature of the problem. Predictive models detect anomalies and anticipate failure. Generative models interpret intent, summarise incidents and help engineers move faster. Agentic systems coordinate action across systems and domains. Taken together, they offer a more credible route to governed, cross-domain autonomy than operators have had before.

2. From task automation to governed autonomy

Figure 2. Current position, stated ambition, and what the certifications actually mean

TM Forum’s Level 0 to 5 taxonomy remains the most useful frame for this discussion, largely because it keeps the debate honest. Its March 2026 benchmark, drawing on 125 respondents at 80 companies, puts 59% of respondents at Level 2 for their network overall, 21% at Level 3 and only 6% claiming Level 4. The share at Level 3 or above rose from 19% to 21% in a year. Progress is real, and it is slow.

Ambition tells a different story. TM Forum’s June 2026 research, based on a survey of 80 operators, found that 20% expect to reach Level 4 or above by 2027, rising to 81% by 2030. I do not read the distance between 6% today and 81% by 2030 as an ambition problem or a technology problem. I read it as an operating model problem, and the rest of this paper is about why.

It is also worth reading the certifications carefully, and TM Forum deserves credit for making this possible. Of roughly 50 validated assessments awarded by the end of 2025, about 30% reached Level 4. Every one of those Level 4 validations used alpha-stage questionnaires, which TM Forum has since withdrawn from the certification service on the grounds that they made a Level 4 score too easy to achieve. Operators also tend to publish the scenarios where they score well rather than the ones where they do not. None of this diminishes the achievement. It does mean that a Level 4 certificate describes a scenario, not a network.

Which leads to the most important implication of the taxonomy. Level 4 is almost never achieved across an entire network at once. Operators progress scenario by scenario, domain by domain and market by market. Telefónica is instructive here: the company reports an average autonomy level of 3.05 globally with nine Level 4 use cases across Spain, Brazil and Germany, and targets an average of 3.75 by 2028 before reaching Level 4 by 2030. That is what a serious roadmap looks like. The real shift is not from manual to autonomous. It is from isolated task automation to governed autonomy.

3. Where operators are proving value

Figure 3. High-value use cases, ranked by the priority operators place on them

The strongest use cases are not theoretical, and the industry has converged on a clear order of priority. Service assurance leads at 78% of respondents rating it high priority, followed by troubleshooting at 74%, then complaint handling and quality optimisation at 55% each. These are the domains where data is available, where the return is legible, and where the operational risk of getting it wrong is manageable.

The results behind them are increasingly specific. China Mobile reached Level 4 in its network operations centres through automated agents and copilots, reporting an 80% reduction in major network faults and a 30% average reduction in fault and customer complaint mean time to repair, alongside the equivalent of 5,500 manual roles redeployed by the end of 2024. Telkomsel’s east Indonesia pilot of AI-driven predictive operations improved its customer experience index by 14.7% and cut wireless traffic loss by 12.6%. MTN South Africa achieved Level 4 validation for IP network optimisation, and Rakuten Mobile did the same for RAN energy efficiency in a live Open RAN environment, delivering around 20% energy conservation. Deutsche Telekom reduced the time needed to manage a major event from hours to about a minute. In field operations, Microsoft now manages more than 65% of fibre-break field dispatches on the Azure network autonomously.

One caution on sequencing, because I see it get this wrong in planning conversations. Network planning and design sits lowest in the industry order of priority at 33%, and TM Forum’s own scenario map does not treat planning and deployment as high priority for the next two years. It is the next frontier rather than proven ground, and I would not anchor a first business case on it.

4. The execution gap

Figure 4. Autonomy falls away at the point of action, and what actually blocks it

Here is the finding that reframed this topic for me. When TM Forum asked respondents which parts of anomaly resolution they had made autonomous, 66% had automated detection, 49% root cause location, 49% decision, and only 34% execution. The same shape appears in customer experience assurance: 66% detect the issue, 60% determine root cause, 40% determine the corrective action, and just 26% implement it. Network configuration change and adaptation sits at 27% against 65% for fault monitoring.

The industry has automated seeing. It has not automated doing. Every percentage point of that decline is a place where a human still has to be in the loop, and the reasons are rarely technical. They are questions of trust, of blast radius, of whether an action can be explained to a regulator afterwards.

The reported obstacles confirm it. Cross-domain integration complexity is rated very challenging by 60% of respondents, up from 53% a year earlier, followed by budget and competing capex priorities at 54%, legacy software processes unsuited to AI at 52%, and the absence of a defined end-to-end architecture or path to Level 4 at 44%. Data quality is the single largest data-specific obstacle at 61%, with siloed data at 45%. Not one of these is a model problem.

This is why I am cautious about treating AI as the transformation rather than the accelerant. AI deserves its central place in the story, and it is the main reason network automation has regained momentum. But four foundations still have to move together. Trusted and accessible data comes first, and it is where most programmes underestimate the work. Operational processes have to be redesigned for autonomy rather than mapped. People, skills and ways of working have to change, with engineers collaborating with agents in clearly defined new roles. And adoption, change management and governance have to be deliberate, with measured rollout, auditable action and retained human oversight. AI can strengthen every one of these. It can substitute for none of them.

5. Building the Network Harness

Figure 5. Network IQ, Customer IQ and the harness that makes engineering reusable

If the execution gap is the constraint, then the answer is not another use case. It is the layer beneath the use cases. I think about it as three blocks, and Microsoft’s contribution sits inside them rather than alongside them.

Network IQ is the shared intelligence layer for network operations, unifying telemetry, topology, service context, OSS and BSS data, operational knowledge and policy. In the Microsoft stack this is Fabric and OneLake, and the point that matters is that unification does not require consolidation. Data can be referenced where it already sits, replicated where that is simpler, or reached inside the operator’s own data centres through a gateway. Inventory can stay on-premises, telemetry can sit in another public cloud, and a national market can keep its customer data in country, while all of it is queried and governed as one logical estate. In telecom that is rarely a convenience and usually the only lawful option. Heavily customised inventory, mediation or activation systems will still need real integration work, and that is precisely the work I want done once and inherited by every use case that follows.

Customer IQ applies the same discipline to the customer pane. Service-to-customer mapping, experience signals, care interactions, complaint history and customer value, sitting on the same data estate rather than a parallel one. This is the block operators tend to defer, and I would argue it is the one that converts autonomy from a cost programme into a revenue programme. A fault becomes answerable not only as what broke, but as who is affected, which of them matter most commercially, and what we tell them first. That is the bridge to the argument TM Forum is now making about Level 4 as a growth strategy rather than an efficiency one.

The Network Harness is what connects the two and makes autonomy scale. It is the reusable operating fabric: the NOA reference architecture, shared agents and skills, common workflows, one governance model and one runtime. Two things sit inside it. At the engineering layer, a coding harness with skills, memory and middleware, integrating the GitHub Copilot SDK, and Microsoft treats that layer as a flex point rather than a lock-in, which keeps model and framework portability in the operator’s hands rather than the vendor’s. Around it, Microsoft Foundry supplies what a production estate needs: a skills library, MCP connections and tools, managed memory, hosted agents, runtime model routing that turns model cost from a fixed vendor price into an engineering variable, retrieval across both intelligence layers, and observability. Expanded TM Forum Open API support keeps all of this alongside existing OSS and BSS rather than in place of them, and agents publish into Teams and Microsoft 365 Copilot so that engineers work where they already are.

Governance is the part that matters most in this industry. Agent traffic inherits the identity, content safety and observability policies already set for the fleet, and it lands in the same telemetry and dashboards as everything else rather than becoming a separate integration with its own access model. The governing question stops being what an agent is capable of and becomes who ran it, under which policy, and where the trace landed. That is the question a regulator asks, and it is the one that ends most autonomy conversations when there is no good answer.

Microsoft Frontier Company is the delivery block, and its composition matters as much as its scale. It brings together three things: deep industry knowledge, change management and continuous improvement experience, and enterprise-grade AI engineering expertise. The delivery mechanic underneath is forward-deployed engineering, with engineers working inside operator teams to co-design, build, deploy and keep improving the systems rather than handing over a platform and leaving. It is the combination that matters. Forward-deployed engineering on its own produces good software that nobody adopts. Industry knowledge and change capability on their own produce good advice that nobody builds. Together, and held to measurable outcomes rather than milestones, they are what Microsoft means by outcome-driven engineering, backed by a 2.5 billion dollar investment and more than 6,000 professionals drawn largely from existing forward-deployed teams.

That combination matters for the argument in this paper, because the harness does not build itself. Somebody has to sit inside the network operations centre, understand why a particular alarm correlation rule exists, turn it into a reusable agent rather than a bespoke script, and then persuade the shift supervisor to trust it. The first is engineering, the second is industry knowledge, the third is change management. Take any one away and the harness stays a prototype.

One practical point, because it comes up in every conversation I have on this. Most operators already run their transformation through system integrators and advisory partners, and embedded Microsoft engineering does not displace those relationships. Microsoft has extended the forward-deployed model into those organisations, so an operator’s existing partners can work inside the same engineering approach rather than alongside a parallel one. For an operator with a decade of accumulated context sitting inside a partner relationship, that continuity is worth more than any individual capability in the stack.

I would also rather point to what we run ourselves than to what we sell. Microsoft operates the Azure global network this way, and the results are public: more than 65% of fibre-break field dispatches managed autonomously, a 60% reduction in time to detect fibre issues, a 25% improvement in time to repair, root-cause analysis 80% faster, and a flat staffing curve as incident volume rose. During a subsea cable cut, agents activated overnight, evaluated alternative routing and contacted partners without a human initiating any of it. Far EasTone has embedded agentic AI across its network operations centre and change management workflows using the NOA framework, with roughly 60% of its NOC operations now AI-assisted, and Vodafone is applying the same blueprint across transport infrastructure and field-force management.

The route through is deliberately staged. Assess the baseline by domain, process and market. Define the target state with interim goals, because 3.75 before 4 is a more honest destination than a round number. Prioritise a portfolio of use cases on value, data readiness and risk. Build the harness that connects Network IQ, Customer IQ and shared workflows. Measure continuously across both business outcomes and autonomy maturity. And tie every project back to the overall Level 0 to 5 ambition, so that individual wins accumulate into something an executive committee can recognise.

What should operators track? When TM Forum asked which improvement indicators matter most, rather than what respondents had achieved, the answers clustered tightly: 82% named reduced operations and maintenance cost, 81% fault prediction accuracy, 80% fault handling duration and 78% fault handling automation rate. That consensus is useful, because it means a business case built on those measures will be legible to peers and to an executive committee. To them I would add three that are less commonly instrumented and more diagnostic: the rate of human intervention, rollback and confidence metrics, and above all the degree of use-case reuse. Reuse is what separates an interesting pilot from an industrialised transformation, and it is the one metric that tells you whether you are building a harness or another island.

6. Conclusion

The telecom industry has pursued automation for decades, but the conditions are genuinely different now. Stronger digital foundations, compounding demand, rising complexity and constrained economics are converging, and AI has arrived with enough capability to matter. That combination makes autonomy a practical necessity rather than a distant aspiration.

The route forward is also clearer than the maturity numbers suggest. Operators do not need to wait for a fully autonomous network. They can move scenario by scenario, building maturity over time, while using AI to accelerate diagnosis, planning and execution. The operators who pull ahead will not be the ones automating fastest. They will be the ones automating once, in a way that the next domain and the next market can inherit.

So I am more optimistic than the maturity numbers on their own would suggest. The autonomous network is within reach, and I do not think that has been true before. But reach is not the same as arrival, and Level 4 is not a milestone waiting to be purchased. No platform arrives with it included. It is the cumulative result of many use cases progressing at different speeds under a common maturity framework, a shared harness layer and a disciplined operating model. Build that, and Level 4 stops being plausible and starts being executable.

References

1. GSA, State of the Market report, April 2026 (5G Standalone launches to end March 2026). https://gsacom.com/paper/state-of-the-market-april-2026/

2. GSMA, From Ambition to Execution: How Open Gateway Is Scaling the Global API Economy, March 2026. https://www.gsma.com/newsroom/article/from-ambition-to-execution-how-open-gateway-is-scaling-the-global-api-economy/

3. Ericsson Mobility Report, mobile network traffic Q1 2026, June 2026. https://www.ericsson.com/en/reports-and-papers/mobility-report/dataforecasts/mobile-traffic-update

4. Ericsson Mobility Report, mobile data traffic forecast to 2031, June 2026. https://www.ericsson.com/en/reports-and-papers/mobility-report/dataforecasts/mobile-traffic-forecast

5. PwC, Perspectives from the Global Telecom Outlook 2025-2029. https://www.pwc.com/gx/en/industries/tmt/telecom-outlook-perspectives.html

6. Dell’Oro Group, Worldwide Telecom Capex to Decline in 2026, April 2026. https://www.delloro.com/news/worldwide-telecom-capex-to-decline-in-2026/

7. TM Forum, Assessing CSPs’ progress towards Level 4 autonomous networks, Benchmark Report, March 2026. https://inform.tmforum.org/

8. TM Forum, 2025 Autonomous Operations Maturity (AOMM) Industry Insights, IG1346 v2.0.0, January 2026. https://www.tmforum.org/

9. TM Forum, Autonomous Networks Leadership Forum and the Scaling to AN Level 4 report, June 2026. https://www.tmforum.org/news-insight/newsroom/autonomous-networks-leadership-forum-spotlights-level-4-shift

10. TM Forum, China Mobile achieves Level 4 AN in network operation centres with intelligent agents. https://inform.tmforum.org/research-and-analysis/case-studies/china-mobile-achieves-level-4-an-in-network-operation-centres-with-intelligent-agents

11. Deutsche Telekom, MINDR multi-agent network diagnostics and remediation. https://www.telekom.com/en/media/media-information/archive/mindr-ai-agents-in-the-network-1102724

12. Microsoft, Evolving the Network Operations Agent Framework, February 2026. https://techcommunity.microsoft.com/blog/telecommunications-industry-blog/evolving-the-network-operations-agent-framework-driving-the-next-wave-of-autonom/4496607

13. Microsoft, Introducing Microsoft’s Network Operations Agent, a telco framework for autonomous networks. https://techcommunity.microsoft.com/blog/telecommunications-industry-blog/introducing-microsoft%E2%80%99s-network-operations-agent-%E2%80%93-a-telco-framework-for-autonom/4471185

14. Microsoft, From Copilots to Coworkers: How AI Agents Are Transforming Azure Networking Operations, May 2026. https://techcommunity.microsoft.com/blog/appsonazureblog/from-copilots-to-coworkers-how-ai-agents-are-transforming-azure-networking-opera/4519850

15. Microsoft, MWC 2026: Microsoft accelerates telecom return on intelligence with a unified, trusted AI platform. https://www.microsoft.com/en-us/microsoft-cloud/blog/telecommunications/2026/02/24/microsoft-accelerates-telecom-return-on-intelligence-with-a-unified-trusted-ai-platform/

16. Microsoft, Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence, July 2026. https://blogs.microsoft.com/blog/2026/07/02/microsoft-frontier-company-ai-engineering-that-amplifies-and-protects-your-intelligence/

17. Fierce Network, Microsoft telco CTO details where AI is paying off and where it has not, March 2026. https://www.fierce-network.com/cloud/microsoft-telco-cto-details-where-ai-paying-and-where-it-hasnt

This article was first published on LinkedIn on August 9, 2026.

August 9, 2026
Why Telecom Needs Outcome-Driven AI Engineering

A personal view on why this shift is emerging now, how FDE, harness engineering and model choice fit into the operating model, and why telecom may be one of its most important proving grounds.

Forward-deployed engineering has quickly become one of the most visible ideas in enterprise AI. OpenAI has launched its Deployment Company. AWS has announced a forward-deployed engineering practice for partners. Anthropic is expanding applied AI engineering through new services and partner models. Salesforce has created an FDE partner network. Microsoft has introduced Microsoft Frontier Company.

When several major companies make a similar move at the same time, the useful question is not who announced it first. The useful question is what problem they are all trying to solve. The label most of them use is forward-deployed engineering, but the shared idea is bigger. It is a shift from shipping models to engineering outcomes, with the deployment team as the starting point rather than the whole answer.

I am part of Microsoft Frontier Company, representing the telecom industry perspective. This article is my personal view of why this model is emerging, what it needs to include, and why I believe it matters for telecom.

My conclusion is simple. Enterprise AI does not have an experimentation problem. It has a production, adoption and value realisation problem.

The problem is not adoption

AI adoption is now widespread. McKinsey’s 2025 global survey found that 88 percent of organisations were using AI in at least one business function. Yet only about one-third were scaling AI across the enterprise, and only 39 percent reported any enterprise-level EBIT impact. PwC’s 2026 CEO survey found that only 12 percent of companies had achieved both higher revenue and lower costs from AI, while 56 percent had seen neither.

The widely quoted MIT NANDA report reached an even starker conclusion. Its preliminary study found that 95 percent of the organisations examined had no measurable profit and loss impact from integrated generative AI pilots. That does not mean that 95 percent of every AI project has technically failed. It does reinforce a more useful point: model capability is rarely the main constraint. Integration, workflow fit, learning and ownership are.

The enterprise has acquired AI faster than it has absorbed AI. Pilots can prove that a model can perform a task. They do not prove that a business can redesign a workflow, connect live systems, govern actions, change human behaviour and produce a measurable outcome.

Figure 1. AI use is widespread, but production integration, workflow adoption and measurable financial impact remain far more limited. Sources shown in the visual: McKinsey 2025 and PwC 2026.

What forward deployment changes

Forward deployment is not simply an engineer sitting at a customer site. Palantir popularised the role by embedding engineers who could combine many capabilities around one important customer problem. The current AI version extends that idea. It brings the people who understand the industry, the workflow, the technology, adoption and value into one continuous team.

Microsoft describes Frontier Company as an outcome-driven engineering organisation that goes beyond conventional FDE. The company has committed $2.5 billion and 6,000 industry and engineering experts to work with customers on co-design, deployment and continuous improvement. The important point is not the size of the organisation. It is the operating model behind it.

Traditional enterprise delivery often resembles a relay race. Strategy identifies a use case. Engineering builds a proof of concept. Integration connects some systems. Security reviews it. The business receives training. Finance later asks whether it worked. Every handoff creates a chance to lose context, ownership or momentum.

A Frontier team should work differently. Industry expertise helps select the right problem and understand the operational constraints. Forward-deployed engineers build in the real customer environment. Harness engineers create the technical system around the agent. Customer engineers provide context and long-term ownership. Change specialists redesign roles and ways of working. Value owners define the baseline, target and evidence required to scale.

Adoption and change management cannot be the final box called training. Frontline users need to shape the workflow during discovery and design. The deployment must define what the human still decides, when the AI can act, how exceptions are handled, and how trust will be measured. Active use, recommendation acceptance, override rates and workflow adoption are as important as model accuracy.

Figure 2. The Frontier operating model brings industry expertise, engineering, adoption and value management together around a customer outcome. The harness and Foundry layer supports model choice, governance, observability and human control.

A Formula One way to explain it

The Formula One analogy is a useful way to explain this. A frontier AI model is like a powerful Formula One engine. The engine matters, but an engine alone does not win a race.

The harness is the car around the engine. It provides the controls, sensors, telemetry, safety systems and connection to the track. The forward-deployed team is the race engineering team working at the circuit. The industry specialist understands the race strategy. The customer environment is the track condition. The business KPI is the lap time, not the horsepower of the engine.

This also explains the day-to-day loop. Scope the outcome and establish the baseline. Build against real data and constraints. Deploy into real work. Prove the result. Learn from production. Package what is reusable and scale it.

The model provides intelligence. The harness enables reliable action. The team connects both to an outcome.

Figure 3. The model is the engine, the harness provides the telemetry and controls, and the forward-deployed team connects both to a business outcome through a continuous learning loop.

The harness, model choice and the economics of AI

Harness engineering is therefore a core part of the Frontier model. An agent needs enterprise context, tools, memory, workflow orchestration, identity, permissions, evaluations, human approvals, observability and feedback. Without this surrounding system, the agent may look impressive in a demonstration but remain fragile in production.

This is also where Microsoft Foundry is strategically relevant. The goal should not be dependence on one frontier model. It should be a governed architecture that can evaluate and use the right model for the right task.

Foundry offers a broad model catalogue across Microsoft and other providers, with tools to compare, deploy and, where supported, fine-tune models. Model routing can reserve more capable reasoning models for complex decisions while sending simpler tasks to smaller, faster and lower-cost models. Organisations can restrict the approved model pool according to performance, sovereignty, compliance or commercial requirements.

Fine-tuning is one option, not the answer to every problem. Retrieval, context engineering, prompt design, caching and workflow redesign may be more appropriate in many cases. The value of a common platform is that teams can test these choices rather than hard-code an early assumption into the architecture.

The same harness can apply company-specific guardrails to user inputs, outputs, tool calls and tool responses. Identity, permissions and human approval rules can reflect the organisation’s risk appetite. Observability can track latency, token consumption, failures, evaluation results and which model was selected. Cost data can then be considered alongside adoption and business KPIs.

That last point matters. AI ROI is not a calculation performed after deployment. Cost, quality, risk and value must be visible throughout the lifecycle. A cheap model that produces rework is not economical. An expensive model that materially improves a high-value decision may be. The correct unit of analysis is the outcome, not simply the token price.

Why this matters for telecom

Telecom is an ideal test of this operating model because meaningful outcomes rarely sit inside one system or one department. An operator combines critical national infrastructure, real-time network operations, customer service, field engineering, enterprise sales, complex partner ecosystems and decades of OSS and BSS investment.

McKinsey’s 2026 telecom research found that only 12 percent of surveyed operators had already captured sizeable impact from AI. This is despite widespread pilots and clear expectations of future value in customer support, networks and IT.

Consider a network incident. A generic AI assistant can summarise an alarm. A production system must do much more. It needs to correlate signals across network and service layers, understand topology and configuration history, assess customer impact, retrieve the right runbook, propose a resolution, respect change-control policy and know when human approval is required.

The people dimension is equally important. Network operations teams need to understand why the recommendation was made. They need clear thresholds for automation and escalation. The performance scorecard should combine technical measures such as diagnostic accuracy with operational measures such as mean time to repair, adoption measures such as recommendation acceptance, customer measures such as minutes of service lost, and financial measures such as avoided cost or service credits.

The same pattern applies to proactive customer care, enterprise quote-to-cash and field service. The agent is only one component. The value comes from connecting industry context, the harness, enterprise systems, human roles and measurable outcomes.

Figure 4. Telecom AI must operate across legacy systems, real-time operations, regulation and partner ecosystems. The network incident example shows why adoption, human approvals and a balanced value scorecard need to be designed into the workflow.

FDE is not magic

Forward deployment is not magic. It can become expensive bespoke engineering under a new name. It can create dependency on a small external team. Every project can start from zero. Field learning can fail to reach the product roadmap. A technically successful deployment can still fail because people do not trust it or because nobody can prove the value.

I believe every successful Frontier engagement should create three things at the same time.

First, a measurable customer outcome. Something meaningful must improve in operations, customer experience, revenue, cost or risk.

Second, reusable learning. The engagement should produce skills, connectors, evaluation sets, guardrail patterns or harness components that make the next deployment faster and better.

Third, customer self-sufficiency. The customer must be able to operate, govern and extend the system without permanent dependency on the original deployment team.

That is the real test of the model. A good forward deployment does not leave behind only a working solution. It leaves behind a stronger product, a more capable customer and a repeatable path to the next outcome.

The first phase of generative AI was about access. The second was about experimentation. The phase now beginning is about production deployment.

The next phase will not be won by the organisation with the most pilots or the greatest loyalty to one model. It will be won by organisations that can repeatedly turn model capability into better work, prove the value and learn faster from production.

For telecom, that may be the most important promise of outcome-driven AI engineering.

A good forward deployment should leave behind a working outcome, reusable learning and a customer that can operate and extend the system with confidence.

Sources and further reading

Selected primary and research sources. Accessed July 2026.

1. Microsoft Frontier Company announcement

2. Microsoft Foundry architecture

3. McKinsey, The State of AI in 2025

4. OpenAI Deployment Company announcement

5. PwC, 2026 Global CEO Survey

6. AWS Forward Deployed Engineering for Partners

7. MIT NANDA, The GenAI Divide 2025

8. Anthropic enterprise AI services company

9. McKinsey, Telcos AI inflection point

10. Salesforce FDE Partner Network

11. Microsoft Foundry Models overview

12. Palantir, Dev versus Delta

13. Microsoft Foundry model router

This article was first published on LinkedIn on July 20, 2026.

July 20, 2026