Platform Team vs Embedded AI Engineers: Where People Sit

A platform team builds shared capability; embedded engineers build domain knowledge. Both are necessary. This guide covers the arrangement, drawing on FISTA Solutions' AI enablement and staff augmentation work.

What does each arrangement give you?

The trade between leverage and context.

Dimension	Platform team	Embedded engineers
Shared infrastructure	Built once	Rebuilt per team
Domain knowledge	Limited	Deep
Expertise concentration	High	Spread thin
Delivery speed for a product	Depends on platform fit	Fast
Consistency	High	Varies
Risk of building unused things	High	Low

What should a platform team own?

The things every AI project needs and nobody should build twice.

Evaluation infrastructure, system connectors, deployment patterns, observability defaults, cost attribution, and governance controls. Each is substantial engineering with no product-specific content.

That is genuine leverage once three or four teams are building. Before that, the platform has no users and the effort is premature. See the industrialization of AI delivery.

What does embedding produce?

Systems that fit the work, because the engineer understands it.

An engineer sitting with the claims team learns which cases are unusual, what the exceptions are, and what a correct outcome looks like. That knowledge is the scarce input and it does not transfer through requirements documents.

It also means the evaluation criteria get defined properly, because the person building understands what is being measured. See why evaluation is the new moat.

Why do platform teams disconnect?

Because they optimise for what they can see.

A team building infrastructure without delivering anything builds what it imagines product teams need. Product teams find it does not fit, work around it, and the organisation funds both the platform and the workarounds.

The symptom is a platform with low adoption and teams building their own versions. That is a structural problem, not a communication one.

Why does pure embedding duplicate?

Because each team faces the same problems independently.

Three teams each build an evaluation harness, three sets of connectors, and three deployment patterns, all slightly different. The cost is three times the work and inconsistency that complicates governance.

It also spreads scarce AI expertise thinly. One experienced engineer per team learns less than a group learning together. See why AI talent markets are restructuring.

How does rotation fix both?

By keeping platform engineers close to delivery.

When platform engineers spend a period embedded in a product team, they experience the platform as users do and return with concrete knowledge of what is missing. The platform stays grounded.

It also spreads expertise: the product team gains an experienced engineer temporarily, and the platform gains domain understanding. It requires deliberate scheduling and it is the mechanism that makes the structure work.

What is the right sequence?

Embedded first, platform extracted later.

Build the first two or three systems with engineers embedded in the business. Notice what repeated. Extract those into a platform and require it thereafter.

Extraction from real projects produces infrastructure that fits. Design in advance usually does not, which is why platform-first organisations end up with unused platforms.

How do you run your own comparison?

Measure how much of each new project is rebuilt from scratch. If teams are rebuilding evaluation harnesses and connectors, the platform is missing or not fit.

Also measure platform adoption. Low adoption with high investment means the disconnection problem, which rotation addresses.

What does switching cost later?

Extracting a platform from embedded work is natural once patterns exist. Dismantling a disconnected platform is harder, because the investment is sunk and the ownership is established.

Starting embedded keeps the sequence cheap.

What do people get wrong here?

Building a platform before there are users. Embedding without extracting shared components. No rotation. Platform teams measured on shipping infrastructure rather than on adoption. And scarce expertise spread one person per team.

How does this interact with governance structure?

Closely. Shared governance infrastructure is a platform responsibility, and it is what makes federated execution safe.

A platform team owning logging, retention, and permission enforcement means product teams inherit compliance rather than implementing it, which removes the central review bottleneck. See centralized vs federated AI governance.

Which should you choose?

Start with engineers embedded in the business. Extract a small platform team once patterns repeat across three or four projects, and rotate platform engineers through delivery so the platform stays grounded in what teams actually need.

What should you do first?

Count how many separate evaluation harnesses exist in your organisation. More than one is the signal to extract a platform.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: engineers embedded with the business first and shared components extracted once patterns repeat, with rotation keeping platform work grounded in delivery, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To run this comparison against your own workload, message FISTA on WhatsApp, or read the industrialization of AI delivery.