The One Number That Tells You If Your AI Deployment Team Is Actually Working
Why most companies building a Forward Deployed Engineering function risk becoming an expensive consultancy — and the single diagnostic that reveals whether field delivery is actually compounding into product.
Every enterprise software company with an AI story seems to be building some version of the same team right now: engineers embedded close to strategic customers, operating where product, data, implementation, and ambiguity collide.
In my previous article, The Rise of the Intelligence Architect, I argued that enterprises need to think beyond individual AI roles and design the system in which humans and AI agents operate together. Forward Deployed Engineering is one increasingly visible part of that shift.
But there is a structural question underneath the enthusiasm for FDE that I think deserves more attention:
How do you know whether the team is actually building a product capability — or quietly building a consultancy?
The pitch is compelling. Put strong engineers directly with high-value customers. Give them the authority to solve problems nobody could cleanly write a specification for. Ship in weeks instead of quarters. Turn the result into a reference customer that helps unlock the next five deals.
That can work. But the first successful deployment proves much less than people think.
The real test is whether the fifth deployment requires less custom engineering than the first.
The failure has a shape — and it's not the one you'd guess
The obvious risk looks technical: can these engineers build production systems under pressure, inside a customer's messy environment, on a deadline? That risk is real, but it is also comparatively easy to see and hire for.
The harder risk is structural.
The first engagement usually looks like a win. A senior engineer embeds with a strategic account, does real discovery, builds something useful, and the customer is thrilled. Sales wants to repeat the model immediately.
The second engagement looks like a win too. So does the third.
Then, by the fourth or fifth, something important may become visible: each customer still requires roughly the same amount of custom engineering as the first. The work is valuable. Customers are happy. Revenue may be growing. The team is busy.
But nothing is getting meaningfully cheaper, faster, or more reusable.
Without anyone consciously deciding to create a services business, the company is now running professional-services economics inside a product company's cost structure.
That is the trap: not failure. Success that never compounds.
The one diagnostic I'd watch
There is one number I would want on the operating dashboard before almost anything else:
Custom engineering effort per customer, tracked engagement over engagement.
Not billable hours. Not utilization. Not deals closed. Not even customer satisfaction by itself.
How much custom engineering does it take to get the next customer live compared with the last one?
If that number is declining, the model is likely doing what an FDE function is supposed to do. Field learning is being converted into reusable product capability. Patterns are becoming components. Repeated integration work is becoming tooling. Discovery is becoming playbooks. Each deployment teaches the product how to require less human intervention the next time.
That is compounding.
If the number is flat, one of two things is probably happening: every engagement is genuinely novel — possible, but unlikely at scale — or the mechanism that is supposed to convert field learning into product has stalled.
If the number is rising, I would be concerned that the FDE team has become permanent human middleware between the customer and the product.
At that point, hiring more Forward Deployed Engineers may increase capacity, but it does not fix the model.
The question is no longer, "How do we staff more deployments?" It becomes, "Why isn't every deployment making the next deployment easier?"
Why this can stay invisible
The reason this problem can survive for so long is that almost every conventional indicator around it may look healthy.
Revenue is growing. Customers are satisfied. Engineers are fully utilized. Strategic accounts are asking for more. The team's backlog is expanding.
All of those signals can be interpreted as success.
Meanwhile, effort per customer quietly remains flat or rises.
Busy is not the same as scalable.
An FDE organization should not simply absorb complexity for the customer. Over time, it should remove recurring complexity from the system.
The second dimension: governance must compound too
There is another failure mode that becomes especially important as these teams move from traditional integrations into agents and model-integrated systems.
Governance cannot be something that happens after the prototype works.
Human oversight, auditability, data controls, model behavior, drift monitoring, explainability, access boundaries, and escalation paths are not merely approval activities. In AI systems, they are part of the architecture.
A security or compliance team reviewing a finished prototype can stop a launch. What it cannot do is retroactively design a human-in-the-loop decision point into a workflow that was never built to support one.
That has to happen during discovery.
The strongest teams, in my view, make governance part of the delivery lifecycle itself: risk tiering informs discovery, data controls shape the prototype, human escalation is designed into the workflow, and the full control set becomes a deployment gate.
This is where the economics and governance arguments meet.
Compounding tells you whether the FDE model scales economically. Embedded governance tells you whether it can scale operationally.
You need both.
Three questions I'd ask before greenlighting an FDE function
- What happens to the fifth engagement's engineering cost — and who is tracking it?
If nobody can answer that with a number, you do not have a scaling diagnostic. You have a hope. - Who can say no to a deal-sized customer request — and has that authority ever actually been used?
A product organization needs a mechanism for distinguishing strategic learning from permanent customization. A veto that can never be exercised is not governance. It is decoration. - Is AI governance a design input during discovery, or a review before launch?
If governance enters only after the prototype works, the team is discovering architectural constraints at the most expensive possible moment.
The uncomfortable part
None of this is primarily a hiring problem.
Great engineers matter. But an exceptional FDE team operating inside the wrong economic mechanism can still become an exceptional consultancy.
The differentiator is whether the organization has built a deliberate path from field work to reusable product capability — and whether governance is designed into that path from the beginning.
The companies I would bet on are not necessarily the ones with the most impressive individual deployments.
They are the ones that can show the curve.
Customer one required this much custom engineering. Customer five required less. Customer twenty required less again.
And if that curve starts moving in the wrong direction, they know exactly why — and exactly what they are going to do about it.
That is when Forward Deployed Engineering stops being a collection of heroic deployments and becomes something much more valuable:
A product system that learns.
This article reflects my personal views and independent analysis. It is not written on behalf of, affiliated with, endorsed by, or representative of any current or former employer or other organization with which I am or have been affiliated. The discussion is based on publicly available information, general industry observations, and conceptual analysis; it does not disclose or rely on confidential, proprietary, or non-public information of any employer, client, or other organization.