In short: Five of the industry’s largest AI companies committed nearly $9 billion to deployment capabilities in about ten weeks in 2026 – a signal that deployment has become one of the hardest parts of enterprise AI. Lotan Levkowitz, managing partner, and Litan Cherikover, investor at Grove Ventures, argue that the forward deployed engineer function, pioneered by Palantir and now being adopted across major AI companies, cannot be copied from a template and has to be shaped around each company’s own product, customer motion, and organization. Drawing on a closed breakfast series with founders and deployment leaders from Israel’s leading B2B AI companies, they explain how to measure whether the function is working and why Israel is positioned to lead the design of AI deployment work itself.
As companies move from delivering software to delivering code, selling AI into the enterprise is becoming a deployment business. What is still open is what that team looks like inside your company, and Israel is uniquely positioned to answer it.
If you are a founder selling AI into the enterprise this year, you already know the shape of it. The demo goes well. The POC goes well. And then the real work starts, inside the customer, done by your own people. For some companies that is dozens of hours on Zoom. For others it is months on site. Either way it is your team, not the customer’s, and it does not end when the contract is signed. That is not a failure of your product. It is the business now.
The largest AI companies are betting on it with their own money. In ten weeks this summer OpenAI put $4 billion into a standalone deployment company, Microsoft $2.5 billion and 6,000 people, Anthropic and Blackstone $1.5 billion, AWS $1 billion, and Google Cloud began hiring hundreds. $9 billion, from companies that agree on almost nothing.
What they understood is simple: the model was never the hard part. When the contract is signed, nobody has yet decided what the technology should actually do. The executive who signed does not do the work, and the team that does will describe a workflow that is not the one they follow. You are not deploying into a company, you are deploying into how one team gets through its day. Feeding the model more documents does not fix that. Someone from your side has to sit with them, decide what the system does, and own whether it works.
Some of the best founders we know will not use the name for this. They hear “forward deployed engineer” as an admission that the product cannot stand on its own, and they say so out loud. Look at who those same companies actually hire, though, and the resistance doesn’t hold up: technical account managers, integration engineers, product people who spend more time in customer offices than at their own desks. Palantir invented the role and shortened it to FDE. Almost everyone does the work today. Almost nobody wants the name.
None of this is new to a founder. In almost every company the founders did this work themselves before anyone had a title for it, sitting with the first customers and discovering the product while building it. That is the honest starting point: the founding team was the first deployment team. The question is not whether to build the function. It is how to reproduce what you already do, once you can no longer be in every room yourself.
You cannot hire more founders, which is why this never used to scale. What is new is that the founder motion has become repeatable. A small deployment team can now carry the same motion, with agents doing the repetitive half of the work, which makes it far lighter to stand up than it was three years ago.
Over the summer we ran a closed breakfast series with founders and deployment leaders from Israel’s leading B2B AI companies. We asked who wished they had started this earlier. Every hand went up. If you are building now, everyone ahead of you thinks they were late.
The second finding is less obvious. No two of those companies had built the function the same way: different reporting lines, different seniority, different points in the sales cycle. That is why the instinct to copy Palantir is a mistake. Bob McGrew, who ran product at Palantir in the years it built the model, answers founders who ask how to copy it with one word: don’t. There is no template, only the question of what shape yours should take.
The received wisdom is that this only works at Palantir prices. Colin Anderson, Palantir’s former CFO, puts the floor near a million dollars a customer, and below that you are lighting equity on fire. What surprised us is how far below that line it still works. We have seen the same motion, in a lighter form, run successfully in low six-figure deals. That moves the floor by an order of magnitude, and with it the number of companies that should be building this.
One line from those breakfasts we hosted stuck with us: the old, orderly triangle of customer, product and engineering has turned chaotic. Deployment now sits in the middle, pulled by all three, and no two companies balance it the same way. Three lessons follow, and the first is uncomfortable. None of them tells you where to sit. They tell you what to fix first.
First: you do not choose how your deployment team spends its time. Your company chooses for you. Wherever it is weakest, the team gets pulled in to cover the gap. If your head of product is not deciding the roadmap, your deployment engineer will. If nobody owns the customer relationship, they will own that too. So look at where your deployment people actually spent last week. It is a free X-ray of your company, and it usually shows something you would rather not see.
Second: the mix has to move from bespoke to product. In year one the work is built for specific customers. By year three most of it should ship to everyone. The rule of thumb we heard: a request that shows up across five or six accounts gets built into the product, a one-off stays inside that account. If year three still looks like year one, you are not a software company with a deployment team. You are a consulting firm whose consultants have engineering titles.
Third: each corner of the triangle is a trap. Pulled to the customer, the team builds only what that account asked for, and none of it comes back to the product. Pulled to product, it generalises too early, turning one account’s request into a platform feature nobody else has asked for. Pulled to engineering, it stops sitting with customers and works from tickets, and the knowledge that made the function worth having disappears.
The measure is simple: engineer-weeks per deployment. Your first deployment costs whatever it costs, one engineer, full time, until it works. After that the number has to fall twice. A second use case at the same customer should cost less, because you already know their stack, their security review and who approves what. The same use case at the next customer should cost less, because your team has met that integration and that objection before, and later because the product absorbed it. If the number never falls, you do not have a product, you have a services business with a good story. The engagement should also be able to end. If your engineers can never hand over and move on, the cost is not an investment, it is cost of goods.
The people who can do this are scarce everywhere: postings for the role grew eightfold last year, and pay has followed. Israel produces that profile in unusual numbers. Every year its intelligence units release engineers who have already done applied AI and large-scale data work on messy inputs, under time pressure, with nobody handing them a spec. That is not a cultural claim, it is the job description.
Your customers are not in Israel. The deployment engineers who sit with them will be hired near them, wherever that is. What Israel can own is upstream: the people who design how deployment works, who decide what gets productised and what stays inside one account, and who set the standard those teams are trained to. Build that here. Hire the engineers where your customers are. Israel should lead this category rather than try to house it.
A deployment engineer is a founder in rehearsal, walking into a mess with no spec and owning the result. When these teams describe who they hire, they are reading back the checklist we use as investors. Palantir’s alumni have founded 111 companies that have raised $11.6 billion between them, and the flow runs both ways: at Ramp, seven of sixteen deployment engineers are former founders. Someone in our breakfast called it the best founder school, which is a hiring pitch and an attrition risk at once. We think the attrition is the point. If the bench produces founders, the flow out is the asset, not the leak, and we spend our days looking for those people before they have a company.
What came out of those breakfasts was worth more than we expected, and more companies are running the same experiment every month, mostly in private and mostly alone. So we will keep convening them, with a series of sessions over the coming months to carry what the early ones learned to the ones starting now. Deployment is where enterprise AI is won. We think Israel can be the ecosystem that wins it.
FAQs
A: A forward deployed engineer is a technical role responsible for deploying an AI product inside a customer’s enterprise environment. FDEs work closely with the customer to understand how the technology should fit into real workflows, handle integration and implementation challenges, and take ownership of making the deployment work in practice. Palantir pioneered the role, but many AI companies now perform similar work under titles such as technical account manager, integration engineer, or product engineer.
A: Engineer-weeks per deployment measures how much engineering time a company needs to complete a customer deployment. The first deployment may take as long as it takes to work, but after that the number should fall in two ways: a second use case at the same customer should require less effort because the team already understands the customer’s stack, security process, and approvals, and the same use case at a new customer should require less effort because the team has already handled similar integrations and objections. If that effort does not decline over time, the company risks operating more like a services business than a scalable software company.
A: Bob McGrew, who ran product at Palantir during the years it built its FDE model, argues that there is no single template to copy. In Grove Ventures’ conversations with founders and deployment leaders, no two companies had structured the function in the same way. Reporting lines, seniority, and where deployment enters the customer journey all varied, so each company has to design the function around its own product, customers, and organization.
A: Israel produces engineers with experience in applied AI, large-scale data, messy inputs, and high-pressure environments where there is often no clear specification. The argument is not that all deployment engineers should sit in Israel. Customer-facing teams should often be hired close to the customers they serve. Israel’s opportunity is upstream: designing how deployment works, deciding what should become part of the product versus remain specific to one customer, and setting the practices that deployment teams elsewhere can follow.
