abhinavbhatia
Sheet 02 / 05 — Blogs← Archive

Forward deployed engineering, from the basics

A free, ten-part series on what a forward deployed engineer does and how to do the job well, built from what public FDE job descriptions ask for. One fictional engagement runs through every part, alongside the Production-ready agents series.

· 7 min read · ~10 min listen· Forward deployed engineering · Agents · Google Cloud · Gemini Enterprise

Getting an AI agent to answer a question in a demo now takes an afternoon. Getting the same agent to work inside a real company, on its data, behind its identity provider and its network rules, with its own engineers able to run it afterwards, takes much longer. The people whose job is to close that gap are increasingly called forward deployed engineers (FDEs).

The title now appears in public job postings at Google Cloud, Microsoft, OpenAI and Anthropic. In my work with partners, I find that people understand the words “forward deployed” much less well than they understand the agent code. This series explains the job from the basics: what an FDE does, and how to do each part of the work well.

If you prefer to watch first, here is the heart of this part as a short animated explainer.

Video: what a forward deployed engineer does and what the ten-part series covers, in three minutes. The narration is a synthetic voice; the script and animation are mine.

Who is this series for?

  • Engineers who build AI systems and want to know what changes when the system has to run in a customer’s estate instead of their own project.
  • Architects, customer engineers and consultants whose work overlaps with forward deployed work and who want a clear picture of the whole engagement.
  • Partners and technical leads who staff, scope or run these engagements and need a shared vocabulary for them.

This is a series about the work itself. It explains what the job involves and how to do it well, and it is not a guide to getting hired anywhere.

What is a forward deployed engineer?

The short version: a forward deployed engineer is a software engineer who works inside one customer’s organisation, writes and ships the code that gets a product working on that customer’s real systems, and brings what they learn back to the team that builds the product. One public Google Cloud posting describes the role as “an embedded builder who bridges the gap between frontier AI products and production-grade reality within customers”.

Part 1 unpacks that definition, including where the term came from and how the role differs from a solutions architect, customer engineer, consultant or product software engineer.

What does one engagement look like?

Most of the series follows the arc of a single engagement (a piece of work with an agreed goal, a start and an end). The stages are the same ones that public job descriptions describe, and each one has its own part.

ONE ENGAGEMENT, TEN PARTS Discover Part 2 the problem and the metric Design Part 3 inside their estate Build Parts 4 to 6 data, systems, frameworks Harden Part 7 prototype to production Support Parts 8, 9 debugging, performance Prove Part 10 outcomes and executives next use case Production-ready agents the build itself, Parts 1 to 12 Part 1 explains the role. Parts 2 to 10 follow one engagement with Acme Consumer Brands.

one engagement from start to finish, and the part of this series that covers each stage; the build and harden stages are where the production-ready agents series goes deeper

Each part opens with a section called “Where does this show up in an FDE job description?”. It quotes or closely paraphrases two to four lines from public postings, then explains what those lines mean in practice and how to do that work well. Every posting I quote is linked in that part’s Sources.

What is the running example?

The same fictional company runs through this series and the Production-ready agents series. Acme Consumer Brands ran an advertising campaign. Marketing says it was a success and supply says it was a failure, and both are right. The advertising data lives in BigQuery (Google Cloud’s data warehouse) and the delivery data lives in Databricks (a separate data platform), and nobody has put the two side by side.

CAMPAIGN_PERFORMANCE (MARKETING, BIGQUERY) SUPPLY_SERVICE (SUPPLY, DATABRICKS) week_start media_spend_eur impressions clicks 2026-05-04 36,317.41 5,467,637 67,774 2026-05-11 41,270.37 9,015,848 89,983 2026-05-18 42,049.65 9,669,827 86,901 week_start units_ordered units_delivered otif_pct 2026-05-04 17,475 15,585 89.18 2026-05-11 16,679 14,799 88.73 2026-05-18 17,448 15,160 86.89 Same brand, region and weeks, two platforms, two owners. Joined on brand, region and week_start: EUR 283,590 of spend meets 87.4% OTIF. First 3 of the 7 campaign weeks (from 4 May 2026). Acme Pure Refill Launch, Western Europe.

the two halves of the Acme story: campaign_performance (one row per campaign, region and week, owned by marketing, read by BigQuery) and supply_service (one row per brand, region and week, owned by supply, in Databricks), shown for Acme Pure in Western Europe

Prerequisite 2: The business terms and the data behind the agents explains every column and how the two tables join.

In this series, you are the FDE embedded with Acme. Your job is to get the marketing and supply question answered by agents that Acme’s own people can use in Gemini Enterprise (Google’s AI assistant platform for companies), and that Acme’s own engineers can run after you leave. Acme and its data are made up; the products, protocols and practices are real.

How does this pair with the agents series?

The two series are designed to be read together. The agents series is the build: three agents, written and hardened step by step, with the code. This series is the engagement around the build: discovery, design inside someone else’s estate, data and integrations, debugging, performance, and proving the outcome to executives.

THIS SERIES: THE ENGAGEMENT AGENTS SERIES: THE BUILD FDE 3 Designing in their estate Part 7 identity, Part 12 users FDE 4 Data readiness and RAG Part 3 touching data safely FDE 5 Enterprise integrations Part 6 A2A, Part 7 identity FDE 6 Agent frameworks Part 1 agents, Part 5 router FDE 7 Prototype to production Parts 7 to 11, the hardening FDE 9 LLM performance Part 11 deploy, observe, cost FDE 10 Executives and outcomes Part 12 giving it to users Where a topic is already built in the agents series, this series links to it instead of repeating it.

how this series pairs with the production-ready agents series: each engagement topic on the left links to the build parts on the right that go deeper

Where a topic is already built in the agents series, I link to it instead of repeating it. For example, Part 7 of this series covers how to take a prototype to production and links to agents Part 7 on identity, Part 9 on guardrails, Part 10 on evals and Part 11 on deployment and cost for the code.

What are the ten parts?

THE TEN PARTS 1 Understand Part 1 What an FDE does Part 2 Discovery 2 Design and build Part 3 Designing in their estate Part 4 Data readiness and RAG Part 5 Enterprise integrations Part 6 Agent frameworks compared 3 Ship and support Part 7 Prototype to production Part 8 Debugging in the field Part 9 LLM performance and cost 4 Prove Part 10 Executives and outcomes Each part opens with the lines from public FDE job descriptions that it explains.

the ten parts of the series grouped into four stages: understand the role and the problem, design and build in the customer's estate, ship and support, and prove the outcome

Stage 1: Understand

Part 1: What a forward deployed engineer actually does. Where the term came from, what public job descriptions ask for, how the role compares with four familiar roles, how an engagement runs from embed to hand-over, and the mix of skills it needs.

Part 2: Discovery: from a business problem to something you can build. The problem statement, business and technical success metrics, feasibility, choosing the first use case, the data and access questions to ask, when to say no, and a one-page engagement brief.

Stage 2: Design and build

Part 3: Designing inside someone else’s estate. The upfront technical design: where the data lives and who owns it, the identity provider, network paths and private connectivity, compliance boundaries and the security review, with a week-one question list and a design review checklist.

Part 4: Data readiness and RAG from zero. How documents become answers: parsing, chunking, embeddings, vector and hybrid search, reranking, grounding and citations, the managed options on Google Cloud, how to evaluate retrieval, and why answers go wrong.

Part 5: Enterprise integrations, APIs, connectors and identity. REST APIs and authentication, content-management connectors, Gemini Enterprise connectors and data stores, identity standards (SAML, OIDC and SCIM), and MCP servers as the integration layer, with the Gemini Enterprise and Databricks Genie build as the worked example.

Part 6: Agent frameworks compared. ADK, LangGraph, CrewAI and Microsoft’s AutoGen, which is now archived in favour of Microsoft Agent Framework (as of October 2026), side by side; the common patterns (ReAct, reflection, supervisor and graph); the same small task in two frameworks; how to choose; and how A2A and MCP let agents built in different frameworks work together.

Stage 3: Ship and support

Part 7: Prototype in days, production in weeks. Building a throwaway prototype on purpose, AI-assisted coding, the hardening checklist, and handing over to the customer’s team with a runbook, named owners and training.

Part 8: Debugging in the field. Reading unfamiliar code, reproducing a failure, logs and traces, telling a customer-environment problem from a product bug, workarounds, and a bug report template that Product and Engineering can act on.

Part 9: LLM-native performance: latency, tokens and cost. Time to first token, tokens per second, context size and its cost, caching, streaming, choosing a model size, batching and cost per request, and why you measure before you optimise.

Stage 4: Prove

Part 10: Talking to executives and proving the outcome. Turning a technical blocker into business impact, outcome metrics and baselines, the steering update, managing scope and expectations, and the close-out review, with a recap of the whole series.

What do I need to follow along?

  • Nothing to install for most parts. Where a part includes code or a template, it runs with plain Python 3 or works as a text file you can copy.
  • For the build itself, the Production-ready agents series lists what you need, including a Google Cloud project.

Some products mentioned in later parts are in Preview on Google Cloud (available to try, but not yet generally available). I label each one and date the status as of October 2026.

What did we learn?

  • A forward deployed engineer works inside one customer’s organisation, ships the code that gets a product working on that customer’s real systems, and brings what they learn back to the product team.
  • Most of the series follows one engagement, from embedding and discovery through design, build and hardening to hand-over and proving the outcome.
  • Every part starts from what public FDE job descriptions ask for, and then explains how to do that work well.
  • One fictional company, Acme Consumer Brands, runs through this series and the Production-ready agents series, with marketing data in BigQuery and supply data in Databricks.
  • The agents series is the build and this series is the engagement around it, so each links to the other instead of repeating it.

What comes next?

Part 1 starts from the beginning. Part 1: What a forward deployed engineer actually does explains where the term came from, what public job descriptions ask for, how the role differs from the technical roles you already know, and how an engagement runs from embed to hand-over.

Sources

Opinions are my own. Every fact in this series comes from public documentation, linked in each part. Acme Consumer Brands and its data are fictional.