IESE AI Club

Role playbook

AI as a career: forward deployed engineer.

The forward deployed engineer is half engineer, half consultant: inside a customer’s business, turning a general-purpose model into a system that does its actual work. Deployment—not model quality—is usually the bottleneck. The scarce skill is translating a messy process into something an agent can do.

This assumes you have the base. Start there if not

The job

What this role actually does.

Six things repeated with each customer. Code changes; the work does not. Move from ambiguous workflow to a system people trust enough to use.

01Discovery 02Prototyping 03Integration 04Evals & guardrails 05Adoption 06Feedback loop

Most examples are vendor customer stories. Their self-reported, unaudited numbers show something was built and used—not a benchmark to expect.

01

Discovery

Synthesis
The use case
Finding, with the customer, the small number of workflows where a deployment is actually worth doing.
Job to be done
When I land in a new organisation, I want the highest-value workflows identified alongside the people who own them, so the first build has both a sponsor and a payoff.
Value to the business
Deployments that start on a problem the business already wanted solved.
How to evaluate it
Value of the shortlisted workflows, and whether each has a named owner. A use case without an owner will not survive your departure.

What AI does here

AI turns notes, process documents, screenshots and exceptions into a first workflow map, surfacing contradictions and duplicate work. It gives you a draft before you fully know the operation.

Workflow map

  1. InputGather frontline interviews, SOPs, sample cases, system maps and the operational measures that matter.
  2. AI-assisted processCreate a first workflow map, cluster exceptions and surface contradictions for field validation.
  3. Human checkpointWalk the map with operators and leaders to distinguish the documented process from the work actually done.
  4. OutputA prioritised problem definition with users, constraints, owners and a measurable target.

What is still yours

Earn access and trust. The stated process is rarely real; the valuable problem may be political, embarrassing or too normal to document. Spotting it is the first test.

02

Prototyping

Build
The use case
Building something real against the customer's actual data, fast, to answer whether this is feasible at all.
Job to be done
When the workflow is chosen, I want a working version in front of users within a week or two, so we learn from behaviour rather than from a slide.
Value to the business
Feasibility answered in days, and requirements discovered while they are still cheap to change.
How to evaluate it
Time to a first working prototype and to a first real user, and the share of prototypes that die honestly rather than drifting on. Prototypes are disposable; say so out loud.

What AI does here

Coding agents turn a workflow into a first version in days: glue, interface and cheap direction changes. Customers learn more by touching an imperfect system than approving another requirements document.

Workflow map

  1. InputChoose one high-value case, representative data, success criteria and the smallest safe interface.
  2. AI-assisted processGenerate application glue, interfaces and test scaffolding so the team can explore the workflow quickly.
  3. Human checkpointCustomer users test the slice; the FDE confirms it handles the real work rather than a polished demo.
  4. OutputA working prototype and evidence for a build, revise or stop decision.

What is still yours

Choose the thinnest slice that proves value. A fast builder produces the wrong thing quickly; a useful prototype handles one real case end to end.

03

Integration

Automation
The use case
Connecting the system to real data, tools, identity and controls inside the customer's own environment.
Job to be done
When a prototype has to become a system, I want it wired into the customer's data and permissions properly, so it can be trusted with real work.
Value to the business
The difference between a demo and something in production.
How to evaluate it
Time to production, residency and permission requirements met, and reliability under real load. Where the data sits and who may act are design decisions, not afterthoughts.

What AI does here

AI drafts API clients, maps fields, builds MCP connections and diagnoses routine integration failures. The mechanics are faster; the boundaries are not.

Workflow map

  1. InputDocument systems of record, field definitions, data classification, allowed actions and approval paths.
  2. AI-assisted processDraft connectors and mappings, inspect errors and suggest repairs within the approved integration boundary.
  3. Human checkpointSecurity and system owners review access, writes, retention and failure handling before credentials or production data are used.
  4. OutputA tested integration with least-privilege permissions, logs and a rollback path.

What is still yours

Security and data boundaries: what it may read or write, what needs approval and what never leaves the customer’s environment. Convenience is not worth a breach.

04

Evals and guardrails

Analysis
The use case
Making quality measurable before deployment, and constraining what the system may do unsupervised.
Job to be done
When the customer asks whether it is good enough, I want an answer built from their real cases and their experts, so the bar is theirs rather than mine.
Value to the business
A deployment the customer's risk function can actually approve.
How to evaluate it
Eval coverage of real cases, pass rate against the agreed bar, and post-deployment incidents relative to what the evals predicted. The customer's experts define the bar.

What AI does here

AI generates cases from real examples, attacks awkward inputs and classifies failures across runs. It makes evaluation continuous; it cannot define correct or tolerable risk.

Workflow map

  1. InputConvert real cases and customer risk tolerances into labelled tests, guardrail rules and severity thresholds.
  2. AI-assisted processGenerate variants, run the suite at scale and cluster failures by root cause or impact.
  3. Human checkpointCustomer experts judge correctness, set escalation rules and decide which failures block launch.
  4. OutputA customer-specific quality bar, regression suite and documented go/no-go decision.

What is still yours

Set the quality bar and agree risk with the customer. A wrong summary and a wrong payment instruction are different failures; encode that before real work.

05

Adoption

Meetings
The use case
Getting the people who do the work to use the thing that was built.
Job to be done
When the system works, I want the team using it inside their real workflow, so the value is realised rather than demonstrated.
Value to the business
The only point at which any of the earlier work pays for itself.
How to evaluate it
Weekly active use among the intended users, share of the target workflow running through the system, and time to competence for a new user. Adoption is enablement work: office hours and role-specific training, not a launch email.

What AI does here

AI drafts training, answers repeat questions and shows abandonment. That supports adoption; employees adopt when it helps, they trust it and managers make room for change.

Workflow map

  1. InputIdentify user groups, changed tasks, training needs, support owners and adoption measures before launch.
  2. AI-assisted processDraft role-specific guidance, answer repeat questions and reveal where users abandon the new flow.
  3. Human checkpointManagers and champions address incentives, workflow changes and concerns that tool usage data cannot explain.
  4. OutputAn adoption plan with training, escalation support and a measured improvement loop.

What is still yours

Almost all of it. Change is incentives, fear, status, habit and the workaround keeping the department alive. Shipping is halfway; usage is the outcome.

06

Feedback loop

Synthesis
The use case
Watching production (sessions, escalations, failures) and feeding what you learn back into the system and the product.
Job to be done
When the system is live, I want the failure patterns visible, so improvement is driven by what actually goes wrong rather than by what we assumed would.
Value to the business
A deployment that gets better after launch instead of decaying.
How to evaluate it
Time from a reported failure to a tested fix, the escalation-rate trend, and whether the same failure recurs. Patterns that repeat across customers belong in the product, not in a per-customer patch.

What AI does here

AI clusters complaints, traces repeated failures and turns field notes into product, prompt and workflow changes. It shortens the path from friction to a candidate fix.

Workflow map

  1. InputCollect usage traces, user reports, escalation notes, outcome metrics and the version that produced each case.
  2. AI-assisted processGroup repeat failures, link them to traces and propose whether the prompt, tool, product flow or guidance may need attention.
  3. Human checkpointReview the examples with users and decide whether the pattern is a true product issue, an edge case or a training gap.
  4. OutputA ranked, evidence-linked change backlog and feedback to the central product team.

What is still yours

Know which complaint is signal. One loud user may be an edge case; one quiet workaround may expose a broken design. Turn both into decisions, not a request queue.

Start this week

  1. Pick one workflow you know well and map every input, decision, handoff and exception with the person who actually runs it.
  2. Build the thinnest version that completes one real case end to end, then put it in front of that person.
  3. Write ten known-correct examples and three failures that must never happen before improving the prototype.

Where it fails in this role

  • Building before discovery. A polished agent for the documented process still fails when the documented process is fiction.
  • Treating a demo as a deployment. The last twenty per cent is permissions, exceptions, monitoring and ownership, and it takes most of the work.
  • Assuming usage follows quality. A reliable system can still die because nobody changed incentives or trained the people expected to use it.

Other playbooks

All nine playbooks Consulting Product management Sales Marketing Venture capital Operations Founder / entrepreneur AI product manager

This role is the Fellowship in miniature.

The Industry Fellowship runs the same loop at student scale: find the workflow by talking to the people who own it, build something against it, and show the value. That is forward deployment in miniature, compressed into a term. Most fellows start as beginners.

Explore the Fellowship Apply for the Class of 2028