The Forward-Deployed Company, Part 1: Should You Build a Forward-Deployed Engineering Team?

The first part of a new series for the people who have to build forward deployment as an organization, and for the leaders deciding whether to build one at all.

Over the summer I wrote a four-part series called The Forward-Deployed Founder. It was about one person. A seed-stage founder who could run the motion Palantir made famous, embedding with a customer and building inside their real workflow, with AI standing in for the rest of the team. The framework was Land, Harvest, Compound, and the whole thing fit on a laptop.

That series left a bigger group of people without an answer. Think of the VP of engineering whose CEO has just announced an FDE team, the head of customer success told to "become forward-deployed" by next quarter, or the enterprise architect asked to build an internal version. None of them is one founder with a laptop. Each has to build a function, and each is facing the same question: how do we build the machine that runs this motion?

This series is my attempt at an answer. I'm calling it The Forward-Deployed Company. Over eight parts it goes through the decisions you face in roughly the order you face them, from whether to build one at all to how the engagement should end. As with everything I write here, it's a synthesis of what's public plus what I've learned working close to how large companies buy and deploy AI, and I'd rather be corrected than agreed with. It starts with two numbers from the same person.

Two numbers from the same analyst

In August, Gartner's Alex Coqueiro gave CIO Dive a forecast that should have stopped more people than it did. "By the end of 2026, more than 85% of tech providers will have launched FDE programs as the core method for delivering AI and condensing deployment timelines." The core method, which is a much bigger claim than a pilot.

Three months earlier, the same analyst had described what happens on the other side of those programs. By 2028, he told CIO.com, "70% of enterprises will be forced to abandon agentic AI solutions from FDE-led engagements because of high vendor costs and lack of internal skills to evolve them independently."

Read those together. Almost every provider is about to sell forward deployment, and most of the enterprises buying it will walk away from what it built. The reasons Coqueiro gives for the walking away matter more than the percentage. The projects cost too much to keep running, and the customer never learned to run them alone.

In the same CIO.com piece, Sanchit Vir Gogia of Greyhound Research put it more bluntly than I would have: "Forward deployed engineers are the invoice for making AI real," and what a lot of companies are paying for is "dependency with better stationery."

So who are these numbers about? If you run a scale-up selling AI into enterprises, you're very likely one of the 85%, and your customers are the 70%. If you lead technology inside an enterprise, you're the 70%, and the 85% are lining up to sell to you. Either way, forward deployment is coming to your business. What's left to decide is which side of it you're on, and whether you chose that side or drifted into it.

When nearly every provider offers something, offering it stops being an advantage.

There's a second implication in the 85% that's easy to miss. When nearly every provider offers something, offering it stops being an advantage. A year ago, "we'll put engineers inside your business" set a vendor apart. By the end of this year it's table stakes, and the providers who win will be the ones whose embedded work leaves them better at the next customer. That difference is what this series is about.

The supply side has its own constraint too. An executive search firm, Christian & Timbers, estimated in July that there are roughly 17,000 forward-deployed engineers in the US, and only about 2,000 with the expertise to deliver meaningful returns. Over the same six months, the share of companies planning to hire them went from 5–10% to 70%. If you're the supply, talent is your bottleneck long before demand is.

Which side of the floor are you on?

The first series made an argument I still believe. The billions the big labs and cloud providers committed to forward deployment this year were aimed away from startups on purpose, because the enterprise version of the motion has an economic floor. Engineers on planes are expensive, and below roughly $50,000 to $150,000 per engagement the enterprise version stops making sense. That's why Series 1 told seed founders to run the motion themselves at a smaller scale. They weren't a customer the giants wanted.

This series starts from the other side of that floor. If you sell AI into enterprises with contract values comfortably above the floor, you're not a customer for forward deployment. You're the supply. The question "should we do FDE?" means something different for you than it did for the seed founder, and I think a lot of confused strategy comes from treating it as one question.

"FDE for startups" is two questions wearing the same three letters.

• Should you buy forward-deployed help from someone else, a lab's deployment company or a partner, to get your own AI working?

• Should you build a forward-deployed function and sell it to your customers?

For most fundable AI companies past their first few enterprise contracts, the interesting question is the second one. And the answer to the second is where the real decisions start: what you're building, how you'll know it worked, how it's staffed, who it reports to, what you promise in the contract, and how it ends.

When should a company start building that function? The most sensible public answer I've found comes from the venture firm CRV. "The founder should be the first FDE," and a dedicated hire makes sense only "when you've validated the pattern through your own embedded work and need to scale it, not before." CRV puts that point at roughly the first three to five paying enterprise customers. I'd add one condition. Hire when the embedded work has started producing something reusable, not just when it has started producing revenue. Part 3 makes that condition precise.

The same question, from inside the enterprise

I want this series to be useful to a second reader too, the leader inside a large company who is being asked to build a forward-deployed function of their own.

That request is showing up more often. A bank, an insurer, or a manufacturer looks at what the AI vendors are doing, notices that the vendors' engineers learn more about its business in six weeks than its own IT team learned in six years, and asks the obvious question. Why don't we have our own?

The floor applies from your side as well. Which of your processes are valuable enough to justify embedded engineers, and which aren't? And for the ones above the floor, do you buy the motion from a vendor, build it yourself, or borrow it from a partner while you build? Part 4 is a decision guide for exactly that choice, with the trade-offs laid out side by side.

If the capability never moves inside, the day the vendor leaves is the day the system starts to rot.

Coqueiro's forecast is a warning aimed straight at you. "Lack of internal skills to evolve them independently" is another way of saying that the enterprises that only ever buy forward deployment end up renting their AI forever. If the capability never moves inside, the day the vendor leaves is the day the system starts to rot. That's the strongest argument I know for enterprises building at least a small forward-deployed core of their own, even while they buy from outside.

The honest counter-bet

It would be easy to write a series that treats forward deployment as the answer to everything. Plenty of people are writing that series. So before going further, I want to give the strongest opposing case a fair hearing, because some very successful people think this whole motion is a mistake.

One of the loudest is Decagon. The customer-service AI company crossed $100 million in annualized revenue while openly betting against forward-deployed engineers, and Newcomer reported that its CEO, Jesse Zhang, sees reliance on them "as a sign of a weak product." Legion Intelligence, which builds AI for defense, argues from the other end of the market that forward-deployed engineers "should build capability within the product using the same tools available to end users, not outside of it." In Legion's telling, a large FDE team is a symptom that the product never matured.

I think both are right about something important. Forward deployment as a labor model, where you send engineers to do by hand what your product can't do, is a crutch. If every new customer needs the same amount of custom engineering as the last, you've built a consulting firm and priced it like software. The Gogia line applies to vendors too.

But look at what Decagon actually does, because it's more interesting than its slogan. Its own Agent Development team has described how it works, and what it describes is going into the field, finding where each build was needlessly custom, and turning that into product, with a large cost reduction to show for it. Part 3 looks at that closely. The short version is that Decagon still goes into the field. It treats every trip as research for the product, and then does the work of turning the research into software.

So I'd reframe the argument around one question. Does the embedding produce something that makes the next deployment cheaper? If it does, forward deployment is how you build a product nobody else can. If it doesn't, the skeptics are right, and you should listen to them.

A test you can run

Here's how I'd decide, with a leadership team in one room and a whiteboard. Five questions. None need a consultant, and you probably already know most of the answers.

1. Are the deals big enough? Take your typical enterprise contract. Is it comfortably above the floor, or are you hoping forward deployment will justify prices you don't yet charge? Embedded engineers are one of the most expensive ways to deliver software ever invented, and the economics only work when the contract can carry them.

2. Is the "how" genuinely ambiguous? If you already know exactly how your product gets deployed at a new customer, you don't need forward deployment. You need implementation, documentation, and a good customer success team. Forward deployment earns its cost when every customer's version of the problem is different enough that nobody can write the playbook in advance. Be honest here. Many companies call their implementation team FDE because the title is fashionable.

3. Will the customer let you in? Forward deployment requires real access to systems and data, a sponsor with authority to change how work is done, and people who will answer questions the same day. An enterprise that wants to "see what you come up with" from a distance won't give you any of that, and no amount of engineering talent makes up for it.

4. Can you name the number? Every engagement needs one business number that everyone agrees on before the work starts, with a baseline and a date. If you can't name it, you can't prove the engagement worked, and you can't price on outcomes. This question is important enough to get its own Part 2.

5. Can you name what the deployments feed? Put another way, what gets better every time you do this? If the honest answer is "our team's experience," you're building a consulting practice. If the answer is a product, a platform, or what Part 3 will call a system of practice, then you have a reason for the whole motion to exist.

Score it however you like, but notice which questions are hard. I'd expect most teams to sail through the first three and stall on the last two, and that wouldn't be a coincidence. The first three decide whether forward deployment is possible. The last two decide whether it's worth doing.

The forward-deployed company

Series 1 ended with a name for a person, the forward-deployed founder. This series needs a name for an organization.

I'll call it the forward-deployed company. It's a company, vendor, or enterprise whose operating model turns embedded, bespoke work inside customers into capability that compounds. It sends people into the messiest parts of a customer's business on purpose, and it gets measurably better with each new customer because of what it learned from the last one. The embedding isn't the business model. The compounding is.

Most companies calling themselves forward-deployed aren't one yet. They have the embedding without the compounding, which makes them an expensive services firm with a software multiple they haven't earned. The rest of this series is about how to close that gap.

The embedding isn't the business model. The compounding is.

It runs in three acts:

• Act I, what this model is and isn't. What "business outcome" actually means, and how that draws the line against consulting and professional services (Part 2). Then how bespoke work becomes product, and the name of the layer that makes it possible (Part 3).

• Act II, the machine. Where the function lives and what a pod looks like (Part 4), then who you hire and what it all costs (Part 5).

• Act III, what you keep and what you promise. The harvest and the contract that decides whether you can keep it (Part 6), what happens when a pod misses its goal (Part 7), and how the engagement should end (Part 8).

What's next

Everything in this series depends on one idea that the market uses constantly and rarely defines: that forward deployment drives business outcomes. Part 2 takes that phrase apart. What an outcome is, analytically. How to measure it so the result survives an argument. How to contract on it without getting burned. And how a pod can move a number in thirty days while staying accountable to results that take four quarters to show up.

Before then, I want to know which side of the floor you're on, and whether you chose it or drifted there. If you've run the afternoon test, which of the five questions did your team stall on? Reply and tell me. The sharpest answers will shape the parts that follow.

This is Part 1 of The Forward-Deployed Company, a series inside The AI-Native Founder for the people building forward-deployed engineering as an organization. It builds on the startup series. The Forward-Deployed Founder.*

Part 2, How to Define the Outcome a Forward-Deployed Team Is Paid For, is next.