Forward deployed engineer and solutions engineer are often used interchangeably, but the distinction matters in AI. A solutions engineer usually helps customers understand, configure, and adopt a product. The role is technical and customer-facing, but it often operates around an existing product surface. A forward deployed engineer goes deeper into the customer's environment and takes more responsibility for turning ambiguous business problems into working technical systems. In agentic AI, that difference becomes visible quickly because the hardest work is not explaining the product. It is deciding what should be built, integrated, automated, reviewed, and measured.
A sales engineer usually supports pre-sale technical credibility. They answer architecture questions, build demos, respond to technical objections, and help prospects believe the product can solve their problem. An implementation consultant helps deploy and configure the solution after purchase. A solutions engineer often spans both sides, especially in startups. A forward deployed engineer is different because they are expected to operate as a temporary member of the customer's problem-solving team. They discover the real workflow, identify constraints, design the deployment path, build or adapt the system, and feed field patterns back to product engineering.
Agentic AI pushes the FDE role closer to systems architecture. A customer may say they want an autonomous research analyst, underwriting assistant, support agent, or operations copilot. The FDE has to determine whether that should be a RAG workflow, a single-agent tool-calling system, a LangGraph-style state machine, a human-in-the-loop workflow, or a non-agentic automation. The right answer depends on risk, data quality, available APIs, latency tolerance, evaluation criteria, stakeholder trust, and cost per successful task. This is not just configuration. It is applied architecture under uncertainty.
For hiring managers, the practical distinction is ownership. If the role is primarily demos and technical explanation, call it sales engineering. If the role is primarily product configuration and adoption, call it solutions engineering. If the role owns ambiguous customer problems through discovery, architecture, build, deployment, evaluation, and handoff, call it forward deployed engineering. AI companies need all three, but they should not blur the expectations. Blurred role design leads to weak hiring, weak onboarding, and customer-facing teams that are not equipped for the real complexity of agentic deployments.
What this means in practice
The practical implementation question is not whether the idea is interesting. It is how a team turns it into a workflow that can be inspected, repeated, and improved. For this topic, the operating focus is direct: Separate demo support, product configuration, and customer-proximate architecture so each role has clear ownership and hiring criteria.
That means the engineering work starts before the first model call. The team must decide what the agent is allowed to know, what it is allowed to do, what evidence it must produce, and which actions require a human decision. This is the difference between an impressive demo and a system that can survive real users, changing inputs, and production constraints.
A credible implementation also includes a feedback path. Every agent run should leave behind enough context for another engineer to answer four questions: what goal was attempted, what context was used, which tools were called, and why the system believed the task was complete. If those questions cannot be answered from logs, traces, or structured outputs, the agent is still operating as a black box.
A simple architecture to reason from
Use this diagram as a starting point, not as a universal blueprint. The important move is to make the stages visible. Once stages are visible, you can assign owners, define contracts, set permissions, measure quality, and decide where human review belongs.
What is the customer trying to accomplish?
Demonstrate technical credibility and answer objections.
Configure the product and guide adoption.
Own ambiguous workflow discovery, architecture, integration, and handoff.
Return field evidence to product and engineering.
Turn repeated field work into product capability.
Role ownership matrix
The example below is intentionally small. Production agentic systems should start with compact contracts like this because small contracts are testable. Once the boundary is working, you can add richer orchestration without losing control of the core behavior.
const aiCustomerRoles = {
salesEngineer: ["technical demo", "security questionnaire", "pre-sale objections"],
solutionsEngineer: ["configuration", "implementation guidance", "adoption support"],
forwardDeployedEngineer: [
"workflow discovery",
"solution architecture",
"customer-specific integration",
"evaluation design",
"production handoff",
],
};Implementation notes
Treat these notes as the first design review checklist. They are deliberately concrete because agentic systems fail most often in the gaps between the model, the tools, the data, and the human operating process.
Role clarity should be written before hiring; otherwise the FDE becomes a catch-all escalation role.
FDE success should be measured by deployed customer outcomes, not demo volume.
Product teams should receive structured field learnings from FDE engagements.
Common failure modes
The fastest way to make an article useful is to name how the pattern breaks. These are the failure modes to watch for when a team moves from reading about this idea to deploying it inside a real workflow.
Operating checklist
Before this pattern graduates from experiment to production, require a short operating checklist. The checklist should include the owner of the workflow, the allowed tools, the risk rating for each tool, the data sources the agent can use, the completion criteria, the review path, and the rollback plan. If a team cannot fill out that checklist, the workflow is not ready for higher autonomy.
The checklist should also define how the system will be evaluated after launch. Useful metrics include task success rate, human correction rate, average iterations per completed task, cost per successful run, escalation rate, and the number of blocked tool calls. These metrics turn agent quality into an engineering conversation instead of an opinion about whether the output felt good.
Finally, make the learning loop explicit. When the agent fails, decide whether the fix belongs in the prompt, the retrieval layer, the tool contract, the permission model, the evaluation suite, or the human process. Mature agentic engineering is not the absence of failures. It is the ability to classify failures quickly and improve the system without expanding risk.
Build real fluency in agentic engineering.
The Academy turns these concepts into a full curriculum, AI tutor, templates, and the CAE credential path.