In short: Most enterprise AI projects do not fail because the model is weak. They fail in the last mile: the connection to real systems, data, permissions and people. That work cannot be done from a distance. It needs engineers inside your organisation until the system runs in daily operation, and a plan for them to leave.
1. The question a CEO should ask
I look at AI the way I look at any investment. Does it pay back? When? And who owns the result once the supplier has gone?
Most AI pilots fail that test. Not because the demo was poor. The demo is usually the easy part. They fail because nobody budgeted for the work between “it works on a laptop” and “people use it every morning”.
That gap has a name in the industry. Palantir built its model around it years ago, with engineers who work inside each customer to deploy and adapt its platforms. Today AI labs such as OpenAI and Anthropic are hiring for the same role: the forward deployed engineer.
2. Where the money is lost
The last mile is not glamorous. It is permissions that nobody documented. A CRM field that means three different things. A legal team that must approve the prompts. A process that only works because one person knows the exceptions.
None of this is in the pilot’s scope. So the pilot ends, the slide says “success”, and the budget for production is a new negotiation. Months go by. The sponsor moves on.
| What the project plan assumes | What actually happens in the last mile | Who pays |
|---|---|---|
| Data is ready once extracted | Access, quality and meaning are negotiated system by system | Your team, in delays |
| Integration is a technical task | It is an organisational one: owners, approvals, security | The sponsor, in credibility |
| Users adopt a good tool | Users adopt a tool that fits how they already work | The business case |
| Handover is a document | Handover is people who have built it themselves | You, every time something changes |
3. What changes with engineers inside
A forward deployed engineer works where the problem is. In your systems. With your people. Until it runs.
That changes three things I care about.
- Time to value. The solution is built in the environment where it will live, so there is no second project to “industrialise” it.
- Risk. Integration, permissions and controls are solved in the first weeks, not discovered after the contract is signed off.
- Ownership. Your team builds alongside. When the engagement ends, they can run and change what was built.
It is not cheap per week. The work is senior and hands-on. But the comparison that matters is not the weekly rate. It is the cost to a system in daily use. A cheaper project that never reaches production is the most expensive option on the table. We compare both models in our decision guide.
4. How to hire it without creating a dependency
Embedded teams have their own trap: they can become permanent. Before you sign, ask for four things.
- A named owner on your side who will take the system over.
- Everything in your repositories from day one: code, prompts, evaluation sets and documentation.
- Success measured by use, not by deliverables: who uses it, how often, with what result.
- A dated exit, with runbooks and a handover your own team has rehearsed.
If a supplier resists any of the four, treat it as a signal.
5. FAQ
Q: What is a forward deployed engineer?
A: A software engineer who works inside the client’s organisation, on its systems and data, until a solution runs in production. The model was popularised by Palantir and is now common among AI companies.
Q: Is it the same as hiring a consultancy?
A: Not quite. A traditional project often designs and builds with the firm’s own team and delivers at the end. Forward deployed engineers build inside your environment, alongside your people, and stay until it runs.
Q: How long should an engagement last?
A: As long as it takes to get a first use case into daily operation and your team able to run it, with a dated handover. No planned end is a warning sign.
Q: When is a project-based model better?
A: When the scope is clear and self-contained, the integration is light and you need a fixed price. Not every AI need requires engineers on site.
6. Conclusion
AI does not create value in a demo. It creates value when it runs inside the business, every day, owned by the people who use it.
That is how we work at Thinkia: as one team with yours, inside your systems, with the exit planned from the start. If you have pilots that never made it to production, this is how we approach it.