There is a new role that is increasingly being talked about: Forward Deployed Engineer, or FDE.
The name can sound strange at first. It is not a common expression and it did not originate in the software world. It comes from a military idea: being deployed on the front line, close to where the operation takes place.
That origin describes the FDE's position: close to the operation they want to transform. They work with users, data, exceptions, legacy systems, and real constraints — and from there they define the problem, design the solution, and take it to production.
I find this role particularly useful for thinking about the next stage of enterprise AI. Not because it is a Silicon Valley trend or because every company needs to create a team with that name, but because it describes a responsibility that many organizations have yet to fully resolve: turning a very powerful technological capability into a better way of working.
What a Forward Deployed Engineer does
An FDE is a technical builder who works close to where operations happen to turn advanced capabilities — today mainly AI and agents — into productive, measurable workflows that are adopted by the people doing the work.
They are not just an engineer who visits clients. Nor are they a consultant who observes from the outside. They combine engineering, product thinking, and operational judgment to deliver a solution to the point where it needs to work every single day.
That involves several things at once.
First, they enter the real process. They do not simply read how the company says it works. They observe where exceptions arise, which approvals are informal, what information lives outside official systems, what shortcuts people use, and where time or quality is lost.
Second, they turn an ambiguous problem into a buildable system. To do that, they need to work with users, technical staff, and decision-makers; distinguish symptoms from root causes; define what outcome matters and what metric will indicate whether an improvement has been achieved.
Third, they build and deploy. An FDE can design architecture, integrate systems, work with data and permissions, define evaluations, instrument observability, and fix failures in production. They do not delegate operational reality to a later phase of the project.
And finally, they turn what was learned into something reusable. That is where a significant part of the role's value lies: the work done for a client or a business unit should not end only in a local solution. It should improve the technical foundation, connectors, evaluations, playbooks, or methodology for the next deployment.
Why it's called "forward deployed"
The translation that makes the most sense to me is field-deployed engineer.
It can also be thought of as a technical advance unit: someone deployed to the front lines who understands the terrain, builds alongside real users, and brings that experience back to a reusable technical core.
The idea is not "advanced" in the sense of sophisticated. It means being deployed forward. Not solving from the rear, but close to the operation being transformed.
Palantir is the company most associated with the term. It popularized and institutionalized the modern version of the role, although the practice draws on older precedents: field engineering, systems integration, professional services, solutions architecture, and product development alongside the client.
In Palantir's model, the distinction is straightforward. They have Devs and FDEs. Devs build common applications for many clients. FDEs (also called Deltas internally) take those applications and capabilities and turn them into results within the specific context of a project or client.
The innovation is not about sending engineers to configure software. It is about having people with the ability to build work close to the problem, be accountable for an operational outcome, and return learning to the core product.
The gap between a model and a business outcome
Enterprise AI has a paradox. The more general a model is, the more contextual work may be needed for it to produce a specific, reliable result.
A model can summarize, classify, reason, generate text, write code, or use tools. But it does not know by default which data is correct, which exception should be escalated, who can approve an action, what level of risk is acceptable, or how the success of a process is measured.
Between an AI capability and a business outcome, there are several layers that someone must design:
context: data, documents, knowledge, and business semantics;
workflow: states, decisions, exceptions, roles, and handoffs;
integration: systems, identity, permissions, and APIs;
reliability: evaluations, observability, limits, and recovery;
governance: security, privacy, auditing, and compliance;
adoption: training, role redesign, trust, and accountability.
The FDE lives at that boundary.
Their question is not only whether something can be built, but what would need to change in the process for the technology to produce a measurable result.
That is why reducing the role to implementer is a mistake. Implementation is part of the work. The greater challenge lies in discovering what is worth building, what can be simplified, where a human must remain in the decision loop, and how it will be demonstrated that the new workflow performs better than the previous one.
What an FDE is not
The boundaries between roles are not perfectly clean. An FDE may do discovery work, integration, architecture design, training, and change management. But there are distinctions worth keeping in mind.
Consulting typically begins with the question "What should the organization do?" The FDE can participate in that conversation, but also takes on the responsibility of building, deploying, and learning from the outcome.
Implementation usually begins once the problem and solution are already defined. The FDE helps define both, especially when the technology still needs to be adapted to the context.
A solutions architect designs a viable architecture. An FDE can do that, but also works on adoption, exceptions, and the decisions that surface after the first integration.
Custom development can solve a specific problem very well. The FDE model becomes more interesting when each deployment leaves behind assets that reduce the effort, risk, or time of the next one. If everything starts from scratch, the organization has an intensive service — not a cumulative capability.
The loop that turns deployment into learning
The loop is simple: a deployment starts from the operation, generates learning, encodes that learning into patterns, and leaves reusable assets that improve the next deployment.
This explains why the role is appearing at applied AI companies like OpenAI, Anthropic, Google Cloud, Scale AI, and Glean. The more problems they solve in real enterprises, the better the tools they develop to solve new ones.
The reusable assets developed in each engagement can include: a connector that resolves a common integration, an evaluation for a recurring task, a permissions pattern, an adoption playbook, a workflow template, or an architecture decision that avoids repeating a mistake.
Building and reusing them matters because it determines whether a company is accumulating a competitive advantage or simply selling more hours.
The FDE does not work alone
The image of an exceptional individual who solves everything is appealing, but it is not a serious model for complex deployments. In many cases, the FDE is part of a pod with other responsibilities: deployment leadership, domain knowledge, product, security, and adoption.
What matters is not that every project has all those titles. What matters is that someone is accountable for each critical question: who decides scope, who knows the process exceptions, who builds, who measures quality, who owns operations, and who turns learning into a shared asset.
This point is especially important with agents. An agent is not simply a new interface. It can read sensitive information, use tools, take actions, and change the order of a process. Deploying it well requires architecture, limits, evaluations, permissions, and clear agreements about when a human must intervene.
Why this matters for Latin America
Many companies in the region do not need to start with a grand "AI strategy." They need to identify which processes are painful, how much those pain points cost, which decisions can be assisted or automated, and what technical and organizational conditions must exist to operate differently.
Sometimes the answer will be an agent. Other times, a copilot. Other times, conventional automation. And in some cases the right solution will be to organize data, define ownership, or redesign an approval process before introducing AI at all.
The value an FDE brings lies in understanding the terrain and choosing a workflow where intelligence genuinely delivers an improvement: less rework, fewer errors, better response times, greater decision-making capacity, or more consistent service.
For companies operating in regulated environments, with complex processes or systems that have grown in layers, this kind of engagement is not a luxury. It is the condition for preventing AI from staying stuck at the demo stage.
The question that matters
What excites me about the FDE's work is the order in which they approach a problem. Before discussing models, agents, or architecture, they need to understand how the work is done today, where it gets stuck, which decision could be changed, and what outcome would justify the effort.
Only then come the technical decisions: what information the system needs, what tools it must integrate with, what controls it requires, and how its performance will be evaluated.
That is why the first question is not a technical one.
It is this: which workflow deserves to be redesigned first, and how will we know it improved?