When Every Platform Went Agentic

Palantir came onto the market around 2004. For the twenty years that followed, the two questions filtered almost everyone out, and FDE stayed a curiosity — one company's strange go-to-market, studied more than copied. Then the ground moved.

What actually changed

The obvious story is wrong. The world did not suddenly realize Palantir's FDE motion was a great idea. What changed is the nature of doing business in the software industry itself: AI made it really easy to build — really easy to write code, and really easy to build sophisticated, customizable software for customers. How many teams are building "agent for X" — insurance, legal, logistics? You don't even need to see the hands.

Follow the chain:

• Nearly every platform is now agentic —
• which means nearly every platform is customizable —
• which means nearly every vendor's customers have no idea what the thing actually does until someone shapes it to their business.

That last line is the 2×2 from the start of this pillar, recurring at industry scale. An open-ended agentic platform is a deeply technical product, no matter how friendly the chat box looks. And its buyers — claims departments, legal ops, hospital systems — are non-technical almost by definition. An entire generation of software companies has drifted into Palantir's quadrant without noticing.

In the wild

Watch where the role is spreading: Anthropic and OpenAI field forward-deployed teams; the fastest-growing agent startups hire FDEs before they hire account executives; "FDE" went from a Palantir-specific title to a category on every AI job board in about two years. The once-niche motion is pulling toward the center of how software gets sold — exactly as the platforms became agentic.

What runs out of road next

There is a second version of this story, told from inside a firm doing the work rather than from the market looking at it, and it arrives at a sharper question. Vasuman Moza's opening premise is that the constraint everyone optimised for is gone:

Clearly execution is no longer the core bottleneck. The models are improving to the point where intelligence is no longer the constraint, and harnesses are being built in a way that allow us to use, whether it's browser use tooling or API tooling, with very robust MCPs, that allow us to execute work with near perfection.

Set aside whether "near perfection" survives contact with the rest of this site — the site's own harness pillar is eleven sheets of reasons it does not. What matters is where he says the constraint moved: "the difference and the bottleneck that is still here is how much can you understand the business?" Every business is different, and the context that makes an agent useful in one finance department is not the context that makes it useful in the next.

That is the FDE motion restated as a bottleneck rather than as a go-to-market. And it produces the question this pillar has been circling: "how deep can you go into a customer without scaling head count exponentially?"

The reason it bites is arithmetic. Depth is what the motion sells, and depth is delivered by a person sitting with process leads for AP, AR, card reconciliation, banking, billing and FP&A, asking each of them not how the work runs but what happens when it goes wrong — "Sarah in AP handles the workflow today in this way, but when things go wrong, she actually sends it over to Chris, who then takes four days of cycle time." That undocumented reality is the product. It is also the thing that does not get cheaper as you add customers.

The harness, pointed at the FDE

Varick's answer to their own bottleneck is the thing this site has been describing for four pillars, applied to a job that is not software engineering. Their FDE agent has three stages, the third still unbuilt at the time of the talk:

• The engagement agent. An assistant that ingests what an FDE actually drowns in — meeting notes, slide decks, hundreds of pages of process documentation — and answers questions against it. The example JD Pruitt gives is entity resolution, not summarisation: "I got an email that mentioned Sarah spelled this way and I have a Slack message with a different way. Are these the same people?"
• The workflow agent. The same assistant embedded in the platform where the FDE builds the automation, checking the work as it is written — "oh, you forgot about this edge case… you should probably ask me who owns this process so I make sure the email goes to the right place."
• The autonomous stage. Not yet shipped: an agent that takes a routine client change request, queries what the firm already knows about that company, and ships the workflow edit without the FDE being involved.

Underneath all three is a single representation of how the customer works — a dependency graph, chosen for a reason worth repeating because it is so unglamorous: "most of these workflows inside of enterprise are remarkably linear. They just have a lot of cycles in them." Process owners want dependencies, not choreography. "They don't want person C in the process to have to deal with something before A and B have approved it." Pruitt is pointedly indifferent about the storage — "there was five companies trying to sell you a graph DB, and you can just use Postgres, whatever it is."

Then two moves that are pure harness engineering, and both are answers to a failure the frontier model produced:

• Post-training, because the default output was wrong in a specific way. Asked whether a frontier model produced good analysis from extracted context, Pruitt says no, and diagnoses it as verbosity plus an inability to triage: "they're so good at figuring out what is the part of the detail the client actually cares about, and what is the part that can get glossed over. And frontier models have absolutely no concept of this." So they post-train open models for that judgement. Read this as what it is — a vendor reporting that a competitor's general-purpose model underperformed its own tuned one at its own task, with no evaluation published.
• An RL environment for the retrieval, not the writing. The second half of the problem is traversing the graph well enough to get the right context in the first place, so they train custom tools inside an RL environment: resolving whether two names are the same person, because "there's a lot of Mikes in every company we work with," and detecting redundancy cycles and violations of the dependency structure.

The reveal

Now look closely at what an FDE actually deploys, primitive for primitive. Instructions shaped to one customer's business. Tools wired into their systems. An execution environment inside their boundary. Procedures codified so the next deployment starts further ahead. Verification against the outcome the contract names. Context assembled from the customer's own data.

That's not like a harness. It is a harness — assembled around one customer's problem, priced as an outcome, with engineers standing where the orchestration layer isn't mature enough to stand alone yet. The platform of primitives is the harness; forward deployed engineering is the harness, sold.

And the section above is the same claim arriving one turn later. When the motion hit its own ceiling — depth per engineer — the remedy was not a better model and not more hires. It was instructions, context, tools, verification and a domain representation, assembled around the FDE's problem the way the FDE assembles them around the customer's. The engineers standing in for the orchestration layer built themselves one.

The chain closes where it began: the same architecture this site opened with — the system around the model — turns out to be the unit of go-to-market too, and then the unit of doing the go-to-market.