Forward Deployed Engineer Tools: The Complete Stack

Forward deployed engineers do not work with a single fixed toolset. They work inside a different customer environment on every engagement, which means the specific tools change constantly.

What does not change is the shape. The FDE stack in 2026 has five consistent layers: discovery, build and eval, orchestration, deployment, and observability.

The specific tools inside each layer vary by company and stack, but the structure is remarkably consistent across Palantir, OpenAI, Anthropic, and the wave of AI-native startups running the FDE model.

This guide covers what is actually running in each layer, why the FDE toolchain looks structurally different from a product engineer’s, and how to think about tool choices in constrained customer environments.

Key Takeaways

• The FDE stack has five layers: discovery, build and eval, orchestration, deployment, and observability. Every tool in the FDE stack either talks to the customer, learns from the customer, or pushes code into the customer’s environment.
• FDEs spend roughly 40% of their time in discovery. That makes the discovery layer the most strategically important layer in the stack, and the one most commonly underbuilt.
• Build order matters more than tool choice. Agent capability comes first, evaluation second, observability third, communication fourth. Skipping evals to ship faster is the most common way FDE deployments fail quietly.
• The eval layer is where FDEs earn their reputation. Building evaluation suites that detect hallucinations and regressions before they reach production is cited as the non-negotiable skill across every frontier lab FDE job posting in 2026.
• Python and TypeScript are the core languages. Python dominates AI framework integration. TypeScript dominates customer-facing integrations with web-based systems.
• The deployment layer is constrained by the customer, not by the FDE. Private cloud, on-premises, airgapped infrastructure, compliance-bound VPCs: the FDE uses what the customer’s environment allows, not what they would prefer.

Why the FDE Stack is Different

A typical product engineer’s stack optimizes for building features for many customers simultaneously. The tools reflect that: shared infrastructure, centralized deployment, standardized monitoring.

An FDE’s stack optimizes for making one specific system work inside one specific customer’s environment, then doing it again for the next customer, faster.

The structural differences:

This structural difference explains why FDEs rarely adopt their company’s standard engineering toolchain wholesale. They need tools that work inside constrained, varied, often legacy customer environments, not inside a clean internal platform.

The Complete FDE Tool Stack at a Glance

Layer 1: Discovery

What it is: The tools FDEs use to capture customer context before writing a line of code, and to stay aligned with customer needs throughout the engagement.

Why it matters: FDEs spend roughly 40% of their week in discovery. The FDE workflow either compounds or collapses at this layer. You cannot ship the right agent if you skipped the customer interview. Every constraint that will kill the deployment (legacy authentication, data residency rules, security review requirements, change management timelines) is visible in discovery, if the right questions are asked.

The tools:

• Perspective AI: AI-moderated interview layer that replaces the discovery survey, the kickoff form, and often the first three weeks of stakeholder calls. Captures customer pain, workflow, vocabulary, and edge cases in a structured, queryable format.
• Granola: AI meeting notes with customer-specific context. Captures decision logs and integration constraints discussed during calls in a searchable format the rest of the stack can reference.
• Read.ai: Meeting intelligence for customer calls, with automatic summaries and action item capture. Strongest for high-volume customer touchpoints.

The FDE trap: treating discovery as a phase rather than an ongoing practice. Customer requirements shift after launch. The FDE who stops discovery after kickoff builds for the original scope, not for what the customer actually needs in production.

Layer 2: Build and Evaluation

What it is: The tools FDEs use to write production code, scaffold AI agents, and verify that those agents produce correct outputs before they touch production users.

Why it matters: Eval engineering is the non-negotiable FDE skill in 2026. Every frontier lab FDE job posting lists it as a core requirement. AI systems in production behave differently from AI systems in demos. Without a functioning eval layer, there is no reliable way to know whether the system is working correctly after it ships.

AI Coding Assistants

• Claude Code: Terminal-based agentic coding assistant. Strong for complex multi-file refactors and integrations inside unfamiliar codebases. Particularly useful when the FDE needs to understand a customer’s existing codebase quickly.
• Cursor: AI-native code editor. Strong for rapid iteration and real-time code generation inside a customer’s development environment. The most widely adopted AI coding tool among FDEs working in TypeScript.

Evaluation Frameworks

• Braintrust: Comprehensive trace logging with zero setup, real-time and batch evaluation, fine-grained access controls for audit trails. Strong when the eval dataset needs to track specific customer queries and responses over time.
• LangSmith: LangChain’s native observability and evaluation platform. Seamless for teams building with LangChain or LangGraph. Provides dataset management, LLM-as-judge evaluation, and production monitoring in a single environment.
• Promptfoo: Open-source evaluation framework. Particularly strong for testing prompts against adversarial inputs, safety filters, and regression testing when the eval dataset is small and the FDE is managing it manually.

Core Languages

• Python: Dominant for AI framework integration, agent scaffolding, data pipeline work, and backend integrations. Required for working with LangChain, LangGraph, and the Anthropic and OpenAI SDKs.
• TypeScript: Dominant for customer-facing integrations with web-based systems, API wrappers, and any deployment where the customer’s existing codebase is TypeScript-first.

Layer 3: Agent Orchestration

What it is: The frameworks FDEs use to build the agent logic itself: how the agent plans, what tools it can call, how it manages state across multi-step workflows.

Why it matters: The orchestration layer determines whether the agent can handle the complexity of a real enterprise workflow: branching logic, tool calling sequences, error handling, state persistence across sessions, and multi-agent coordination.

The three patterns in 2026:

Pattern 1: Bare-Metal Sdks

• Anthropic Claude Agent SDK: Direct programmatic control over Claude’s tool calling, multi-turn conversations, and agentic loops. Best when the FDE needs precise control over model behavior and is standardizing on Claude for the deployment.
• OpenAI Agents SDK: Equivalent for OpenAI model deployments. Strong thread management, built-in tool use, and code interpreter integration. Best when the customer environment is already using OpenAI APIs.

When to use: When the agent workflow is relatively simple, the FDE wants minimal dependencies, and precise control over model interactions matters more than framework abstractions.

Pattern 2: LangGraph

LangGraph sits on top of LangChain and provides graph-based orchestration for complex, stateful multi-step agents.

It is the framework of choice for agents with branching logic, human-in-the-loop checkpoints, and workflows that must maintain state across sessions.

When to use: Complex enterprise workflows with multiple decision points, long-running tasks, or requirements for human approval at specific steps.

Pattern 3: Durable Workflow Engines

• Inngest: Event-driven durable workflows that survive failures and infrastructure outages. Particularly relevant for FDE deployments where the customer’s environment has reliability constraints or where the agent workflow spans hours or days rather than seconds.

When to use: When the customer’s environment is unreliable, when workflows need to survive restarts, or when the business process the agent automates takes longer than a single session.

Layer 4: Deployment

What it is: The infrastructure FDEs use to run the AI system inside the customer’s environment.

Why it matters: The deployment layer is the one most constrained by the customer’s infrastructure. The FDE cannot choose the deployment target freely. They work with what the customer’s security team approves.

Cloud Deployment

• AWS, Azure, GCP: The three major cloud providers. Most enterprise customers have a committed cloud provider. FDEs deploy inside the customer’s existing cloud account using the customer’s IAM, networking, and security controls.
• AWS SageMaker, Azure ML, Vertex AI: Managed ML platforms for model serving when the deployment includes fine-tuned or hosted models alongside the agent layer.

Serverless and Edge

• Modal: Function-as-a-service optimized for AI workloads. Strong for bursty inference workloads and rapid prototyping inside customer environments that allow serverless deployment.
• Vercel: Front-end deployment and serverless functions. Common for customer-facing AI features with a web interface.
• Cloudflare Workers: Edge deployment for latency-sensitive applications. Used when the customer’s users are globally distributed and response time is a hard requirement.

Container Infrastructure

• Docker: Container packaging that ensures the agent runtime is portable across the customer’s infrastructure, regardless of the underlying operating system or host environment.
• Kubernetes: Container orchestration for deployments that require scaling, self-healing, and rolling updates. Standard for enterprise customers with existing Kubernetes infrastructure.

Layer 5: Observability

What it is: The tools FDEs use to monitor agent behavior in production, detect output quality degradation, and feed production signals back into the eval layer.

Why it matters: The deployment is not the end of FDE responsibility. It is the beginning of a different kind of responsibility: knowing whether the system is working correctly after it launches, and detecting when it stops.

LLM-Specific Observability

• Langfuse: Open-source, self-hostable. Span-level trace data across Claude, GPT, and Gemini, with USD cost attribution at the trace, span, and token level. The leading choice for FDEs who need data residency compliance or who cannot route LLM traffic through third-party infrastructure.
• Helicone: Open-source AI gateway proxy. Token consumption, cost, latency, and error rates by user, feature, or endpoint. Strong free tier makes it the default starting point for FDEs in early engagement phases.
• Datadog LLM Observability: Enterprise full-stack observability extended to LLM calls. The natural choice for customer environments already running Datadog APM, where AI monitoring needs to integrate with existing alerts, dashboards, and SIEM infrastructure.

Application-Level Observability

• Honeycomb: Distributed tracing and observability for complex systems. Strong for debugging multi-service architectures where the AI agent is one component among many in the customer’s infrastructure.
• PostHog: Product analytics and session recording. Useful when the AI feature is customer-facing and the FDE needs to understand how real users are interacting with the AI output in the product interface.
• PromptLayer: Prompt versioning and telemetry. Tracks which prompt versions are running in production, with usage metrics and version comparison. Useful for FDEs managing rapid prompt iteration after launch.

The FDE Tool Selection Framework

With this many tools available, the FDE’s real skill is choosing the right subset for each customer engagement.

Three questions that narrow the selection:

1. What does the customer’s environment allow?

Security review, data residency requirements, approved vendor lists, and compliance obligations constrain the deployment layer before any other consideration.

Identify these constraints in discovery, before you have committed to a tool that the customer’s security team will not approve.

2. What is the customer’s existing stack?

An FDE deploying inside a customer running Azure, TypeScript, and the OpenAI API reaches for different tools than one deploying inside a customer running GCP, Python, and Anthropic’s Claude.

Meeting the customer’s stack reduces integration overhead and makes the deployment more maintainable by the customer’s own team after the FDE leaves.

3. What is the complexity of the workflow being automated?

Simple single-step agents with one or two tool calls do not need LangGraph. Complex multi-step workflows with human approval checkpoints and state persistence across sessions do.

Match the orchestration framework to the workflow complexity, not to what the FDE is most familiar with.

Ready to Deploy AI Inside Your Infrastructure?

Phos AI Labs is an embedded AI consulting firm for US businesses in the $5M+ revenue range.

We are Anthropic Official Partner & OpenAI Select Partner.

Our team includes 10+ forward deployed engineers who work across this full stack: discovery, build, eval, orchestration, deployment, and observability, inside your actual infrastructure.

Engagement pricing:

• AI Readiness Audit: from $10,000
• Ongoing embedded delivery: from $15,000/month
• Full embedded AI department: up to $50,000/month

All engagements scoped on a call. No self-serve checkout.

• Strategy before systems: We identify which AI workflows will produce measurable ROI before any system is scoped.
• AI Foundations that hold: We design the context engineering and integration architecture your team runs on for years.
• Real team training: We build your team’s ability to own and operate the system after we leave.
• Private AI Workspace: We design AI environments with access controls and governance built in from the start.
• AI Implementation: We build the AI system inside your actual infrastructure, integrated with your data and systems.
• Honest judgment, every time: We tell you which tools are right for your customer environment and which are not.
• We stay until it compounds: We are not done when the system ships. We are done when it is running reliably in production and producing measurable outcomes.

400+ engagements. Clients include Zapier, Coca-Cola, Medtronic, Sotheby’s, Dataiku, and American Express.

Talk to the team at Phos AI Labs.

FAQs

What Tools Do Forward Deployed Engineers Use?

The FDE stack has five layers. Discovery: Perspective AI, Granola. Build and eval: Claude Code, Cursor, Braintrust, LangSmith. Orchestration: LangGraph, Claude Agent SDK, OpenAI Agents SDK. Deployment: AWS/Azure/GCP, Modal, Vercel. Observability: Langfuse.

What Programming Languages Do FDEs Use?

Python and TypeScript are the two core FDE languages. Python dominates AI framework integration, agent scaffolding, and backend integrations with LangChain, LangGraph, and the Anthropic and OpenAI SDKs.

TypeScript dominates customer-facing integrations with web-based systems.

What is the Most Important Tool in the FDE Stack?

The eval framework is the most strategically important choice. Evaluation suites that detect hallucinations and regressions before production are the non-negotiable FDE skill in 2026.

Without a functioning eval layer, the system’s quality is unknown.

How Do FDEs Choose Which Tools to Use?

Three questions narrow the selection: what the customer’s security requirements allow, what the customer’s existing tech stack looks like, and how complex the workflow is.

The customer’s environment is the primary constraint.

What is the Difference Between LangGraph and Bare-Metal Sdks for Agent Orchestration?

Bare-metal SDKs provide direct control over model behavior with minimal abstraction, best for simple agents.

LangGraph provides graph-based orchestration for complex, stateful multi-step agents with branching logic, human-in-the-loop checkpoints, and state persistence.