Why the forward deployed engineer is back with generative AI

Where the role comes from

The forward deployed engineer appeared at data analytics software vendors. Their product was powerful and generic. Their customers had dirty data, internal rules nobody had written down, and users with no time to learn yet another tool. Somebody was missing in between. Not a consultant writing recommendations, not a sales engineer running a demo. An engineer who sits at the customer site, opens the real data and writes the code that connects the product to the business.

That profile has always existed in organisations that ship useful software. It simply became visible again, because the same configuration now repeats at scale with generative AI. A language model is a generic product, available to everyone at the same public price. It knows nothing about your product codes, your pricing terms, your edge cases, or who should get the file when it falls outside the rules. Anthropic, which builds the Claude models, hires for this profile under the forward deployed engineer title, in Paris included, as its own careers page shows. That knowledge lives with you. It is almost never written down. The work consists of going where it actually is.

Value is not in the model, it is in the wiring

People spend a lot of time comparing models. For a management team that is a secondary question. Models improve fast, they replace each other, and a well built agent should be able to change engine without being rewritten. What separates an agent that gets switched off after a month from one that stays is the wiring into the business. That wiring has four layers, and none of them can be bought.

First, the corpus. Which documents are authoritative, which are obsolete, which one wins when two contradict each other. In most organisations nobody ever had to settle that in writing, because humans instinctively knew which version to trust.

Second, the vocabulary. The same word means two things depending on the department. An order does not mean the same thing in procurement and in accounting. An open case means something different to support and to legal. A model that ignores those gaps produces answers that sound right and are wrong.

Third, the rules. When a discount applies, approval thresholds, what is allowed and what is not. They are usually spread across a spreadsheet, an ERP and the memory of two people.

Fourth, the edge cases. This is where the tool earns or loses its credibility. Users judge an agent on the hard files, not on the easy ones they already handled without difficulty.

None of those four layers can be collected through a specification document. You can ask a manager to describe the process. They will describe the official version. The real version shows up when you watch over their shoulder while they handle an awkward file and ask why they just did that. That is exactly what an embedded engineer does. On this point, moving from an idea to a tool that holds in production follows the same rules as any business software, which we cover in the prerequisites for going to production.

The build cycle has changed

For twenty years the dominant method was to specify, approve, develop, test. It works when system behaviour is predictable on paper. With a probabilistic component it stops working. You cannot write in advance what the model will answer on your documents, because the answer depends on your documents. You also cannot seriously estimate quality until you have tried it on real data.

So the cycle becomes: connect to a real sample, look at what comes out, measure, correct, repeat. Each lap takes hours, not weeks. That rhythm has an organisational consequence many management teams underestimate. If the person who writes code and the person who knows the business are not in the same room, every lap costs a meeting, a written summary and two days of waiting. The loop dies.

That is the structural reason this role is back. The forward deployed engineer is not a friendlier developer. It is someone who can hold both ends: read a business rule with a manager, translate it into code the same afternoon and show the result the next morning. We describe that format in our embedded engineer offer, and it varies by function, from finance to commercial operations.

An agent is judged on real cases, not on a demo

An agent demo always goes well. You pick the questions, you know the answers, the tool impresses. That moment proves nothing. The only thing that proves something is an evaluation set: a list of real cases taken from your own files, each with the expected answer validated by someone who does the job.

Building that set is field work, and it is the step projects usually skip. You sit with users, pull recent files including the ones that went badly, and write down what a good answer would have been. You include the boring cases: the unreadable attachment, the request that mixes two subjects, the customer asking something out of scope, the missing data. You also include the traps, where the right answer is to answer nothing and hand over to a human.

Once that set exists, the whole project changes. You stop arguing about impressions. You can compare two versions of the agent, decide whether a change improves or degrades it, and above all decide when to go live on something other than the excitement of a demo meeting. The set becomes a company asset, independent from the model in use. It survives a change of supplier.

It also makes the budget conversation honest, because it links the quality you get to the real running cost, a subject we cover in what an agent costs in production.

Guardrails are business decisions

An agent that gets a rewording wrong is an annoyance. An agent that states a false availability, a price that no longer exists or a customer reference that never agreed to be named is a commitment made on behalf of the company. That difference is not technical, it is legal and commercial. So it has to be settled by the business, not by the engineer alone, and certainly not by the model vendor.

Our own rule is simple and not negotiable. Anything that commits the company never comes out of the model. A price comes from the system that holds prices. Availability comes from stock. An address comes from the reference system. The model can write the sentence around it, it does not produce the data. The calculation happens server side, the value is checked before display, and if it is not available the agent says so instead of improvising.

The second question is human validation. Which actions can the agent perform on its own, which ones must go through someone. Sending a quote, closing a ticket, editing a record, triggering an order: each of those deserves an explicit written answer with a name attached. An engineer cannot settle that alone. Neither can a committee that has never seen the tool run. You need both, in the same room, looking at the same concrete cases. Regulation weighs in too, which is why we made it a mandatory step in our approach to responsible AI.

What to write down before going live

• The list of data the agent is never allowed to produce itself.
• Actions allowed without approval, and actions requiring a human decision.
• Expected behaviour when information is missing.
• The handover path to a human, with the person who actually receives it.
• Who reviews the week's exchanges, and how often.

Adoption is half the job

An agent nobody opens has solved nothing. It is the most common ending for corporate AI projects, and it is rarely caused by technical quality. It is caused by the tool landing next to the real work rather than inside it.

The signs show up early. The agent lives in a separate application users have to remember to open. It answers well but slowly, and the manual gesture stays faster. It does not show where its answer came from, so users check everything again and lose the benefit. It was announced as a productivity gain, which teams immediately translate as a threat.

Here again the answer is on the ground. You put the agent inside the tool people already use. You show sources so checking takes seconds. You start with the task everyone hates, not the one that demos best. You name two or three users who test for real during the first weeks and whose remarks get handled quickly, because one ignored piece of feedback kills the willingness to test. That collective learning matters as much as the code, and we give it a method of its own.

What AI changes in the engineer's own work

The job has also changed from the inside. Writing a first working version takes far less time than it used to. An engineer can arrive in the morning with a business rule described out loud and show something running by the afternoon. That is real progress, provided you understand what you do with the time it frees.

Used well, that time goes to observation and measurement. Watching users work. Growing the evaluation set. Hunting for the cases where the tool fails silently, which is the most dangerous failure of an agent: a wrong answer stated with confidence. That work has no automatable equivalent, because it consists precisely of confronting the machine with reality.

Used badly, that time creates a new and fairly common risk. Since building is cheap, you build before you have understood. You ship in three days a tool nobody asked for, clean, fast, useless. Easy production moves the bottleneck: it is no longer in development, it is in judgement. The question to ask before opening the editor has not changed, it just became easier to skip. What is the problem, who lives with it, and how will we know it is solved. That is the logic behind our AI agent method.

Signals that you need this profile

A few situations come back often, and you can recognise them without an audit.

• You tested an assistant on your documents, the demo was good, and six months later nobody uses it.
• Your teams spend real time looking for information that already exists, somewhere everyone knows poorly.
• A supplier asked you for a full specification for an AI project, and you cannot write it because you do not yet know what is feasible.
• Critical process knowledge sits with one or two people who are leaving soon.
• You are hesitating between an off the shelf tool and a custom build, with nothing objective to decide on.

In those cases what is missing is rarely a better model. It is someone who comes to look, writes code, measures, and stays long enough for the tool to enter daily habits. The full sequence of a go live is described in our article on deploying an AI agent.

If you want to understand the role before considering an engagement, start with our pillar page, the forward deployed engineer explained simply. If you already have a subject in mind and want to know whether it holds up, the AI diagnostic exists for that: looking at your data, your processes and your constraints, then telling you what is feasible and what is not.

Sources

• Anthropic, open roles (Forward Deployed Engineer, Paris)

Frequently asked questions

Do we need a forward deployed engineer, or is an internal AI team enough?

They complement each other. An internal team knows the business and stays after the project. The embedded engineer brings experience of traps already met elsewhere and speeds up the first months. The sign of a successful engagement is that the internal team can take the tool over without us.

Can we start without a specification document?

Yes, and on an AI subject it is often better. What you need at the start is a precise problem, accessible real data and an available person from the business. The specification gets built as you go, from what you observe on your own files.

How do we know an agent is reliable enough to go live?

By running it against a set of real cases from your files, with expected answers validated by the business. You then decide the acceptable threshold according to the stakes, and frame the rest with human approval. A good feeling in a meeting is never enough.

Our data is messy. Should we clean it before starting an AI project?

Not entirely, or you will never start. You work on the scope needed for the first use case, and running on real data quickly reveals which defects actually get in the way. Cleaning becomes targeted instead of an endless preliminary project.

What happens when the model we use becomes obsolete?

A well built agent separates the engine from the rest: connectors, business rules, guardrails and the evaluation set remain yours. Changing model then means replaying the evaluation set and comparing. That is exactly why the set is an asset worth building early.