Map the Workflow and the Forward Deployed Engineer's Role

Objectives

• Describe how a Forward Deployed AI Engineer connects customer discovery, implementation, and operations.
• Draw the current workflow with users, systems, bottlenecks, and a human decision owner.
• Draft discovery questions for the workflow's users and stakeholders.

1. Start with the work, not the model (3 minutes)

A Forward Deployed AI Engineer connects a customer's real work to an implemented, supported AI application. The role combines understanding workflows, communicating with stakeholders, building inside customer environments, and supporting deployment. Recurring solutions can also become reusable engineering patterns. This is broader than choosing a model or producing a convincing chat demo. [S30]

Think of the work as three connected responsibilities:

Discovery should establish the existing problem before predicting benefits. After delivery, teams need to compare actual benefits with their expectations and adapt the service. Production also requires feedback and ongoing governance, not just a successful launch. [S2][S12]

Demo versus delivery: A demo might answer one selected policy question beautifully. Delivery must also establish which policy version is authoritative, what happens when evidence is missing, who approves a response, and how a failed handoff is handled. A proof of concept should test business value, data readiness, feasibility, and risk—not merely presentation quality. [S11]

Check yourself: A model gives an accurate answer in a presentation. Is the customer problem solved? Not yet: there is no evidence here that the answer fits the actual workflow or can be operated reliably.

2. Meet the fictional workflow (3 minutes)

All people, systems, and events below are invented teaching examples. They are not customer research findings. Use fictional examples for this exercise; real research notes and prototype entries can contain personal data and must be handled through approved services and agreed research purposes. [S3]

An employee asks: “Can I expense a replacement headset?” Today, the employee searches a policy portal. If the answer is unclear, they send a message to a shared support inbox. A support agent reads the question, searches the policy portal, and reviews the applicable policy. If the answer is supported, the agent replies. If an exception or interpretation is needed, the agent creates a ticket for the policy owner. The policy owner decides the exception; the support agent communicates that decision and closes the request.

In our fictional interview, the employee says, “I cannot tell which page applies.” The support agent says, “I repeat the search, then copy the question into a ticket if it needs a decision.” The policy owner says, “Tickets often arrive without the relevant policy link.” These statements suggest places to investigate, not proven causes or measured savings.

Separate the workflow's parts:

• Users: employee, support agent, policy owner.
• Systems: policy portal, shared inbox, ticket system.
• Candidate bottlenecks: finding the applicable policy, repeating searches, rebuilding context during handoff, waiting for an exception decision.
• Human decision owners: the support agent owns routine response approval; the policy owner owns exception decisions.
• Workflow boundary: from an employee's policy question to an approved response or a completed exception handoff and eventual response. It does not include changing company policy or issuing a reimbursement.

Writing down stakeholders, constraints, the system boundary, and external interfaces helps make architecture discussions concrete. At this stage, a simple map is enough; you do not need a detailed system design. [S20]

Check yourself: Is “the ticket system” a decision owner? No. It stores and routes work. A named human role remains accountable for the decision in this example.

3. Draw and validate the current state (4 minutes)

Use the accompanying workflow diagram as a first draft of the fictional current state. It deliberately contains no AI component. First understand what happens now; adding a proposed solution too early can hide manual steps or imply agreement that does not exist.

To create your own version:

1. Write the trigger and the end state: a question arrives; the employee receives an approved answer.
2. Put each actor next to the action they actually perform.
3. Label the systems used at each step.
4. Add branches for missing evidence, exceptions, and handoffs.
5. Mark suspected delays as hypotheses until observation or measurement confirms them.
6. Identify the role that approves each consequential decision.

Ask the support agent to trace one ordinary case and one exception through the map. Ask the employee whether the stated endpoint really resolves their need. Ask the policy owner whether the exception path preserves their authority. Describing stakeholders, interfaces, interactions, and risks is a useful foundation for later architecture notes. [S20]

For our example, an exception ticket should carry the original question, relevant policy link and version if available, what remains uncertain, and the requested decision. This is a proposed handoff checklist to validate with the policy owner, not a claim about an existing system's fields.

Do not label every delay an AI opportunity. An unclear policy page might need an editorial fix. An incomplete ticket might need a better form. A prototype should test uncertain assumptions with only enough implementation to learn whether a candidate approach deserves further work. [S19]

Check yourself: Where could a request stall after the agent finishes searching? At the exception handoff, particularly if the policy owner must ask for missing context. The map should show that branch rather than stopping at “create ticket.”

4. Run a guided discovery interview (4 minutes)

Use questions about specific past work rather than asking whether someone wants an AI assistant. The following interview guide is an original exercise, informed by the need to understand customer workflows, document stakeholders and constraints, and establish the existing problem before estimating improvements. [S30][S20][S2]

Research data can include recordings, notes, and prototype entries—not just contact details. Prefer anonymized material for sharing and do not move real support records into unapproved tools. [S3]

Follow vague answers with neutral prompts: “What happened next?”, “How often does that happen, and where could we check?”, and “Who makes that decision?” Record conflicting accounts as open questions rather than silently choosing one.

Practice: Draft one additional question for the employee and one for the policy owner. Avoid leading questions such as “Would automatic answers save you time?” Better alternatives ask what currently consumes time and which decisions require human judgment.

5. Turn observations into an engineering handoff (3 minutes)

Create a short discovery note that separates what was observed, what is assumed, and what must be checked. Establish baseline measures before estimating improvements; projected savings are not measured results. [S2]

For this fictional exercise, a useful note could contain:

• Problem hypothesis: agents repeat policy searches and may lose context when escalating exceptions.
• Evidence so far: fictional interview statements only; no observed cases or timing data.
• Unknowns: frequency of exceptions, source freshness, access restrictions, and whether the ticket system permits a draft-only integration.
• Candidate thin slice: help an agent prepare a policy-linked draft response and handoff summary. Keep sending and ticket creation manual during the initial experiment.
• Human boundary: the agent reviews routine responses; the policy owner decides exceptions. A generated draft cannot authorize an exception.
• Next validation: walk through representative routine, ambiguous, and unanswerable questions with the agent and policy owner before choosing an implementation.

For document-based AI, define the domain and answerable questions before building retrieval. Include questions the documents cannot answer and have a domain expert validate expected answers. [S4] Begin with the simplest approach that can test the use case; add retrieval or action tools only when the need justifies them. [S11]

Keeping the initial experiment draft-only is an exercise design choice, not a universal deployment requirement. If later versions gain action tools, permissions and authorization must be enforced outside the model, with appropriate human approval for high-impact actions. [S15]

The code example is a small JSON discovery record—not an AI application or evidence that a customer system has been integrated. It demonstrates how to preserve an unknown explicitly instead of inventing a baseline. The field names are local to this exercise.

Check yourself: Should baseline_agent_minutes be zero if nobody has measured it? No. Use null to represent missing information; zero would assert a measurement.

6. Produce your first delivery artifact (3 minutes)

Spend three minutes making a one-page discovery artifact. Use the fictional scenario, or another wholly fictional policy question. Do not use private employee records.

Your artifact should contain:

1. A one-sentence problem statement without naming an AI solution.
2. A current-state diagram with the employee, support agent, policy owner, portal, inbox, and ticket system.
3. Two suspected bottlenecks, clearly marked as hypotheses.
4. A named human role for routine response approval and another for exception decisions.
5. Six discovery questions spanning at least three stakeholder roles.
6. One unknown that could change whether you build anything, plus a concrete way to investigate it.

Self-review: Can another reader trace both a routine answer and an exception through your map? Can they distinguish an observed fact from a hypothesis? Can they identify who may say yes or no to an exception? If not, revise the artifact before discussing a model.

Example acceptable unknown: “We do not know whether support agents can access the relevant policy versions. Ask the system administrator to confirm permissions, then have an authorized agent demonstrate access using an approved test account.”

You have now practiced the connection between discovery and implementation: a workflow map and open questions constrain what is worth building. Operations closes that loop by checking actual usefulness, cost, and feedback after delivery. [S30][S12] The next lesson turns the mapped problem into agreed business value and success criteria; you do not need to invent performance targets here.

{
  "scenario": "fictional_policy_support",
  "trigger": "Employee asks a policy question",
  "systems": ["policy_portal", "shared_inbox", "ticket_system"],
  "routine_response_approver": "support_agent",
  "exception_decision_owner": "policy_owner",
  "bottleneck_hypotheses": [
    "Agents repeat the employee's policy search",
    "Exception tickets may lack policy context"
  ],
  "baseline_agent_minutes": null,
  "evidence_status": "fictional_interview_only",
  "candidate_scope": "Draft response and handoff summary for agent review",
  "automatic_actions_allowed": false
}

An original, fictional discovery record. Unknown timing stays null; this is documentation, not an integration or executable workflow.

Key takeaways

• A Forward Deployed AI Engineer connects customer discovery, implementation, and ongoing operations—not just a model demonstration. [S30][S12]
• Map the current work before inserting AI: show actors, systems, branches, handoffs, and decision owners.
• Treat interview statements and bottleneck hypotheses differently from observed cases and measured baselines. [S2]
• Ask stakeholders about specific work, evidence, constraints, and approval boundaries.
• A small discovery artifact should expose uncertainties that could change or stop the proposed implementation.
• Use fictional examples for practice and approved data-handling processes for real research. [S3]

Common mistakes

• Drawing a chatbot before understanding the existing workflow.: Map the employee's question, agent review, system interactions, and exception path first. Keep the proposed future state separate.
• Assigning exception approval to a model or ticket system.: Name a human decision owner. In this fictional workflow, the policy owner decides exceptions and the support agent approves routine responses.
• Treating a stakeholder's complaint as a measured bottleneck.: Label it as a hypothesis, then identify an observation or approved measurement that could confirm or reject it.
• Asking only whether users would like an AI assistant.: Ask them to trace a specific case, explain uncertainty, and identify what makes the task complete.
• Copying private support tickets into an unapproved discovery tool.: Use fictional examples in this exercise. For real research, follow approved storage, access, consent, and anonymization practices. [S3]

References

1. Forward Deployed Engineer — role description, Anthropic
2. Measuring the benefits of your service, UK Government Digital Service
3. Delivering and sustaining the value of a generative AI application, Amazon Web Services
4. Architecting a successful generative AI proof of concept, Amazon Web Services
5. Managing user research data and participant privacy, UK Government Digital Service
6. arc42 Documentation: Practical tips and examples for the arc42 template, arc42
7. How the alpha phase works, Government Digital Service
8. RAG preparation phase, Microsoft
9. AI Agent Security Cheat Sheet, OWASP

See the full course: Forward Deployed AI Engineering: From Customer Problem to Production