What Actually Is a Salesforce Forward Deployed Engineer?

A few weeks ago I spent two days in Munich at the workshop that closes out Salesforce's FDE Ready program. Forward deployed engineer is a title that has been travelling faster than its definition. Most people I ask are not sure whether it describes a consultant or an engineer, whether it is a job or a badge, or which part of an Agentforce project it is meant to cover.

The program exists because of a gap Salesforce could hardly miss. Everybody in the ecosystem is playing with Agentforce, and far fewer of those experiments turn into something a business actually runs on. Pilots demo well and then sit there. That is a problem for the customer, who spent a year on it, and it is a problem for Salesforce, because an agent nobody adopted consumes nothing and a customer with a dead pilot is harder to sell to next time. FDE Ready is the answer to that: put the people who deliver these projects through a qualification aimed at getting agents adopted rather than at getting them built.

It is a certification path, and its requirements describe the role better than any job ad does. Before you can attend the workshop you need the Agentforce Specialist certification, Agentblazer Legend status, the Data 360 Consultant certification, and the implementation readiness courses for both products. Five prerequisites, every one of them either Agentforce or Data 360. The workshop itself is then not a build course. It spends its time on what the technologies now make possible and on the consulting frame around them: which use cases are worth attempting, how you qualify them, and how you plan to show the thing worked after it went live.

The title came from Palantir, which sent engineers to sit inside intelligence agencies whose data nobody at headquarters was cleared to see, so that the people building the software were in the room where it got used. AI companies revived the idea for the same reason, because the hard problems live where the customer's data and processes live. Gergely Orosz wrote a good history of the role on The Pragmatic Engineer. Salesforce runs FDE teams of its own for Agentforce and, in April 2026, extended the model to partners through the FDE Partner Network. Aquiva is named in the announcement among the specialized Product Development Outsourcers.

None of this makes the role less technical, because an FDE is expected to build the thing as well. Agents in Agentforce, grounded on unstructured data through retrieval, with a vector index behind them and Data 360 doing the data work underneath. Data 360 is not only where the monitoring lives. It is also the integration story, the way an agent reaches data that was never going to be copied into Salesforce, Zero Copy included, and the layer where retrieval actually sits.

That combination is a rare skill set today. Plenty of excellent Salesforce engineers and consultants have never grounded an agent on a vector index, never modelled a Zero Copy source, never built a semantic model to report on either. The certification is how Salesforce moves that skill into its partner base, because Agentforce and Data 360 are the two bets the platform is now built around.

Step one: What can you build today with AI?

Every agentic system today sits on a dial with no good setting. Turn it toward determinism and you are writing the code you wrote a decade ago, at which point the AI is decoration. Turn it toward prompts and instructions and you get a system nobody can predict, which demos well and cannot ship. No position on that dial removes the problem.

Hallucination is why, and it is not a defect awaiting a patch. The model predicts plausible continuations and holds no separate notion of what is true, and training and evaluation reward a confident guess over an admission of uncertainty. OpenAI's researchers argue that this is the root of it and that different incentives would let a model say it does not know. Others argue from learning theory that it cannot be removed at all. Anyone selling you a solved version of this is ahead of the evidence.

The current answer is to move the dial back toward determinism. Agent Script and LangGraph do it the same way: a state graph carries the control flow, the business-critical steps execute as code, and human-language prompts are reserved for the places where code cannot express what the person actually wants. That is the useful criterion. It is also where the difficulty moves to, because deciding which places those are is a judgement call every time.

Where the dial belongs, nobody has settled. We have not, and from the conversations in Munich, neither have the people building the tools. What that leaves for a project is blunt: if a rule can describe the work, write the rule, because a model doing a rule's job is slower, more expensive, and occasionally wrong in a way the rule never is.

This is where the first step runs into the second. The flashy demo, the one where an agent orchestrates across four systems and exercises discretion at every step, is rarely the one that ends up in production with a thousand people using it every day. And it does not fail mysteriously. It fails measurably: the first-attempt success rate is too low, escalations climb, the people who tried it once do not come back, and somewhere a team is quietly redoing the agent's work by hand. Anyone with monitoring in place sees that in the first week. Anyone without it argues about it for a quarter.

Step two: How do you measure success and failure?

Monitoring is not a phase at the end. It is a design input, because what you can measure about an agent later is decided by how you build it now.

It answers two questions at once, and they get collapsed into one. Whether the agent is broken: does it get there on the first attempt, how fast, how good is the answer, how often does a human take over. And whether the agent is irrelevant: is anyone using it, did the handling time move, did the escalations fall. An agent can be in perfect technical health and completely pointless. Only the first of those shows up in the logs by default.

The second half is the one that gets forgotten. The same numbers that prove an agent earns its keep also tell you what to change next: which topic it keeps failing, which question it keeps handing back to a person, which phrasing it misreads. Without them the next release is guesswork with a roadmap drawn around it. With them it is a list.

On the Salesforce platform this runs on Data 360, which most people still call Data Cloud and which is the most misunderstood product in the stack. It gets filed as customer unification, or as the integration layer, and it is both of those, but it is also the data lake the rest of the platform reports from. A semantic model is not something you bolt on in month six to answer a question from month two. Two facts also kill the usual objection that it is expensive and optional: there is a free tier, and ingesting your own CRM data through the native connectors costs nothing.

This is also the thing a pilot quietly skips. A pilot is allowed to cheat: sample data, no security model, a friendly user, no uptime promise. Production takes all four allowances back at once, and everybody plans for that part, because it looks like engineering. What nobody plans for is the argument for going live, and a pilot nobody instrumented has nothing to make that argument with except a demo that worked. A demo that worked is not a business case.

The engagements where we could show what an agent did for the business were the ones where this sat in the scope from the first workshop. Nobody adds it afterwards, because by then nobody has a reason to.

Step three: Implement it, test it, roll it out

None of this replaces the engineering. A use case that survives the first two steps still has to be implemented, tested and rolled out, and that is the part everyone already recognises:

• Connect the agent to the systems the business runs on: the ERP, the billing system, the ticketing tool, the data warehouse. Most of these were never designed to talk to an agent, and some were never designed to talk to anything.
• Structure the data the agent is grounded on, because an agent reading stale or inconsistent records is confidently wrong at scale.
• Build the security model around the agent: permissions, guardrails on what it may say and do, an audit trail for what it did.
• Set up the operational controls that let it run unattended but governed: monitoring, escalation paths, versioning, a way to roll back.

That work takes more than Agentforce skills. It takes people who know the platform itself properly, and it takes Data 360 skills, because the grounding, the integration and the reporting all sit there. Which is why the room in Munich was not only consultants. A good part of it was engineers with years of Salesforce behind them, and the qualification path in front of the workshop is a stack of technical certifications rather than a methodology course.

Where Aquiva fits in

The network launched with Accenture and Deloitte as headline partners, joined by more than 30 firms including Capgemini, Cognizant, IBM Consulting, KPMG, PwC, Slalom and Tata Consultancy Services, and Salesforce puts the network behind one in three successful Agentforce implementations to date. We covered the launch in our TDX 2026 roundup. Most of that list are global system integrators. The Product Development Outsourcer category is a smaller one, and Salesforce's announcement names Aquiva, Appiphony and Bridgenext in it.

We sit in both categories, as a system integrator and as a PDO, and for this work that combination is the point. A production agent behaves like a product, so it needs versioning, upgrade paths, monitoring and somebody who answers the phone when it breaks, and it also needs someone who can sit with the business and settle what is worth building in the first place. Few partners with that breadth were running Agentforce projects a year or two ago, when most of the ecosystem was still watching. We were.

And in case you are wondering whether Aquiva only recently jumped on the AI bandwagon, we did not, and the evidence is public. We started My Org Butler in January 2024, before Salesforce had an agent product to build on at all: the first version ran on the OpenAI Assistants API behind a Salesforce front end, and it moved onto Agentforce once that could carry it. It is open source, and so is speccy, which Aidan Harding released recently to help developers use AI without getting sloppy and lazy, and documented in this blog post. We have been giving conference talks about this work since then, and we publish what we learn, including how much of our own work we can safely hand to AI and how hard that turns out to be, written up here.

Frustrated with stalled AI pilots? Talk to us

The useful part of running our own is not the tooling. It is that we have already argued about which of these jobs deserved an agent, and been wrong about a few of them, which is the argument every customer is about to have. Most of this work ships through an AI Pod, which is how we staff it.

See how our Salesforce forward deployed engineering works →

Get your Agentforce use case reviewed →