Forward Deployed Engineers vs Hiring an In-House AI Team

Your CEO wants an AI agent in the product by next quarter. An AI agent is software that uses an AI model to carry out tasks, not just answer questions. Your engineers are strong, but none of them has shipped one.

Then the vendor whose AI model or platform you plan to use offers to send forward deployed engineers. These are the vendor's own engineers. They sit with your team and build the agent on your systems. It sounds like the fastest way in, and it often is.

The harder question comes later: when they leave, can your team still change what they built? This guide compares three options. The first is a vendor's forward deployed engineers. The second is an embedded partner team: a services firm's engineers who join your team for a set period, then hand over. The third is hiring your own. It covers who owns the work, how the cost behaves over time, and what to settle before you sign.

What are forward deployed engineers, and should you use them?

Forward deployed engineers are a vendor's engineers who join your team to build and deploy AI on your own systems. They get a first version live fast. The risk comes later: Gartner expects 70% of enterprises to abandon AI agents built this way by 2028. Use them only once IP ownership, knowledge transfer and the exit plan are settled.

Put simply:

Forward deployed engineers buy you speed. The contract decides whether you keep what they build.

What is the forward deployed engineering model?

The role started at Palantir in the early 2010s. In Palantir's own description, quoted by The Pragmatic Engineer (August 2025), a normal developer works on one capability for many customers. A forward deployed engineer works on one customer with many capabilities.

AI companies have adopted it. OpenAI's job advert says its forward deployed engineers lead end-to-end deployments of its models in production with its most strategic customers (OpenAI careers, read November 2026). The Pragmatic Engineer adds that they write code directly on the customer's systems.

Forward deployed engineering (FDE) is the delivery model around that role. In the vendor version, the vendor's engineers work directly with customers to build and deploy solutions. Watch for FDE washing: providers putting the label on ordinary consulting or implementation work.

Remember who pays them. Many startups that employ forward deployed engineers also use them to help win customers. That is fine, but their employer's goals are not yours.

Why does Gartner expect 70% of vendor FDE projects to be abandoned?

On 29 September 2026, Gartner predicted that by 2028, 70% of enterprises will abandon agentic AI (its term for AI agents) built by vendor forward deployed engineering. Its two reasons: costs climb, and customers can't change the system on their own.

Picture month six. The agent worked on launch day. Then a new product line needs new rules. A cheaper AI model comes out. Customers ask for something the agent wasn't built to do.

If the people who understand the agent work for the vendor, every one of those changes goes back to the vendor. You pay their rates for as long as the agent runs, or you let it decay.

The report says these engagements often fail structurally before they fail technically. Analyst Mukul Saha says the best ones agree governance, IP ownership, knowledge transfer and an exit strategy from day one.

The report adds one more number. Through 2028, fewer than 20% of FDE engagements will turn a customer's recurring needs into features of the vendor's core product. Our reading: most of what gets built stays custom to you, and someone has to look after it.

Settle who owns the agent before the build starts, not after launch.

Forward deployed engineers vs an embedded team vs hiring: how do they compare?

Two terms first. Evals are the test cases that check whether the agent's answers are right. A runbook is the written instructions for running and fixing the agent day to day. Whoever holds both can change the agent safely. We cover how an AI-native team works elsewhere.

Side by side

The two outside options carry the same risk. What differs is who the engineers work for, and whether the vendor also wants to sell you its product.

Choose by how central the AI is

1. The work sets up the vendor's own product. Vendor forward deployed engineers fit, because the expertise you need is theirs. Still write the exit plan.
2. The AI is a feature you will keep changing. An embedded team can ship the first version, teach your engineers as it goes, then hand over.
3. The AI is your product. Hire an in-house AI team. Outside help can get you started, but the core skills must live with you.

When does each option make sense?

Vendor forward deployed engineers

The report's advice is narrow. Use FDE only for problems that need deep product expertise, fast adaptation, or close integration between the vendor's technology and your own systems.

Say you have chosen a vendor's agent platform and need it wired into your billing system. The people who know that platform best work for the vendor. Paying them to set it up can beat months of your team learning it alone. Don't use them when the agent is the core of your product.

Hiring an in-house AI team

If AI agents are the heart of your product, hire. The skills that decide whether your product works should belong to you.

In our experience, one AI engineer is rarely enough. A first agent feature needs three kinds of skill. Someone owns the architecture. Engineers build the agent and its connections to your systems. Someone owns the evals.

For a sense of the market, look at OpenAI's advert. As of November 2026, it offers a base salary of US$185,000 to $300,000 plus equity for a forward deployed engineer in San Francisco. It asks for 5+ years of experience. Don't hire first if you need something live this quarter and haven't found the people.

No outside team at all

• The feature is small and well documented. In our experience, a strong engineer can build a simple question-answering feature from a model provider's documentation.
• You can't name an owner. If nobody on your side will own the agent after launch, any outside team will leave you dependent. Fix that first.
• You aren't sure AI belongs in the product. Run a short, fixed-scope trial before committing to anyone for months.

How do you settle IP ownership, knowledge transfer and the exit plan before signing?

A good engagement has three phases: before signing, during the work, and the exit. The same steps work for any outside team, including ours.

Before signing

1. Write down why you need them. Name the problem and the expertise you lack. If you only need more hands for ordinary, well-specified software work, a standard services contract may fit better.
2. Put ownership in the contract. Name IP ownership of the code, the prompts, the eval set, the agent's settings and the documentation. Add knowledge transfer and an exit plan with a date. This is not legal advice, so have your lawyer review it.

During the work

3. They build in your tools, with your engineers. Embed the outside engineers with your domain experts, engineers and end users, so knowledge is shared as the work happens.
4. You own the eval set and approve each release. If your team writes and marks the test cases, the definition of a right answer stays with you. Our guide to AI evaluation explains how these tests work.

At the exit

5. They hand over and step back. You get documentation and the runbook. Your engineers run the last few releases while the outside team watches.
6. Your team ships a change alone, on the planned date. Carry out the exit plan agreed at the start. Don't extend the engagement because your team isn't ready.

How we plan knowledge transfer: Avesta AgentOS experience, your systems

We work as an embedded team, so this is the model we know best. Our engineers built and run Avesta AgentOS, our platform for running AI agents in production.

That experience comes with the team. We build your AI agents on your existing systems, and you own their code and prompts. You also keep the final call on what ships.

Our pods (small teams that join yours) have three roles. A product engineering lead owns the architecture. AI product engineers build the agents and product features. An evals and quality engineer builds the test suites and the checks every release must pass.

Two patterns from public case studies are worth copying with any partner:

• Let the client write the test set. India Avenue supplied 50 real questions and marked every answer right or wrong. Those questions became the test suite, and every change still runs against them. Because the client wrote them, the standard for a right answer is theirs, and it stays with them whoever builds next.
• Pilot small, and let the client decide. With OnlyFacts, a short discovery led to a working pilot in under 3 weeks. The decision to go further was theirs. The same release checks now let them move to a newer Claude model the week it lands, with proof the answers didn't change.

In the end, your own people need to own the agent. Hold us to the same six steps.

The bottom line

Forward deployed engineers, an embedded team and an in-house hire can all get an agent built. They differ in who can change it afterwards. Pick the model by how central the AI is to your product. Then put ownership and the exit plan in writing before anyone writes code.

If you already work with an outsourcing partner, read why your outsourcing partner can't build your AI product next.

If the team that built your agent left tomorrow, could your engineers ship the next change?

---

Want AI agents in your product, built by a team you can hold to these six steps?

AI-native product engineering at Avesta Labs

Get started: hello@avestalabs.ai