FDE vs. Traditional Systems Integrators (SI): 5 key differences and when to choose each

FDE (Forward-Deployed Engineering) is a delivery model where engineers embed on-site with customers, moving enterprise AI from demo through production and actual adoption. Traditional systems integrators (SI) deliver to specification, hand over a system that passes acceptance, and consider the engagement complete once it goes live. Comparing FDE to SI doesn't come down to whose technology is better. It's whether you're buying a deliverable or a result: a system that goes live and people actually use.

A real situation

Late last year we picked up a manufacturing project. The year before, the customer had hired a well-known SI to deploy an AI quality-inspection system. Acceptance day looked perfect; every metric hit. Contract closed, final payment cleared, system went live.

Six months later, I'm at the site and the line operators are still doing visual inspection by eye. The system's determinations function as a reference, not a decision-maker. Actual adoption rate under 20 percent. The system wasn't broken, and the SI hadn't breached anything; what they delivered matched the spec perfectly. Except the spec never said anything about getting the operators to trust it and actually step back.

This is where FDE and SI differ most. Technology isn't the issue. The differences come down to three dimensions: delivery model, risk ownership, and edge cases.

Three axes: FDE vs. SI

Axis	Traditional SI	FDE
Delivery Model	Deliver to spec, acceptance closes the contract; waterfall, milestone-driven	Engineers embed on-site, iterate with business processes; the deliverable is "results being used"
Success Defined As	System passes UAT, features meet spec	People use it daily post-launch; adoption and business metrics achieved
Risk Ownership	Out-of-scope issues become change orders; adoption risk falls to customer	Take on go-live and adoption risk; we own the failure too
Edge Cases	Standard flows first, exceptions get custom quotes	Edge cases are the focus; we surface what's unusual on-site
Data and Knowledge	Build with provided data; missing data blocks progress	We fill in tacit knowledge, clean dirty data, codify unwritten rules
Team Placement	Primarily remote, requirements handled through liaisons	Embedded with your team, sitting next to the users
Contract Focus	One-time delivery + operations SLA	Shared ownership through adoption, then handoff

Delivery model: a system or a result?

The SI business model rests on a clear spec. That's their strength; scope is defined, pricing is defined, acceptance is defined. But enterprise AI's difficulty is that the variables that actually determine success usually can't go in the spec: whether users will change their habits, how the model handles messy data, how exception workflows get routed.

FDE assumes the spec is wrong from the start. Engineers come in, watch the real workflow, then build while they iterate. The deliverable isn't a system that passes acceptance. It's a state where people are using it and the metrics are moving.

Risk ownership: who's responsible for adoption?

This dimension is often overlooked and remarkably expensive.

In an SI contract, adoption usually isn't in the promise. The system runs, the features work, responsibility ends. Whether employees actually use it becomes an organizational change issue, separate from the SI's scope.

FDE takes that on. Our position is direct: a beautiful demo doesn't count. What counts is people using it after launch. That means we assume the risk; if adoption is 4% three months in, that's on us, not customer resistance. That kind of ownership requires different work: you investigate why the operator doesn't trust the system instead of writing it into the closeout report.

Edge cases: where standard solutions die

SIs are good at nailing 80 percent of standard workflow. The remaining 20 percent of exceptions usually become custom quotes or get scoped out entirely.

The reality is that AI projects often fail in that 20 percent. That manufacturer's line had a batch of older material with surface reflections that made the vision model misfire; nothing that shows up in any spec, only in real work. FDE's value is having someone on the ground, uncovering every 'we do it different here' spot and building it into the system.

When to choose each

SIs work well when what you're deploying is mature, standardized, and well-specified; ERP modules, standard reporting, existing software. They're fast and cost-effective. Using FDE in these cases would be unnecessary overhead.

But if this is an AI project where the outcome isn't clear, it depends heavily on site-specific knowledge, and whether people actually adopt it is make-or-break; Copilot rollouts, agentic workflows, RAG knowledge systems; you need someone sharing the risk with you all the way through adoption.

That's how Tenten does FDE: we don't hand off an accepted system and leave. We put engineers in your shop, we watch adoption climb, and only then do we step back.