IT Operations Doesn't Need Forward-Deployed Engineers. It Needs to Build the Ones It Already Has.

I've spent a fair amount of time arguing that implementation, not model capability, is what determines whether enterprise AI actually pays off. The current wave of forward-deployed engineering (FDE) ventures — Anthropic, OpenAI, and a handful of consultancies have all launched one in the past few months — is a validation of that argument. But validating that implementation matters isn't the same as agreeing on what's actually being implemented, and that's where I think this wave gets it half right.

Look closely at what these teams are shipping, and a pattern emerges: the work is overwhelmingly process automation and code assistance. Workflow redesign, custom internal tools, coding agents wired into a company's existing software stack. That's valuable work. It's also a narrower slice of enterprise operations than the industry conversation suggests, and it leaves the largest, most expensive, most operationally mature category almost untouched: IT operations itself.

That's the gap I want to name directly. IT operations isn't short on automatable process the way, say, a finance team's reconciliation workflow is. It's already sitting on decades of tooling — ITSM platforms, monitoring stacks, orchestration engines, cloud and converged/hyperconverged infrastructure, each with its own control plane and API surface. The art of possibility here isn't building a new workflow from scratch. It's an FDE-caliber engineer who can reach into that existing tooling and eliminate the work that tooling was never allowed to eliminate, because the humans running it were being billed by the hour, not by what got removed.

Here's what that looks like in practice, across the three categories that make up most of an IT operations queue.

Proactive tickets: the control panel is the target, not the ticketing tool

A large share of any operations queue is proactive noise — alerts that fire, get acknowledged, and close with no action taken, or the same handful of remediation steps run by hand every time a switch flaps or a service degrades. Most automation efforts stop at the ticketing layer: faster triage, smarter routing, a chatbot that summarizes the alert. That's process automation applied to the wrapper, not the problem.

The actual leverage sits one layer down, in the monitoring and orchestration tools themselves and the control panels they talk to. An engineer working this the way an FDE would needs to go past the alert into the device or platform API — authenticate against the control panel, run the diagnostic, execute the remediation, handle credential failures and retries the way a senior engineer would. That's not a code assistant helping someone write a script faster. It's redesigning the monitoring-to-orchestration path so the alert resolves itself and the ticket category stops existing. That distinction — automate the response versus eliminate the need for a response — is exactly where generic FDE work and IT-operations-specific work diverge.

Business impact: the dependency map lives in the infrastructure, not the codebase

Most IT operations reporting stops at operational metrics — MTTR, ticket volume, SLA adherence — because nothing in a standard ops stack traces causation from a specific piece of infrastructure to a specific business outcome. A code assistant can't build that map; it doesn't have visibility into cloud spend, converged infrastructure health, or which workload sits behind which SLA.

This is where the ITSM, monitoring, and cloud platforms have to be treated as a connected system rather than separate tools each getting their own point automation. The work is building the dependency graph across them — which infrastructure components, when degraded, actually move the numbers the board tracks — and keeping that graph current as the environment changes. Done well, it turns "we resolved 190,000 tickets" into a specific, defensible line connecting infrastructure health to loss ratio, downtime, or whatever the equivalent KPI is in the business. That's an IT operations and platform-architecture problem first, a coding problem a distant second.

Reactive workload: eliminate the request path, not just the ticket

Identity and access management — password resets, access requests — is reactive, end-user-generated workload that exists almost entirely because the underlying process still requires it. A code assistant can help build a self-service portal faster. It can't decide that passwordless authentication should replace the password reset flow entirely, because that decision lives in identity infrastructure and platform architecture, not in application code.

Implemented at the platform level — passwordless authentication, self-service access tied directly into the identity provider and control panel — the majority of this category gets designed out of existence rather than resolved faster. What's left, genuine exceptions and anomalous access requests, gets routed to a model trained to recognize what it can't resolve and hand off with full context. Humans handling exceptions, not humans handling volume.

Enterprises already have their FDEs — they're called SREs

There's a piece of this that the external-vendor framing misses entirely: enterprises don't need to import forward-deployed talent to get this done. They've already been investing in it for years, under a different title.

Site reliability engineers already have the thing that makes an FDE valuable in the first place — deep, working knowledge of the platform surface: the ITSM system, the monitoring stack, the orchestration layer, the cloud and converged infrastructure, and the control panels underneath all of it. What most SRE organizations haven't had is the AI and Gen AI enablement to turn that platform knowledge into elimination at scale. They've been doing the work the traditional way — runbooks, scripted automation, manual correlation across tools — because that was the available toolset.

Trained and enabled with AI, that same SRE function becomes the internal FDE. Not someone who needs a vendor's engineer parachuted in to learn the environment from scratch, but someone who already knows where the workload is, who can now train models on that environment's specific failure patterns, deploy them against the control panels they already operate, and supervise the exceptions that need human judgment. That's the difference between SREs using AI as a better search bar and SREs using AI to actually deliver the outcome the AI promise has been selling — eliminated workload, not faster-handled workload.

This matters for the buy-versus-build question every enterprise evaluating Ode, the Deployment Company, or a consultancy's FDE team should be asking. External FDEs bring implementation pattern experience across many environments. Internal SREs, AI-enabled, bring something external teams can't easily replicate: institutional knowledge of exactly which alert has never once required a human, and exactly which control panel API needs to be trained against to eliminate it. The highest-leverage move for a lot of enterprises isn't hiring an implementation firm — it's pointing AI enablement at the SRE org they already built.

Why this distinction matters

All three examples share a discipline: Eliminate, Empower, Harden, Automate. Eliminate the workload that shouldn't exist. Empower the people and systems that remain. Harden what's left against failure. Only then automate — because automating a process you haven't eliminated just makes the process run faster, not go away.

Generic FDE and code-assistant work is real and worth doing, but it's aimed at building new things faster. IT operations doesn't need more things built faster. It needs someone with the platform depth — ITSM, orchestration, monitoring, cloud, converged and hyperconverged control panels — to go eliminate the workload those platforms were built to manage in the first place. That's a different skill set than shipping a coding agent, and it's the piece the current wave of implementation firms hasn't fully reached yet.

It also raises the pricing question again. None of the current implementation ventures have announced pricing tied to avoided cost, eliminated ticket volume, or headcount actually removed — because that pricing model only makes sense once you're doing elimination work, not automation work. Until implementation firms move into IT operations specifically, avoided-cost pricing will stay theoretical rather than something buyers can actually ask for.

This is part of an ongoing series on AI-native IT operations. Read the full framework at murthymalapaka.com/insights.