Forward deployed engineering: the complete guide / Where the model came from
Is the forward deployed engineer role being automated?
Palantir now ships a product called AI FDE: an agent that operates Foundry through conversational commands, builds pipelines, edits ontologies, writes and tests functions, and builds applications in a closed loop. A company naming a product after its own signature role is making a statement about which half of that role was mechanical. The platform operation is being automated. Deciding which problem is worth solving inside an organization that cannot describe it, and being answerable when the answer is wrong, are not. That split is the whole answer, and it is the same split that governs any AI-native team.
Key takeaways
- Palantir's AI FDE is documented as an interactive agent that operates Foundry conversationally, in a closed loop of execute, observe, decide, within the permissions the user already holds.
- What automates is platform operation: pipelines, ontology edits, function writing, application scaffolding. That was a real share of the original job.
- What does not automate is discovery inside an organization that cannot specify its own problem, and accountability when the system is wrong.
- The permission model is the transferable lesson: an agent operating inside a customer environment must inherit that user's existing access rather than a broader service account.
The demand for forward deployed engineers was created by the AI wave. The same wave is now automating part of the job. Both things are true and they are less contradictory than they sound.
What Palantir shipped
Palantir's documentation describes AI FDE as an interactive agent that operates Foundry through conversational commands, translating natural-language requests into platform operations.
Its documented capabilities: developing and modifying data pipelines, creating and updating ontologies, writing and testing functions, managing data connections, read-only exploration and governance auditing, and building React applications.
It works in what the documentation calls a closed-loop operation model: the model executes an action, observes the result, and uses that feedback to decide the next action. On access, the documentation states that users have complete authority and visibility over what information the model can reach, starting with minimal context and expanding as needed, and that all operations respect existing user permissions.
Read the naming as a confession
Palantir invented the forward deployed engineer. When it built an agent and called it AI FDE, it was telling you which part of that role it considered mechanical.
That part is real and it was a genuine share of the week. Writing a Foundry transform, modelling a domain into an ontology, wiring a data connection, scaffolding an application: these are skilled tasks, they take time, and they are exactly the kind of work a model with tool access does well.
If your mental model of the job was "the person who builds the pipeline", that job is being compressed.
What is not in the capability list
Read the list again for what is absent.
Deciding which problem is worth solving. The agent operates on a request. Somebody has to sit with an operator for a week and work out which of their fourteen frustrations is the one whose automation changes an outcome. That is discovery, and it is the reason the role exists at all.
Establishing what correct means. In an AI system nobody knows the acceptable error rate or the escalation path until it runs on real data with real users. Getting a room of people who disagree to commit to a definition of good enough is not a tool-use problem.
Getting through the organization. Change advisory boards, security review, a data protection assessment, a release window, and the person in finance who has to approve the data access. This is where deployments die, and it is social rather than technical.
Being accountable. When the system produces a wrong answer that costs the customer money, somebody is answerable. An agent is not a party to a contract.
Where this leaves the job
Our read: the typing shrinks and the judgment does not move.
That is not a comfortable answer for anyone whose value was throughput. It is a good answer for anyone whose value was working out what to build inside a company that could not tell them. The hiring data already leans that way: across 1,000 postings, customer communication was the most-named soft skill at 47 percent, ahead of problem-solving under pressure and adaptability across industries.
It also means the ratio inside an engagement changes. If pipeline work compresses, the same engineer covers more ground, and the constraint becomes how fast the customer's organization can absorb change rather than how fast code appears.
The condition that makes it safe
If a model is writing the code inside somebody else's production environment, the verification has to be stronger than it would be in your own.
Generated code is not secure by default. The checks that prove a change does what the specification said have to be derived from the specification, written before the code exists, and graded by something other than the model that produced the code. In a customer environment, a wrong answer is their incident, their regulator and their customer relationship.
This is the whole argument of eval-driven development, and forward deployment is where it matters most.
The permission lesson worth copying
The most transferable detail in Palantir's documentation is not a capability. It is that all operations respect existing user permissions, and that context starts minimal and expands deliberately.
Any agent operating inside a customer environment should inherit the access of the person directing it rather than running on a broad service account, because a service account with wide access is how a helpful agent becomes a breach. Our page on security and access for embedded engineers covers the human version of the same rule.
What we would tell a buyer
Ask a vendor how much of the work their engineers do is model-generated and what proves it correct. Both answers matter, and the second one matters more.
For our own account: the code on our engagements is AI-written and every change has to pass an eval suite derived from the specification before it reaches your branch. That is why the model runs at a price a body shop cannot match. It is also why we can say the accountability did not move: the suite is the evidence, and we are the party answerable for it.
Next: how an engagement runs, or the Palantirization problem for the commercial critique.
Best for
- Assessing whether to invest in this capability as tooling improves
- Deciding what to look for in a vendor whose engineers use AI heavily
- Understanding which part of the role holds its value
Avoid if
- You want the current hiring picture rather than the trajectory
Verify before you commit
- Ask a vendor what share of delivered code is model-generated, and what proves it correct
- Confirm the checks are derived from the specification and graded independently of the model that wrote the code
- Confirm any agent operating in your environment inherits a user's permissions rather than a broad service account
Common questions
Will AI replace forward deployed engineers?
It is compressing part of the job. Palantir ships an agent called AI FDE that operates its platform conversationally, building pipelines, editing ontologies, writing functions and scaffolding applications. What it does not do is decide which problem is worth solving inside an organization that cannot describe it, or be answerable when the answer is wrong.
What is Palantir's AI FDE?
A Palantir product documented as an interactive agent that operates Foundry through conversational commands. It develops and modifies data pipelines, creates and updates ontologies, writes and tests functions, manages data connections, audits governance and builds React applications, in a closed loop of execute, observe and decide, respecting existing user permissions.
Which parts of the role do not automate?
Four. Deciding which problem is worth solving. Establishing what correct means when nobody knows the acceptable error rate yet. Getting a change through the customer's approval path, which is social rather than technical. And being accountable when the system is wrong, since an agent is not a party to a contract.
What changes about an engagement when the code is model-generated?
The typing compresses and the constraint moves. The limiting factor becomes how fast the customer's organization can absorb change rather than how fast code appears. Verification also has to be stronger than in your own environment, because a wrong answer is the customer's incident and their regulator.
How should an agent be given access inside a customer environment?
It should inherit the permissions of the person directing it, with context starting minimal and expanding deliberately, which is what Palantir's documentation describes for its own agent. A broad service account is how a helpful agent becomes a breach, and least privilege matters more here than in a system you own.
Related reading
How autonomous are AI coding agents, really?
Engineers at the frontier labs now say a model writes one hundred percent of their code. Read the quotes closely and the human is still in every one of them. Here is what the 2026 evidence supports, and what it does not.
Never let the model grade its own work
When the same run writes the code and the tests, a green build proves the code agrees with itself. That is not verification, and it is the most common way an AI-built codebase becomes confidently wrong.
More in Where the model came from
The Palantir forward deployed engineer model
Palantir popularised the forward deployed engineer, and it did so for one reason: its early customers could not describe what they needed until they saw software working against their own data. That made discovery impossible from outside the environment, so the engineer moved inside it. Every later version of the model, at AWS, OpenAI, Anthropic and hundreds of startups, inherits that assumption whether or not the company adopting it has the same problem. Understanding the original condition is how you tell whether the model will work for you or just cost you margin.
How AWS, OpenAI and Anthropic run forward deployed engineering
Four companies run public forward deployed engineering programmes: Palantir, which created the model, and AWS, OpenAI and Anthropic, which adopted it. Everything below comes from what each company published about itself, and is labelled as such, because a company describing its own delivery model is making a claim rather than reporting a fact. AWS is the one worth studying closely: it made two commitments in writing that the others did not, pricing on business results rather than billable hours, and customer self-sufficiency once the engagement ends.
The Palantirization problem
In January 2026 a16z partner Marc Andrusko published an argument against the model his own firm had popularised: most companies copying Palantir end up with an expensive services business dressed as software. He names four conditions Palantir met that most startups do not, describes the services trap as thousands of bespoke deployments nobody can maintain, and offers five questions that pressure-test whether a company has a platform or a labour arbitrage. This is the most useful critique of forward deployed engineering in print, and it is worth reading before you adopt the model or buy from someone who has.