The Missing Delivery Model for Enterprise AI
Introducing Forward-Deployed Operators (FDOs) and AI Operating Units (AIOs)
TL;DR: The bottleneck in enterprise AI has shifted from technology to delivery. Most internal and external approaches fail because they optimise for experimentation, effort, or enablement rather than operational outcomes. This essay introduces Forward-Deployed Operators and AI Operating Units as two sides of the same operator model. Both are cross-functional teams accountable for delivering working AI systems into live workflows, built on reusable software and outcome-linked economics, with one operating externally and the other embedded internally.
In recent newsletters, I argued that the limiting factor for enterprise AI was no longer model capability, but organisational readiness. I have been dissecting the reasons why AI progress stalls, from workflow design, integration depth, tech fluency, leadership structure, and trust. Across those threads, a single failure: the way enterprises attempt to roll out AI is no longer aligned with how AI creates value.
Why AI delivery keeps breaking
Let’s call it from the outset: I think the constraint has shifted from technology to delivery.
Internal AI initiatives tend to move slowly and have fragmented ownership. Work is layered onto existing roles, incentives reward stability rather than risk-taking and change, and responsibility is split across technology, data, product, and P&L owners. Delivery cycles stretch to the point where strategy is revised multiple times before implementation lands, and roadmaps built on annual planning horizons struggle to keep pace with much shorter innovation cycles. Outcomes are also bounded by the weakest link across a long chain of functions, where capability and judgement are uneven by default. Even when intent is strong and assuming budgets remain, momentum fades once initiatives move beyond experimentation and into the harder work of production.
External launches struggle for different reasons. Many stop short of the work required to make AI survive in production; treating integration, security, reliability, and long-term ownership as follow-on concerns. Commercial incentives play a large role here. Time-and-materials models reward persistence rather than resolution, making it rational to extend delivery rather than compress it. Large consultancies and systems integrators, with significant overhead to sustain, are structurally biased toward bespoke rebuilds and long-running programmes rather than fast, repeatable execution tied to outcomes. At the same time, the expertise presented to clients is often uneven, with senior involvement concentrated on sales and coordination while delivery is pushed to junior teams. As AI shifts value creation closer to workflows, decisions, and sector-specific economics, generalist approaches weaken. Without deep industry context and clear skin in the game, credibility erodes and proof points rarely turn into operating capabilities.
Both approaches fail for the same underlying reason. No one is accountable for turning AI capability into sustained operational change.
Operators as the organising principle
AI creates value when it reshapes workflows, decision-making, and economics inside the organisation. That kind of change sits awkwardly between functions: neither a pure technology challenge nor a business one. What has been missing is a delivery model designed explicitly to own that middle ground.
The model I am proposing takes two closely related forms, one external and one internal. Both centre on a different kind of operator: accountable for outcomes rather than tools or advice, responsible for taking working systems into live workflows, and designed to step away once those systems are proven in practice.
Each addresses a different organisational constraint. Together, they form a more realistic way to operationalise AI.
1. Forward-Deployed Operators (FDOs)
Forward-deployed operators are temporary, embedded teams brought into an organisation to deliver a specific AI-driven outcome under time and performance pressure. The concept draws inspiration from earlier forward-deployed engineering (FDE) models, most notably those pioneered in complex software deployments, while extending the scope well beyond engineering enablement.
In this model, the operator is the unit of delivery. FDOs work in hybrid teams bringing together domain expertise, commercial judgement, product ownership, data science, and engineering as a single, accountable group. They are operators with different disciplines, working to the same mandate and measured against the same outcomes, not adjacent functions coordinating across hand-offs. Traditional functional boundaries are labels we like to organise ourselves around; in AI they only matter as enabling components of a single system, with value emerging at their intersection.
An explicitly external construct, this hybrid delivery model sits between classic consulting and product deployment. FDOs arrive to execute, not to advise, and they leave once results are proven. Their mandate is deliberately narrow, with success defined upfront through measurable KPIs tied to live workflows.
Delivery starts from reuse rather than reinvention - now made possible as AI systems are increasingly modular and adaptable, shaped through orchestration, tuning, and workflow design rather than bespoke builds. Teams arrive with base software and established patterns that already encode how similar problems have been solved elsewhere. Sector depth matters here, because it enables teams to begin from a position of material readiness rather than extended discovery.
Most of the work lies in adaptation: integrating with existing systems, shaping interfaces around real work, tuning models against operational decisions, and readying everything for production use. Engagements are outcome-linked, with payment gated on performance in production and software licensed at handover. Risk sits with the operator until the system works, and exit is explicit once agreed thresholds are met.
This model exists to compress learning curves, transfer execution risk, and deliver change quickly in environments where internal capacity, incentives, or structures make that difficult to achieve alone.
It could be easy to interpret this as outcomes-based consulting with a multidisciplinary team. That framing misses several structural shifts. The operator model does not sell advice, capacity, or effort. It exists to deliver a working system into production and make itself unnecessary. Reusable software, sector playbooks, and longer payback horizons are central to how value is created. Those constraints are difficult to reconcile with traditional consulting economics, which is why the model behaves differently in practice.
2. AI Operating Units (AIOs)
AIOs are the internal counterpart to FDOs, shaped by the same delivery logic.
Unlike traditional AI centres of excellence or platform teams, AIOs are not designed to enable others at scale. They are designed to operate. Their legitimacy comes from changing how work is done inside the business, not from building shared capabilities, standards, or tooling. For that reason, they sit closer to P&L ownership than to central technology functions.
As with FDOs, the unit itself is the point. Product, data, engineering, domain, and commercial expertise are brought together without rigid functional boundaries. Titles matter less than contribution to the outcome.
In principle, there is no reason enterprises cannot build this capability internally. In practice, sustaining it is difficult. The talent mix is rare, incentives tend to soften over time, and delivery urgency erodes once teams become permanent. Without explicit constraints, operating units gradually accrete scope, turn into functions, and lose the very characteristics that made them effective. Where AIOs struggle to form or to hold their shape, FDOs can fill the gap.
Together, these two constructs reflect the same underlying insight. AI requires operators who can own outcomes across technical, product, and organisational boundaries. The difference lies in context, incentives, and duration; but the nature of the work itself remains.
Why this delivery model works now
This operator-based approach was not viable a few years ago but several conditions have shifted.
Enterprise software delivery has moved away from monolithic integration programmes toward more modular architectures. LLM-centric systems can be shaped through orchestration and workflow design rather than extended build cycles, making rapid, outcome-driven delivery realistic. At the atomic level, agentic systems are built from familiar components, a model, instructions, and tools. The challenge is no longer building but operationalising them reliably.
Execution capacity has also compressed. When AI is used well, small senior teams can deliver changes that previously required large delivery organisations, with fewer handoffs and tighter feedback loops between domain understanding and system behaviour.
Just as importantly, patterns now repeat. Across sectors, similar structures emerge around decision support, human-in-the-loop design, and the relationship between AI systems and existing records of truth. That accumulated experience enables base software and playbooks that materially reduce time to value.
Finally, the organisational context has changed. Curiosity has given way to execution pressure. Boards and executives are less interested in experimentation narratives and more focused on whether AI investments translate into tangible changes in cost, throughput, or revenue.
Naturally, this approach does not fit every company or every problem. It assumes clarity on objectives, workable data foundations, and a willingness to commit to outcomes.
What this changes
2026 will be the year of AI execution pressure.
Progress is not a function of tool access but ability to deploy change under real-world constraints. Delivery models that optimise for extended effort or diffuse ownership struggle in that environment. Models built around operators, whether internal or external, align more closely with how AI value is actually realised.
FDOs and AIOs are two sides of the same coin. One accelerates and de-risks execution from the outside. The other sustains and unlocks impact from within.
From here, the advantage lies with organisations that can harness both, and turn AI into an operating capability rather than a recurring experiment.
About
I analyse AI progress beyond the headlines, focusing on enterprise execution, incentives, and real-world economic impact.