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.

Article content — 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.

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.

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.

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.