Why so many AI agent projects fail without an FDE approach

The starting mistake: treating an AI agent as a one-off delivery

Many companies still approach an AI agent like a fixed-scope software project: write requirements, build, launch, give users a short training session and consider the work complete.

That model can suit deterministic features. It becomes fragile when a system has to interpret ambiguous requests, use several sources, handle exceptions and act inside a process that keeps changing.

An AI agent does not encounter technical bugs alone. It encounters organizational contradictions: the written rule differs from daily practice, a critical field is missing, two teams follow different processes, a customer presents a new case or a decision depends on tacit expertise.

Our thesis is straightforward:

The greatest risk is not choosing the wrong model. It is building too far from the real work, then leaving the field too early.

The website or platform comparison has limits. Every serious digital product needs maintenance and observation. Agents simply amplify that need because their behaviour depends more heavily on changing context, data, instructions, tools and human usage.

What Forward Deployed Engineering actually means

FDE stands for Forward Deployed Engineer. It describes an engineer working close to the customer environment, at the intersection of engineering, product and operations.

OpenAI’s current Forward Deployed Engineer role description spans discovery, technical scoping, system design, building, production rollout and adoption. Success is measured through production usage, measurable workflow impact and evaluation-driven feedback that can improve the product.

That definition matters. An FDE is neither a developer sent to the customer to complete a ticket list nor a consultant who delivers recommendations without owning implementation. The role needs to:

• observe how the work is actually performed;
• understand business goals, constraints and trade-offs;
• build or modify the system;
• support adoption by the operating team;
• measure what works and what fails;
• turn local learning into reusable components or playbooks.

The FDE reduces the distance between the people who understand the problem and the people who can change the solution.

Why business discovery takes time

One kickoff meeting is not enough to understand a department. The process shown in a procedure is rarely identical to the process people follow.

For a first scope, one to four weeks of immersion is often a reasonable benchmark in our experience. Some situations need less time; others need much more. This is not a universal FDE standard.

The objective is not to claim complete understanding after four weeks. It is to learn enough to select a useful and bounded problem. By the end of this phase, the team should have at least:

1. a map of the current workflow and its owners;
2. a list of frequent exceptions and sensitive cases;
3. an inventory of data, tools, permissions and broken handoffs;
4. a baseline measure such as delay, volume, errors, re-entry or cost;
5. a business owner able to make decisions;
6. a set of real cases for evaluating the first solution.

Without these elements, teams often build an impressive demonstration that does not survive its first month in production.

The long tail: where demonstrations stop working

After-sales service illustrates the problem clearly. Simple requests are easy to demonstrate: retrieve an order, summarize a case or propose a response.

Reality contains a long tail of harder cases:

• the order was divided between several carriers;
• a commercial policy changed but was not updated everywhere;
• the customer has both a logistics incident and a refund request;
• a distributor follows specific contractual rules;
• critical information exists only in a free-text comment;
• the case must move from support to finance or legal.

These cases consume the most human effort precisely because they require experience and judgement. An agent can already help gather context, check sources, detect an exception, prepare a response or recommend the next step. That does not mean it should immediately make the final decision.

The responsible strategy is to increase the assisted or automated share of the work progressively, retaining human approval wherever uncertainty, impact or irreversibility requires it.

Starting small does not mean remaining in a prototype

A good first FDE deployment is not an isolated demonstration. It is a thin slice of production:

• one team;
• one frequent workflow;
• a limited number of tools;
• one primary metric;
• a clearly positioned human approval step;
• a simple way to flag a bad result.

In after-sales service, the first agent might classify the request, assemble the order history and prepare a sourced response. The adviser keeps control of sending and the commercial decision.

This step exposes the real differences between the imagined process and the lived one. If results are reliable, the system can later suggest the next action, update the CRM or handle certain standard cases within explicit boundaries.

A small scope reduces the cost of learning. It does not reduce the ambition.

Training is part of the product

Giving people access to an agent does not create adoption. Teams need to learn:

• what the agent can and cannot do;
• which sources it uses;
• when a response needs verification;
• when to take over or escalate;
• how to report an incorrect result;
• which data should never be entered.

This should not be a one-off webinar at launch. Effective training uses real departmental scenarios and evolves with the product.

Microsoft’s agentic AI adoption maturity model looks beyond technology across strategy, process transformation, governance, value, architecture and organizational readiness. Its integration guidance also warns that organizations treating agents as a purely technical exercise often experience weak adoption.

The FDE trains users to work with the agent, but users also train the FDE to understand the business. That loop is part of the system.

The company needs to retain process ownership

The FDE should not become the only person who understands the solution. That merely moves the dependency.

The company needs a durable business owner—often supported by reference users—who understands:

• the expected outcome;
• important rules and exceptions;
• who owns each decision;
• which data is genuinely available;
• recent market or organizational changes;
• the agent’s current limits.

This person does not need to become an AI engineer. They need to evaluate outcomes, prioritize improvements and maintain the connection between the process and the technical team.

Part of the FDE’s job is therefore transferring a method: observe, test, measure, document and improve.

A production agent is a living system

Even when the business workflow remains stable, its environment changes:

• models and model behaviour evolve;
• vendors modify their APIs;
• cost and latency change;
• reference documents are updated;
• users discover new applications;
• the market introduces new exceptions.

A serious team therefore maintains an evaluation set, versions instructions and tools, monitors errors, documents human approvals and decides explicitly when autonomy should increase.

Microsoft’s guidance for operating AI agents treats the move from pilot to enterprise asset as a managed lifecycle through to retirement, not a single launch event.

Not every business pain point needs an agent

Forward Deployed Engineering is not about putting AI everywhere. It should also make it possible to conclude that an agent is unnecessary.

If a task follows fixed rules, uses structured data and requires no interpretation, a script, API integration or deterministic workflow will often be cheaper, faster and more reliable. Microsoft’s business planning guidance for AI agents similarly recommends avoiding agentic complexity where traditional code is sufficient.

The right system may combine:

• deterministic automation for predictable steps;
• an agent for interpretation, research or decision preparation;
• a human for sensitive, novel or ambiguous cases.

The FDE’s role is to position that boundary based on the real work, not on the current technology trend.

Measure value, not delivery

“The agent is in production” is not a business outcome. A team should track a small set of measures before and after deployment:

• usage within the targeted workflow;
• handling time and time genuinely saved;
• correction or manual rework rate;
• output quality and user satisfaction;
• escalation frequency;
• errors, incidents and uncovered cases;
• cost per case;
• movement in the selected business metric.

Saving ten minutes on a rare task may create less value than saving thirty seconds across thousands of cases. Evaluation needs to remain connected to volume, risk and process value.

FDE as a model for continuous transformation

Companies do not fail with AI agents because of technology alone. They fail when they automate a process they have not observed closely enough, start with too much scope, neglect training or leave nobody responsible for evolving the system.

A stronger FDE approach follows a simple loop:

1. immerse in the real work;
2. select a frequent, measurable and reversible problem;
3. build the first useful production slice with the team;
4. train, observe and collect failures;
5. improve the system and transfer capability;
6. expand only when value and trust have been demonstrated.

FDE is not a magic solution. It is a way to prevent impressive technology from becoming disconnected from the organization it was meant to help.

To frame an initial workflow, explore our approach to custom AI agents and n8n and API automation.

Analysis prepared on 27 July 2026 from our deployment experience and the official OpenAI and Microsoft sources linked throughout the article.