The Forward Deployed Futurist

Forward Deployed Engineers are having a moment. The role, pioneered by Palantir, has seen job postings increase by 800-1,000% in 2025. Salesforce is building a thousand-person FDE team. Stripe, OpenAI, and Anthropic are all hiring for variations of the same idea: engineers who don’t build from headquarters but embed directly with clients, living inside their problems until they understand them better than the people who created them.¹

Nobody, as far as I can tell, has asked what happens when you apply this principle to foresight.

The Foresight Delivery Problem

I’ve written about this before (in The Beginning and the End of Foresight and Wie Foresight- und Innovations-Teams wirksam werden): foresight work has an impact problem. The scenarios get built. The report gets delivered. The client is happy. And then nothing happens. Insights gather dust while the organisation moves on to next quarter’s priorities.

The common diagnosis blames methodology: if only we had sharper signals, more rigorous analysis. I think the diagnosis is wrong. The methods are fine. The delivery model is broken.

Most foresight firms take a brief, apply their standard toolkit, and throw the results back over the fence. The engagement ends where the actual work should begin: at the point where futures thinking needs to become organisational practice. This is a structural problem, not a skills problem. And it turns out someone in a completely different industry figured out an answer.

What Palantir Figured Out

Palantir’s insight² (and I’m borrowing liberally from Zoe Scaman’s excellent The Palantir Model here) was that the real product is embedded cognitive capacity. Their Forward Deployed Engineers move into client organisations for months, sometimes years. They don’t trust briefs. They don’t trust stated requirements. They assume the organisation is wrong about what’s actually broken.

And they’re usually right.

Scaman puts it well: the difference between “tell me your problem” and “let me watch you work for six months” is the difference between stated and revealed preferences. Any behavioural economist will tell you those are very different things.

There’s a second piece that matters: Palantir splits its engineers into two groups. FDEs build bespoke, fast, whatever-works solutions on site. Product Development engineers then extract the patterns and build reusable infrastructure. Every engagement makes the whole system smarter. This is how knowledge compounds instead of staying locked in someone’s head.

Forward Deployed Foresight

What would foresight look like if it followed this logic?

Start with the context problem. External futurists rarely understand an organisation deeply enough to produce relevant futures. They capture what the brief says, not what the organisation actually needs. The real strategic questions (the ones that would make a foresight project genuinely useful) hide in the gap between what people tell you in a stakeholder interview and how they actually make decisions. You can’t access that gap in a two-day workshop.

Then there’s the translation problem. Even good foresight work stays abstract without someone who bridges both worlds: the futures thinking and the organisational reality. That bridge requires presence. It requires understanding who holds power, whose budget is threatened, which team will block implementation and why. Almost none of this shows up in a deliverable.

The most effective foresight engagements I’ve been part of had elements of this. Not the full Palantir residency model, but enough embedded time to understand context that no brief could have captured. The patterns are clear: depth of context correlates directly with depth of impact.

Here’s where it gets interesting for solo practitioners. Palantir can afford to embed engineers because they have a second layer extracting and systematising the patterns. A solo futurist doesn’t have a Product Development team. Every engagement would be linear, not exponential. Scaman calls this “artisanal consulting”: brilliant bespoke work that doesn’t compound.

Unless you have AI.

AI tools change the calculus for solo practitioners in a fundamental way. Systematic documentation practices (what I call “Documentation as Infrastructure”), knowledge graphs, pattern libraries, AI-assisted analysis: these create the encoding layer that Scaman identified as missing. The solo futurist’s accumulated context doesn’t have to disappear when they leave. It can become searchable, reusable infrastructure. Each engagement feeds the system, and the system feeds the next engagement. That’s the beginning of a flywheel.

Open Questions

This idea raises more questions than it answers. A few that I’m sitting with:

Does it scale? Even with AI as an encoding mechanism, one person can only be embedded in one organisation at a time. The Palantir model works because they deploy teams across hundreds of clients simultaneously. A solo Forward Deployed Futurist is inherently limited. The question is whether the AI-powered knowledge infrastructure compensates enough to make the model economically viable.

What distinguishes this from an Interim Head of Strategy? The answer, I think, lies in the mandate. An interim fills a role. A Forward Deployed Futurist brings an external perspective and a specific lens (futures thinking) while remaining structurally outside the org chart. The value comes precisely from not being absorbed into the organisation’s own logic.

Which organisations are ready for this? Scaman’s observation about Palantir applies here: this model requires a certain type of client. One in enough pain to tolerate the intrusion, to let someone see the mess. Most organisations haven’t reached that point with foresight. They’re still in “hire a consultancy and shelve the report” mode.

What about the encoding problem? AI helps, but it doesn’t fully solve it. Pattern recognition across engagements, building a genuine “private pattern library” of organisational futures challenges: that’s a hard problem. The tools exist. The practices are emerging. But turning embedded experience into systematic, reusable knowledge at quality is still more aspiration than reality.

Towards a Model

If I were sketching the building blocks, they would look something like this:

Time: Months, not weeks. Enough to move past stated problems to revealed ones.

Access: Not just the strategy department. Across functions, up and down the hierarchy, into the meetings where actual decisions happen.

Mandate: Diagnosis paired with implementation support. The Forward Deployed Futurist stays through the point where insight becomes action.

Infrastructure: AI-powered documentation and knowledge systems that capture patterns, build institutional memory, and create the encoding layer that makes each engagement compound.

Exit design: Unlike Palantir, the goal is capability transfer. The organisation should be able to continue the work after the futurist leaves (even if, realistically, most won’t).

I don’t have the full picture yet. But what I keep coming back to is the relationship between the futurist and the organisation. Change that, and the methods we already have might finally land. I’m exploring what that could look like in practice.