A three-stage FDE agent

The first part of the talk explained why forward-deployed engineers (FDEs) are needed: someone must learn how a particular customer works, then redesign that work around AI. In this section, JD Pruitt explains the proposed tool for scaling that role.

His basic idea is a specialized assistant for FDEs. He calls it a “Codex for our FDEs.” This is an analogy: the tool is intended to help FDEs with their engineering and workflow work. It is not evidence that the system has the same implementation or capabilities as Codex.

The problem: customer context is large and difficult to use

Pruitt describes FDEs working with large collections of customer material. The material can include notes, internal documentation, and presentation slides. The challenge is not simply making a model read one more document. The FDE needs to turn scattered material into a reliable understanding of:

• which processes the customer uses;
• who owns each part of those processes; and
• how the parts connect when the normal path fails.

He contrasts this kind of work with a situation in which an engineer can quickly ask another person for an answer. When the relevant knowledge is spread across a customer’s files, that quick conversation is replaced by document collection and analysis.

One example is an FDE uploading about 150 pages to Claude, writing a prompt, and waiting for the result. Pruitt says that the resulting analysis could be verbose and incorrect. This anecdote explains the operational pain the proposed agent is meant to reduce. It is not a benchmark, and the talk gives no accuracy measurement for the example.

The important failure is context quality. A long answer is not necessarily a useful answer. An FDE needs the details that affect the workflow, while irrelevant details can make the proposed process harder to understand.

The roadmap

The agent is described as three connected stages. They move from understanding the customer, to checking a workflow while it is built, to handling small changes with less direct FDE involvement.

Click to enlarge

Caption: Slide titled “3 Pillars of the Agent” showing three connected agent columns.

The slide supports the roadmap of customer-facing engagement, workflow-level assistance, and end-to-end workflow agents. Its Development Agent column is visible, but the image does not label that column as being in development. That status comes from Pruitt’s spoken explanation.

Stage 1: an engagement agent builds customer understanding

The first stage is an engagement agent. Its job is to help with the discovery work that comes before reliable automation.

The agent receives heterogeneous customer inputs, such as:

• meeting or interview notes;
• process documentation; and
• PowerPoint slides.

It then helps ask questions that an FDE must answer. For example, it may help determine who is responsible for a process and whether two differently written references point to the same person. Pruitt gives the kind of identity problem that appears in messy customer information: an email may use one spelling, while a Slack message uses another spelling, even though both refer to one employee.

This stage is not the same as replacing customer interviews. Its purpose is to help the FDE organize and interpret the information gathered during engagement. The human still supplies the relationship and the deeper process understanding that the earlier chapters identified as central to FDE work.

In practical terms, the engagement agent helps the FDE answer two connected questions: what does this customer actually do, and who is involved?

That answer becomes the basis for constructing a workflow. If the initial understanding is incomplete, later automation can be aimed at the wrong process or assigned to the wrong owner.

Stage 2: a workflow agent checks the design as it is constructed

The second stage is a workflow agent embedded in the platform beside the model that is constructing the workflow. Its role is not merely to produce another independent summary. It checks the workflow being built.

For example, it might point out that:

• an edge case was forgotten; or
• a process owner is missing or assigned incorrectly.

This gives the FDE a chance to correct the workflow before deployment. The sequence matters:

1. The engagement agent helps gather and organize customer context.
2. A model uses that context to construct a workflow.
3. The workflow agent reviews the construction for omissions and ownership problems.
4. The FDE can fix the design before it becomes an operational agent.

The two agents therefore solve different problems. The engagement agent helps build the understanding that the workflow needs. The workflow agent checks whether that understanding has been turned into a sufficiently complete workflow. Treating them as one generic chatbot would hide this division of responsibility.

The talk does not provide an accuracy rate, a complete evaluation procedure, or the exact safeguards used by this checking agent. The claim is about the intended function: catching issues during workflow construction.

Stage 3: an autonomous assistant handles routine changes

The third stage is an autonomous assistant for small, routine workflow updates requested by a client. Pruitt explicitly says this stage is still in development.

His example is a client email saying that a quality-control report should go to a different recipient. A future agent could:

1. read the request;
2. look up the relevant company context;
3. identify the affected workflow on the platform; and
4. update that workflow.

The intended result is not general autonomous operation of the customer’s enterprise. It is a bounded update that would otherwise require an FDE to handle manually. The FDE would spend less time on routine workflow minutiae and more time interviewing customers and understanding how their processes work.

The boundary is important. The speaker describes the capability as a future direction, not as a completed system. The transcript supplies no details about approval rules, rollback behavior, evaluation metrics, or other safeguards for autonomous changes. Those details would be necessary before treating the example as a production design.

How the stages fit the FDE role

The three stages form a leverage loop:

flowchart LR
    A[Customer notes, documents, and slides] --> B[Engagement agent\norganizes context and ownership]
    B --> C[Workflow construction]
    C --> D[Workflow agent\nflags omissions and ownership errors]
    D --> E[Deployable customer workflow]
    E --> F[Routine client-requested update]
    F --> G[Autonomous assistant\nfuture stage]
    G --> E
    B -. preserves FDE time for interviews .-> H[FDE discovers how the customer works]

The first two stages support human-led discovery and design. The third stage is intended to automate a narrower class of follow-up changes. This matches the broader argument of the talk: AI can provide leverage without removing the human work that supplies customer-specific context.

The central distinction

The proposed FDE agent is not just a faster document summarizer. Its stages correspond to three different points in the lifecycle of a bespoke enterprise workflow:

Stage	Main question	Intended contribution
Engagement agent	“What is true about this customer’s operation?”	Organize context, process responsibility, and identity.
Workflow agent	“Did we construct the workflow correctly and completely?”	Flag missing edge cases and ownership errors before deployment.
Autonomous assistant (in development)	“Can this small requested change be applied without routine FDE work?”	Look up context and update a workflow on the platform.

The progression also explains why the agent is connected to the FDE rather than presented as a standalone replacement for the role. The FDE supplies judgment, communication, and discovery. The agents reduce the cost of handling context, checking workflow details, and applying routine changes. In the speaker’s proposal, that combination lets scarce FDE capacity reach more customer work without abandoning the embedded relationship.