Who Should Build Your AI System, and Why Consider a Forward Deployed Engineer?

If you’ve already worked out where AI makes sense in retail, what implementation challenges can arise, and what defines AI readiness of your e-commerce stack, one decision remains: who is going to build it?

That question is one reason a forward deployed engineer keeps coming up in AI conversations. The role puts an engineer directly inside the client’s technical environment and keeps them with the project through implementation and production rollout.

The same work can stay with an internal team or go to a consultancy. The right setup depends on the expertise already in-house, how much implementation is still ahead, and how closely the people doing the work need to operate inside the company’s systems.

That’s what we’ll work through here: where each setup fits and whether a forward deployed engineer belongs in the project you already have in mind.

Who is a forward deployed engineer?

A forward deployed engineer (FDE) works closely with a client team to get a specific system into production. The role can cover data access, integrations, application logic, deployment, and whatever else that project needs to work in the client’s environment.

That scope is what makes the role unusual. A conventional engineer is usually responsible for a defined part of a product. An FDE is assigned to a client problem, so the work can cross several parts of the system.

The model is most closely associated with Palantir, which popularized forward deployed engineering through engineers working directly with customers. By 2026, the term had spread across the AI industry, with OpenAI and Anthropic hiring FDEs, AWS launching its own Forward Deployed Engineering organization, and Microsoft introducing a similar embedded engineering model.

At product companies such as Palantir and OpenAI, what engineers learn during customer deployments can also feed back into the product or model roadmap. That part varies by employer, which is one reason FDE roles can look different from company to company.

How does an FDE differ from other engineering and client-facing jobs?

The easiest way to tell these roles apart is to look at what each person is expected to carry through the project.

There can be plenty of overlap. A solutions architect may write code, a consultant may stay through delivery, and an AI engineer may work directly with customers. The title alone tells you less than the actual responsibilities attached to it.

Once that distinction is clear, the bigger decision is how to staff the implementation: internally, through a consultancy, or with an embedded engineering team.

Three ways to staff AI implementation

The implementation can sit with an internal team, a consultancy, or an embedded engineering team. Your AI team structure affects where project knowledge stays, how quickly work can start, and who remains responsible after launch. Let’s take a closer look at each option. 

An internal team

If the people who will build the AI system already work inside the company, they start with an advantage: they know the systems, the data, the people who own them, and the decisions that shaped the current setup. There is also no handover at the end. The same team that builds the system stays responsible for it afterward.

The catch is hiring. If the required expertise is missing in-house, recruiting can delay the start of AI/ML development. The AI talent shortage is already showing up in hiring data: AI and machine learning were among the hardest technical roles to fill in 2026.

Keeping the work in-house makes the most sense when the company already has most of the required expertise and expects the system to become a long-term part of its product or operations. In that case, building the capability inside the team can pay off well beyond the first release.

A consultancy

A consultancy can be useful when the project still needs a second set of eyes. It can structure discovery, test early assumptions, and turn a broad AI idea into decisions the company can act on.

The difficulty comes with continuity. If the engagement ends with the strategy, the people who shaped the plan are not the people building it. Context has to be handed over, questions may reopen, and another team has to turn the recommendations into working software.

This model makes sense when the main job is to decide what should happen next and there is already an engineering team ready to carry the work forward.

An embedded engineer

An embedded engineer stays with the project through implementation. They join the client’s day-to-day work, use the same project channels and meetings, and get access to the codebase, systems, and data needed for the build. Embedded engineering is the setup; the forward deployed engineer is the role working inside it.

That access makes everyday decisions easier. If something depends on a business rule or the way a system behaves, the engineer can go straight to the person who owns that area and use the answer in the work right away.

For the same reason, someone inside the company needs to stay involved throughout the project. They help with access and business decisions, bring in the right people, and follow the work closely enough to take it over later.

The handover then happens gradually through shared code, documentation, reviews, and walkthroughs. If no one on the client side is ready to take that knowledge on, the project becomes much harder to carry forward once the embedded engineer leaves.

That dependence on the client team is easier to see in a real project. E-commerce development is a good example because even one AI feature can involve several systems and teams, so let’s follow one from the first brief to handover.

Forward-deployed engineer in e-commerce

Take a common e-commerce brief: reduce repetitive customer service work around order status and returns. To get that feature into production, the engineer first needs to see where order data lives, how return rules are applied, which actions the storefront can expose, and what customer data the AI can use.

If the store runs on Salesforce Commerce Cloud or BigCommerce, the platform team gives the engineer access to the store environment, codebase, APIs, and existing integrations. The team that manages an enterprise resource planning (ERP) or order management system (OMS) provides order data. Merchandising explains product rules and exceptions. Customer service opens the support tools and shows which order or return cases take the most manual work.

If return eligibility depends on product type, purchase date, shipping region, and current order status, the engineer can confirm those rules with the people who own them before coding the flow.

The same group stays involved as the feature moves toward launch. The code stays in the client’s repositories, technical decisions are documented, and internal engineers join reviews and walkthroughs. By handover, they know where the feature gets its data, how its rules work, how to change them, and who owns each dependency.

For this setup to work, access and internal ownership have to be available during the build. If the platform team cannot grant access, OMS ownership is unclear, or no internal engineer follows the feature through reviews, the build stalls or the handover leaves key knowledge with the embedded engineer.

The last question is who builds it

At the start, we left one question on the table: once the use case is clear and the stack is ready, who is actually going to build the system?

By now, the answer depends on three things: 

1. What expertise already exists inside the company.
2. How much implementation work is still ahead.
3. How closely the engineer needs to work with the systems and people behind the project.

That is also why forward deployed engineering has become part of the conversation around how to build an AI team. It gives companies another way to staff implementation when the work needs to happen inside the existing technical environment and stay close to the people who will own it later.

If you are already at the “who builds it?” stage and looking for an AI implementation partner, we can talk through the use case and see whether an embedded setup fits the project.