The Dawn of the Forward Deployed Engineer

Update, August 2026: I got the market need right, but I got the title wrong. I expected AI Deployment Engineer and AI Deployment Specialist to emerge as separate roles. Since publishing this, the market has increasingly standardized around Forward Deployed Engineer, or FDE, as the catch-all role for this work.

The responsibilities did not disappear. They converged. A credible FDE now needs full-stack engineering from proof of concept through production, client-facing consulting judgment, and AI-native engineering across agentic coding, production agents, evals, MCP, and Skills. We have not seen enough market value in introducing another title, so Elios now uses FDE.

I Was Right About the Gap and Wrong About the Title

Every team needs to become AI-native.

That sounded obvious when I first wrote this post, but the next question was harder:

What do you actually do?

Companies bought ChatGPT. Engineers adopted GitHub Copilot, Cursor, Claude Code, and Codex. Finance wanted help with Excel. Marketing wanted help with decks. Operations wanted workflows automated. Engineering wanted agentic coding, MCP servers, and safer ways to ship faster.

Buying the tools was the easy part.

Deploying them was the hard part.

That part of the original argument still holds. Where I was wrong was assuming the market needed new titles for the people doing the work.

I called them AI Deployment Engineers and AI Deployment Specialists. The market kept using Forward Deployed Engineer as the broader category instead.

That is okay. It is useful to make a prediction, watch the market, and change your mind when the evidence changes.

The Market Standardized Around FDE

OpenAI's current Forward Deployed Engineer role owns discovery, technical scoping, system design, implementation, production rollout, adoption, and measurable workflow impact.

Ode with Anthropic is organized around the same basic need: experienced engineers and operators working with client experts to turn frontier AI into production systems and measurable business results.

Different companies divide responsibilities differently inside their teams. That does not mean buyers want another collection of overlapping job titles.

The market found a useful catch-all: FDE.

An FDE is not just a software engineer working at a customer site. An FDE is also not a consultant who can talk about AI but cannot build the system. The role sits at the intersection of engineering, consulting, and AI-native delivery.

Companies Bought AI. They Did Not Deploy It.

Most companies are still not AI-native.

They may use ChatGPT. They may have Microsoft Copilot. They may have a few internal experiments or an AI roadmap sitting in a planning document.

That is not the same thing as deploying AI into the company.

The gap shows up everywhere.

On the engineering side, the AI roadmap often has no owner. Engineers context-switch between exploration and real delivery. Pilots never make it into production. License costs accrue while adoption stalls.

Across the rest of the business, people are still assembling reports, presentations, approvals, and handoffs manually. The technology is not usually the bottleneck.

The bottleneck is deployment.

What Is a Forward Deployed Engineer?

A Forward Deployed Engineer is a full-stack, client-facing, AI-native engineer who embeds with a company, turns an ambiguous business workflow into a production system, and leaves behind measurable value and a capability the client can own.

That definition has three pillars. All three are required.

Pillar One: Full-Stack, From POC to Production

An FDE has to build.

They understand frontend and backend systems, APIs, data models, authentication, infrastructure, testing, observability, and production risk. They can enter an unfamiliar repository, learn the system, make sound architectural decisions, and ship code that the client's team can maintain.

They know the difference between a demo and a proof of concept. They also know the difference between a proof of concept and production.

The job includes:

• Building a focused POC to test the riskiest assumption.
• Turning what works into a maintainable full-stack system.
• Integrating with the client's real data, permissions, and systems of record.
• Designing for reliability, latency, cost, failure handling, and rollback.
• Instrumenting and operating the system after launch.
• Documenting and transferring ownership to the client team.

An FDE who cannot take work from POC to production is missing the engineering core of the role.

Pillar Two: Consulting and Client-Facing Delivery

An FDE also has to work directly with people.

The client rarely arrives with a perfect problem statement. The workflow is messy. Stakeholders disagree. Important details live in meetings, spreadsheets, tribal knowledge, and exceptions that nobody wrote down.

The FDE has to find the real problem before moving quickly in the wrong direction.

That means:

• Running discovery with executives, operators, engineers, and end users.
• Mapping the current workflow, systems, authority boundaries, and failure modes.
• Turning ambiguity into scope, milestones, acceptance criteria, and risks.
• Explaining technical tradeoffs without hiding behind jargon.
• Pushing back when the requested solution will not produce the desired outcome.
• Driving rollout, adoption, enablement, and knowledge transfer.
• Establishing a business baseline and measuring whether the deployment helped.

This does not turn every FDE into an account executive or project manager. It means an FDE cannot disappear into the code and expect someone else to translate the client forever.

Pillar Three: AI-Native Engineering

The third pillar is not a list of fashionable tools.

Claude Code, Codex, MCP, and Skills matter because they change how we build and what we can build. The competency is knowing how to use them with engineering judgment.

An AI-native FDE can:

• Use agentic coding tools to move faster without outsourcing understanding.
• Create Skills that preserve repeatable instructions, examples, and decisions.
• Build MCP servers and connectors with real authentication and least-privilege access.
• Design agents with clear tools, state, boundaries, approvals, and human escalation.
• Fit the interface to the workflow instead of defaulting everything to a chatbot.
• Build evaluation and trace-review systems that keep nondeterministic software measurable.
• Separate deterministic application logic from the parts that genuinely need a model.

Using Claude Code or Codex every day is useful. Shipping vibe-coded slop faster is not the standard.

Evals Are the Control Loop

Evals are not a final testing phase or a dashboard added after the build. They are the control loop for AI product development.

My baseline here is Hamel Husain's work on domain-specific eval systems.

The FDE should define success for the actual workflow, inspect traces, perform error analysis, build a durable dataset, and write scoped tests around observed failure modes. Deterministic assertions should be used wherever possible. Human evaluation should cover judgment that code cannot express. Model-based judges should be calibrated against human labels instead of trusted because they produce a score.

Those evals should run during development, in CI, and against production traces. When a real user finds a new failure, that failure should become a regression case.

Without that loop, the team is still guessing.

Training Is Not Enough, but Custom Software Is Not Always the Answer

There is a version of AI adoption that looks like this:

1. Buy licenses.
2. Run a training session.
3. Send a few prompt examples.
4. Tell everyone to use the tool.
5. Hope productivity happens.

That does not work very well.

Generic webinars do not change the way a team operates. People need someone to sit with them, understand the work, connect the right tools, write the right instructions, and make sure the workflow survives real use.

The opposite mistake is treating every AI use case like a six-month custom software project.

Some workflows need a production application. Others need a governed connector, a Skill, a targeted automation, or a better operating process. The FDE's job is to make that judgment based on the workflow rather than forcing every problem into the same shape.

Every Team Has a Different Workflow

AI deployment is difficult to standardize because every team is different.

Finance pulls from a different stack than marketing. Legal has different risk constraints than sales. Two engineers on the same squad may need different data sources, local tooling, and agent workflows.

A generic rollout misses that.

A proper deployment asks better questions:

• What work happens every week?
• Who owns the outcome?
• What inputs and systems of record does the team use?
• Where does the output go?
• What data can AI access?
• Which actions require human approval?
• What does success look like before we build anything?
• What evidence would prove the workflow improved?

The answer will look different for every team.

That is the point.

What Changed at Elios and for Me

At Elios, we have not seen a need to keep teaching the market a separate AI Deployment Engineer category. Multiple overlapping roles created more confusion than clarity.

We now use Forward Deployed Engineer as the market-facing role. An FDE may lean more heavily into architecture, delivery, domain work, or adoption on a particular engagement, but the standard still includes all three pillars.

That is also how I describe my own work now. I am a Lead Forward Deployed Engineer. My official title is VP of Technology at Elios AI.

The title changed. The deployment problem did not.

The Opportunity

Companies do not need more AI theater. They need people who can enter the real environment, understand the real workflow, build the real system, measure whether it works, and leave the team stronger.

That is the Forward Deployed Engineer.

The companies that win will not be the ones that buy the most AI licenses. They will be the ones that deploy AI into useful parts of the business with the right mix of engineering, consulting, evals, adoption, and human judgment.

The real work is not buying AI.

The real work is making the team AI-native.

Want to Talk About Forward Deployed Engineering?

If your company needs an FDE, or if this is the kind of engineer you want to become, I would love to connect.

You can find me on LinkedIn, email me at matt@eliosai.com, or book a 30-minute AI strategy session.