Role and delivery model
Forward Deployed Engineer: the engineer closest to the business
A Forward Deployed Engineer (FDE) works directly with business teams to turn an operational problem into a system that can be used in production. The role goes beyond advisory work: the FDE maps the workflow, connects data and tools, builds, tests with users and measures the result.
How the embedded model works
The FDE works inside the company’s delivery loop, with the people who run the process, data owners and IT. This proximity shortens the distance between a stated need, the system’s actual behaviour and the exceptions found during testing.
The FDE does not replace the business owner, who decides the expected result, or IT, which retains its architecture and access rules. The role connects them: a business decision becomes a testable rule, a technical constraint becomes a clear trade-off, and user feedback returns directly to the build.
From workflow to a production system
The work progresses through verifiable decisions. Each step produces something the team can review, test or operate.
01
Understand the process
Follow the work with the people who perform it and identify inputs, decisions, exceptions and manual rework.
02
Map data and tools
Identify useful sources, quality, access rights, APIs, exports and the systems that remain authoritative.
03
Define a testable scope
Choose one part of the workflow, its users and the criteria that show whether the system helps.
04
Build and integrate
Assemble AI and software components in the intended environment, with the necessary controls around data and outputs.
05
Test real cases
Let users try the system, document errors and exceptions, and correct them before expanding usage.
06
Move to production and measure
Organise deployment, monitoring, operating responsibilities and the measurement agreed at the start.
FDE, consultant, engineer and delivery partner: who owns what?
| Role | Starting point | Main responsibility | Typical boundary |
|---|---|---|---|
| Consultant | A problem to frame | Analysis, recommendations and direction | Does not necessarily build the system |
| AI engineer | A defined technical need | AI components, evaluation and production | May be removed from the business workflow |
| Software engineer | A product scope | Reliable, maintainable software | Does not always own problem discovery |
| Freelancer | An engagement and deliverables | Independent execution of a scope | Supervision and continuity depend on the contract |
| IT services / traditional project | A specification and a team | Delivery capacity and project governance | Field feedback often crosses several intermediaries |
| Forward Deployed Engineer | An operational problem to transform | The full loop across business, integration, build, tests and usage | Requires available users and organised access |
When an FDE is useful, and when it is not
The model fits when…
- the use case depends on exceptions only frontline users know;
- the solution must connect several tools, data sources or business rules;
- users can test the work regularly;
- a business owner can decide scope and expected results;
- the company wants to learn from one system before expanding.
Another model is better when…
- a standard product already covers the need;
- nobody can provide access to data, tools or users;
- the project is limited to a study, with no intent to build or operate;
- the scope is stable and an internal team already has the required capacity.
The skills that define the role
The role requires a combination. A gap in any one area breaks the delivery loop, even when the others are strong.
Software engineering
Write, review, test, deploy and maintain code inside an existing environment.
Data and integration
Work with SQL, APIs, pipelines, exchange formats, permissions and data quality.
Applied AI
Choose an approach, build evaluations, handle errors and monitor cost and behaviour.
Process analysis
Separate the documented procedure from actual work and choose where intervention is useful.
Communication and trade-offs
Clarify a rule, explain a constraint, record a decision and obtain actionable feedback.
Production operations
Define monitoring, incident ownership, escalation and required documentation.
AI Makers
A practice backed by systems already delivered
AI Makers draws on company-wide experience from more than 200 systems deployed across all engagement models. This figure describes the firm’s overall delivery experience, not 200 FDE engagements. For an FDE, it helps identify recurring problems: incomplete access, changing data formats, missing exceptions, late evaluation and undefined operating ownership.
It never replaces studying the client’s context. It provides checkpoints and playbooks that the engineer adapts to the company’s process, tools and rules.
Understand the role before choosing a delivery model
This page defines the role and how it works. A diagnostic starts with the workflow, its users, data and operating constraints before deciding whether an embedded engineer is appropriate.
Frequently asked questions
What is an FDE’s main responsibility?
To turn an operational problem into a system used in production, connecting business framing, technical delivery, user testing, tool integration and measurement.
Does an FDE replace a consultant?
Not exactly. A consultant may frame and recommend. An FDE is appropriate when the company also needs someone to build, integrate, test and monitor the solution with its users.
How is an FDE different from an AI engineer?
Both can build AI systems. The FDE is distinguished by direct participation in the business loop and ownership of the full path from workflow to production use.
How is an FDE different from a freelancer or IT services firm?
Status alone does not define the difference. The FDE model organises continuous responsibility across process discovery, delivery and user feedback. Other providers can work this way, but are often engaged against a scope defined in advance.
Who works with the FDE?
The process owner, users, data owners and IT. The business decides outcomes and rules, IT governs architecture and access, and the FDE turns those decisions into a testable system.
What documentation supports handover?
It depends on scope, but should cover operation, access, decisions, tests, operating procedures and known limits. Ownership for updates should be agreed before production.