Forward Deployed Engineers Are a Symptom, Not a Solution

When a company sends an engineer to sit with your team for three weeks and wire AI into your workflows by hand, that is not a service. It is a workaround.

OpenAI recently announced its Deployment Company. The pitch: OpenAI engineers embed with your team, learn your processes, and build the integrations that turn a chat interface into something useful at work. Palantir built its entire business on this model. Now the labs are doing it too.

I understand why. If your product is a chat interface bolted onto a model, most teams have no idea how to turn that into actual work. Someone has to show up and translate.

But here is the part that does not get said out loud: needing a forward deployed engineer is not a feature. It is an admission. It means the product was not built for the way people actually work. It was built for a demo.

Key Takeaways

• Forward deployment is a symptom, not a solution. It signals the product was not built for real workflows.
• The model layer and software layer are converging at the same companies, creating a new kind of double lock-in.
• The software layer should be independent of the model layer. Switching models should not require rebuilding your setup.
• Lava connects your AI agent to the tools you already use, across any model, without an engineer on-site.

What Forward Deployment Actually Costs

The sticker price of forward deployment is not the problem. It is the ongoing cost.

A three-week engagement gets you integrations. But integrations with what? Your current tools, your current workflows, your current model. Every time a new model releases, every time you add a new SaaS tool, every time a process changes, you are back to the start. The integration is not yours. The engineer who built it is not yours. The knowledge of how it works often walks out with them.

Teams that go through this process once often describe the same experience: months of planning, weeks of on-site work, a working prototype at the end, and then a slow drift back toward the old way of doing things as the integrations break down and no one knows how to maintain them.

This is not a knock on the engineers. They are good at what they do. The problem is structural. A product that requires expert intervention to deliver value has a scaling problem baked into its design.

The Double Lock-In Nobody Is Talking About

There is a second problem emerging that is more consequential than the deployment issue alone.

The companies selling you the model and the companies selling you the software layer are increasingly the same company. OpenAI builds models and now builds deployment services. Google builds Gemini and builds Workspace integrations. Microsoft builds Azure OpenAI and builds Copilot.

When your workflows are wired directly into one model provider's software, switching models means rebuilding your workflows. Switching software means retraining your team. You end up stuck twice.

This was not always the case. Three years ago, the model layer and the software layer were separate markets. Model providers built foundational capabilities. Tool companies built on top of them. The lines are blurring fast, and the teams being sold bundled solutions today may not fully understand what they are agreeing to.

The Bet We Made

We have made the opposite bet at Lava.

Our goal is that one person on your team signs up, connects the tools you already use, and it works. No integration sprint. No engineer flown in to hold your hand for three weeks. You log in and your agent is already looking at the same screen you are.

This is a harder engineering problem. It is much easier to send an engineer to wire up a specific set of integrations for a specific customer. It is harder to build a product that works for the general case, across arbitrary tools, without a multi-week deployment.

We think the harder problem is the right one to solve.

Why the Software Layer Should Be Independent

We also think the software layer should be independent of the model layer.

Use Claude. Use OpenAI. Use whatever new model shows up next quarter that is suddenly the best price-to-performance option in the market. None of that should require an engineer flying out to redo your setup. The model you run on is an implementation detail, not a product decision that locks you in for years.

This matters more as the market moves faster. New models release on shorter cycles. Pricing shifts. A model that was the obvious choice six months ago may not be the obvious choice today. Teams that are locked into a single model provider's ecosystem feel this acutely, because switching is not a configuration change. It is a project.

The right architecture keeps the model choice lightweight. You should be able to switch in an afternoon, not a quarter.

The Real Question

The question that does not get asked enough is not who has the best forward deployment team. The question is why deployment needs a team at all.

If a product genuinely integrates with how your team works, you should not need a specialist to make it useful. You should be able to open it, connect your tools, and get to work. The fact that this is rare, that most AI products require significant human effort to deliver value, is not a fact about the difficulty of the problem. It is a fact about where most products are investing.

The forward deployment model will scale for some customers. Large enterprises with specific workflows and the budget to pay for white-glove implementation will continue to use it. But most teams do not have that budget, and more importantly, they do not want that dependency.

They want a tool that works on its own.

The bottom line: Forward deployed engineers are a response to products that do not work out of the box. The answer is not better deployment. It is better products.

How Lava Helps

Lava is the workspace that connects your AI agent to the tools you already use, across any model, without an engineer on-site.

You sign in, connect the apps your team already uses, and describe what you want done. Your agent can work across Gmail, Slack, Salesforce, Notion, and hundreds of other tools through a single interface. Switch models without switching workflows. Add a new tool without a new integration project.

Lava for Teams extends this to organizations that want a shared agent across their entire stack, with centralized controls and spending visibility.

No deployment sprint. No expert on-site. No lock-in.