Re-engineer the workflow around AI

The previous chapter showed why an FDE must first discover how work really happens. This chapter takes the next step: redesign that work around AI.

The key distinction is adding AI to a process versus designing a process in which AI has a useful role. The speaker warns against “slapping AI onto broken processes.” If the original process has unclear ownership, unnecessary handoffs, or steps that do not fit the operator's work, putting a model on top of it does not remove those problems. It may only produce an answer that is technically plausible but unusable in the customer's operation.

Source claim: The speaker presents this redesign as the FDE's second responsibility. He connects a mismatch between the process and the AI pilot to poor outcomes, including pilots that do not reach production or do not produce measurable ROI.

Why a capable model can still fail

An AI system does not operate in a vacuum. Its output must enter a real workflow. Someone must know what the output means, decide what to do with it, and handle the cases where the normal path does not apply.

That creates a causal chain:

1. The business has an existing process.
2. The process contains local rules, dependencies, and operator knowledge.
3. A pilot is designed without understanding those details.
4. The model produces an output that does not fit the way the work is actually performed.
5. The pilot may look impressive in isolation but fail to become a production process or show measurable value.

This is why workflow redesign is different from model selection. A better model can improve execution, but it does not by itself decide which steps should change, which context operators need, or where accountability should remain.

The speaker cites figures of 95% and 87% while discussing unsuccessful AI pilots. These figures are references made in the talk, not independently documented measurements here: the source supplies no study definitions, baselines, or methodology. The safe lesson is therefore not that these exact percentages apply universally. It is that a pilot can fail at the boundary between a model and the surrounding operation.

Adoption requires both familiarity and change

There is a tension in replacing an existing workflow. A replacement must be familiar enough that the people who use it can understand and operate it. At the same time, it must be different enough to create measurable value. A redesign that changes nothing has little upside. A redesign that feels unrelated to the operator's work may not be adopted.

The talk illustrates this tension with an eleven-step workflow compressed into one step. Compression can be valuable because it removes effort. But the number “one” does not prove that the new process is better. Operators still need to understand what the new step does, what information it needs, and what happens when it cannot complete the work. The illustration is about adoption and value, not a universal rule that every workflow should become a single action.

The speaker makes a related point through a coding analogy. Even when an AI system performs much of the execution, human input still matters. A person provides direction and context. The kind of context differs by domain: a finance operator, salesperson, marketer, procurement specialist, and logistics operator do not know the same things or judge risk in the same way. A workflow cannot be redesigned well by assuming that every operator has the context or skills of a software engineer.

In practical terms, re-engineering around AI asks questions such as:

• Which parts of the current process are repetitive and well specified?
• Which parts require a person to interpret local business context?
• Which failures are safe to recover from automatically?
• Which decisions need approval or must remain with a human?
• What would make the new process useful enough to adopt and valuable enough to justify the change?

These questions turn the FDE's earlier workflow map into design decisions.

Click to enlarge

Visual at 06:42: A slide titled “Why We Need FDEs” presents three reasons for forward deployed engineering.

The slide supports the broader progression in the talk: FDEs map existing work, redesign processes around AI, and deploy agents over existing systems. It does not show the specific eight-step allocation described below, so that allocation should be read as the speaker's illustration rather than as information visible in this frame.

Calibrate autonomy one step at a time

The speaker proposes dividing a workflow into three kinds of work:

1. Autonomous steps — the agent performs the step without a person intervening in the normal case.
2. Human-in-the-loop steps — the agent performs part of the work, but a person reviews, approves, corrects, or supplies an important decision before the process continues.
3. Human-only steps — the step remains with a person rather than being assigned to the agent.

This is calibrated automation. It does not ask whether the whole workflow should be automated. It asks what level of autonomy is appropriate for each step.

For example, the speaker gives an illustrative eight-step allocation:

Allocation	Number of steps	Meaning
Autonomous	4	The agent handles these steps in the normal path.
Human-in-the-loop	3	The agent assists, but a person remains part of the decision or control path.
Human-only	1	A person handles this step.

The numbers are an example, not a universal template or a confirmed customer workflow. The important idea is the reasoning behind the allocation. An autonomous step should be sufficiently understood and low-risk for that level of control. A human-in-the-loop step is useful when AI can reduce effort but a person should still check the result. A human-only step may be necessary because the risk is too high, or because the agent's contribution would not be valuable enough to justify the change.

Human-in-the-loop does not mean “the human does the whole job while the AI watches.” It means responsibility is shared in a defined part of the step. By contrast, a human-only step places the work outside the proposed agent path. Keeping one step human is not necessarily a failure of automation. It can be the correct design when safety, accountability, or limited expected value matters more than maximum automation.

The FDE's design responsibility

The FDE therefore performs more than an implementation task. The FDE uses the discovered process to decide how the future process should work:

Map the real process
        ↓
Identify dependencies, exceptions, and operator context
        ↓
Split the workflow into meaningful steps
        ↓
Assign each step an autonomy level
        ↓
Test adoption and measurable value

This sequence explains why the chapter follows workflow mapping. Without the map, the autonomy choices are guesses. Without step-level choices, “AI transformation” remains a vague promise. The design must preserve enough human involvement for risky or context-heavy work while removing effort where an agent can help.

The next chapter moves from process design to deployment. Once an FDE has redesigned a workflow, the agent still has to operate with the enterprise systems that hold the customer's work. In other words, workflow re-engineering decides what the AI-centered process should be; platform integration decides where that process can run.

Takeaway

AI creates value through a workflow, not beside one. The FDE's job is to understand the existing operation and deliberately allocate work among autonomous, human-in-the-loop, and human-only steps. That is how a pilot can become an adopted process instead of a model demonstration attached to a broken workflow.