A Forward Deployed AI Engineer works alongside a customer's team to turn a business workflow into a working AI application. The role can include discovery, software development, integration, evaluation and deployment, with responsibility for measuring whether the result helps the people using it.
In this embedded AI engineering model, the engineer needs regular access to the people doing the work and the technical owners of the systems involved. The exact responsibilities vary by company, so agree on the scope, the decisions the engineer can make and who will operate the result.
Define the outcome before the first sprint
Choose one workflow, name its business owner and agree how improvement will be measured. Those decisions give discovery, development and evaluation a shared purpose.
The first month is often spent testing assumptions about data access, quality, integration and adoption alongside the build. The plan below illustrates how that work might fit into four weeks for a narrow use case. Access delays or more demanding controls can extend it.
How to allocate the first month
For a twenty-day month of roughly 160 hours, the allocation below is a useful planning example. Building and integration take 35%; the remaining time covers discovery, evaluation, production readiness and helping users adopt the workflow.
A sample four-week engagement
- 01Week one
Discover and baseline
- Turn "we want an AI agent" into one workflow with one owner
- Observe the people doing the work, including exceptions and workarounds
- Map data, APIs, identity, retention and network boundaries
- Measure the baseline before any AI touches it: cycle time, rework, cost per task
- Assemble an initial evaluation set, for example 30 to 100 cases; expand it to cover the risks
- 02Week two
Build one complete workflow
- Scaffold the service, CI/CD, tracing and prompt versioning
- Test the integration with the greatest uncertainty early
- Get one real user through the workflow end to end
- Set up repeatable evaluation and classify failures
- Review with users and prioritise changes against the agreed outcome
- 03Week three
Harden and pilot
- Separate read and write permissions; no credentials in code
- Add telemetry: latency, cost, task outcome, human override
- Define failure behaviour: timeouts, fallback, abstention, escalation
- Onboard a small pilot group suited to the workflow, for example 10 to 30 users
- Run real tasks and compare against the week-one baseline
- 04Week four
Assess production readiness and results
- Prioritise failures by frequency and consequence
- If ready, use a limited or shadow release with tested rollback
- Name the operational owner and provide the runbook
- Report what improved, what remains unresolved and the cost of continued operation
- Document reusable connectors and evaluation methods
Measure the workflow before changing it
Record current handling time, rework, cost per task and the quality standard before introducing AI. Otherwise, an impressive prototype leaves the team without a reliable comparison for the month-end decision. Early technical experiments can run alongside this measurement, especially when they test an uncertain integration.
Published customer stories show the kinds of outcomes worth measuring. NTT DATA's case study reports incident analysis falling from three days involving five engineers to thirty minutes. Rakuten reports roughly 50% lower mean time to recovery, while STADLER reports 30–40% time savings on common tasks. These are vendor-published customer results, not controlled comparisons or forecasts for a first-month engagement.
Choose measures that describe the workflow, such as resolution time or completed cases, and track usage separately. A technically sound application may still need changes to training, interface design or the process before people use it regularly.
Risks to address during discovery
| Risk | Early warning | What we do about it |
|---|---|---|
| Access delay | A prototype exists but no production-like data access by end of week one | Bring security and IAM into discovery; build on sanitised fixtures meanwhile |
| POC trap | Demo excitement, no baseline | Measure before building; make the month-end decision depend on pre/post evidence |
| Scope creep | Three departments in the first sprint | One workflow until the core metric moves; keep an explicit "not now" list |
| Incomplete evaluation | Quality judged from hand-picked prompts | Version representative cases in approved storage; rerun evaluation on relevant changes |
| Tool overreach | The agent can mutate high-value systems | Least privilege, typed tool contracts, human approval for consequential writes |
| Cost explosion | Great demo, uneconomic unit cost | Track cost per successful task, not per token |
| Handoff failure | Only the engineer can operate it | Name customer owners early; ship runbooks; run an incident drill |
What the first month should hand over
The handover should let the customer decide whether to expand, revise or stop the project. Include the chosen workflow and baseline, source code and configuration, evaluation cases and results, pilot findings, quality and cost monitoring, a readiness assessment and an operating runbook. State which production requirements remain open.
Check that the handover works
Have the future operator deploy the application, investigate a failed task and practise recovery using the documentation. Resolve gaps before the engineer leaves or define the support needed to cover them.
Document components that could be reused, such as connectors, evaluation tooling or deployment configuration. Keep customer data and confidential workflow details within the agreed ownership and access boundaries.
Our Forward Deployed AI Engineering service follows this sequence of discovery, implementation and measurement. The first engagement should leave a clear decision about the next phase, supported by working software and documented results.