Forward Deployed Engineers Are Hot. But They Can’t Fix AI’s Data Problem

Getting AI from a promising pilot into production is proving to be less about picking the right model and more about solving the messy problems underneath it: fragmented data, legacy systems, integration and who owns the technology after it goes live.

That challenge has helped fuel the rise of ‘forward deployed engineers,’ or FDEs, who work directly inside customer environments to turn AI projects into working systems. But embedding engineers alone doesn’t guarantee success.

In an email Q&A with The AI Innovator, Sean Falconer, vice president of product, AI products and strategy at Confluent, discusses why FDE programs are spreading across the AI industry, where they can fall short and why the underlying data architecture may ultimately matter more than the engineers themselves.

Confluent is an enterprise data infrastructure company that helps businesses move and process data across their systems in real time.

The AI Innovator: What are companies discovering about embedded engineering teams and how they get AI into production?

Sean Falconer: The term ‘forward deployed engineer comes from Palantir, which built its whole go-to-market around embedding engineers directly inside customer environments instead of routing through traditional sales or professional services. In the last couple of years, that model has spread well beyond Palantir, especially among AI companies, because the same problem keeps showing up.

A generic demo or pilot doesn’t survive contact with a customer’s actual data, security constraints, and legacy systems. Even though we present AI as a magic black box where inputs go in, AI magic happens, and goodness comes out the other side, the reality is much messier. Getting AI into production is largely an integration problem, not usually a model problem, and integration work has to happen on-site, hands-on, with a specific customer’s stack.

AI coding tools have accelerated this trend because they make it cheap to spin up a working, customer-specific integration fast. But that’s also a trap. We’ve lived this ourselves. The hard part was never writing the code, it’s what happens six months later when the engineer has moved on and someone has to patch, secure and support what shipped. The companies getting real value from FDEs are the ones who decide upfront whether each engagement is meant to generalize into the core product or stay a one-off, before they write a line of code.

What are the most common data architecture problems that derail AI deployments, even when companies bring in FDEs?

The most common problem is that a company’s data is scattered across dozens of systems, and there’s no fast, affordable way to get a single consistent view of the business at the moment an AI system needs it. Most of that data lands in a warehouse or lakehouse built for a different job, a human analyst running a query once a day or once an hour and being fine with data that’s a bit stale. That architecture works when the consumer of the data is a person. It breaks down when the consumer is software, an agent that’s making a decision right now and needs the current state of the business, not last night’s batch load.

Bringing in an FDE doesn’t fix this. An FDE can get one use case working against one customer’s data, but they can’t rearchitect how that company moves and reconciles data company-wide in the course of an engagement. So what often happens is the FDE builds a bespoke pipeline to patch around the staleness and fragmentation for that one project, and the underlying problem – lack of a consistent, current view of the business – is still there for the next project. The AI deployment looks like it works in the demo and then falls apart in production because it’s reasoning over data that’s already out of date.

What should companies have in place before investing in an FDE team to give their AI projects the best chance of success?

The single most important thing is deciding, before the engagement starts, what happens to the code afterward. Does it become an open source accelerator, a roadmap item that core product owns, or a documented reference architecture? If a company can’t answer that question up front, the FDE will ship something the customer loves and nobody will own it six months later.

The second thing is measuring FDEs on the right outcomes. If a company evaluates them the way it evaluates professional services, utilization and billable hours, they’ll look like an expensive cost center and get cut in the next budget cycle, even if their work is quietly driving pipeline and product roadmap. The metrics that matter are things like pipelines influenced, accelerators reused across multiple accounts, and how many engagements have a core product engineer co-staffed alongside the FDE, since that’s what actually determines whether the work graduates into something durable.

Third, and often skipped, is having a real plan for support and security ownership once that code is live in a customer’s environment. Companies that skip this end up years later with an escalation on code nobody can support anymore. 

And finally, the underlying data architecture has to be sound enough that an FDE is solving a genuinely new problem, not duct-taping around the same stale, fragmented data that will sink the next ten AI projects too.

From your perspective, what separates organizations that successfully move AI from pilot to production from those that remain stuck in experimentation?

The ones that make it treat this as a data and ownership problem, not a model problem. They accept early that a pilot works because someone hand-curated a clean dataset for the demo. Production won’t have that luxury, so they invest in getting a consistent, current view of the business before they scale the AI effort, instead of bolting a flashy model on top of the same stale, fragmented pipelines that were never built for a software agent to consume.

The second thing is they decide upfront who owns the thing once it’s live. A pilot that impresses everyone in a review and then has no team assigned to support, secure, and maintain it in production is dead on arrival; it just takes longer to admit it. The organizations that get stuck tend to run AI as a series of one-off experiments, each judged by whether it worked in a demo, rather than by whether it’s actually running, generating value, and has a real owner.

The pattern shows up across the industry too. Survey after survey has found that most enterprise AI pilots never reach production, and it’s rarely because the model wasn’t good enough. It’s because nobody built the plumbing or the ownership structure for it to survive contact with the real business.

As more AI vendors offer FDE programs, do you think the competitive advantage will come from the engineers themselves or from the underlying data infrastructure that supports AI applications?

Palantir is the clearest proof of this. They basically invented the FDE title, and the assumption people draw from that is Palantir’s edge was hiring exceptional engineers who could drop into a customer and just make things work. That’s true for the first 90 days of any engagement, but it’s not why Palantir became repeatable across hundreds of customers.

What actually carried forward was the ontology, a layer that takes a customer’s raw, scattered data and maps it into objects, properties, and actions that mean something in business terms: a shipment, a patient, an account, and the ways those things can change. The FDE’s real job wasn’t writing clever code; it was doing that mapping.

Once it existed, the next engagement wasn’t starting from zero; it was extending a structure that already worked, and later, once Palantir built its Artificial Intelligence Platform on top, that same structure is what let AI agents reason over a customer’s data reliably instead of hallucinating against a pile of disconnected tables.

Other AI vendors standing up FDE programs are making the same mistake people make when they try to copy Google by handing out free lunch and snacks and assuming that’s the secret. It’s a real perk, and it’s not nothing, but it’s a wild oversimplification of what actually made Google successful, and treating it as the cause instead of a side effect will leave you with a nice cafeteria and none of the underlying engine.

FDEs are the free lunch of this story. The ontology is the search index. Companies hiring sharp engineers and calling it an FDE program while skipping the durable and repeatable data structure underneath are going to get Palantir’s cafeteria, not Palantir’s business.