AI Engineer vs Forward Deployed Engineer: tasks and ownership

While putting together my AI job market overview, I kept seeing two titles alongside each other: AI Engineer and Forward Deployed Engineer. Their job descriptions can look very similar. Both involve code, models and production deployment. The difference is often where the work happens and which result the engineer owns.

I would separate them by what organizes the work. An AI Engineer usually builds an AI feature or system within a product. A Forward Deployed Engineer, or FDE, owns implementation for a particular customer, including the customer's process and data. One person can do both. The job title alone does not define the boundaries.

What an AI Engineer builds

Suppose a product needs document search. The engineer has to decide how documents are uploaded and refreshed, how relevant passages are retrieved and how to evaluate the model's answer. Access rules matter: a document that a user cannot open should not leak through the assistant's response.

The first working example leaves plenty unresolved. Some questions get good answers; others get confident mistakes. Long documents cost too much to process. A model change breaks checks that used to pass. These become architecture and operational questions that the engineer needs to handle.

For this work, I would want a set of test questions with expected behavior. If a fact is absent from the documents, the system should say so. If sources conflict, the answer should make that visible. Liking the way an assistant responds is not enough to release a new version.

Within a product, those decisions need to support repeated use. Another user will upload different documents, the volume will change and new constraints will appear. The AI Engineer has to consider how the next team or customer will use the same feature.

What a Forward Deployed Engineer owns

Now imagine deploying that search system at a particular company. Current documents live in several places, old versions are unmarked and departments disagree about who can see prices. Employees ask questions differently from the person who built the demo.

The FDE works through those conditions with the customer. Where is the authoritative information? Who can approve access? Which interface fits an employee's work, and what should happen when the system cannot answer? An otherwise functional feature can remain unused if those decisions are unresolved.

This is engineering work. OpenAI's FDE description places customer delivery alongside platform development. The engineer still writes and debugs code. Some requirements emerge during implementation, as the customer's data and working habits become clearer.

I covered the format in more detail in FDE work for a small business. Here I am interested in the division of responsibilities: improving a shared feature and making it work in a particular environment.

One example, two areas of responsibility

Take a hypothetical company receiving event enquiries through Telegram. A message might contain a date, an approximate guest count and a long voice explanation. The customer may omit the city or change the date an hour later.

An AI Engineer could build field extraction, voice processing and output checks. The system needs a way to express uncertainty about a date. If the customer corrects the guest count, it should update the enquiry rather than create a second unrelated one. Those cases help evaluate the technical implementation.

The FDE has to understand how people handle the enquiry. Which fields are required before estimating a price? Who receives the request, and where should it appear? May the system send a clarification automatically? What happens when a reply arrives at night or a manager has already edited the record?

If two engineers share the work, they need an agreed boundary. Suppose the model recognizes a correction correctly but the CRM rejects the update. Who sees the error, who fixes it and what does the manager see meanwhile? Those questions should be settled before enquiries start disappearing.

The interface could be a Telegram bot. A staff member who needs fields and statuses on a screen might be better served by a Mini App. The interface should follow how people work, rather than the engineer's title.

The skills the roles share

Both roles benefit from understanding unfamiliar code, working with APIs and checking behavior on difficult inputs. With LLMs, that includes understanding model limitations, request costs and evaluation. The engineer should also be able to explain a technical choice to someone who does not write code.

The difference is often how the day is spent. In a product team, an AI Engineer may spend a long time improving a shared system and coordinating changes with other developers. An FDE encounters more questions about the customer's organization: who decides, why the data looks this way and what can change in the process.

AI Engineers also talk to users, and an FDE may build a component that later becomes part of the shared product. There is no rigid dividing line. When a company hires under either title, I would ask about the first project and the result expected a few months later.

A certificate or a list of libraries answers a different question. I would rather examine a system someone built: why they chose that architecture, where it fails and what happens after a failure. My Dantiva build notes show the product side of that work. Dantiva is my own product, with a web interface, a Telegram bot and a Mini App.

How a company can decide whom it needs

If a product already has users and needs a better AI feature for everyone, the task is closer to AI Engineering. Examples include improving retrieval quality, reducing response latency or checking a new model before replacing the old one.

If the technology is already chosen and the difficulty lies in one team's data, permissions and daily work, someone needs to own implementation. The FDE format fits that need. It is still worth checking whether ordinary automation is enough. Some processes need neither an agent nor an LLM.

A small company may not need two separate positions. An engineer and consultant can cover both parts when the scope is limited and their skills fit. In that arrangement, the result and handover need to be explicit: what works after launch, what remains manual and who supports the system.

That is how I approach my own work. First understand the task and its constraints, then choose a suitable implementation. Depending on the project, that could mean an AI agent, RAG inside an existing product or a conventional integration. A title can describe the format, but the work still needs to be defined.

When is implementation finished?

A useful completion criterion is that the team can carry out the agreed process without the demo's author standing beside them. There is a way to notice a failure and investigate it. The right people own the accounts, costs are visible and limitations are documented.

After launch, revisit the cases used to test the system. Do they work with real data? Are employees using it? Has it created manual work that nobody counted? The answers help decide what to improve and whether to expand the deployment at all.

When choosing between an AI Engineer and an FDE, I would start with the result needed and the environment it must work in. That describes the task more accurately than choosing the more fashionable title.

FAQ: AI Engineers and FDEs

How does an AI Engineer differ from a Forward Deployed Engineer?

An AI Engineer usually owns an AI feature or system within a product. An FDE owns implementation in a particular customer's environment, including data, integrations and user workflows. Their work can overlap.

Does an FDE write code or only consult?

An FDE writes code and handles technical implementation. Customer work helps establish requirements and get the system into use; it does not replace engineering skills.

Can one person do both jobs?

Yes, especially in a small team with limited project scope. Technical quality, implementation and ongoing support still need explicit ownership.

Which role does a small business need?

It depends on the task. Developing a shared AI feature calls for AI Engineering. Implementing a system within an existing team's work calls for experience closer to FDE work. First check whether AI is needed and whether the result can be measured.