Is the forward deployed engineer role being automated?

The demand for forward deployed engineers was created by the growth of AI. The same technology is now automating part of the job. Both things are true and they are less contradictory than they sound.

What Palantir released

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 name as an admission

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 routine.

That part is real and it was a genuine share of the week. Writing a Foundry transform, modelling a domain into an ontology, setting up a data connection, creating the starter code for 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 getting smaller.

Worth being specific about how much smaller. A transform that used to take two days of writing and testing can now be described in a paragraph and produced in minutes, with a person checking the output rather than typing every line of it. That is a genuine change to the week of anyone whose job was mostly writing that kind of code, and it is not a change that arrives gradually over years. It arrives the week a customer's environment gets access to the tool. Anyone planning a career or a hiring pipeline around the old shape of the job is planning around a shape that is already changing underneath them.

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 group 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 fail, 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.

A worked comparison makes the split concrete. Imagine an insurer wants a claims triage system built inside its own environment. An agent with platform access can be told to build a pipeline that pulls claim records, apply a model to score them, and stand up an application that shows the scores to an adjuster. It will do all of that competently and fast. What it will not do is sit in the room when the head of claims and the head of compliance disagree about which false negatives are acceptable, decide that the real problem is not scoring speed but a missing appeals step three screens later, or answer to the regulator when a wrongly declined claim becomes a complaint. Those three things are the job. The pipeline was always the easier half.

Where this leaves the job

Our view: writing the code takes less time, and the judgment stays with a person.

That is not a comfortable answer for anyone whose value was the amount of code they produced. 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 shows this: 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 takes less time, the same engineer does more work, and the limit becomes how fast the customer's organization can accept change rather than how fast code appears.

This changes what a good engineer's week looks like without changing what a good engineer needs to be able to do. First Round Review's rough split of 20 percent customer-facing time and 80 percent building was measured against a world where building was the slow part. When building speeds up, either the ratio shifts toward more customer time, or the same engineer covers more accounts, or the engagement reaches production sooner than it used to. All three are plausible outcomes, and which one actually happens at a given company depends on whether the organization on the customer's side can approve and adopt change at the same pace the code now appears, which is rarely the limiting factor people expect it to be.

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.

The reason this matters more here than almost anywhere else is that a forward deployed engagement already sits inside another company's systems, often with access that a normal vendor relationship would never grant. Adding an agent to that arrangement without the same discipline about permissions multiplies the size of the mistake a single bad instruction can make. An agent with a broad service account can touch records nobody asked it to touch, because nothing in its access stopped it, and by the time anyone notices, the action has already happened. An agent scoped to exactly what the directing person could reach themselves fails the same way a human employee would: visibly, and inside a boundary someone already agreed to.

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. A vendor who can answer the first question but not the second is telling you they write code fast without telling you how they know it is right, which is the exact combination that produces an expensive incident inside your own systems.

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 firm that only rents out engineers cannot match. It is also why we can say the accountability stayed with us: 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.