The forward-deployed trap: why most agents built for you get abandoned

"Forward-deployed engineer" has become the most fashionable job title in enterprise AI. A vendor sends engineers to sit with the customer, learn the work and build agents around it. Done well, it is the fastest way to get something real running. Done the usual way, it leaves the customer with a system nobody inside can change.

In September 2026 Gartner put a number on the usual way. It predicts that by 2028, 70% of enterprises will abandon agentic AI built by vendors' forward-deployed engineers, mainly because of cost and an inability to evolve those systems in-house. It also expects fewer than 20% of those engagements to turn the customer's recurring needs into features of the vendor's product. Gartner's analysts say these engagements "often fail structurally before they fail technically".

We deliver with engineers on the customer's side too, so this is a criticism we take personally. Here is how we think the structure should work instead.

Why it fails structurally

Three patterns show up again and again.

The knowledge leaves with the engineers

The most valuable output of a good engagement is an understanding of how the customer's work really runs: the exceptions, the workarounds, the rules nobody wrote down. In a bespoke build, that understanding lives in prompts, glue code and the engineers' heads. When the engagement ends, the system remains and the understanding goes.

Every customer gets a one-off

When each engagement starts from a blank agent, nothing compounds. The next customer with the same process pays for the same discovery again, and the vendor's product never learns. That is the "fewer than 20%" in Gartner's prediction: recurring needs that never become product.

Nobody inside can change it

A system built in the vendor's style, on the vendor's scaffolding, with no tests a customer's team can run and no record of why it does what it does, is very hard to own. The first time the process changes, the customer has a choice between paying for another engagement and switching it off. Many switch it off.

What to own instead

Gartner's advice is to settle governance, IP ownership, knowledge transfer and an exit plan at the start of the engagement, and to keep to the exit plan. We agree, and we would make it concrete. At the end of an engagement, the customer should own five things.

1. The platform, in their boundary. Running in their cloud or on their servers, with source they can read, under their brand if they want it.
2. The knowledge, as a layer. Their ontology, their process logic and their rules, stored as reviewable objects, not hidden in prompts.
3. The tests. Evaluation cases written in business terms, and journeys that prove each screen and flow in a real browser, that their own team can run on every change.
4. The record. A signed ledger of every action the agents took, why it was allowed and who approved it, so the system can be audited without the people who built it.
5. The skills. People on their side who have built and changed the system alongside ours, not read a handover document.

The test of an engagement is not what runs on the day the engineers leave. It is what the customer can change the month after.

Build once, deliver many times

The other half of the fix is on the vendor's side: turn recurring needs into product, on purpose. That is why we package knowledge as offers in a marketplace, described by industry, process, team and platform. When a delivery team solves order-to-cash leakage for one customer on NetSuite, the solution becomes an offer the next customer installs, and the SAP build of the same offer runs the same evaluation cases. Each engagement starts further ahead than the last, and the customer gets a layer that has been through more than one real business.

It changes the economics, too. Engineers spend their time on the part that is genuinely specific to the customer, the Tailored edition, rather than rebuilding what the last three customers already needed.

How we structure an engagement

Our services partner, Relevance Lab, delivers Camaan in five stages: assess, prove, build and scale, run, and hand over. The share of the day-to-day work moves from their engineers to the customer's team as it goes, and the customer can stop after any stage. The hand-over is planned from the first day, which is the exit plan Gartner asks for, and it includes the code, the runbooks and the knowledge.

Two practical rules help more than anything else:

• Pair from the first week. Every agent, workflow and report is built by a mixed pair, one of ours and one of theirs.
• Nothing ships without its proof. No change goes live without its evaluation cases and its journey, so the customer inherits a system that tells them when they have broken it.