"Stop sending me engineers." That's the headline on a CIO's column in CIO.com on October 13, and it's the first time I've seen a buyer say out loud what the enterprise side of this series has been circling.
Praveen Jonnala runs IT at Vistance Networks. His argument is that the labs have the diagnosis right, most AI pilots don't move profit, and the treatment wrong. Forward deployed engineers get you into production. They don't get you diffusion, the internal people who can find and fix the next problem without a vendor in the room. His example is a demand-forecasting agent that improved accuracy and didn't change cash, because the trade-off that moves cash, inventory against service levels, belongs to operators, not to a visiting engineer. The line I'd put on a wall: "In engagements structured this way, the lab learns your business. You learn their product." And the one he wants on a T-shirt: "I don't need more forward-deployed engineers. I need backward-deployed domain experts."
Six days later, this morning, Bertrand Maltaverne published the procurement version. He spent years as an implementation consultant, and his piece at Procurement Tidbits is called "Your vendor's forward-deployed engineer is moving in... Plan the move-out!" It has six contract terms and six questions, and it quotes Charlie Gottdiener, Anaplan's CEO, on customers who end up with forward deployed engineers "that they have to pay for and rely on in perpetuity."
Both pieces landed in a week when the supply side kept growing. CNBC reported on October 15 that Lightcast counts more than 7,300 US postings for the role in the first nine months of 2026, against fewer than 200 in all of 2023. Atlassian launched its own program on October 7. Every one of those engineers lands in someone's building, and the people who own the buildings have started writing.
This is part 10 of The FDE Transition. Part 9 was comp. This one is the other chair: what to ask for in the contract when you're the one buying.
The short version
The buyer's fear is dependency, and it's the right fear. Gartner's September prediction is that 70 percent of enterprises will abandon agentic AI built by vendor FDEs by 2028, "trapped by soaring costs." The usual fix is an exit clause. An exit clause gets you out. It doesn't get you what you paid for. What you paid for, if the vendor is running the model honestly, is a product that absorbs your deployment so you need fewer of their hours next quarter. So I'd contract for the loop, not just the exit. Six lines: the customer layer is yours, including the eval rows; the contract says which codebase the engineer works in, per layer; FDE hours fall over the term, by contract; a named counterpart on your side is the deliverable; your team passes an independence test before the engineers leave; and the renewal price is written before the pilot. And one question before you sign any of it: name three product features that began as customer field work, with dates. A vendor who can't is a services firm with a new title, and you should pay services prices.
Take the CIO's objection all the way
I've been on both sides of this table, and Jonnala's column is the best version of the buyer's case I've read, so I want to give it full weight before I argue with it.
He's right that production isn't diffusion. He's right that an outside engineer can't own a trade-off whose result shows up in cash three quarters later. And he's right about the asymmetry. The vendor's engineer leaves knowing your exceptions, your unwritten rules, which approver actually decides. You're left knowing how to use their product. The handbook's economics chapter carried Andrew Ng's version of this, that a company's own AI engineer is the structurally better bet. Jonnala's is sharper, because his isn't a point about the stack. It's a point about who learns.
Where I get off is "nobody is selling those." Nobody sells backward-deployed domain experts, he writes, so the only people who can build them are already on your payroll.
True, and it's the opening. The month-two page in part 6 already has a line for this: one named person on the customer's side who can make a change to the customer layer and see the rows run afterward. That person is Jonnala's backward-deployed domain expert. An honest FDE vendor should be producing one on every engagement, because the vendor's own margin depends on leaving. So don't ask the vendor to send fewer engineers. Ask for a contract where producing your operator is what the engineer is there to do, and where the proof is written down.
Whose codebase
Here's the question most procurement teams don't know to ask, and two announcements this year answer it in opposite directions.
Atlassian's program, announced October 7 with Avani Prabhakar, its chief people and AI enablement officer, quoted: engagements run about twelve weeks, the customer contributes its own engineers who learn to build alongside, and Atlassian's engineers work in Atlassian's codebase, so fixes, reusable agents, and connectors ship to every customer. Read that as a buyer. The thing built in your building goes into the product, and you get it back in the next release. So does your competitor, which is the deal.
AWS's partner-led FDE program, introduced in June by Chandra Pinapala, Erik Farr, and Karthik Sonti, describes partners building a reusable delivery harness, domain ontologies, evaluation frameworks, MCP servers, a context graph, that grows with each engagement. Then the sentence a buyer should read twice: "The delivery IP stays with the partner. The compounding advantage stays with the partner."
Nothing dishonest in either. But they're different purchases. In one, the engineer's work compounds into a product you'll keep paying for and keep receiving. In the other, it compounds into a consultancy's toolkit. In a third case, the common one, it compounds into your own repository and nowhere else, and you've bought custom software with a vendor's badge on the engineer.
Part 4 split what an FDE may change into the harness and the code. The buyer's version of that contract is one column wider: for each layer, where does the work go? Vendor product, partner harness, or our repo. Write the answer per layer. Then write who owns what's left in your building. Maltaverne's second term is ownership of code, configurations, prompts, and business logic built for the customer. Mukul Saha at Gartner, in the CDOTrends write-up of the prediction, says the statement of work should explicitly cover evaluation datasets, labeled examples, prompt libraries, data mappings, and any model weights tuned on your data.
The eval rows are the one I'd fight for. Part 4 said they're the customer's and they travel with the pull request. They're also the only thing in that list that lets you switch vendors and know on day one whether the new system is worse.
Hours that fall, and the price after the pilot
Maltaverne's fourth term is FDE hours that decline over the contract term. I'd make it the second thing I negotiated.
The economics chapter's one signal for whether the model is working is FDE hours per deployment, quarter over quarter, falling. The vendor should be tracking it. If they are, they can commit to it. Atlassian's twelve weeks is a slope with an end, and a customer engineer on the other side of it. Gottdiener's "in perpetuity" is a flat line. The difference between the two is a number in the contract.
And the number next to it is the one Maltaverne puts fourth on his list of questions: what will FDE support cost after the pilot and after year one? Gartner's "soaring costs" is a renewal story. Vendors who ran the pilot at a loss recover it at renewal, and by then the customer has built twenty workflows on the engineer's configuration and can't walk. Get the year-two price before the pilot starts. If the vendor won't quote it, they're telling you what it is.
The test before they leave, and the question before you sign
Saha's best recommendation is the exit test. Before the exit date, your internal team completes a full release cycle, change request, testing, production, while the vendor's engineers only observe.
That's the keys line from part 6 with a test attached, and I'd move it earlier. Run it thirty days after go-live, while the engineer is still there to watch it fail. If your named counterpart can't ship a change to a prompt or a routing rule and see the rows pass, the engagement isn't done, however many workflows are live. The org design chapter said adoption is a deliverable owned by name. This is how a buyer collects it.
Then the question I'd ask before any of this, and it's Saha's too. Ask the vendor to name three product features that began as customer field work, with examples and dates. Gartner's own forecast is that fewer than 20 percent of FDE engagements through 2028 will turn recurring customer needs into core product. So most vendors won't have three. That's fine to know. Saha's advice when the answers are vague: price and contract the work as ordinary services. I'd add one more question, from part 3: who is the product manager who reads what your engineers send back, and what's the turnaround? A vendor who can't name that person has FDEs and no loop. You'd be paying the product premium for a staffing agency.
What this means in the seat, and at the top
If you're the FDE: the buyer is going to start asking whose codebase your work goes into. Know the answer before they do, and if it's "the partner's harness," know that the customer is about to read it as a reason to pay less.
If you run product at a vendor: get the three features ready. With dates. If you can't, the buyers who read Jonnala this week are going to price you as services, and they'll be right.
If you're the buyer: Jonnala's last line is "We are spending millions sending AI experts to learn business. We should be sending business operators to learn AI." The contract that answers him is the one where the FDE's deliverable is your operator.
One thing to try this week: pull the FDE statement of work on your desk, yours or the one you're being asked to sign, and check it against the six lines. Customer layer ours, including eval rows. Codebase named per layer. Hours that fall. A named counterpart. An independence test. The renewal price. Every blank is a dependency you're about to sign for, and the 7,300 postings say the engineer is already on the way.
Sources: Praveen Jonnala, "Stop sending me engineers: what OpenAI, Anthropic and Microsoft misread about enterprise AI," CIO (October 13, 2026) · Bertrand Maltaverne, "Your vendor's forward-deployed engineer is moving in... Plan the move-out!", Procurement Tidbits (October 19, 2026), with Charlie Gottdiener quoted · CNBC, "AWS, Anthropic race to deploy army of specialized engineers key to proving AI spending will pay off" (October 15, 2026), citing Lightcast · Atlassian, "Atlassian Launches Forward Deployed Engineering Program to Scale Enterprise AI Transformation," Business Wire (October 7, 2026), with Avani Prabhakar quoted · Chandra Pinapala, Erik Farr, and Karthik Sonti, "Introducing Forward Deployed Engineering for Partners: Winning the Future of Enterprise AI," AWS Partner Network Blog (June 30, 2026) · CDOTrends editors, "The Engineers Left Yesterday. Can You Run Your Agents Today?", CDOTrends (October 5, 2026), with Mukul Saha's recommendations · Mukul Saha, "Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028," Gartner (September 29, 2026)
Part of the running argument on AI Product Management: once building is cheap, the scarce work is deciding what gets built for everyone, and the buyer's contract is where you find out whether a vendor is doing that work at all.
Related answer: What should an enterprise put in a forward deployed engineering contract?
Frequently asked
What should an enterprise put in a forward deployed engineering contract?+
Six lines. Ownership of the customer layer, meaning configurations, prompts, data mappings, business logic, and the evaluation rows built on your data. Which codebase the vendor's engineer works in, the vendor's product, a partner's harness, or your repository, per layer. FDE hours that decline over the contract term. A named counterpart on your side whose independence is the deliverable. An independence test before the engineers leave, in which your team runs a full release cycle while the vendor only observes. And the renewal price for FDE support, written before the pilot starts.
Why is an exit clause not enough in an FDE engagement?+
An exit clause gets you out. It doesn't get you what you paid for. In an honest forward deployed model the vendor's product absorbs what its engineers learned on site, so the next quarter needs fewer of their hours. A buyer who only contracts for the exit leaves without the thing the premium was for. Contract for the loop: whose codebase the work goes into, hours that fall, and proof the vendor has shipped field work as product before.
What did Praveen Jonnala mean by backward-deployed domain experts?+
Praveen Jonnala, SVP and CIO at Vistance Networks, wrote in CIO.com on October 13, 2026 that enterprises don't need more forward deployed engineers from vendors, they need their own operators trained in AI, because outside engineers can't own cross-functional trade-offs and the learning leaves with them. His line: 'the lab learns your business. You learn their product.' The contract answer is to make producing that internal operator the FDE's deliverable, with a named counterpart and an independence test.
Who owns the code and prompts a forward deployed engineer builds?+
Whoever the contract says, and the default is often not the customer. AWS's partner-led FDE program states that the delivery IP, including ontologies, evaluation frameworks, and the context graph, stays with the partner. Atlassian's program has its engineers working in Atlassian's codebase so improvements ship to all customers. Mukul Saha at Gartner recommends the statement of work explicitly cover evaluation datasets, labeled examples, prompt libraries, data mappings, and any model weights tuned on your data. Bertrand Maltaverne's contract terms put code, configurations, prompts, and business logic built for the customer in the customer's name.
How do you test whether an FDE engagement left the customer independent?+
Before the exit date, the customer's internal team completes a full release cycle, from change request through testing to production, while the vendor's engineers only observe. That is Mukul Saha's recommendation as reported by CDOTrends. It is the keys line from the month-two handoff page with a test attached: one named person on the customer side can make a change and see the evaluation rows run afterward, without the vendor.
How can a buyer tell a real FDE vendor from a services firm with a new title?+
Ask the vendor to name three product features that began as customer field work, with examples and dates. Mukul Saha at Gartner says if the answers are vague, price and contract the work as ordinary services. The same release predicts that fewer than 20 percent of FDE engagements through 2028 will turn recurring customer needs into core product capabilities, so most vendors will not have an answer, and that is useful to know before signing.
What is The FDE Transition series?+
A twice-weekly series on falkster.com for forward deployed engineers and the leaders building around them. Part 1 is the thesis that the FDE is the Product Builder arriving from services. Parts 3 through 6 cover the handback to product, the codebase contract with engineering, the promise with sales, and month two with customer success. Part 7 is the scorecard, part 8 the career out of the seat, and part 9 comp and equity. Part 10 is the enterprise buyer's side: what to put in the contract. The parts that follow cover when not to hire FDEs and the FDE as the author of the eval.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn