A Forward Deployed AI Engineer owns one thing from end to end: a single valuable but ill-defined workflow, carried all the way into production and shown to have made a difference. That ownership is the whole distinction. An ML engineer who spends time with customers is still an ML engineer, and a solutions engineer who writes code is still a solutions engineer. What changes is who answers for the result.
Palantir framed the distinction years ago and it still holds. Product engineering is one capability, many customers. Forward deployment is the inverse.
One customer, many capabilities.
— Palantir, on the forward deployed model
That inversion is why the first month matters so much. The engineer is doing product discovery, application engineering, evaluation, integration, security review and change management at once. The goal is not maximum code output. It is retiring uncertainty in the right order.
Where the month actually goes
Roughly 160 hours across twenty working days. If you are used to conventional delivery, the striking part is that building is barely a third of it.
The four weeks
- 01Week one
Discover and baseline
- Turn "we want an AI agent" into one workflow with one owner
- Shadow the people doing the work, not the executive description of it
- Map data, APIs, identity, retention and network boundaries
- Measure the baseline before any AI touches it: cycle time, rework, cost per task
- Collect 30 to 100 representative cases as a gold set
- 02Week two
Build the thin slice
- Scaffold the service, CI/CD, tracing and prompt versioning
- Build the highest-risk connector first, not the easiest
- Get one real user through the workflow end to end
- Stand up the eval harness and label failures by category
- Demo to users and cut anything that does not move the metric
- 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 deliberately small cohort, 10 to 30 users
- Run real tasks and compare against the week-one baseline
- 04Week four
Production and readout
- Fix the largest measured failure classes, not the most interesting ones
- Canary or shadow release with tested rollback
- Name the post-launch owner and ship the runbook
- Executive readout: what improved, by how much, at what cost
- Extract the reusable connector, eval set and pattern
Why day one is not for writing code
The most common failure is the POC trap: an impressive demo with no baseline and no economic hypothesis, which cannot be scaled because nobody can say what it improved. If you have not measured the current process, you have nothing to compare against later, and the decision at the end of the month becomes a matter of enthusiasm rather than evidence.
The strongest published deployments all share this discipline. NTT DATA recorded a baseline first: an incident analysis that took five experienced engineers three days. The same analysis later finished in thirty minutes. Rakuten measured feature time to market at twenty-four working days before it fell to five.
Note what those numbers measure: workflow outcomes, with a before and an after. Token counts and prompt volumes would say nothing useful here. Adoption gets measured separately and on purpose, because a system that passes its evals and then sits unused has failed at the only thing that mattered.
The failure modes worth naming early
| 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 |
| Eval blindness | Quality judged from hand-picked prompts | Commit representative cases to source control; rerun on every change |
| 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 "done" looks like at day twenty
What gets handed over is an evidence package answering one question: is this operating model worth scaling? Inside it, a prioritised workflow with a measured baseline, a representative eval set, a production-capable thin slice, telemetry for quality and cost and adoption, a real pilot cohort, a readiness record, a runbook with a named owner, and a quantified readout. The agent itself is the smallest part.
The question that separates a good engagement from a good demo
Can the customer operate this without the engineer who built it? If the answer is no, the month produced a dependency rather than a capability, however good the metrics look.
A second output is easy to skip and expensive to lose: the reusable one. A connector, an eval harness, an integration pattern, a piece of product feedback. Without it, every engagement starts from zero and the model degrades into custom development with a better job title.
That is the loop we run: discover locally, build locally, measure locally, then extract the general pattern so the next deployment starts further along.