The precise role of an FDE has always been ambiguous. I lived and breathed this role for 14 years at Palantir, and while my job title never changed my areas of responsibility, the skills I needed and the experiences I gained were in constant flux. As more firms hire for it that ambiguity will only increase, so how do you place a value on the role? The FDE concept works best with small teams embedded with the customer and their workflows, solving for an organisation's most valuable problems. Value alignment is essential. The vendor supplying the FDEs and the engineers themselves need to be incentivised by delivering successful client outcomes, otherwise you have hired an expensive time and materials consultant. Before jumping into a highly competitive and supply-constrained market it's important to understand how much and where value in your organisation can be unlocked with the advances in AI. Only then can you begin to understand what a small sharp team of AI native FDEs is worth to you.

Snowflake and Databricks have now joined Palantir and Microsoft in selling a layer that tells AI agents what your business means. Last week Netflix showed the same idea working at scale on its own stack. When this many players land on the same answer, the argument is settled: agents need a shared model of your customers, products and decisions before they can be trusted to act. The risk now sits with who holds that model. If every platform builds its own version of your business, you’re back to conflicting definitions, one layer up. We see the ontology as the core of an enterprise operating system, the part that should outlast any vendor you buy from. The strongest ones we’ve built grew from the decisions people make every week, and to the people using them they look unremarkable. Build yours that way, keep it in a form you own, and let whichever platforms you choose work from it.

Ontologies are in fashion because LLMs read data the way people do, in natural language. Palantir are over a decade ahead in terms of their capability and their understanding. From an engineer's perspective, the technology used to build an ontology is a natural place to start, but it's inconsequential. As a business, your ontology needs to have two things. The first is a strong design. At Palantir we worked backwards from the decisions people were making in order to run the organisation. A good design looks unremarkable to the end user because they look at it and think, that's just how we work. The second is real world impact. An ontology that adds value to your business doesn't just present data to the end user in an easy-to-understand way, it allows them to act on it. It describes the processes and the decisions that need to be made and it models the governance around who can make those decisions, when and it captures the why. Once an action is taken in the ontology it has a real world effect, it is not merely a simulation or a plan for somebody else to action. A graph database in its own right can't achieve this. The ontology that transforms the business is a fully-fledged capability in its own right.

The saving is real, but there are important nuances hidden behind the headline. Before the switch, Revolut kept tight token limits on the commercial frontier models, so engineers rationed them and rarely let agents do routine work like reading tickets or replying to review comments. Once Revolut owned the hardware, the capacity had to be used. The limits came off and people went fully agentic, working with agents all day. I think that explains more of the gain than the cost does. It's also not a like-for-like swap. GLM has a smaller context window and doesn't handle images, so it can't do user interface work the way Claude Opus can. Then there's scale. Usage comes in spikes, so a smaller team either buys hardware for the peaks and leaves it idle most of the time, or throttles people right when they need it most. Revolut has enough engineers to keep 56 Nvidia B200 chips busy, and by our rough sums those cost somewhere between $2m and $3m before you pay to power and run them. For most firms, the cheaper first test is to lift the limits on the tools you already pay for and see what changes while keeping engineers accountable for everything the agents ship.

The most useful line in the interview is Cascio’s research finding: companies that cut jobs without changing how the work gets done have never outperformed their competitors in the two years that follow. Early results suggest that holds even for profitable companies. That’s the risk in any AI restructure. Removing people is easy to show on a spreadsheet. The return comes from redesigning the work they did, so that AI and the people who stay can carry it. A buyout also loses the people with the most options, and Cascio’s fix is simple: managers telling their best people they have a future there. Procter & Gamble did exactly that in its buyout in the early 2000s.