ENTERPRISE AI DELIVERY & GOVERNANCE

The Forward-Deployed Engineer Gold Rush: New AI Revolution or Old Consulting Model?

Separating the hype from the realities of enterprise AI deployment, economics, governance, and long-term customer success.

By Vijay Rengan, Founder & Chief AI Officer, EMLI

The technology industry has a remarkable ability to reinvent established concepts with new terminology. The latest example is the Forward-Deployed Engineer, or FDE.

Enterprises need engineers who turn AI into working business applications. In its October 2, 2026 announcement, Anthropic committed $100 million to train 10,000 “Frontier Deployed Engineers” by the end of 2027—a training target, not job openings. Hiring enthusiasm and compensation discussions do not establish lasting customer value.

In LinkedIn postings I follow, FDE can mean product deployment, solution architecture, custom AI development, or internal AI transformation. This confuses candidates about skills and employers about whether they need a platform engineer or transformation leader. Gartner also observes that providers apply the label to implementation, professional services, solution engineering, and AI consulting.

Gartner’s September 29, 2026 briefing predicted that by 2028, 70% of enterprises would abandon agentic AI built by vendor forward-deployed engineering, citing rising costs and difficulty evolving solutions themselves. This is a forecast, not an observed failure rate, but it questions delivery durability.

Deployment investment and disappointing outcomes could coexist. When does forward deployment create sustainable capability, and when does it leave an expensive, difficult-to-maintain solution?

Having spent 35 years developing enterprise software, managing engineering teams, and delivering technology solutions to major corporate customers, I find the underlying concept familiar. We deployed engineers directly into customer environments long before the term FDE became fashionable. Comparable work was carried out by contractors, consultants, and resident engineers, although the responsibilities varied across engagements.

Look beyond titles: what exists, what must be built, how the economics work, and who takes responsibility afterward? These questions distinguish product-centered engineering from broader AI transformation.

An Old Concept with a New Name

For almost two decades, my company, EML Incorporated, provided advanced technical engineering and support services to IBM and its enterprise customers.

We routinely assigned engineers to customer environments to troubleshoot complex systems, resolve critical technical issues, implement solutions, and work alongside customer technology organizations.

Our engineers were highly specialized. They understood the technology, developed relationships with customers, operated within established contractual boundaries, and frequently worked on business-critical infrastructure.

There was nothing revolutionary about embedding technical expertise with the customer. It was simply how complex enterprise technology was delivered and supported.

Customers purchased established technology; engineers installed, configured, integrated, troubleshot, and supported it in their environments.

The product existed before the deployment began.

That distinction helps explain when modern FDE works—and when the assignment becomes something else.

Where Forward-Deployed Engineering Makes Sense

Palantir illustrates product-centered forward deployment.

Customers buy access to Foundry, Artificial Intelligence Platform (AIP), and Apollo. Palantir's engineers integrate data, develop applications, configure workflows, and operationalize this established ecosystem.

FDEs may write sophisticated applications, build customer-specific functionality, and improve the platform. This is substantial engineering, beyond installation or configuration.

Custom code is compatible with FDE when deployment builds on a reusable technological foundation that continues to evolve.

Teams know the architecture, capabilities, tools, security framework, and operating environment.

Customer requirements vary; a substantially consistent product makes deployment repeatable.

FDE teams own discovery, custom engineering, integration, validation, production rollout, and initial production stabilization before transition to ongoing operations.

Full lifecycle ownership does not mean indefinite support. After stabilization and formal handoff, FDEs can move to other implementations; designated customer owners and an established support organization sustain operations.

Palantir’s published support-services description separates implementation resources, standard support, and additional Customer Success services, including centralized development guidance, remote user support, and use-case maintenance. Handoff and coverage depend on the agreement; a wider organization supports customers beyond implementation.

Field-to-core-product feedback distinguishes the model structurally. Palantir describes field engineers working with core engineering to improve software around customer missions. Customer discovery and an established foundation coexist as useful field work becomes shared capability.

This is the fundamental economic advantage of a mature FDE model: repeatability.

Large enterprises and governments investing substantially in Palantir's platform can often justify specialized deployment engineering within the commercial relationship.

Repeatability does not make every deployment routine or identical; it means extending a known foundation rather than inventing each solution anew.

A middle case combines established models and tools with customer-specific applications. OpenAI’s FDE role spans discovery, design, development, and production rollout; Anthropic’s includes applications in customer systems. This can be legitimate FDE without complete enterprise transformation. The questions remain: what must be built, and will it become reusable and supportable?

When FDE Becomes an AI Transformation Initiative

Consider a financial services company modernizing customer service, automating documents, improving financial analysis, and connecting business applications.

Without a single deployable product, it must assess processes, systems, infrastructure, risk, and investment priorities: a transformation initiative extending beyond platform adaptation.

An AI transformation leader aligns business objectives, executive sponsorship, priorities, and the investment case. Finance validates baselines, realizable versus theoretical savings, and implementation and operating costs. Budget ownership, staged funding, scope control, and post-adoption returns need explicit management.

A solution architect designs integrations around existing applications and business requirements.

An infrastructure architect evaluates hosting, networking, compute, storage, appropriate GPUs, security, and operations.

Data engineers must address data quality, integration pipelines, permissions, and information architecture.

AI and product engineers must build applications, agentic workflows, model integrations, APIs, evaluations, and user experiences.

Security and governance specialists must establish privacy safeguards, regulatory controls, auditability, and risk management.

Business process owners and change-management professionals must prepare employees, redesign workflows, organize training, and measure adoption and business outcomes.

Internal teams and external partners can share these capabilities without separate full-time positions, but every responsibility needs an accountable owner.

One person can sometimes cover all of these functions in a smaller deployment. For a small company, I personally handled them myself while deploying E-QUERY on local hardware. That does not mean every talented AI engineer has the executive, architectural, financial, managerial, and operational experience—or the authority—to lead an entire AI transformation initiative.

An FDE title does not turn one engineer into an entire enterprise delivery organization.

Transformation requires broader skills, authority, funding, and organizational support. Labeling it FDE can create unrealistic expectations of an engineer or deployment team.

The Economic Difference Is Repeatability

FDEs and consultants may perform the same daily tasks: discovery, custom development, integration, and deployment. The business-model distinction becomes clearer when we ask what the vendor can reuse for its next customer.

In a mature FDE model, each deployment builds on a common platform, architecture, tools, integration patterns, governance capabilities, and delivery methods. Customer-specific engineering remains necessary, but recurring needs also feed improvements into the core product. Over time, those improvements should reduce the effort required for similar deployments.

A broader AI transformation engagement may offer less opportunity for that reuse. One customer needs document intelligence; another needs manufacturing computer vision, supply-chain forecasting, or customer-service agents. Shared components help, but differences in infrastructure, data, expertise, evaluation, and support can still require substantial new engineering.

This is the concern behind the forecast discussed earlier: Gartner forecasts that through 2028, fewer than 20% of FDE engagements will convert recurring customer needs into core-product capabilities. Its warning is that work marketed as FDE may retain the economics of consulting. This is a forecast about product reuse, not an observed failure rate.

The economic distinction is how revenue grows. A product company aims to serve more customers without adding engineering staff in the same proportion. A consulting business generally needs more specialized delivery capacity as projects increase in number and complexity. These are tendencies: product deployments still cost money, and consultancies can improve productivity through reusable assets and automation.

Neither model eliminates delivery costs. Vendors must recover engineering costs through implementation fees or product revenue, or subsidize them. Customers must justify total implementation and operating costs against measurable benefits. Repeatability helps, but the model must work economically for both sides.

Practical Considerations for the FDE Model

Beyond a reusable platform, delivery organizations must address:

  • Governance, confidentiality, and intellectual property: Who controls access, permitted data use, IP ownership, security, and incident response—and how is customer information protected after the engagement?
  • Supervision and employment responsibilities: Who directs the work, manages personnel, and resolves competing priorities?
  • Employee turnover and knowledge continuity: Can the implementation continue when an engineer leaves?
  • Support after deployment: Who maintains the system once the deployment team moves on?
  • Training and adoption: Who prepares employees and measures effective use?
  • Delivery economics and business value: Can the customer relationship justify the engineering cost and deliver a measurable return?
  • Internal enterprise deployments: Do the team’s mandate, funding, and authority match its responsibilities?

Governance Must Be Built Into the Deployment Model

Governance begins before engineers receive access to customer systems. Forward deployment can happen onsite or remotely; either arrangement needs customer-controlled identity, least-privilege permissions, restricted development environments, approved model endpoints, access logging, and prompt credential revocation. Synthetic or masked data should be used for testing where appropriate.

The engagement must also define permitted data use, ownership and reuse rights for code and deployment artifacts, confidentiality, incident response, and accountability. These decisions cannot be left to individual engineers or added after systems have been connected.

A forward-deployable AI product must be not only technically reusable, but also governable across different customer environments.

Customer reluctance to expose proprietary information can reflect sound risk management. Controls and clear responsibilities earn trust.

One of the most important lessons from my years managing engineers at customer locations concerns confidentiality. An engineer may encounter customer records, financial information, pricing strategies, operating procedures, and intellectual property. An enterprise AI implementation can extend that visibility across repositories ordinarily separated by department.

A reputable vendor and a confidentiality agreement do not eliminate the risk. The engagement must address unauthorized downloads, disclosure to external model services, and misuse of information, with responsibility determined by the applicable contracts, law, and circumstances.

I also encountered a particularly uncomfortable question as an enterprise services executive: what happens when an engineer leaves the vendor and joins the customer’s competitor?

Files and credentials can be removed, but knowledge of the business may remain. Confidentiality and trade-secret protections may restrict improper use or disclosure; they cannot erase what someone has learned. General professional knowledge is not automatically the customer’s property, and joining a competitor is not inherently improper. That distinction makes carefully limited access and appropriate obligations important from the outset.

Who Actually Manages the FDE?

When EML engineers worked within customer environments, we distinguished the customer’s responsibility for requirements and deliverables from EML’s responsibility for managing its employees. Customers identified problems and priorities; employee administration and supervisory responsibilities remained with EML.

Forward deployment does not necessarily mean working onsite. But what happens when a customer expects five days of onsite presence while the vendor’s engineers follow a hybrid schedule? Hybrid work may still mean a full working week; the potential mismatch is physical presence and coverage, not necessarily the number of days worked.

Agree on onsite presence, remote availability, hours, response expectations, and backup coverage before assignment. The vendor must staff the customer's operational needs, including critical-period absences. Engagement managers should resolve differences rather than leave engineers negotiating with customer supervisors.

Define who assigns work, evaluates performance, approves leave, and resolves competing priorities, with accountable managers and escalation procedures.

Depending on the facts and applicable law, close customer supervision may also create joint-employment obligations. EEOC guidance on contingent workers explains that a staffing firm and client may both be employers under the federal anti-discrimination laws it addresses. A contractual label alone does not settle the issue.

Benefits, tax, and wage-and-hour questions require separate analysis. Neither onsite work nor vendor-managed supervision alone determines the outcome; counsel should review the actual arrangement. Clear management boundaries are an operating discipline, not a guarantee against legal exposure.

What Happens When an FDE Leaves?

Suppose the lead engineer resigns six months into an implementation. A capable replacement may still lack essential knowledge of architecture decisions, business requirements, data exceptions, and undocumented dependencies. The result can be delay, additional expense, and lost customer confidence.

Continuity requires shared documentation, configuration management, knowledge transfer, replacement arrangements, and structured handoffs. Departures also require access revocation and review of any continuing confidentiality obligations.

An established product ecosystem helps because replacements can rely on familiar architecture, tools, and operating procedures. Customer-specific knowledge must still be shared. The customer should not depend on one person to keep the implementation moving.

Deployment Is Only the Beginning

Supporting business-critical technology taught me that continuity extends beyond installation. APIs, schemas, infrastructure, and models change. Someone must maintain integrations, investigate incorrect agent responses, and monitor quality, reliability, and costs.

A mature product company must architect its platform for centralized support from the beginning.

Deployment teams establish monitoring and diagnostics, document configurations, validate operational readiness, and formally hand over to support. AI requires continuing evaluation of models, prompts, workflows, and human oversight.

Customer, vendor, or partner support needs diagnostic access and escalation paths sufficient to resolve issues without the original engineers.

A product that can be repeatedly deployed but cannot be efficiently supported is not a scalable enterprise product.

Who Trains the Customer's Employees?

Palantir's Training application and Learning portal offers platform courses and organization-specific materials. Customers still need training tailored to configured applications, workflows, and responsibilities.

Product deployments and internal or consulting-led transformations alike need ownership of onboarding, refreshers, and updates as systems and processes change; demonstrations are insufficient.

Law-firm attorneys, paralegals, administrators, IT, and compliance staff need role-specific training in permitted data use, output verification, exceptions, and changed procedures. Technical success can fail without effective use.

FDEs can train administrators and establish initial programs. Customer leaders, process owners, and vendor enablement resources must own ongoing training and adoption, support revised workflows, and measure use and business improvements.

Internal FDE Teams: A Different Mandate

I have seen enterprises use internal FDE teams to serve business units, adapting common AI platforms, shared data services, and governed integrations to departmental workflows.

Without that common foundation, the mandate is transformation: identifying worthwhile problems, usable data, architecture, development needs, and organizational change.

Calling business units customers does not equate building a capability with adapting an established platform.

The first cohorts of Anthropic’s academy include engineers from Accenture, Commonwealth Bank of Australia, and Morgan Stanley returning to lead named Claude projects internally. The label extends beyond vendor deployment staff; examine the actual mandate.

LinkedIn FDE and AI Solutions Architect postings I follow seek hands-on models, agents, and integration expertise alongside business-value discovery, investment cases, budgets, portfolio priorities, team building, and business-leader engagement.

Together, these describe transformation leadership spanning strategy, architecture, engineering, finance, governance, and adoption.

Recruit accordingly, with funding, cross-functional decision rights, and executive sponsorship. The FDE title does not remove leadership responsibilities.

As I discussed in Your AI Transformation Needs Enterprise Authority, engineers cannot independently enforce enterprise-wide governance or adoption; an internal FDE label supplies no such authority.

Final Perspective

After 35 years in enterprise technology, I see real value in putting capable engineers close to customers. The current enthusiasm for FDEs reflects a familiar need: people who can understand the business and turn technology into working solutions. Whether that work creates durable value depends on the delivery model behind them.

Leadership must first distinguish between deploying an established platform and undertaking an AI transformation initiative. Both can be worthwhile, but they require different skills, authority, investment, and expectations. Using the same title for both does not make the assignments equivalent.

The enthusiasm surrounding FDEs and Gartner’s warning give us reason to examine what survives the initial implementation. A successful engagement leaves a working capability, trained users, clear accountability, and a support organization able to maintain and evolve the solution. Those are the outcomes by which the model should be judged.

The value of the FDE model depends on clarity about what already exists, what must be built, and who will sustain it. A new title does not change those responsibilities. Nor does calling it “forward-deployed engineering” turn a ground-up AI transformation into a product deployment.

References and Further Reading