Video summary

This Is How Forward Deployed Engineering Is Actually Done

Main summary

Key takeaways

Business

What a Forward Deployed Engineer (FDE) / FTE does

  • Purpose: Ensure a business actually uses AI by embedding AI into the real systems and workflows the company already runs—not by writing strategy decks.
  • Core competency: Identify, per step in a process, whether the work should be handled by:
    • Human
    • Deterministic software rules
    • AI

Concrete example: refund agent that “followed policy” but caused churn

  • An AI agent approved/denied refunds according to documented policy, but later the company started losing long-term customers.
  • The FDE observed an undocumented step:
    • If the order was paid via company card, approvals were effectively “pre-allowed”
    • Reason: disputes cost too much (argument cost outweighed refund value).
  • Result: the workflow was updated so this fixed rule ran before the model’s decision.

Why AI adoption fails in most companies

  • Many teams “slap AI on top of broken or misunderstood processes.”
  • A key underlying issue: people inside the business can’t clearly articulate the real workflow problem.
    • They describe what they imagined instead of what’s actually happening.

Metrics / research cited

  • MIT study: reviewed 300 AI projects; 95% produced no measurable return.
  • Cause (per MIT): companies built with generic demo-ready tools and never learned how the business actually ran.

Budget / operational cautionary tale

  • A company executive burned $10M in 3 months (intended for a year) by:
    • giving tools to everyone
    • letting teams improvise
    • achieving no measurable improvement to existing business outcomes

Another operational “process mismatch” example

  • Palantir lost a full year due to a workaround that was invisible until someone watched the work:
    • an engineer resisted a new file format because she used to double-click files to verify data
    • the new format didn’t support that action
  • Fix: they built a compatibility tool so she could “open like before,” and adoption happened 2 days later.

Playbook: How big companies operationalize forward-deployed engineering

Analysis of talks from OpenAI, Anthropic, Coda found repeatable patterns.

Step 1 — Choose the right target process (high volume / repeatability)

  • Start with processes that are costing the business something, typically where volume is high.
  • Rule of thumb from the video:
    • automating one message saves little
    • automating thousands per week drives meaningful productivity
  • Data source: the business’s existing history (e.g., support tickets) to find volume hotspots.
  • Example:
    • OpenAI at a major bank: targeted one job done by ~thousands of advisors/day
    • ~98% of advisors used what was built

Step 2 — Build on top of existing tools, not around them

  • “An agent is only as good as what it can reach.”
  • Example:
    • If teams live in Notion, don’t migrate everything to a new system.
    • Connect the agent to Notion using MCP so work continues where it already happens.
  • Example:
    • A client spent $5M over 5 years integrating into their finance system; moving them off wasn’t viable—so the build focused on connecting everything else to that system.

Step 3 — Minimize workflow change (keep familiar steps)

  • Don’t compress an 11-step process into 1 step if users will have to “trust invisibility.”
  • Keep steps visible so people can verify.
  • Strategy: agent executes within steps, while the process structure remains understandable.

Step 4 — Plan for a long “trust” rollout (not just build time)

  • Example timeline:
    • 6–8 weeks to complete technical build
    • ~4 months of pilots/testing before advisors reliably relied on it
  • Reason: daily users need changes to earn adoption.

“Run it yourself” roadmap (5 steps) for applying FDE work

  1. Observe the real job end-to-end

    • Watch a person do the repetitive work.
    • Write down every step in actual order.
  2. Question each step’s purpose

    • Ask why each step exists.
    • If nobody can give a concrete reason, it’s often an ancient workaround.
  3. Decide what becomes AI vs software vs human

    • Filter each step through:
      • Fixed rule? Keep as deterministic software (no need for AI).
      • Messy judgment call? That’s the AI part.
      • High cost if wrong? Keep with a person.
    • Example allocation (from Moses’ “8-step process” example):
      • 4 steps run autonomously (AI/software)
      • 3 steps run with human checking
      • 1 step stays fully human (a business call AI can’t own yet)

Additional failure-mode principle:

  - Build for **how things can fail**, not just success cases.
  - “If there’s only one way it goes right, there are a thousand ways it can go wrong.”
  - Practical implication: handle areas where the model is **uncertain** (it may still output confident answers).
  1. Validate before touching real work

    • Models vary slightly even with the same prompt.
    • Test against real historical examples with known correct answers.
    • Measure accuracy by:
      • counting correct outputs
      • inspecting misses and iterating fixes
  2. Quantify business value (money/cost/risk)

    • You must measure whether the system:
      • brought money in
      • saved cost
      • reduced risk
    • Example KPI correction:
      • Cursor complaint: agent cost $2,000/day
      • Root cause: agent picked which engineer to send for broken equipment
      • True business cost: sending the wrong engineer cost more than $2,000/day
      • Lesson: evaluate not just agent cost, but what it prevents or improves

Concrete case: building an internal chatbot (the video’s “how it was done”)

  • They built a chatbot for non-technical departments (HR, accounts) so they could use Claude Code capabilities.
  • Problem addressed:
    • Claude Code assumes users can do setup/engineering integrations.
    • Users needed connectivity to Slack, email, and other tools, but they wouldn’t do the setup.
  • Implementation approach:
    • Engineers sat with HR and accounts to capture repetitive workflows.
    • The documented processes became:
      • instructions the agents follow
      • knowledge the chatbot answers from
  • After first version deployed to real work:
    • departments reported it saved time

Skills profile for running forward-deployed engineering

  • One company described it as needing:
    • broad across business, process, and technology
    • one deep technical area
  • But the video suggests:
    • for FDE execution, emphasis is likely more on business/process fluency
    • because “building” can be largely handled by agents/tools
  • Hiring advice (via Palantir exec reference):
    • avoid the “careful engineer” who wants perfect code for 10 years
    • prioritize getting a rough but functional system into a real user’s hands quickly (agents enable fast iteration)

How to start: the “audit” as the entry point

  • Start with the smallest business you can physically visit.
  • Spend ~1 hour shadowing the person doing the most repetitive work.
  • Run the 5-step process to produce an audit.
  • The audit is framed as something businesses actually pay for, and is presented as the biggest initial bottleneck in pitching/pursuing FDE work (because it packages a real company’s workflow steps + value).

Key metrics / KPIs mentioned (or implied targets)

  • Hiring / market indicators
    • Job postings for this role: +729% in a year
  • Adoption effectiveness
    • Bank advisor adoption: ~98%
  • AI project success
    • 95% of AI projects: no measurable return (MIT study)
  • Cost / budget
    • Executive overspend example: $10M in 3 months
    • Cursor example: agent cost $2,000/day vs larger avoided cost from correct routing
  • Timeline
    • Technical build: 6–8 weeks
    • Trust / pilot period: ~4 months
  • Benchmark for rollout
    • Accuracy validated by running through real examples and counting correctness (no numeric threshold specified)

Presenters / sources mentioned

  • Colin Jarvis (OpenAI)
  • Vasuman Moza (runs AI work / “forward deployed” type engagements; previously at Meta)
  • Moses (referred to as running/leading this approach; includes the Notion/MCP and 11-step trust examples)
  • Dex AI (sponsor; talent agent for software engineers)
  • MIT (study on 300 AI projects)
  • AWS (funded/created a department of forward deployed engineers)
  • Anthropic (talks; role examples)
  • Coda (talks; context)
  • Palantir (example of workflow workaround causing a year delay; executive quote referenced)
  • Meta (via Vasuman Moza’s background)
  • Cursor (case about agent cost and cost-of-misrouting)
  • OpenAI, Anthropic, Coda (as companies whose talks were analyzed)
  • Y Combinator (mentioned as containing many startups hiring FDEs)

Original video