AI forward deployed engineer

Pathway version 1 · 34 lessons in 8 modules · shared module: system design (planned)

A curated sequence over the library for a AI forward deployed engineer: 34 lessons in 8 modules, from the foundations of the role to its advanced topics.

What the role asks for

Responsibilities

Scope at staff

Technologies

AI coding tools

Cloud and compute

Data platforms and pipelines

Frontend frameworks

LLM and agent tooling

Languages and runtimes

Low-code and robotics

Security operations

The path

1. Foundations: The Forward Deployed Delivery Model

This module covers how a forward deployed engineer takes a customer engagement from a signed scope to a system running in production, and the working methods that keep that delivery bounded and verifiable. It moves from the delivery model itself to scoping and design documents, workflow mapping, and proofs of concept with measurable exit criteria.

1. The forward deployed delivery model: from signed scope to go-liveL2
A forward deployed engineer (FDE) is a software engineer embedded with a customer, responsible for making the product work on that customer's real data, systems and processes.
2. Technical scoping, design docs and solution architecture for customer engagementsL2 · Practice
Scoping turns a customer's stated need into a bounded technical commitment, and the design document is where the trade-offs behind that commitment are written down and reviewed.
3. Mapping customer workflows and choosing what to automate with AIL2 · Practice
Before any model is called, an FDE has to understand how the customer's work is actually done and decide which steps are worth automating.
4. Rapid prototyping, POCs and pilots with measurable success criteriaL2 · Practice
Prototypes, proofs of concept and pilots are how an FDE reduces uncertainty quickly and gives the customer evidence for a go or no-go decision.

2. Software Foundations for Field Engineering

A forward deployed engineer writes most of the glue between a customer's systems and an AI product, usually alone and under time pressure, so the general-purpose stack has to be second nature. This module covers the five foundations that work rests on: Python, TypeScript on Node.js, React with Next.js, Postgres, and AI coding tools used with production discipline.

5. Python for integrations, services and data transformationL2 · Practice
Python is the default language for field integration work because one language covers throwaway scripts, data transformation, HTTP services and the whole AI library ecosystem.
6. TypeScript and Node.js for services and toolingL2 · Practice
TypeScript adds a static, structural type system on top of JavaScript and compiles away to plain JavaScript that Node.js runs on a single-threaded event loop.
7. Full-stack customer applications with React and Next.jsL2 · Practice
Customers judge an AI deployment by the screen their people use, so a forward deployed engineer is often expected to build that screen as well as the backend.
8. SQL and data systems: schemas, indexing and partitioning in PostgresL2 · Practice
Almost every deployment ends up reading from or writing to a relational database, and Postgres is the one most often named.
9. Shipping production code with Claude Code and other AI coding toolsL2 · Practice
Agentic coding tools read a repository, run commands, edit files and iterate on test results, which changes the engineer's job from typing code to directing and verifying it.

3. APIs and Enterprise Integrations

Forward deployed work lives or dies on connecting an AI system to the customer's real systems of record: CRMs, ERPs, ticketing tools, event buses and decades-old databases. This module covers the request/response contract (HTTP, JSON, OAuth 2.0), the push and streaming contract (webhooks and Kafka), and the patterns for integrating with and migrating off legacy systems without breaking the business.

10. REST APIs, JSON and OAuth 2.0 authenticationL2 · Practice
Most enterprise integrations are HTTP calls carrying JSON, authorized by an OAuth 2.0 access token.
11. Webhooks and event-driven integrations with KafkaL2 · Practice
Polling an API tells you what changed eventually; events tell you when it changes.
12. Integrating legacy systems and running migrationsL2 · Practice
Customers buy AI systems to change how work is done, but the work still runs through systems that are old, poorly documented and business critical.

4. LLM Application Building Blocks

This module covers the four building blocks that almost every customer-facing LLM system is assembled from: the model API itself, the prompt and context around it, typed outputs and tools, and retrieval over private data. Each lesson starts from how the mechanism works and ends with how a deployed team operates it under real cost, latency and correctness constraints.

13. How LLMs work inside applications: tokens, context windows and model APIsL2 · Practice
A large language model is a function that takes a sequence of tokens and predicts the next one, repeated until a stop condition.
14. Prompt engineering and context engineeringL2 · Practice
Prompt engineering is the practice of writing instructions a model can follow reliably; context engineering is deciding what information occupies the window at each step and in what form.
15. Structured outputs and tool callingL2 · Practice
Structured outputs make a model return data that conforms to a schema, so downstream code can consume it without parsing free text.
16. Retrieval-augmented generation with vector databasesL2 · Practice
Retrieval-augmented generation supplies a model with relevant passages from an external corpus at request time, so answers are grounded in data the model was never trained on and can cite it.

5. Agents and Agentic Workflows

This module covers how agentic systems are designed, connected to customer systems, kept running through failures, measured, and constrained. It moves from single-agent loops and SDK primitives through MCP servers and durable orchestration to evaluation and guardrails, the parts that decide whether a deployment survives contact with production.

17. Agent architectures and agentic workflows with agent SDKsL2
An agentic system sits somewhere between a fixed workflow, where code decides the order of model calls, and an autonomous agent, where the model decides its next step in a loop with tools.
18. Building Model Context Protocol (MCP) serversL2 · Practice
The Model Context Protocol is an open standard for connecting AI applications to external systems, so one integration works across many hosts instead of being rewritten per agent framework.
19. Agent orchestration and durable executionL2 · Practice
Orchestration decides which agent or step runs next and what context it receives; durable execution makes sure a long run survives crashes, deploys and rate limits without losing or repeating work.
20. Evaluating LLM and agent systemsL2 · Practice
Evaluation turns a vague sense that the system seems fine into a number tied to defined success criteria, so prompts, models and architectures can be changed with evidence.
21. Responsible AI controls and guardrailsL2 · Practice
Responsible AI work combines a governance process that identifies and tracks risk with technical controls that limit what a model-driven system can see, say and do.

6. Customer Data: Pipelines and Platforms

Customer deployments succeed or fail on the state of the customer's data: where it lives, how clean it is, and how reliably it moves. This module covers cleaning and linking messy records, working inside Snowflake and Databricks accounts you do not own, building tested transformations with dbt, and scheduling it all with Airflow or Dagster.

22. Cleaning messy customer data: data mapping and entity resolutionL2 · Practice
Customer data arrives as overlapping exports from CRMs, ERPs and spreadsheets, with inconsistent formats, missing values and the same real-world entity recorded many times.
23. Working in customer data platforms: Snowflake and DatabricksL2 · Practice
Most enterprise customers already keep their analytical data in Snowflake or Databricks, so AI work starts inside an account someone else owns and governs.
24. ELT transformations with dbtL2 · Practice
In ELT, raw data is loaded into the warehouse first and transformed there with SQL.
25. Data pipeline orchestration with Airflow and DagsterL2 · Practice
An orchestrator schedules pipeline steps, runs them in dependency order, retries failures and records what happened.

7. Infrastructure and Deployment into Customer Environments

This module covers how an AI forward deployed engineer gets a system running inside infrastructure the customer owns: their cloud accounts, their clusters, their private networks and sometimes their GPUs. It moves from cloud and delivery fundamentals to restricted networks, self-hosted inference, and the latency and cost tradeoffs that decide whether a deployment survives production.

26. Deploying into customer clouds: AWS, Google Cloud and AzureL2 · Practice
Forward deployed work usually ends with software running in an account the customer owns, under their identity, network and compliance rules.
27. Containers, CI/CD and serverless deliveryL2 · Practice
Containers, pipelines and serverless functions are the packaging and delivery mechanics behind every customer deployment.
28. Networking for private, air-gapped and classified customer environmentsL2 · Practice
Many enterprise and government customers run workloads on networks with no public ingress, tightly filtered egress, or no internet connection at all.
29. GPU infrastructure and model serving for inference workloadsL2
When a customer cannot or will not call a hosted model API, the forward deployed engineer has to run open-weight models on GPUs inside the customer environment.
30. Scaling and performance-cost tradeoffs for LLM systemsL2 · Practice
LLM systems have an unusual cost and latency profile: spend scales with tokens, latency scales mostly with output length, and capacity is bounded by provider rate limits or by GPUs.

8. Operating Deployments: Reliability, Security and Reuse

This module covers what happens after a deployment goes live: seeing what the system and its agents are doing, finding and fixing failures, and passing security and compliance review in regulated environments. It closes with how to turn the custom work of one engagement into platform features and internal tools that the next engagement can reuse.

31. Observability: logs, metrics and agent tracesL2 · Practice
Observability is the ability to understand what a running system is doing from the telemetry it emits: logs, metrics and traces.
32. Debugging production systems and running postmortemsL2
Debugging production systems is a disciplined loop of triage, observation, hypothesis and test, not a hunt driven by intuition.
33. Security reviews, governance and compliance in regulated industriesL2 · Practice
Regulated customers will not put an AI system into production until it passes their security and compliance review.
34. Turning one-off customer builds into reusable platform features and internal toolingL2 · Practice
Forward deployed work creates custom solutions under time pressure, and its long-term value depends on how much of that work the next engagement can reuse.

Changes

Version 1, 2026-10-12: re-expressed the gigai 0.1.11.10 shipped course as references into the library