Forward Deployed AI Engineers: what agents do and what to hire for

A Forward Deployed AI Engineer works inside a customer's environment to get an AI solution running on a real task. They learn how the work is done, build the integration, test it on real cases and hand it over so the customer can run it without them.

The role is changing because agents now do a growing share of the building. They also raise the stakes. An agent that plans, calls tools and updates systems needs careful engineering around it, and that engineering happens on the customer's site.

So the job is moving away from writing every line and towards deciding what to build, proving it works and making it safe to hand over.

What agents already do

Agents are now a working part of the deployment kit. Some of this is the product the engineer ships, and some is the tooling they use.

• Run multi-step work. An agent may plan, call tools, read enterprise data, update systems and trigger approvals across several steps. That is the thing the engineer now has to fit into a customer's processes.
• Handle messy inputs. Salesforce describes agents working on unstructured data such as emails, PDFs and spec sheets, and on legacy ERP logs, with humans in the loop.
• Speed up the engineer's own research. Salesforce's engineers describe using AI-augmented tools to compress information hunting from hours to minutes.
• Build the first version. Job postings now ask engineers to design and ship agents built on frontier models and combine them with RPA and custom code. Writing the agent is the routine part.

Where agents help and a person decides

Most of the real work sits here. The agent drafts, retrieves or proposes. The engineer judges.

Workflow design is one example. A posting for a staff-level role asks the engineer to define what the agent does, what the human does, and where they hand off, and to place review checkpoints so review adds value without becoming the bottleneck. A model can suggest a workflow. Someone has to know which handoffs the customer's staff will actually follow.

An agent can write the integration. It cannot tell you whether the customer's problem was the one they asked you to solve.

Evaluation is another. Agents can generate test cases and score outputs. The engineer decides what counts as a good result for the customer's task, agrees a baseline and reads the failures.

Debugging is similar. Tools help trace a failing call, but the cause is usually in a system nobody documented: schema drift, rate limits, awkward authentication. The engineer decides whether to patch it, work around it or raise it with the customer.

What still needs a person

Defining the real problem. One deployment firm describes a manufacturer asking for an AI to generate production schedules. The engineers went on site, watched the work and found the bottleneck was schedules collapsing when materials ran late. The better build was early warning of delay risk. That came from observation and interviews, not from the request.

Deciding what stays human. A Reddit posting expects the engineer's judgement to shape where AI adds value, where conventional automation is better, and what should remain a human decision.

Earning trust and saying no. Telling a customer something should not be built yet takes calm judgement and evidence. An agent will not hold that conversation for you.

Carrying the last stretch. Reporting on why enterprise AI stalls points to fragmented systems, nuanced policies, legacy constraints and edge cases between pilot and production. The engineer is accountable for getting through them, and for a handover the customer's team can run.

What this means for who you hire

The profile gaining value is the engineer who is strong on judgement as well as code. They can build quickly with agent tooling, but they spend their effort on scoping, evaluation and handover. They have shipped LLM features in production, they are comfortable in a customer's building, and they can explain a trade-off to a non-engineer.

The profile losing value is the pure implementer who needs a finished spec, and the demo builder with no production evidence. If the main skill is turning a ticket into code, an agent now does much of that.

Be careful with candidates who are fluent in agent frameworks but have never been blamed for a customer outcome. Familiarity with the tools is easy to acquire. Experience of things going wrong on someone else's systems is not.

How to spot a strong candidate

"Tell me about an AI integration you built inside a customer's environment. What was hardest?"

A good answer is specific about the customer's systems, constraints and what went wrong, and shows how they debugged. Worry if the story is only about the model and the customer barely appears.

"How did you decide whether a deployment was working for the customer?"

A good answer names task-level measures agreed with the customer, a baseline and evaluation on real cases. It measures the customer's outcome, not just the model.

Where to find them

Titles vary widely, so searching by job name misses good people. Alternative titles include Forward Deployed Engineer, AI Deployment Engineer, Applied AI Engineer and Deployment Solutions Engineer.

• Full-stack and backend engineers who have shipped LLM features in production.
• Applied ML engineers with customer exposure.
• Solutions engineers and technical consultants who now write real code.
• Former founders, who are used to owning an outcome with a customer. They are rarely labelled correctly.

They tend to work at AI labs, AI startups and deployment-heavy software companies that embed engineers with clients. Demand is high and everyone is fishing in the same small pool, so look at adjacent backgrounds before the obvious ones.

Our own analysis, drawn from the role profile in our job families library and recent public reporting on how agents are used in this work. Titles and practice vary by company.