The Future of FDEs

Forward-deployed engineers are having a moment. Every AI company now has a team of them: engineers who sit inside a customer, learn the business, and build the thing the product alone could not. It works. It is also how a company ends up selling engineers instead of software, and how an enterprise ends up with a dependency instead of a capability. When the engineer rotates out, the system starts to rot.

We run forward-deployed engineers too. We just think the role has an expiry date built in, and that the whole point of the job is to reach it. An FDE’s job is to leave.

We produce FDEs, we do not collect them

The classic FDE is a rare animal: a senior engineer who is also at ease in a boardroom, who can read an ERP export and a procurement contract in the same afternoon. You cannot hire enough of them, so the model stays small, slow and expensive.

Our answer is to make the role producible. Three things do most of the work. A method: the same discovery we have written about before, where the first session builds trust and the later ones do the challenging, and where use cases are chosen for their chance of shipping rather than their chance of impressing. A platform: the agents, the voice, the guardrails, the deployment options, already built, so the engineer arrives with a workshop rather than a blank repository. And a playbook: every deployment we finish becomes a pattern the next engineer starts from.

A strong engineer with those three is effective inside a large enterprise in weeks. Not because the problems got easier, but because most of every problem is the same as the last one, and we stopped solving that part from scratch.

Arriving without friction

The most expensive part of an enterprise engagement is not the build. It is the six months before it: security reviews, data residency questions, identity, procurement, the network team. A forward-deployed engineer who spends their first quarter getting access is a very expensive way to get access.

So our FDEs arrive with the boring parts already answered. The platform runs in the European Union, inside the client’s own cloud, or on their own machines, whichever their policy says. It speaks the identity system the enterprise already uses. It keeps an audit trail without being asked. Nobody’s data goes anywhere it should not. The first week is about the business, not about us.

The same goes for the systems already in place. Enterprises do not want to be re-platformed; they want what they have to work better. The agent plugs into the ERP, the CRM, the shared mailbox, the phone line that already exists. We meet the organisation where it is, including the spreadsheets nobody officially admits to.

Bringing the technology in, not the people

Here is the difference that matters. In the classic model the engineer is the deliverable, and everything they build is theirs. In ours, the deliverable is the platform installed inside the enterprise, with the client’s own people already building on it.

From the first week, everything an FDE builds lives in the client’s own studio: visible, editable and testable by the people who own the process. We build the first agent with them, not for them. By the third, they are proposing the next one. Turning a client into a power user is not a training module at the end; it is the shape of the work from day one. When our engineer walks out, the capability stays, because it was never in their head. It was in the platform, and in the team.

Autopilot

This is the part people find uncomfortable, so it is worth being precise. Autopilot does not mean unattended. It means the system flies itself while a pilot watches the instruments instead of holding the stick.

A system on autopilot knows its own health. It shows every conversation, what it cost, where it hesitated, which actions waited for a human before going ahead. It refuses what it should refuse, the same way on the phone as in chat. When a model is retired or a better one appears, the switch is a setting, not a project. When something drifts, someone in the client’s team sees it before a customer does, and fixes it in the same place they built it.

That is what leaving looks like. Not a handover document and a farewell email, but a system that keeps producing the outcome it was built for, operated by the people who own the outcome. Our engineer checks in. They do not sit in.

What this does to the role

Measured this way, the future FDE looks different from the current one. Their success metric is exit velocity: how quickly the enterprise stops needing them. Their portfolio is a list of systems running without them. They accumulate patterns instead of billable hours, and every pattern makes the next engagement shorter. The role stops being a heroic exception and becomes a repeatable craft.

For the enterprise, it means getting the outcome without the dependency. The AI works, the team owns it, and the vendor’s engineer is a phone call away rather than a line item forever.

Our best FDE is the one who leaves the fastest. We are building the role, the platform and the company around that sentence.

If you want to work this way, we are hiring. If you want it done inside your organisation, talk to us.