uyeon.dev
Published on

How Palantir Broke the SI Curse

In the summer of 2026, a strange scene kept repeating.

On June 30, AWS committed $1 billion to a business of embedding its own engineers inside customer companies. Two days later Microsoft raised the stakes with $2.5 billion and 6,000 engineers. Back in May, OpenAI had raised more than $4 billion for a near-identical venture, and Anthropic had formed a $1.5 billion joint venture with private-equity backers.

The best companies in software were suddenly racing to pour money into staff-deployment work — the very business the industry had spent decades teaching itself to avoid. And nearly every account of these announcements noted one fact: the company that invented this model nearly two decades ago was Palantir.

So what exactly did Palantir invent that everyone is now copying? To give away the ending: it wasn’t “deployment.” It was a structure that lets you start as a staffing business and end as a software company. Half of that structure lives in business design; the other half hides in software architecture that runs deeper than it first appears.

The SI curse isn’t about labor cost

There is an old curse on the systems-integration business: it only grows as fast as headcount.

It’s usually explained as a labor-margin problem, but if you’ve built software, you know the real cause is something else — codebase divergence. Build custom for every client and you spawn a separate copy of the code (a fork) per client; past ten forks, every new feature must be ported ten times. The maintenance burden grows worse than linearly with customer count.

SI fails to scale not because people are expensive, but because what those people build accrues as liability instead of asset.

And yet Palantir deliberately picked this cursed path. Security-cleared engineers of its own sat at customer sites like Fort Bragg or Langley for six to twelve months, learning the domain and writing production code directly. That role is the FDE — Forward Deployed Engineer. On the surface, it looks like ordinary staff-augmentation.

The difference is in what the deployed person leaves behind. An SI contractor leaves a one-off deliverable on the client’s stack and walks away. A Palantir FDE leaves two things on Palantir’s own platform: the customer’s ontology, and field requirements fed back into the core product.

By accounts of how the model runs, FDEs spend four days a week on the customer site but reserve one day for platform engineering. The same deployment burns cost on one side of the industry and accrues assets on the other.

So why doesn’t the codebase fork?

Here’s the question any engineer should ask. FDEs do bespoke work for every customer — why no forks?

Because the layer where customization happens is forcibly separated. Palantir’s platform reads as three layers:

  • At the bottom, a single core shared by all customers: Foundry (the data-integration platform), Gotham (the government and defense product), and AIP (the Artificial Intelligence Platform, which connects AI to operations)
  • Above it, per-customer ontology and pipeline configuration
  • On top, applications that consume that configuration
The three layers of Palantir's platform: application layer, per-customer ontology and pipeline configuration, single shared platform core, and Apollo for deployment
The three layers of Palantir's platform: application layer, per-customer ontology and pipeline configuration, single shared platform core, and Apollo for deployment

FDE output is, as a matter of principle, deposited only in the middle layer. Customer specificity is absorbed through configuration and schema definition, not code changes — config over code.

This principle is what breaks the curse. At a hundred customers there is still exactly one core to maintain, and a new core feature ships to all hundred at once. Conversely, the moment the principle erodes — the moment an FDE under deadline pressure starts pushing customer-specific code into the core — Palantir degrades into an expensive SI shop.

I suspect this is also why the role demands top-tier engineers: the substance of the job is adjudicating whether a field request is “a problem solvable in configuration” or “a problem that belongs in the core as a generic capability,” and that adjudication takes senior-level abstraction skill.

The ontology: a translation layer between data and users

Second question. How can non-developer operators safely build their own workflows with no-code tools?

The ontology is usually introduced with the metaphor of “a semantic map of business entities and processes,” but the reality is more concrete: it is a translation layer inserted between messy source data and the people who use it. Instead of exposing source tables and columns, it defines domain objects — orders, equipment, patients — the relationships between them, and the actions permitted on each (move inventory, approve, reassign dispatch). Operators and upstream applications look only at this layer, never at raw source data.

To make it concrete: suppose a dispatcher at a logistics company uses the no-code builder to create a “rebook delayed orders” workflow. What she manipulates on screen is not the dozens of tables scattered across the TMS and ERP, but three objects — delivery order, vehicle, driver — and a single action: reassign dispatch. Who may change which orders, and where every change gets recorded, is already defined at the ontology layer, so there is simply no path by which she could corrupt ledger data or build an operation beyond her permissions.

That layer separation is the technical precondition for self-serve. The no-code builder is safe precisely because what operators can touch is limited to objects and actions defined in the ontology, with access permissions and data history (where each piece of data came from and how it was transformed) enforced centrally there.

AIP, which connects AI to operations, rests on the same principle. Rather than handing the model raw database access, it exposes only ontology objects and permitted actions as tools — so even when the AI produces a wrong answer (a hallucination), the path by which that becomes a live system malfunction is structurally cut off. AIP’s rapid success after 2023 was no accident: a layer laid down over more than a decade turned out to be exactly the safety harness AI agents needed.

The business-side lock-in flows from the same substance. The ontology is not a copy of data; it is the organization’s operating rules and permission structure, codified. Leaving requires not a data migration but a reconstruction of organizational knowledge.

The moment the economics flip from headcount to usage

Follow one customer’s lifecycle and the handoff point comes into focus.

Entry happens through the AIP bootcamp. Instead of long proposals and PoC negotiations, Palantir builds something working on the customer’s real data within days. The reason this is even possible is the architecture above: the core already exists, so only the skeleton of an ontology needs assembling, collapsing time-to-demo from weeks to days. This is why Palantir internally treats FDEs not as a cost of sales but as the pipeline itself.

The period after signing, while FDEs complete the ontology, is the SI phase. When it ends, operators build their own workflows on the ontology, the FDEs move to the next customer, and revenue grows with usage rather than deployed headcount. With token-based pricing — billing in proportion to AI usage — now standard, the revenue ceiling per customer is set not by seats but by the economic value of the work the AI performs. The self-serve phase effectively has no ceiling.

In short: the early labor cost is an investment producing an asset called the ontology, and the moment that asset is complete, the account’s economics switch from headcount-proportional to usage-proportional. Palantir didn’t avoid the SI phase; it passes through it deliberately, having pre-dug an architectural exit.

The other half nobody copied: the feedback loop and Apollo

The flywheel of “field learning gets absorbed into the platform” is easy to say and does not work without organizational design.

Palantir baked it into the FDE’s job structure itself. During the weekly platform day, FDEs generalize customer-specific requests into generic feature proposals and review other FDEs’ code. The feedback loop that usually dies in companies where field and product organizations are separated is force-welded into one person’s weekly routine. Every turn of the loop shortens the next customer’s deployment, letting the same FDE headcount push more customers through to self-serve — which is why the labor bottleneck loosens over time.

The last puzzle piece is deployment. Palantir’s flagship customers are government and military organizations on closed networks, completely cut off from the outside internet. Continuously delivering updates of a single core to hundreds of such sites requires a dedicated deployment platform, and that is Apollo. Define each environment’s constraints up front — security classification, available versions, approval state — and Apollo works out on its own which environments can accept an update and rolls it out there.

If config over code guarantees “there is one core,” Apollo guarantees “that one core actually reaches every site.” To the usual explanation — software companies had no field organization, consultancies had no platform — add one more: even with both, without this deployment infrastructure the model does not hold in regulated industries and closed-network markets.

The numbers are starting to show it. Contrary to the long-standing image of a government contractor, the commercial segment had grown to 46% of revenue by mid-2026 on Forbes’ tally, and in the Q2 2026 results released the week of this writing, US commercial revenue grew 149% year-over-year, driving total revenue growth of 93%.

It isn’t free, of course

The elegance of the model rests on the premise that the conversion actually happens, and that premise can wobble.

The entry-phase labor bottleneck is structural. Senior engineers who can adjudicate the config-versus-code boundary are scarce, and new-customer velocity is chained to their hiring velocity. High initial deployment cost effectively closes off the SMB market.

And config over code is a principle, not a law of physics. Preventing the “core contamination” scenario described earlier — customer-specific logic seeping into gray zones under delivery pressure — is a never-ending governance fight. The ontology itself is double-edged: the deeper it goes, the higher the exit cost, which is the moat and simultaneously the reason new customers hesitate at the contract table.

There are dissenters, too. Analysis suggests FDE-style deployment works in dynamic environments needing real-time adjustment but can amplify risk in stable systems with strict governance and release processes. Kinaxis, which uses the same approach, argues FDEs are meaningless without domain expertise; Anaplan considers the whole concept oversold.

And the biggest threat is the opening scene itself — the success. In May 2026, OpenAI launched the OpenAI Deployment Company, a subsidiary that raised over $4 billion from a 19-firm consortium led by TPG, and even EY and Salesforce have formalized FDE organizations. From an engineering standpoint, though, what the imitators have replicated so far is the staffing model — not twenty years of accumulated ontology assets, not the platform enforcing config over code, not the closed-network deployment infrastructure. Whether frontier labs’ newest models can route around that accumulation is what to watch next.

Questions this leaves for builders

This is a story at Palantir’s scale, but the structure is worth holding up against any product organization. Three questions compress it.

  1. Of the per-customer work you’re doing right now, do you distinguish what can be pushed down into configuration from what belongs in the core — and who makes that call?
  2. Does the loop that returns field discoveries to the product exist in your org chart, or are you relying on goodwill?
  3. Is what you leave with a customer a deliverable, or an asset?

What makes Palantir special is not that it created a job title called FDE. It’s that it answered these three questions — with architecture and organizational structure — twenty years ago.

References

View on GitHub

Comments