In the previous chapter, we saw that an FDE (forward-deployed engineer) investigates a customer's actual work and maps its workflow. The next responsibility described by the speaker is not to add AI to that workflow afterward. It is to redesign how the work itself proceeds around AI. The speaker explains that it is not enough to simply "slap AI onto a broken process."
As background, the speaker gives figures related to pilots: about 95% in one example and 87% in another. He uses them to describe the problem of pilots failing to reach production or produce measurable ROI (return on investment). These are figures cited by the speaker. The talk does not give the definitions, comparison groups, or measurement methods behind them. Therefore, they should be read as material supporting the importance of process design, not as statistics that are known to apply generally.
The cause is not only whether a model can produce an answer. If we introduce a model without understanding the underlying workflow and the operator's situation, its output may look correct but still fail to fit the way the work is done. For example, the AI cannot produce an executable proposal if it does not know who approves, which information is checked first, or who receives an exception. The process investigation from the previous chapter prepares us to find these mismatches.
Example: Suppose expense processing often goes wrong because operators check items in the wrong order. If we simply ask AI to "automate the checking," it may make one task faster while leaving the original problems of approval order and exception handling in place. We should first review the process, decide which parts AI should handle and which parts people should judge, and then design the automation.
The speaker also uses a contrast with coding. Even when AI advances the work of writing code, people still provide the goal and the necessary inputs in some situations. But operators in finance, sales, marketing, procurement, and logistics each have different business knowledge. Work that looks similar does not necessarily have the same context. Simply providing a model or an API therefore does not mean that the operation has become AI-centered.
Redesign creates a tension between ease of adoption and the size of the value. If the replacement is completely different from today's work, users cannot understand how to operate it. If it is almost the same as today's work, the value may not justify the cost of change. In the speaker's explanation, a replacement must be familiar enough for the operation to use, but new enough to create measurable value. That value includes more than time saved; it also includes effects on cost, revenue, and risk.
Example: Even if an eleven-step operation can be compressed into one step, adoption will not progress if users cannot understand what was removed and where they should make a judgment. Conversely, if AI handles several steps behind the scenes while clearly showing users the checks they need to make, people may accept the change more easily. This illustrates that shortening work and redesigning work are not the same thing.
各ステップに適切な自動化の境界を置く
Set the right automation boundary for each step
話者は、業務の各ステップを三つの種類に分ける考え方を示します。
The speaker presents an approach that divides each workflow step into three types.
AIが自律的に処理するステップ
**Human-in-the-loop（人間が途中で確認・介入する方式）**のステップ
最初から最後まで人が担当するステップ
A step that AI handles autonomously
A human-in-the-loop step, where a person checks or intervenes during the work
For example, an eight-step flow might allocate four steps to autonomous handling, three to handling with human intervention, and one to human-only handling. This is an explanatory example for adjusting the boundary according to risk and value, not a template that every company must use. In a human-in-the-loop step, AI advances part of the work and a person checks or corrects it when needed. A human-only step is different. We may decide not to automate it because the risk is too high or because adding AI would not create enough value.
Figure: A slide showing a sequence in which FDEs understand current work, redesign the process around AI, and deploy agents on top of existing systems.
This slide supports the explanation that an FDE's work is not just handing over a tool. It involves investigating existing work, changing it to fit AI, and deploying it in the real environment. However, the image does not show the specific 4-3-1 allocation of the eight steps described above.
In this way, the understanding of work from the previous chapter leads to automation decisions for each step. The resulting workflow must then be implemented on the company's existing systems so that it can operate in practice. The next chapter covers the idea of placing agents on top of those existing enterprise systems.
Some parts of the talk contain uncertain transcription, and the expression "gold loops" is unclear. The talk also does not identify which formal customer case, if any, the 95%, 87%, or 4-3-1 figures represent. Here they are treated as the speaker's claims and explanatory examples only to the extent supported by the available material.