Skip to content
Back to Tech
GenAI · 16 min read

SaaS Isn't Dead - It's Picking Up Forward Deployed AI Engineers

Palantir's claim that SaaS is dead is provocatively wrong. The useful read is that AI is blurring the line between custom and packaged software, and the SaaS companies that win the next decade will pair a strong platform core with Forward Deployed AI Engineers - and feed every customer engagement back into the platform.

Share
On this page

Steve Banker’s Forbes piece on May 16 is the most quotable enterprise-software headline of the year so far. Danny Lukus, a deployment strategist at Palantir, told the room that SaaS is dead - and pointed to every Fortune 500 finance team running its operations out of Excel as exhibit A. “We have humans doing manual data integration and creating their own logic. There are a lot of bad things that happen as a result of that.” On the same beat, CTO Shyam Sankar claimed AI FDE - Palantir’s AI-powered Forward Deployed Engineer - is now powering SAP ECC-to-S/4HANA migrations “in as little as 2 weeks.”

The market is taking it seriously. Software stocks were down $300B+ in two days during the recent “SaaSpocalypse” sell-off. Palantir Q1 revenue grew 85% to $6.5B+ ARR. Sales and marketing as a percentage of revenue collapsed from 60% to 23%. Net dollar retention sits at 139%. The numbers are unusual enough that they force the rest of the industry to take the thesis seriously, even when the thesis is half-cooked.

Here is what I think the useful read is. “SaaS is dead” is the wrong headline. The accurate headline is that AI is blurring the line between custom and packaged software, and the SaaS companies that win the next decade will be the ones that pair a strong platform core with Forward Deployed AI Engineers - and crucially, feed every customer engagement back into the platform. That last clause is the part everyone is missing, and it is the part that decides whether you end up a platform or a consultancy.

This piece is what I think classical SaaS companies actually need to do.

What Palantir Actually Does Differently

To make any useful argument about whether SaaS is dead, you first have to be precise about what Palantir is doing that almost no other software company does. The three pieces matter individually and matter more together.

1. The Ontology

The Ontology is Palantir’s structural moat. It is not a data lake. It is a semantic, executable representation of a business’s logic, assets, and processes - a digital twin that AI agents and humans operate against. Where a traditional data warehouse sits below the application layer, the Ontology sits above it, mapping the data from SAP, Oracle, custom systems, and operational sources into a unified business model that knows what a contract, a plant, a part, or a customer means in your specific company’s terms.

This is the part competitors are slowest to grasp. The Ontology compounds. Every workflow you build on top of it makes the next one cheaper. Every AI agent you point at it makes the business logic more durable. It is why Palantir’s 139% net dollar retention is structurally different from a typical SaaS’s 110% NDR. Customers are spending 39% more each year not because they bought more seats, but because the Ontology became more of how they operate.

2. The Forward Deployed Engineer

Palantir doesn’t ship a product and let customers figure it out. They embed engineers inside customer environments and have them build the production workflows on top of the platform. The structured team is sharp:

  • Delta (engineer) writes production code, navigates broken data, implements the system.
  • Echo (strategist) understands the political and workflow reality of the customer, ensuring the work actually gets adopted.

The tension between the two is the design. What looks like consulting from the outside is the deliberate construction of pattern data: every deployment teaches Palantir what is bespoke to that customer and what is generalisable. The reason the model isn’t a services trap - this is the part most analysts miss - is the explicit pattern-recognition function. The FDE’s real job is to identify abstractions that appear repeatedly and pull them back into the platform.

3. AI FDE: Forward Deployed Engineers as Agents

In late 2025 and through 2026 Palantir extended the FDE model to AI itself. AI FDE is an agent that operates Foundry through natural language: building data pipelines, managing repositories, constructing Ontology objects, running transformations. The Sankar claim about two-week SAP migrations is downstream of this - what used to take a year of human FDE work plus customer teams now takes weeks of AI FDE work plus a much smaller human bridge.

This is the part that the “SaaS is dead” framing actually points at, although it under-sells it. The real change is not that AI replaces SaaS. The real change is that AI collapses the cost of the custom layer that has always sat on top of SaaS, and that collapse changes the maths of every enterprise software deal.

Why “SaaS Is Dead” Is Provocatively Wrong

The slogan is good marketing and bad analysis. Three things are true at once, and the slogan only honours one of them.

True: Pure packaged SaaS, with no integration layer and no customer-specific logic, is hitting a structural wall. The Forbes piece’s point about every finance team running Excel on top of their SaaS is the symptom, not the diagnosis. Packaged software has always required a customer-side build to make it actually fit. That build has historically been done by consultants, internal engineering teams, or, in the worst case, Excel. AI does not eliminate this layer. It collapses its cost, which changes who wins the value created.

True: Pure custom software does not scale. Every dollar Palantir charges for an FDE engagement is a dollar a competitor could spend on their own engineers, on a Big Four firm, on a consultancy, or on internal teams. The reason Palantir wins is not because their FDEs are cheaper. They are not. The reason Palantir wins is because the work the FDE produces compounds into a platform asset (the Ontology and the platform-level abstractions). If you stripped the platform feedback loop out, Palantir would be Accenture with hoodies.

True: The boundary between custom and packaged is becoming fluid, not vanishing. The right mental model for the next decade of enterprise software is a platform plus a service that turns into platform, with AI compressing both halves. SaaS, in this world, doesn’t die. It evolves into the package plus deployment plus feedback loop structure that Palantir is the loudest example of.

If you are a SaaS CEO and you take the “SaaS is dead” headline at face value, you will overreact. If you take the underlying shift seriously, you will start rebuilding your business model around a structure that classical SaaS has been resisting for fifteen years.

The Three Things Classical SaaS Must Do

Here is the operating playbook I would hand to any classical SaaS leadership team trying to figure out what to do this year and next. There are three moves, in order, and each one only works if the previous one is in place.

Move 1: Keep the Platform Strong - And Make It Worthy of Compounding

The first instinct of a SaaS CEO reading the Palantir story will be wrong. The instinct will be: “we need to add an AI tab and a chatbot.” That is exactly the move that doesn’t work.

What does work is investing in the substrate of the platform so it can absorb increasingly complex customer-specific logic without bloating the core. Three properties matter most:

  • A real data model, not a CRUD-shaped database. Most SaaS data layers are designed for the canonical use case and resist deviation. A platform built to compound has a semantic model - object types, relationships, derived properties, change history - that can absorb the next customer’s edge case without forking the schema. You don’t have to call it an Ontology. You do have to build one.
  • API-first composability. Every action the platform performs must be addressable by code, not just by UI. This is table stakes for agents to use it, and it is also the precondition for Forward Deployed AI Engineers to do anything that compounds.
  • Honest extensibility. Customer-specific extensions need a first-class path that doesn’t fork the core. Most SaaS architectures permit “customisation” only via a feature toggle or a configuration table. That is not what the agentic era needs. You need a sandbox where customer logic can be written, run, governed, and - critically - promoted into the platform when it earns its way there.

If you cannot do Move 1, no amount of Move 2 will save you. You will become a services business with a SaaS skin.

Move 2: Add Forward Deployed AI Engineers as the Service Layer

This is the move classical SaaS is going to be most resistant to, because it looks like services revenue. Investors hate services revenue. Boards hate services revenue. Senior managers spent twenty years removing services revenue from their P&L on the way to becoming pure-play SaaS.

That instinct is now wrong, and the reason it is wrong is that the cost structure of services has collapsed. A Forward Deployed AI Engineer is not a billable human consultant. It is a human engineer working with agents at five-to-ten-times throughput - in some workflows much more. The economics of “FDE-style engagement plus AIP-level agents plus platform leverage” don’t look like a 30% gross-margin services business. They look like a high-margin platform business with an embedded delivery arm.

Concretely, what this means for a classical SaaS company:

  1. Hire (or build) a Forward Deployed AI Engineering function. Small, senior, allowed to live inside customer environments. The job description is closer to staff engineer than to solutions architect. They write production code, they implement workflows in the platform, they instrument outcomes, they pair with customer teams.
  2. Equip them with agents from day one. AI FDE-style automation is the only way the maths work. Without agents at meaningful leverage, you re-create a 30% gross-margin consultancy. With agents, you keep platform-class margins.
  3. Don’t sell the engagement. Bundle it. Bake the FDE engagement into onboarding and into expansion. Customers don’t want to buy software and then sign a services SOW. They want to buy a working capability. If you make the FDE engagement feel like an SOW, your sales velocity collapses. If you make it feel like the first ninety days of value delivery, expansion accelerates.

The model from No Rules Rules and from my piece on empowered teams applies here as much as inside your own org. Forward Deployed AI Engineers are empowering customers the way empowered product teams are empowered inside your org. You give them context - the business problem, the customer’s data, the workflows to be transformed - and you let them solve it. What you don’t do is centralise the decision-making in some product committee that doesn’t have the customer’s data.

Move 3: Feed Everything Back Into the Platform

This is the move that decides whether you become a platform or a consultancy. It is also the part Palantir nailed, the part most services-heavy enterprise vendors miss, and the part that classical SaaS has the closest cultural fit to of anyone in the industry - if they make the move deliberately.

The discipline is this: every Forward Deployed AI Engineering engagement produces three artifacts. One is a working customer deployment. The second is a recorded set of patterns - abstractions, primitives, edge cases - that came up during the work. The third, and most important, is the promotion decision: which of those patterns belongs in the platform, and which stays bespoke?

The promotion decision needs an explicit forum. At Palantir, I gather, this happens through a tight loop between deployment teams and platform engineering. At a classical SaaS company, I would set up exactly that loop, weekly cadence, no exceptions:

  • What did our FDEs build in customer environments this week?
  • Which of those patterns is going to show up at the next five customers?
  • Who owns promoting those patterns into the platform?

The flywheel is identical to what Kief Morris described as the agentic flywheel in my earlier piece, just applied to the vendor-customer relationship instead of to the internal engineering loop. The customer engagement is the data source. The platform is the harness. The promotion process is the agent that improves the harness from the data. The compounding moat is the platform itself, getting richer with every engagement.

If you do Move 3 well, your platform improves faster than competitors who are only collecting telemetry. If you do Move 3 badly, you grow a services business that competitors will copy in eighteen months.

What This Means in Practice

Let me make the abstract concrete with three predictions and three traps.

Three predictions for SaaS over the next 24 months

  1. Every category-leading SaaS adds a Forward Deployed AI Engineering function. It will not always be called that. Salesforce will rebrand it. SAP will spin it into a new tier. The shape will be the same: senior engineers, plus agents, embedded with customers, paid for inside the platform contract rather than as a separate SOW. The ones who execute it as a platform investment rather than a services line will win.
  2. The Ontology pattern becomes the new differentiator. Whoever owns the semantic layer of a customer’s operational data owns the AI-era moat. Watch closely for SaaS vendors who quietly publish object-oriented data models, executable business logic surfaces, and agent-addressable APIs. Those are the ones building the moat, even if they don’t market it that way.
  3. Pure horizontal point-solution SaaS gets crushed. The vendors who sell one feature - expense reports, e-signatures, single-purpose CRM modules - are the ones with the most to lose. Their customers can now generate equivalent functionality with a competent AI engineer in a fortnight. The vendors that survive are the ones with deep data gravity, semantic models, and integration moats. Everyone else becomes a feature inside someone else’s platform.

Three traps to avoid

  1. The AI-tab trap. Bolting Claude or GPT into your existing app and calling it AI-enabled SaaS. This does not change your economics. Customers know.
  2. The services-creep trap. Letting FDEs become a billable consultancy. The moment your FDE org has a separate P&L with services-style margins, the platform feedback loop dies because no one is incentivised to pull bespoke work back into the platform. Keep the FDE function inside platform engineering, with platform-economics ownership.
  3. The fork-the-product trap. Letting one large customer’s bespoke build live forever as a special branch. This is how SaaS companies died in the 1990s and how they will die in the 2030s. The discipline of pulling patterns back into the platform is what keeps the architecture coherent.

How This Fits Everything Else I Have Been Writing

I find it striking how many of the threads in the agentic series converge on this article. Quick map:

The pattern across all of them is the same: the human role is concentrating at architecture, context, and judgement; the agentic layer is compressing the cost of everything else; and the winning structure is the one that captures the compression as compounding platform value rather than as a one-time services margin.

Palantir spotted this earlier than anyone and built the company around it. Classical SaaS can copy the pattern. The window for doing it is narrow.

The Takeaway

SaaS is not dead. The slogan is wrong, the analysis is incomplete, and the headline will look silly in five years. But the underlying shift it is pointing at is real. The cost of customising packaged software is collapsing. The boundary between platform and service is blurring. The companies that win the next decade of enterprise software will be the ones who pair a strong platform with Forward Deployed AI Engineers - and who feed every engagement back into the platform.

If you are running a classical SaaS company, your work is clear. Strengthen the platform substrate. Build a small, senior, agent-equipped Forward Deployed AI Engineering function. Bake the engagement into the customer relationship rather than into a separate SOW. Most importantly: build the weekly forum that turns every customer engagement into platform IP.

The companies that do this in 2026 will own their categories in 2030. The companies that take “SaaS is dead” at face value, panic, and add an AI tab will be acquired or eaten by the ones who didn’t.

References

palantir saas forward-deployed-engineers ai-engineering platform-strategy agentic-flywheel ontology enterprise-software business-model

Related articles

·GenAI

On the Loop - Leading AI Is an Empowerment Problem

Kief Morris's agentic flywheel, published on Martin Fowler's site, lands almost word for word on the same principles Marty Cagan and Reed Hastings have been preaching for decades. Leading AI agents isn't a new discipline. It's empowered product management with a new kind of teammate.

·GenAI

The Perfect CLAUDE.md for Enterprise Software Engineering

How I use CLAUDE.md files to encode engineering excellence standards - turning tribal knowledge into enforceable, AI-augmented guardrails for building enterprise-grade SaaS.

·GenAI

AI in a Nutshell - Models, Concepts, and the 2026 Landscape

A concise overview of AI models, fundamental concepts, and the current state of AI engineering - from frontier models to local LLMs and agentic systems.