Taming AI Chaos: The Rise of the Enterprise Superagent - Presentation by KPMG

Taming AI Chaos: The Rise of the Enterprise Superagent - Presentation by KPMG — Ai4

Ai4

AI-assisted summary of Taming AI Chaos: The Rise of the Enterprise Superagent - Presentation by KPMG — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 18, 2026, this presentation features Mark Shank, Google Cloud Leader and banking AI lead at KPMG. According to the description, the session explores how organizations can transition away from building disconnected bots to orchestrating real business outcomes with enterprise Superagents built in partnership with Google Cloud.

## TL;DR Mark Shank deconstructs the post-demo 'AI psychosis' that leads enterprises into either brittle, overloaded prompt files or rigid, 12-week bespoke framework builds. He argues against creating proprietary agent harnesses, recommending instead that organizations build process-centric control planes around standard platforms and revive formal process maps as dynamic finite state machines. Deployment is spearheaded by Forward Deployed Engineers who bypass toy sandboxes to solve live workflow bottlenecks for a single domain expert, controlling the operational blast radius before scaling outward. This architecture culminates in enterprise 'superagents' that invert conventional human-AI workflows by orchestrating end-to-end business processes and delegating complex exceptions back to people.

## Atmosphere & style The presentation carries a pragmatic, refreshingly candid, and battle-tested tone that cuts through Silicon Valley marketing hype with wry humor about executive overexcitement and corporate slideware. Shank delivers his message with authoritative ease and directness, blending nuanced architectural analysis with relatable operational pain points. Listening feels like attending an insider strategy debrief that replaces utopian promises with hard-won engineering discipline and realistic corporate delivery realities.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=4s) Initial enterprise AI proof-of-concepts often trigger 'AI psychosis'—an overhyped expectation of overnight transformation that quickly stalls against practical enterprise production hurdles. - [01:51](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=111s) Overloading agent skill files leads to non-determinism and constant babysitting, delivering modest 10% to 20% productivity gains rather than true workflow transformation. - [01:51](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=111s) Custom-built agent frameworks require 10 to 12 weeks of squad engineering per use case and suffer from 'RPA Lite' fragility when underlying foundation models are updated. - [05:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=304s) Formal process maps can be rehabilitated as finite state machine references for agents, providing the 'letter of the law' while models dynamically interpret the 'spirit of the law' without rigid RPA scripting. - [06:41](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=401s) Enterprises should avoid building proprietary agent harnesses unless they plan to co-train and fine-tune foundation models directly against the harness. - [09:36](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=576s) Engineering teams must shift focus from bespoke harnesses to robust control planes, implementing shell-level hooks and validation checks to ensure viable unit economics and governance. - [12:11](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=731s) Connecting agents to data requires higher-level, process-centric tool layers rather than simplistic CRUD database wrappers to ensure compliance, auditability, and guardrails. - [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) Forward deployed engineers (FDEs) represent the crucial delivery role of 2026, reorienting the SDLC away from isolated toy demos toward building directly in production from day one. - [14:18](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=858s) Production risk is managed by strictly controlling the blast radius, pairing an FDE with a single domain expert before incrementally expanding adoption to teams of 5 and 10. - [16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) Enterprise superagents invert the traditional AI paradigm by taking ownership of the end-to-end business process and delegating edge cases and human judgment tasks to workers. - [17:39](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=1059s) Sustainable enterprise AI transformation succeeds by starting narrow with embedded practitioner tools and scaling architectural governance outward alongside user adoption.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=4s) Introduction and the "AI Psychosis" Demo Trap

Mark Shank introduces himself as the Google Cloud leader for KPMG and the firm's AI sector leader for banking, drawing upon direct experience implementing AI agents internally and for enterprise clients. After joking about making the trek to the back of the fifth floor and using modern generative AI tools to whip up comic illustrations that previously took a week of graphic design work, he describes a classic enterprise scenario that triggers an initial wave of euphoria. A team identifies a use case, cobbles together a data connector or Model Context Protocol (MCP) server, drafts a skill file, drops it into an agent harness like Gemini Enterprise, and runs a successful live demo.

The demo performs smoothly, triggering what Shank calls an immediate wave of "AI psychosis" where leadership and teams convince themselves that the entire business is about to be completely revolutionized overnight. However, that early excitement invariably slams into practical enterprise realities, forcing organizations down one of two fraught paths to production.

```mermaid flowchart TD accTitle: The Two Flawed Paths of Enterprise Agent Deployment

subgraph S1["Initial POC Phase"] A["Connector / MCP + Skill File"] --> B["Successful Demo"] B --> C["'AI Psychosis' (Overhype)"] end

subgraph S2["Path 1: Overloaded Skill Files"] C --> D["Hundreds of Directives"] D --> E["Non-Determinism & Babysitting"] E --> F["Modest 10-20% Gains"] end

subgraph S3["Path 2: Bespoke Frameworks"] C --> G["Custom Build (LangGraph / ADK)"] G --> H["10-12 Week Enterprise Cycles"] H --> I["'RPA Lite' & Model Fragility"] end ```

[01:51](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=111s) The Dilemma: Prompt Brittleness vs. Bespoke Agent Development

When organizations attempt to mature their early prototypes, they encounter steep operational bottlenecks regardless of which development approach they choose:

1. **Overloaded Skill Files and Agent Babysitting:** As teams add instructions to an agent's skill file, models struggle to reliably follow them. Once directives reach a few hundred instructions, non-determinism sets in and the agent begins to fail, forcing knowledge workers to babysit the system constantly. Shank compares this to the 2024-era coding assistant boom (such as Cursor), where empirical studies revealed developers achieved only a 10% to 20% productivity lift—a helpful boost, but far from the transformative revolution enterprise leaders expected. 2. **Heavyweight Bespoke Builds:** Alternatively, organizations assign an agile engineering squad to construct a "real agent" from scratch using frameworks like LangGraph or Agent Development Kits (ADKs). Because enterprise deployment requires strict compliance, security, and governance gates, shipping even a single agent takes 10 to 12 weeks of dedicated squad effort. This timeline cannot scale across the thousands of cataloged use cases in an enterprise backlog. 3. **The "RPA Lite" Fragility Trap:** Bespoke multi-agent harnesses frequently end up baking in brittle logic tailored around the specific "jagged intelligence" of a particular foundation model version. When model providers update or deprecate a model, the enterprise agent's behavior shifts or degrades, breaking production workflows. Shank gives a brief nod to the Databricks meta harness launched several weeks prior as an emerging effort to tackle these evaluation and orchestration headaches.

[05:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=304s) Rehabilitating Process Mapping: Finite State Machines Without the RPA Trap

Shank addresses a controversial topic in enterprise architecture: reviving formal process mapping. While process mapping carries a negative corporate reputation because diagrams historically "sat on a shelf" after being drafted once, committing to maintaining a formal process map creates an ideal finite state machine for AI agents to query.

The critical difference that prevents this architecture from devolving into rigid Robotic Process Automation (RPA) is that the process map serves as a *reference*, not a rigid boundary:

- **Reference vs. Bounding:** The agent queries the map as a dynamic tool to discover valid next steps and transitions rather than executing hard-coded deterministic scripts. - **Letter vs. Spirit of the Law:** The formal process map represents the "letter of the law," while the LLM-powered agent acts as the "spirit of the law," dynamically interpreting context and applying discretion at each stage.

[06:41](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=401s) The Illusion of the Custom Agent Harness

Most off-the-shelf enterprise agent harnesses are designed primarily as an "exoskeleton of the information worker"—boosting individual task efficiency rather than restructuring end-to-end enterprise operations. While individual productivity gains are valuable, they fall short of answering what an AI-native operational model (such as an AI-native procurement or procure-to-pay lifecycle) should look like with built-in auditability, transparency, and governance.

Despite these limitations, Shank strongly warns enterprises against building their own agent harnesses from scratch:

- **The Post-Training Hurdle:** Building a proprietary harness is only justified if an organization is prepared to post-train and fine-tune models directly on that harness. Very few enterprises have the appetite or capital to clear that hurdle rate. - **Tighter Model-Harness Coupling:** Frontier labs (such as DeepSeek, Poolside, and Moonshot AI's Kimi) are designing foundation models and execution harnesses as co-dependent systems trained against each other. Attempting to maintain a generic custom harness without model co-training creates an unsustainable engineering burden.

```mermaid flowchart LR accTitle: Exoskeleton vs Process-Centric Agent Harnesses

subgraph Exoskeleton["Worker-Centric Exoskeleton"] direction TB W["Individual Worker"] --> H1["Off-the-Shelf Harness"] H1 --> T1["Task Speedup (10-20%)"] end

subgraph ProcessCentric["Process-Centric Superagent"] direction TB P["Enterprise Process"] --> H2["Platform Harness + Custom Control Plane"] H2 --> T2["End-to-End Governance & Native Automation"] end ```

[09:36](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=576s) Building Process-Centric Infrastructure and Control Planes

Instead of building a bespoke harness, enterprise engineering should focus on building the control plane and infrastructure *around* existing harnesses. Shank emphasizes that automating real enterprise work has proven far more costly and challenging than early AI marketing suggested, making a well-structured control plane essential for viable unit economics.

To achieve robust governance without sacrificing model adaptability, teams must shift from basic data piping to process-aware tooling:

- **Shell-Level Hooks:** Governance should be enforced at the harness shell level. Platforms like Claude Code provide customizable pre-tool call and post-tool call hooks that execute deterministic validation checks against tool invocations. - **Process-Centric Tool Abstractions:** If MCP servers and tools are implemented as simplistic, one-to-one database wrappers, extracting governance and auditability becomes nearly impossible. MCPs and tool definitions must expose higher-level, process-centric abstractions that reflect operational milestones rather than raw CRUD operations.

[12:11](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=731s) The Process-Oriented Tool Layer and Governance

Establishing a dedicated tool layer directly above underlying data connectors bridges the gap between raw data access and actual business execution. Rather than exposing low-level system integrations directly to agents, wrapping those connectors into a structured, process-oriented tool layer provides the necessary operational controls. This architecture ensures that when models interact with core systems, they operate within strictly defined guardrails that enforce enterprise governance.

This structural separation is what unlocks true software reusability while guaranteeing reliability. By mediating interactions through curated, process-centric tools, organizations can achieve the institutional trust, repeatability, and factual accuracy required to run complex, automated processes reliably across an enterprise.

[12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) The Forward Deployed Engineer: The SRE of 2026

Turning architectural concepts into reality requires rethinking the delivery model. The term "forward deployed engineer" (FDE) has emerged as the defining "zeitgeist term in 2026," with every major hyperscaler—Google included—rolling out large-scale FDE initiatives. The sudden ubiquity of the role mirrors the historic rise of the site reliability engineer (SRE), rapidly shifting from an obscure title to an essential discipline that every enterprise suddenly feels compelled to staff. However, because the title has spread so quickly, organizations risk misunderstanding the mission; treating an FDE like a "glorified sales engineer" fundamentally misses the mark.

The core objective of the forward deployed engineering model is not to add a flashy pre-sales phase before handing off work to a slow, traditional software development life cycle (SDLC). Instead, it requires fundamentally reorienting the SDLC itself toward shipping small, functional slices directly into production. The defining distinction between an FDE and the endless parade of isolated lab experiments and toy demos that have dominated enterprise AI is stark and uncompromising: a forward deployed engineer builds in production from day one.

[14:18](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=858s) Production Deployment and Controlling the Blast Radius

Deploying directly into production often sounds alarming to traditional IT and risk leaders who immediately question the safety mechanisms. The safeguard in this model is not an isolated sandbox; it is the deliberate limitation of scale and "blast radius." Rather than waiting months to build an enterprise-wide application, an FDE embeds directly with a single individual—often the star practitioner in a department like procurement who knows the operational nuances better than anyone and spends their day navigating painful "swivel chair computing" across disconnected systems. The FDE crafts customized, production-grade tools tailored specifically to eliminate friction for that one power user, working with real business data rather than sanitized test data in a lab.

```mermaid flowchart TD accTitle: FDE Blast Radius Scaling Model accDescr: Flow diagram showing how forward deployed engineers scale AI tools from a single user to production teams with expanding governance.

subgraph Phase1["Phase 1: Seed in Production"] A["FDE pairs with 1 Domain Expert"] --> B["Build tools for real workflow"] B --> C["Solve manual swivel-chair tasks"] end

subgraph Phase2["Phase 2: Controlled Expansion"] C --> D["Expand to immediate team: ~5 users"] D --> E["Expand to department: ~10+ users"] end

subgraph Phase3["Phase 3: Production Hardening"] E --> F["Uncover and patch corner cases"] F --> G["Layer on enterprise controls & governance"] end ```

Once that primary user is successfully running the tools in their live daily workflow, the solution expands along a controlled gradient. The engineer introduces the tooling to the user's immediate team of five, then broadens it to ten, encountering and handling real-world corner cases at each incremental step. Governance, safety checks, and enterprise controls are layered on organically as the blast radius widens. This controlled rollout explains how forward deployed engineering teams can credibly claim they delivered working production AI within weeks: they genuinely reached production, but did so within a tightly managed, risk-controlled cohort.

- Forward deployed engineers bypass artificial sandbox testing to solve real workflow bottlenecks in live production. - Risk is governed through intentional blast-radius containment, starting with a single domain expert. - Iterative user expansion (1 user to 5, then to 10) surfaces edge cases gradually before full-scale deployment.

[16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) Inverting the Dynamic: Superagents and Human Delegation

The concept of the "superagent" brings these architectural layers and delivery paradigms together by managing risk at the macro-process level. Rather than deploying isolated chatbots, a superagent acts as an orchestrator that shares a unified workspace with human workers. This model completely flips the traditional mental model of AI. While earlier paradigms framed the agent as a passive "exoskeleton" wrapped around an information worker, an enterprise superagent takes ownership of orchestrating and driving the entire workflow from end to end.

Under this inverted dynamic, the superagent manages the business process and directly delegates tasks to human professionals when necessary. Whenever an agent encounters an edge case, lacks a dedicated automated tool, or requires human judgment to satisfy workflow criteria, it routes the assignment to a person inside the shared work surface. By placing the AI in the orchestrator seat while keeping humans seamlessly in the loop to handle complex exceptions, enterprises fundamentally transform how work is distributed and completed.

[17:39](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=1059s) Scaling Smartly: Embedding, Governed Delivery, and Wrap-Up

In a rapid 90-second close, the entire strategy boils down to starting narrow in order to scale sustainably. Although the forward deployed engineer is often discussed as an implementation detail, the entire transformation actually begins with them on the ground. Success hinges on placing an FDE alongside an embedded domain expert to build live, working solutions directly into their daily routine.

By delivering governed production software from the outset, engineering teams establish the essential architectural hooks required for enterprise operations. From that proven foundation, the tools and superagent workflows can expand outward across broader teams, scaling governance, compliance, and automated orchestration in tandem with user adoption. With a humorous nod of thanks to the room for staying engaged rather than looking at their phones, the session concludes with an invitation to continue the conversation one-on-one.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=4s) A team identifies a use case, cobbles together a data connector or Model Context Protocol (MCP) server, drafts a skill file, drops it into an agent harness like Gemini Enterprise, and runs a successful live demo. — Mark Shank

> [01:51](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=111s) Once directives reach a few hundred instructions, non-determinism sets in and the agent begins to fail, forcing knowledge workers to babysit the system constantly. — Mark Shank

> [05:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=304s) The formal process map represents the 'letter of the law,' while the LLM-powered agent acts as the 'spirit of the law,' dynamically interpreting context and applying discretion at each stage. — Mark Shank

> [06:41](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=401s) Building a proprietary harness is only justified if an organization is prepared to post-train and fine-tune models directly on that harness. Very few enterprises have the appetite or capital to clear that hurdle rate. — Mark Shank

> [09:36](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=576s) Automating real enterprise work has proven far more costly and challenging than early AI marketing suggested, making a well-structured control plane essential for viable unit economics. — Mark Shank

> [09:36](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=576s) If MCP servers and tools are implemented as simplistic, one-to-one database wrappers, extracting governance and auditability becomes nearly impossible. — Mark Shank

> [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) The defining distinction between an FDE and the endless parade of isolated lab experiments and toy demos that have dominated enterprise AI is stark and uncompromising: a forward deployed engineer builds in production from day one. — Mark Shank

> [14:18](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=858s) The safeguard in this model is not an isolated sandbox; it is the deliberate limitation of scale and 'blast radius.' — Mark Shank

> [16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) Under this inverted dynamic, the superagent manages the business process and directly delegates tasks to human professionals when necessary. — Mark Shank

> [17:39](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=1059s) Although the forward deployed engineer is often discussed as an implementation detail, the entire transformation actually begins with them on the ground. — Mark Shank

## Mentioned Mark Shank, KPMG, Google Cloud, Ai4, Gemini Enterprise, Model Context Protocol (MCP), Cursor, LangGraph, Agent Development Kits (ADKs), Databricks, DeepSeek, Poolside, Moonshot AI (Kimi), Claude Code

## Video description Mark Shank - Google Cloud Leader, KPMG

Discover how to stop building disconnected bots and start orchestrating real business outcomes with Superagents built by KPMG and Google Cloud.

[Source](https://www.youtube.com/watch?v=7k3K-Efd54Y)

中文简报

治理AI乱象:企业超级智能体的崛起——毕马威演讲 Mark Shank 剖析了演示之后出现的“AI精神病”(AI psychosis)现象,这种状态导致企业要么陷入脆弱且过载的提示词文件,要么耗费12周去构建僵化的定制框架。他反对创建专有的智能体运行架构,转而建议企业围绕标准平台构建以流程为中心的控制平面,并将形式化流程图重新激活为动态有限状态机。部署工作由前线部署工程师(Forward Deployed Engineers)牵头,他们绕开玩具式的沙盒环境,直接为单个领域专家解决实际工作流瓶颈,从而在向外扩展前控制运营影响范围。这种架构最终催生了企业“超级智能体”,通过编排端到端业务流程并将复杂异常情况交还人工处理,彻底颠覆了传统的“人-AI”工作流。 企业初期的 AI 落地常陷入过度期待的“AI 精神病”幻觉,塞满指令的技能文件仅带来 10% 至 20% 的微弱提效,而定制开发框架每个用例需耗费 10 到 12 周且极易因底层模型更新而失效。 (1:51) 将正式业务流程图重构为智能体查询的有穷状态机(FSM),能让流程图提供框架约束的“法律条文”,由大模型动态解释“法律精神”,避免陷入传统 RPA 的脆弱与僵化。 (5:04) 企业应停止从零自建专有 Agent 底座,转而重点构建控制平面,利用 Shell 级校验钩子与面向业务流程的高阶工具层来确保合规、审计及合理的单位经济效益。 (9:36) 前向部署工程师(FDE)成为 2026 年的关键交付角色,他们摒弃沙盒玩具演示,从第一天起就与一线业务专家结对在生产环境中开发,并通过受控的爆炸半径逐步扩大应用规模。 (12:43) 企业超级智能体(Superagent)彻底逆转了人机交互逻辑,从被动的个人辅助外骨骼转变为端到端业务流的编排中枢,并在遇到边缘特例或需人工裁决时主动向人类员工委派任务。 (16:10)

Reading summary

Mark Shank of KPMG argues that enterprise AI initiatives stall when caught between brittle prompt files and unscalable custom builds. To reach reliable production scale, organizations must adopt process-centric control planes, deploy embedded forward deployed engineers within controlled blast radii, and invert workflows using superagents that orchestrate processes and delegate exceptions to humans. The Traps of Prompt Overload and Bespoke Builds (1:51) Shank observes that initial proof-of-concept successes routinely ignite an "AI psychosis," convincing leaders that operations will transform overnight. In reality, teams hit two major bottlenecks when moving to production. Attempting to manage agents via skill files degrades performance once directives reach hundreds of instructions; the resulting non-determinism forces constant human babysitting and yields modest 10% to 20% productivity gains, comparable to developer outcomes with 2024-era tools like Cursor. Conversely, constructing bespoke agents from scratch using frameworks like LangGraph or Agent Development Kits (ADKs) requires 10- to 12-week squad cycles to satisfy enterprise compliance, rendering backlogs of thousands of use cases unmanageable. Furthermore, these custom builds risk becoming brittle "RPA Lite" workflows that fail whenever foundation model providers alter or deprecate underlying models. Process Mapping and Harness Control Planes (5:04) Rather than attempting to build proprietary agent harnesses from scratch—an effort Shank cautions requires massive capital to co-train models alongside the harness, as seen in frontier labs like DeepSeek, Poolside, and Moonshot AI—enterprises should focus on building control planes around existing harnesses. This requires rehabilitating formal process mapping to serve as a dynamic finite state machine. Operating as a reference rather than a rigid script, the process map establishes the "letter of the law," while the agent applies contextual discretion as the "spirit of the law." At the technical layer, governance must be enforced through harness shell hooks—such as pre- and post-tool call validations in Claude Code—rather than generic data piping. Teams must replace basic, CRUD-style Model Context Protocol (MCP) server wrappers with higher-level, process-centric tool abstractions that capture true business milestones and maintain auditability. Forward Deployed Engineering and Controlled Blast Radii (12:43) To implement these architectures, Shank highlights the forward deployed engineer (FDE) as an essential discipline akin to the historical rise of the site reliability engineer (SRE). Unlike pre-sales staff or lab-bound developers running sandboxed demos, FDEs build directly in live production environments from day one. Risk is managed by strictly controlling the initial "blast radius": the engineer embeds directly with a single operational expert, such as a procurement practitioner managing fragmented "swivel-chair computing," to automate friction points using real operational data. Once proven, the tooling expands incrementally to five and then ten users, surfacing real-world edge cases while layering on compliance, security, and governance controls as adoption scales. Superagents and Inverting the Delegation Model (16:10) The superagent architecture brings these layers together by shifting AI from an individual worker "exoskeleton" to an end-to-end process orchestrator. Instead of acting as passive assistants responding to human prompts, superagents manage macro-level business workflows within a shared operational surface. In this inverted model, the agent drives the process forward and actively delegates tasks to human specialists whenever it encounters edge cases, lacks specific tooling, or requires expert discretion, establishing a reliable division of labor between automation and human judgment. Shank concludes that sustainable enterprise AI transformation does not stem from building massive proprietary harnesses or isolated sandboxes, but from placing forward deployed engineers alongside domain specialists to deliver small, governed production slices that scale systematically alongside user adoption.

精炼阅读摘要

毕马威(KPMG)技术与银行业AI主管Mark Shank指出,企业在概念验证成功后常陷入“AI精神病式的盲目乐观”,但随后会在提示词过载与高昂定制周期的两难中受挫;企业应放弃从零自研智能体基座,转而利用业务流程图构建有限状态机控制面,并通过驻场部署工程师(FDE)以极小爆炸半径在真实生产环境中迭代,最终演变为由超级智能体统一编排业务并反向向人类委派边缘任务的协作体系。 概念验证幻觉与智能体落地的工程瓶颈 (1:51) Mark Shank指出,工程团队利用模型上下文协议(MCP)和技能文件拼凑原型并顺利演示后,常引发管理层产生业务一夜颠覆的“AI精神病”。然而,当企业试图将原型投入生产时,往往被迫在两条充满缺陷的路径中抉择:第一种路径是不断向技能文件追加提示词,但当规则达到数百条后,大模型的非确定性便会导致频繁失控,迫使知识工作者陷入无休止的人工照看(babysitting)。Shank援引2024年以Cursor为代表的编程助手经验指出,实证研究表明该模式仅带来10%至20%的生产力提升,远未达到管理层预期的颠覆性变革。 若选择第二种路径,组建敏捷工程团队利用LangGraph或智能体开发套件(ADK)从零定制复杂系统,受制于企业合规、安全和治理门槛,交付单个智能体通常需要耗费10至12周的工程周期,根本无法应对企业积压的成千上万个业务场景需求。更严峻的是,定制多智能体框架往往依据特定基础模型的“锯齿状智能”(jagged intelligence)固化了脆弱逻辑,一旦底层模型升级或被弃用,工作流便会失效,沦为脆弱的“轻量级RPA”。 有限状态机重构与流程中心化控制面 (5:04) 为规避非确定性且不陷入RPA的死板逻辑,Shank主张重构曾被企业弃置的正式业务流程图,并将其转变为供智能体调用的动态“有限状态机”。这一架构的关键在于流程图仅作为可查询的参考框架,而非硬编码的执行边界:正式流程图代表不可违背的“法律条文”,明确合规的状态转换与动作;而大语言模型则充当“法律精神”,负责理解上下文并在每个环节中行使裁量权。 在工程实现层面,治理必须沉淀在智能体基座外围的控制面上,而非简单的底层数据读写。Shank强调,若将MCP等工具仅作为数据库CRUD接口的简单封装,将极难实现合规与审计。企业应当在基座Shell层设置类似于Claude Code的工具调用前置与后置钩子(hooks),并把数据连接器包装为体现业务里程碑的高阶流程抽象工具层,以此保障企业级自动化流程的可靠性、复用性与事实准确性。 放弃自研基座与工作者外骨骼的局限 (6:41) 市场上现成的商业智能体基座大多被设计为“信息工作者的外骨骼”,其核心价值在于提升个体任务的处理效率,但无法指导AI原生运营模式(例如具备内生审计与透明度的采购生命周期)的构建。即便如此,Shank仍明确警告企业不要尝试从零自研专有的智能体基座。 其核心阻碍在于高昂的技术与资金门槛:自研基座只有在企业具备能力直接针对该基座进行模型后训练(post-train)和微调的前提下才具合理性,极少有企业拥有充足的资本和技术意愿迈过这一门槛。此外,DeepSeek、Poolside以及月之暗面(Moonshot AI)的Kimi等前沿实验室正在将基础模型与执行基座作为紧密协同的系统共同训练,企业若独立维护通用的定制基座,将面临难以维系的工程与维护负担。 驻场部署工程师与受控爆炸半径交付 (12:43) 面对工程落地鸿沟,Shank将“驻场部署工程师”(FDE)定义为2026年企业级AI最重要的时代角色,其战略地位堪比当年的站点可靠性工程师(SRE)。FDE绝非售前技术支持或演示人员,其核心特征是从第一天起就直接在真实生产环境中开发,彻底告别孤立的沙盒测试与玩具演示。 针对传统IT和风控部门对直接投产的安全担忧,FDE通过严格限制“爆炸半径”(blast radius)来建立安全机制。FDE不采用人工测试数据,而是直接嵌入业务前线,与一名饱受跨系统“转椅计算”(swivel chair computing)困扰的业务骨干结对,为其量身打造消除摩擦的生产级工具。当单人运行稳定后,工具按受控梯度逐步扩展到5人团队、再至10人部门,在逐步放大的真实业务场景中捕获边缘案例,并逐层叠加企业治理与安全护栏。 超级智能体反转:端到端编排与人机委派 (16:10) 在宏观业务流程层面,“超级智能体”概念彻底颠覆了传统的人机协作模式。早期范式将AI视为包裹在知识工作者身边的被动外骨骼,而超级智能体则在共享工作空间中升格为端到端流程的主导编排者。 在这一反转模式中,超级智能体全面接管业务流程的推进与编排。每当智能体遭遇未覆盖的边缘情况、缺乏专用工具或需要专家裁决时,它会主动将任务路由并委派给共享工作空间内的人类专业人员。通过让AI担任宏观流程编排者并让人类无缝接管复杂异常,企业得以重塑工作分配机制,在保证合规与控制的前提下实现真正的大规模自主运营。 Shank总结指出,企业智能体规模化转型的核心在于“从小处着手,以受控方式持续扩展”:以驻场部署工程师结对业务专家为起点,在真实生产环境中沉淀治理控制面与流程规范,再逐步扩展至超级智能体协同网络。该演讲基于企业实践经验与行业趋势研判,但尚未深入探讨在高度监管或遗留系统极其繁杂的环境中,跨系统状态同步与复杂人机权责划分的技术细节及失败成本。

Detailed notes — zh

## Background 本视频由 YouTube 频道 Ai4 于 2026 年 8 月 18 日发布。内容记录了毕马威(KPMG)的 Google Cloud 业务负责人 Mark Shank 的主题演讲,主要探讨企业如何告别零散孤立的 Bot 开发,借助毕马威与 Google Cloud 打造的“超级智能体”(Superagent)编排并实现真实的业务成果。 ## TL;DR 演讲深入剖析了企业在经历惊艳 Demo 后的“AI 精神病”幻灭期,指出盲目堆砌技能规则与自研 Harness 极易沦为脆弱且难以维护的“轻量级 RPA”。Mark Shank 提出将业务流程映射作为有限状态机,为 Agent 提供合规的“法律条文”,并强调企业应聚焦于构建流程中心化控制面与面向业务的高阶工具层。此外,他倡导由前线部署工程师(FDE)深入生产一线、严格控制爆炸半径以渐进式扩展,最终借助能够在共享工作区中反向向人类委派任务的“超级智能体”重塑企业人机协作范式。 ## Atmosphere & style 演讲开篇以幽默自嘲的漫画切入,用“AI 精神病”等生动比喻精准击中企业在技术狂热后遭遇落地撞墙的现实焦虑。Mark Shank 凭借扎实的金融与云业务一线实践,以务实、犀利且极具信服力的语调破除行业迷思,直言不讳地指出自研底座与盲目提效的误区。整场演讲从直面困境的冷峻剖析自然过渡到构建控制面与 FDE 方法论的系统性解法,节奏紧凑且富有启发性,给观众带来兼具战略视野与实战穿透力的沉浸体验。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=4s) 概念验证阶段的 Demo 演示容易引发过度的“AI 精神病”狂热,但 Agent 在进入实际业务深水区时会迅速遭遇规则膨胀与非确定性挑战。 - [01:47](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=107s) 模型在单个 Skill 文件中能够有效遵从的指令数量存在上限,目前辅助编程等工具在实证研究中带来的真实生产力提升通常仅为 10% 到 20%。 - [01:47](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=107s) 自建的多 Agent 编排框架往往沦为脆弱的“轻量级 RPA”,其交互逻辑深度绑定特定模型版本的参差智能,在底层模型升级或废弃时极易失效停摆。 - [05:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=304s) 业务流程图应被定义为可供 Agent 查询的有限状态机,作为合规边界的“法律条文”,而 Agent 则负责在实际业务场景中充当灵活裁决的“法律精神”。 - [06:41](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=401s) 企业不应轻易自研 Agent 运行底座(Harness),除非具备针对该 Harness 进行模型后训练(Post-train)的能力,否则自研底座将带来沉重的维护包袱。 - [09:36](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=576s) 企业的工程重心应聚焦于围绕标准 Harness 构建流程中心化控制面,并通过工具调用前后的 Hook 机制建立细粒度的外壳级治理与合规审计。 - [12:11](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=731s) 工具设计必须从底层的“一对一纯数据访问接口”升维为具备“业务流程语义”的高阶操作单元,以保障端到端执行的准确性与跨系统复用度。 - [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) 前线部署工程师(FDE)的核心价值在于深入业务一线,在严格控制爆炸半径的前提下,直接在真实的生产环境中交付受控的小微用例。 - [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) FDE 采用渐进式扩展策略,初期仅与单兵能力极强的核心业务专家共创,随着受众从 1 人扩大至团队规模,再逐步叠加治理与异常处理机制。 - [16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) 超级智能体(Superagent)颠覆了传统 AI 作为人类外骨骼的单向模式,转而作为全局工作流编排者,在遇到缺失能力时主动向人类专家反向委派任务。 - [16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) 人机共享工作区(Shared Workspace)让超级智能体与人类业务专家在同一操作界面内协同推进复杂业务,重塑了企业级智能体的工作范式。 - [17:39](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=1059s) 企业推进 AI Agent 的稳健闭环逻辑为:以 FDE 贴身共创为起点、在生产环境中植入治理策略,随后沿团队链路自下而上明智地规模化扩展。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=4s) AI 蜜月期与“AI 精神病”:从惊艳 Demo 到现实撞墙 演讲者 Mark Shank 首先幽默地感谢大家不辞辛劳爬到五楼最深处的会议室。作为毕马威(KPMG)的 Google Cloud 业务负责人以及银行业 AI 部门主管,他的实践洞察深深植根于金融业务一线,既包括协助客户落地 AI Agent,也涵盖毕马威内部的自主实践与演进探索。为了直观呈现这种体验,他借助小工具制作了一张漫画,调侃道“在过去这得耗费一个平面设计师整整一周时间”。紧接着,他讲述了一个极易引起共鸣的场景:当企业挖掘出一个全新业务用例时,团队上下往往群情激奋,大家迅速构建起数据连接器或 Model Context Protocol(MCP)接口,编写技能文件(Skill File),并将其接入现成的 Agent 运行底座(Harness)——无论是 Claude Co-work、Gemini Enterprise 还是企业自研的测试框架。 ```mermaid flowchart LR accTitle: Agent 从 Demo 到落地的现实落差 subgraph S1["概念验证阶段"] A["业务用例 & Skill 文件"] --> B["Agent Harness / MCP"] B --> C["Demo 演示成功"] C --> D["陷入 'AI 精神病' 狂热"] end subgraph S2["落地挑战阶段"] D --> E["规则膨胀与非确定性"] E --> F["生产力微弱提升 / 高昂维护成本"] end ``` Demo 演示十分顺利,Agent 完美完成了任务,全场惊艳,随之而来的便是一种集体狂热——Mark Shank 将其生动地形容为“AI 精神病(AI psychosis)开始发作”,每个人都深信这项技术马上要颠覆所有流程。然而,狂欢过后,团队必然会在落地深水区撞墙,此时企业通常面临两条困难的演进路径。 --- ### [01:47](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=107s) 提效瓶颈与构建陷阱:从 10% 的生产力微升到“轻量级 RPA” 当企业试图继续推进时,第一个技术瓶颈是技能指令的承载上限:已有大量研究表明,模型在单个 Skill 文件中能够有效追踪和遵从的指令数量是有限的,哪怕写上两三百条,模型最终也会出现非确定性偏差并开始崩溃,逼得人类必须全程充当“保姆”进行人工盯防。这种现象在 2024 年软件工程领域的 Cursor 等辅助编程工具中已经得到印证——经过实证研究,开发者获得的真实效率提升通常只有“10% 到 20%”,这与大家最初期盼的颠覆性革命相去甚远。 另一种路径是组织正规军构建“真正的 Agent”,采用 ADK、LangGraph 等专业框架打造。然而,企业级交付必须经过严格的合规与上线门槛,即使在理想状态下也需要耗费 10 到 12 周。这意味着一个敏捷小队整整 3 个月只能交付一个小 Agent,面对企业目录中数以千计的潜在用例,这种模式在经济和人力上完全不具备可扩展性。 更严峻的问题在于维护维度的脆弱性。很多团队耗费心血定制出的多 Agent 编排框架,往往沦为一种“轻量级 RPA(RPA light)”,其多 Agent 交互逻辑深度绑定了特定模型版本的“参差智能(jagged intelligence)”。一旦底层大模型发生版本迭代,Agent 的行为就会产生难以预测的偏差甚至退化;而当老模型被云厂商正式弃用时,企业跑在上面的核心流程便面临瞬间停摆的危机。Mark Shank 也顺带提及,Databricks 刚推出的 Meta Harness 正试图在一定程度上缓解这种模型交替带来的痛点。 --- ### [05:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=304s) 重构业务流程映射:让状态机成为 Agent 的“法律条文”而非枷锁 面对上述挑战,Mark Shank 提出了一个让传统 IT 部门心生抗拒却极为关键的工具——业务流程映射(Process Mapping)。在传统企业管理中,流程图往往饱受诟病,沦为绘制一次便被束之高阁的“书架摆设”。但如果在 AI 时代企业愿意严谨定义并持续维护核心业务流程,它将成为 Agent 运行中最强大的资产,本质上提供了一个可供 Agent 查询的有限状态机(Finite State Machine)。 ```mermaid flowchart TD accTitle: 流程图作为有限状态机赋能 Agent subgraph StateMachine["有限状态机 (流程图)"] M1["法律条文 (Letter of the Law)"] M2["定义节点状态与合规路径"] end subgraph AIAgent["Agent 认知引擎"] A1["法律精神 (Spirit of the Law)"] A2["动态理解、灵活推理与分支选择"] end M1 -.->|"作为参考工具查询"| A1 M2 -.->|"提供合规动作候选"| A2 ``` 这种架构设计与传统 RPA 有着本质区别: - **参考物而非硬编码束缚**:流程图在系统中的角色是动态参考系,而非传统 RPA 那种机械死板的动作边界。 - **“法律条文”与“法律精神”的辩证分工**:Mark Shank 将其比喻为“流程图代表法律的条文(the letter of the law),而 Agent 则是法律的精神(the spirit of the law)”。流程定义了系统允许走向的状态与合规规则,Agent 则负责在实际业务上下文中进行灵活解释与应用。 --- ### [06:41](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=401s) 别自研 Harness:模型与 Harness 深度绑定下的架构选型 市面上现成的企业级 Agent Harness(如各类 Copilot 与工作台)核心定位于为知识工作者提供“外骨骼(exoskeleton)”,侧重于放大个体的生产力。但当企业试图重新思考业务本质——例如探索“AI 原生的采购部门”或“AI 原生的从采购到付款(Procure-to-Pay)流程”时,现成产品在端到端流程治理、透明度以及审计追踪方面便显得力不从心。这诱使许多团队萌生了从零自研专属 Harness 的想法。 Mark Shank 直言“自研 Harness 是个错误决定”。他给出了一个极其硬核的判断标准:“如今如果你不打算针对自己的 Harness 对大模型进行后训练(Post-train),你就不应该去自研 Harness。”当前 AI 实验室(如 DeepSeek、Poolside、Kimi 等)的发展趋势是模型权重与专用 Harness 高度协同训练。普通企业如果无法承担这种端到端协同训练的成本,自研框架只会带来无尽的适配包袱和维护泥潭。 ```mermaid flowchart TD accTitle: 模型与 Harness 强耦合下的开发分工 subgraph LabLayer["基础模型与 Harness 层 (由前沿实验室构建)"] H["Agent Harness / 核心运行底座"] M["深度后训练的 Base/Chat 模型"] M <==>|"强耦合与联合调优"| H end subgraph EnterpriseLayer["企业自建控制面 (企业基础设施)"] C["流程中心化控制面 (Control Plane)"] T["流程级 MCP / 业务感知工具集"] G["Shell 级治理拦截 (Pre/Post Tool Hooks)"] end EnterpriseLayer -->|"包围与治理"| LabLayer ``` --- ### [09:36](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=576s) 围绕 Harness 构建控制面:从外壳级治理到流程化工具设计 既然不应自研 Harness,企业的工程力量究竟该投向何处?答案是:**围绕标准 Harness 构建外围控制面与基础设施**。AI 自动化在大型企业落地时被证明远比最初宣传的更为昂贵且充满挑战,而构建一套以业务流程为中心的控制面(Process-centric Control Plane)正是控制成本、达成有效自动化的关键突破口。 在具体的架构实现与治理层面,演讲重点阐述了以下核心原则: - **外壳级治理(Shell-oriented Governance)机制**:以企业常用的 Cloud Core 为例,平台提供了丰富的 Tool 调用前(Pre-tool call)与调用后(Post-tool call)的拦截钩子(Hooks),支持多对多的规则匹配,实现细粒度的安全与合规审计。 - **工具定义的范式转移**:如果企业仅仅将 MCP 当作后端数据源的“一对一简单数据抽象”,系统就很难在宏观层面实现流程级控制。要实现真正的流程治理,必须将底层数据与动作封装为具备“流程语义”的高阶工具交付给 Agent 调用。 - 企业推进 Agent 自动化不应重蹈覆辙去硬编码工具,而应将本体(Ontology)、上下文记忆与技能配置等关键要素解耦,聚焦于流程控制面的搭建。 - 只有将工具设计从底层的“纯数据访问接口”升维到“业务流程操作单元”,才能在多 Agent 协同体系中构建起真正具备合规性与可解释性的企业级智能系统。 ### [12:11](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=731s) 面向流程的工具层与企业级治理控制 在底层数据连接器之上构建专门的工具层(Tool Layer),能够将基础数据能力封装并暴露为更贴合实际业务流程的工具。这种架构设计不仅能够赋予企业强有力的治理与控制能力,使各类系统无缝对接,还带来了高度的组件复用性。更关键的是,它在整个端到端流程中建立了坚实的信任基石,保障了业务执行的准确度与可重复性,从而推动 AI 真正落地到复杂的企业级业务流中。 ```mermaid flowchart TD accTitle: Superagent 架构与治理流程 accDescription: 展示从底层数据连接器到工具层、再到超级智能体编排与人机协作的完整架构。 subgraph DataLayer ["数据与连接层"] A["企业数据源 / 系统"] --> B["Data Connectors 数据连接器"] end subgraph ToolLayer ["流程工具与治理层"] B --> C["Process-Oriented Tools 面向流程工具"] C --> D["Governance & Controls 治理与合规控制"] end subgraph AgentLayer ["超级智能体编排与协同"] D --> E["Superagent 超级智能体"] E -->|"任务委派与编排"| F["Shared Workspace 共享工作区"] F <-->|"人机协同交互"| G["业务专家 / 人类工作者"] end ``` --- ### [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) 前线部署工程师(FDE):从沙箱玩具走向生产环境 当企业真正着手构建与落地这套体系时,方法论的转变至关重要。“前线部署工程师”(Forward Deployed Engineer, 简称 FDE)已经成为当下的行业时代热词,各大头部云厂商(包括 Google Cloud)都相继推出了大规模的 FDE 培养与部署计划。这一角色就像当年的 SRE(网站可靠性工程师)一样迅速崛起,成为人人都想拥有、且企业必须具备的核心岗位。然而,业界对 FDE 的理解各不相同;如果仅仅把 FDE 当作“被美化的销售工程师(glorified sales engineer)”,那就彻底用错了方向。 FDE 的本质绝非在传统软件开发生命周期(SDLC)前增加一个演示环节,而是彻底将软件开发生命周期直接导向“生产环境中的小微用例”。FDE 与传统 AI 实验室演示、沙箱 Demo 最核心的区别在于:**FDE 直接在真实的生产环境中开展工作**。为了控制潜在风险并消除人们对直接在生产环境部署的恐惧,其核心控制机制在于严格限制“爆炸半径(blast radius)”与初期规模: - **贴身共创**:FDE 不使用脱离实际的沙箱测试数据,而是直接深入业务一线,与单兵作战能力最强的一线员工(例如采购部门中最懂业务细节、最擅长跨系统协调和处理复杂流程的专家)坐在一起,为他们量身定制辅助完成日常工作的生产工具。 - **渐进式扩展**:当单个用户的工具打磨成熟后,再逐步向其所在的核心小组推开,受众规模从 1 人扩大到 5 人、再到 10 人。 - **动态增加治理**:随着用户基数扩大并开始遭遇更多的边缘异常情况(corner cases),团队再逐步叠加相应的治理机制与安全合规控制。 很多企业惊叹 FDE 能够在短短数周内就在生产环境中交付成果,这种所谓“魔法”的秘密正在于此:在严格控制爆炸半径的前提下,以极小的用户切片在真实生产环境中极速闭环,兼顾敏捷速度与风险可控。 --- ### [16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) 重新定义“超级智能体”:人机共享工作区与任务反向委派 演讲所倡导的“超级智能体”(Superagent)是对前述数据连接、流程工具与生产实践的集大成者。它不仅具备在业务流程级别全局管控风险的能力,更带来了人机协作交互范式的根本性颠覆。 过去的传统观念通常将 AI 智能体视为人类知识工作者的“外骨骼(exoskeleton)”,由人去驱动 AI。而超级智能体则“反转了剧本(flipping the script)”:如果由超级智能体负责整个业务工作流的编排与全局推进,那么智能体本身就拥有向人类委派任务的权限。当超级智能体在执行流程中发现“当前没有合适的子智能体能够处理该特定环节,而该任务又是推进工作流所必需的”时,它会主动将该步骤派发给人类专家。通过为人类与智能体构建“共享工作空间(shared workspace)”,双方在同一操作界面内协同完成复杂工作,彻底重塑了企业思考与运用 AI 智能体的动态模式。 --- ### [17:39](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=1059s) 聚焦单点、稳健扩展:智能体落地总结 在演讲的最后收尾阶段,核心落地路径被精炼总结为一套闭环逻辑: 1. **以 FDE 为起点**:由前线部署工程师深入业务现场,选定关键业务骨干作为共创伙伴,开展端到端的伴随式开发。 2. **在生产环境中治理**:抛弃虚假的沙箱环境,直接在生产环境中交付受控的工具,同步植入企业级的安全钩子与治理策略。 3. **明智地规模化扩展**:沿着团队链路自下而上稳健放大规模,伴随使用人数与流程复杂度的增加同步升级管控与治理体系。 演讲在致谢全场观众专注聆听的热烈氛围中圆满结束,并开放了后续的深入交流与答疑。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=4s) AI 精神病(AI psychosis)开始发作,每个人都深信这项技术马上要颠覆所有流程。 — Mark Shank > [01:47](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=107s) 经过实证研究,开发者获得的真实效率提升通常只有 10% 到 20%,这与大家最初期盼的颠覆性革命相去甚远。 — Mark Shank > [01:47](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=107s) 很多团队耗费心血定制出的多 Agent 编排框架,往往沦为一种轻量级 RPA(RPA light),其多 Agent 交互逻辑深度绑定了特定模型版本的参差智能(jagged intelligence)。 — Mark Shank > [05:04](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=304s) 流程图代表法律的条文(the letter of the law),而 Agent 则是法律的精神(the spirit of the law)。 — Mark Shank > [06:41](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=401s) 如今如果你不打算针对自己的 Harness 对大模型进行后训练(Post-train),你就不应该去自研 Harness。 — Mark Shank > [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) 如果仅仅把 FDE 当作被美化的销售工程师(glorified sales engineer),那就彻底用错了方向。 — Mark Shank > [12:43](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=763s) FDE 与传统 AI 实验室演示、沙箱 Demo 最核心的区别在于:FDE 直接在真实的生产环境中开展工作。 — Mark Shank > [16:10](https://www.youtube.com/watch?v=7k3K-Efd54Y&t=970s) 如果由超级智能体负责整个业务工作流的编排与全局推进,那么智能体本身就拥有向人类委派任务的权限。 — Mark Shank ## Mentioned Mark Shank, KPMG (毕马威), Google Cloud, Model Context Protocol (MCP), Claude Co-work, Gemini Enterprise, Cursor, ADK, LangGraph, Databricks, Meta Harness, DeepSeek, Poolside, Kimi, Forward Deployed Engineer (FDE), Site Reliability Engineer (SRE) ## Video description Mark Shank - Google Cloud Leader, KPMG Discover how to stop building disconnected bots and start orchestrating real business outcomes with Superagents built by KPMG and Google Cloud. [Source](https://www.youtube.com/watch?v=7k3K-Efd54Y)

Source quotes

[0:04] Mark Shank: AI 精神病(AI psychosis)开始发作,每个人都深信这项技术马上要颠覆所有流程。 [1:47] Mark Shank: 经过实证研究,开发者获得的真实效率提升通常只有 10% 到 20%,这与大家最初期盼的颠覆性革命相去甚远。 [1:47] Mark Shank: 很多团队耗费心血定制出的多 Agent 编排框架,往往沦为一种轻量级 RPA(RPA light),其多 Agent 交互逻辑深度绑定了特定模型版本的参差智能(jagged intelligence)。 [5:04] Mark Shank: 流程图代表法律的条文(the letter of the law),而 Agent 则是法律的精神(the spirit of the law)。 [6:41] Mark Shank: 如今如果你不打算针对自己的 Harness 对大模型进行后训练(Post-train),你就不应该去自研 Harness。 [12:43] Mark Shank: 如果仅仅把 FDE 当作被美化的销售工程师(glorified sales engineer),那就彻底用错了方向。 [12:43] Mark Shank: FDE 与传统 AI 实验室演示、沙箱 Demo 最核心的区别在于:FDE 直接在真实的生产环境中开展工作。 [16:10] Mark Shank: 如果由超级智能体负责整个业务工作流的编排与全局推进,那么智能体本身就拥有向人类委派任务的权限。

Source quotes

[0:04] Mark Shank: A team identifies a use case, cobbles together a data connector or Model Context Protocol (MCP) server, drafts a skill file, drops it into an agent harness like Gemini Enterprise, and runs a successful live demo. [1:51] Mark Shank: Once directives reach a few hundred instructions, non-determinism sets in and the agent begins to fail, forcing knowledge workers to babysit the system constantly. [5:04] Mark Shank: The formal process map represents the 'letter of the law,' while the LLM-powered agent acts as the 'spirit of the law,' dynamically interpreting context and applying discretion at each stage. [6:41] Mark Shank: Building a proprietary harness is only justified if an organization is prepared to post-train and fine-tune models directly on that harness. Very few enterprises have the appetite or capital to clear that hurdle rate. [9:36] Mark Shank: Automating real enterprise work has proven far more costly and challenging than early AI marketing suggested, making a well-structured control plane essential for viable unit economics. [9:36] Mark Shank: If MCP servers and tools are implemented as simplistic, one-to-one database wrappers, extracting governance and auditability becomes nearly impossible. [12:43] Mark Shank: The defining distinction between an FDE and the endless parade of isolated lab experiments and toy demos that have dominated enterprise AI is stark and uncompromising: a forward deployed engineer builds in production from day one. [14:18] Mark Shank: The safeguard in this model is not an isolated sandbox; it is the deliberate limitation of scale and 'blast radius.' [16:10] Mark Shank: Under this inverted dynamic, the superagent manages the business process and directly delegates tasks to human professionals when necessary. [17:39] Mark Shank: Although the forward deployed engineer is often discussed as an implementation detail, the entire transformation actually begins with them on the ground.

Original transcript

[0:04] I appreciate everybody making it all the way  up here to the fifth floor in the very back. [0:09] Uh try and try and make this informative or  entertaining for you. My name is Mark Shank. [0:14] I lead the Google Cloud business for KPMG. And  I'm also the uh AI sector leader for um banking. [0:23] And that's where a lot of my my personal  experience comes from. I was asked to kind [0:27] of talk to you about uh share some experiences  really from you know what we've seen both working [0:34] with clients and implementing uh AI agents for  ourselves and kind of how that's evolving and [0:40] what are some of the problems you know that we've  seen around that. So [clears throat] you know [0:47] can't can't help but use like the power of nano  banana to make a good comic, right? This used to [0:52] take a week and like a graphic artist. But I  think that you know let me tell you a story. [1:00] See if this resonates with anybody. You've  got a use case. Everybody gets all excited. [1:05] Uh you know maybe you build a data connector.  Maybe it's an MCP. Maybe it's not that formal. [1:10] Whatever. Uh you you write a skill file.  You put it you put it in an agent insert [1:17] uh you know whatever whatever agent  harness you're using Cloud Co-work [1:22] Gemini Enterprise uh you know whatever or  something your your company custom built. [1:28] And you go you do a demo. It does the work. Cool.  It's great. Everybody gets all super excited. [1:34] AI psychosis starts to set in. Uh this is  this is going to revolutionize everything. [1:40] But you know you inevitably run into into  challenges. And you really you you can kind of [1:47] go two different ways. All right.  So you you run into challenges. The [1:51] At some point in time this has been pretty studied  like you there's only so many directives you can [1:56] put in a skill file for for the model to  actually keep track of varies. You know, [2:02] it can be a couple hundred, several hundred,  but it does start to fall down at some point. [2:06] Right? There there is non-determinism, there's  you know, all these things that kind of, [2:10] you know, make you want to be more formal, make  you want to go at it, or you just have to baby sit [2:15] the agent. So, this is in the software development  world, we saw this in the kind of, you know, [2:20] 2024 era with with with like cursor. And it's how  much more productive were you really? Empirically, [2:29] you know, it's studied you're kind of 10 to  20% more productive. That's not exactly the [2:34] revolution that everybody was looking for  with AI agents, right? Or you sit down, [2:40] you grab some of your developers, and you start  to build a quote-unquote real agent, right? [2:46] And, you know, you're using ADK, LangGraph,  whatever. You start to build this out, but [2:53] shipping in enterprise is is you know, has  real gates, it has real things you have to [2:58] work through. It's not just something you  can fall down and do super fast. And so, [3:04] you know, even in a in a good scenario, can take  10 to 12 weeks to push that out. So, you've now [3:10] occupied a whole agile squad for 3 months to  ship a little agent. And that does not scale [3:17] across the thousands of use cases that, you know,  your organization has cataloged. Right? And then, [3:25] to kind of add insult to injury, even after you've  shipped it, it can be, you know, you you end up [3:33] it's really hard to build this kind of bespoke  harness and and LangGraph or whatever, you know, [3:41] framework you're using that that isn't How  do I want to say this? It can turn into like [3:48] RPA light. And that and you can you can bake some  brittleness into this agent that you're trying to [3:55] to not make it or your specifically shaping  the multi-agent interaction around whatever [4:03] version of jagged intelligence that you're  getting out of the model that you built it on. [4:07] So, inevitably models get updated, the agent  starts to behave differently, possibly worse. Uh [4:14] you know, models get deprecated. We're seeing a  lot you know, we're starting to see that models [4:18] going away and you're like, "Hey, I've got  enterprise process running on this and you're [4:22] you're taking it away." You know, all all this  stuff comes back. Quick plug on the last panel. Uh [4:31] the Databricks meta harness for really  does a lot towards the last panel. So, [4:37] if you haven't looked at that, they just launched  it 6 or 7 weeks ago, but but it's pretty cool. [4:42] So, we've seen a ton of this. We've seen  this internally. We've seen this at clients. [4:46] And it's it's totally fine if you have this really  awesome business case and you know, you don't mind [4:53] spending the money on on building the agent,  you can totally go and do that. You still have [4:57] the maintenance issue. You still have, you know,  all these ongoing issues. But, one of the things [5:04] and I was I was a little afraid to kind of put  this on a slide. I was watching the last session [5:09] that was up here. Uh and it it made me feel a  little better cuz they were talking about talking [5:14] about it maybe not as formally as this, but you  know, we have such a knee-jerk uh kind of negative [5:22] reaction towards uh process mapping. Right? It was  it was abused in in the in the in the corporate [5:30] world for so long. It was something that's kind  of done once and then maybe it sat on a shelf. [5:36] And but if you're really willing to do it,  if you're really willing to formally define [5:43] uh a process and commit to maintaining that, it  is an amazing tool from an agent perspective, [5:50] right? You now have a kind of finite state machine  to query it for the agent to query. The big [5:56] difference that makes this not RPA, again, like,  you know, I keep kind of coming back to that, [6:03] not wanting to fall into the traps of what  we've learned in the past, the big thing [6:06] that makes this not RPA is that you're the it's  it's a reference. It's not bounding, right? So, [6:15] the agent is using it as a tool to understand  what uh the next options are in the process or or [6:22] where to potentially go. It's kind of like  the the map exists as the letter of the law, [6:27] the agent exists as the spirit of  the law to interpret uh and apply, [6:32] right? So, that's almost a little bit of an aside.  I want to go back to harnesses real quick. So, [6:41] what are You hear a lot of common complaints  about uh you know, the agent harnesses that [6:48] are off-the-shelf now for uh for enterprise use,  right? Inherently, they are very much designed [6:57] as the kind of be that exoskeleton of uh of the  information worker. We want to supercharge the [7:03] information worker. We want to make them super  productive. And that's really cool. That's great. [7:08] There's a I I enjoy being super productive. I  imagine you all are probably here for the same [7:12] reasons. Um And and that's definitely not a bad  thing. I'm not complaining about that. I'm just [7:18] saying that there are there are times when  you're looking at it and you're saying like, [7:22] "Well, I really wish I had something that  was more process set process-centric, [7:26] more organi- more organizationally centric, uh  that really helped me um you know, that that gave [7:33] me the the the governance, the the transparency,  um you know, the the auditability, all these all [7:40] these different things that I want to do to be  able to actually manage a process and and manage [7:46] manage a department, particularly as you start  trying to rethink the nature of work instead [7:52] of just saying how do I make all of my people  super productive and saying what is an AI native [7:58] uh procurement function look like? What is an AI  native uh procure-to-pay process look like? Just [8:06] picking those out of the air. And a lot of people  answer that by looking to build their own harness. [8:18] I think this is the wrong call. You  can see a lot of projects out there. Um [8:24] I obviously it's it's it's it's it's totally  appropriate for some some people to build their [8:30] own harness. I would argue these days if you're  not willing to post-train a model on your harness, [8:35] then you shouldn't be building a harness. And  that's a pretty high hurdle rate relative to the [8:41] general use, you know, of all the companies  that are going to be using agent harnesses, [8:45] the ones that are going to be willing to do that  for a bespoke harness is is pretty small. Because [8:51] what you're seeing is is that harnesses and models  are getting more and more tightly coupled. Uh if [8:57] I haven't looked at X today, but if I don't I Deep  Sea is supposed to be releasing their harness any [9:03] day now. Uh Poolside has their own heart like like  Kimmy has I mean all of all of the labs have their [9:09] own harnesses. They're all training against the  harness. If you're not willing to kind of take on [9:14] that level of a burden, I don't really think that  that is kind of the route that you want to go, [9:19] at least at at the kind of high level that  we're talking about. Doing something that's, [9:23] you know, smaller, specific task-oriented harness,  you know, you run into the challenges from the [9:29] first slide that I talked about, but if you're  willing to deal with those, yeah, sure, fine. So, [9:36] you don't build the harness. You  build the infrastructure around it. [9:42] Right? So, you don't go and uh you know, try to  build a harness so that you can, you know, uh put [9:52] explicit governance calls and things around the  tool calling or, you know, baking your ontology. [9:59] And I did just say the word ontology. I'm sorry.  I very kind of explicitly left the kind of the [10:04] data and the memory and and the skills and stuff  out of this talk. It's all very important topics. [10:12] I did only have 20 minutes. So, I was just  trying to trying to focus on you know, [10:17] what are you what are you uh you know, building  around you know, around the around the agent [10:22] to help it kind of do at the work and automate  the work that we're all kind of being told that [10:29] the that the AI is going to enable. AI  is going to drive all of this automation. [10:34] Uh and the reality of driving that automation  is, you know, it it kind of it's proven more [10:40] challenging for large organizations to do and  and more costly than originally advertised. [10:47] This is something that can help, you know,  kind of reduce that. Right? And so, from a [10:54] from a control plane perspective, you want to look  at being uh you know, more process-centric. Like, [11:03] how do you how do you do that? What does that  mean? Um Wow, I [clears throat] shouldn't lower my [11:10] face. That that was weird. Anyway, sorry.  Uh the But, how what does that mean? So, [11:17] governance around uh you know, around agents  is very shell oriented. That was a line on [11:22] the last slide, but it but it's important,  right? It it the governance that you attach [11:27] is is control mechanisms that that you've put  down at the shell level. They actually give you uh [11:34] speaking specifically like cloud core, that's  something that I've that I work with. You know, [11:39] you have you have uh pre-tool call and post-tool  call hooks that you can tie into. Many to many, [11:45] you can put in as many as you want. You match it  against the tool calls. But it would if you want [11:50] process-centric governance and control, then  you have to give process-centric tools. If you [11:57] if you treat your MCPs as just kind of one-for-one  uh data abstractions for your data sources, [12:05] then it's going to be very hard to work backwards  into some kind of uh process level control. So, [12:11] having a a tool layer on top of that uh that that  uses those data connectors, but exposes a more [12:18] uh process-oriented tool, allows, you know, you to  have that kind of governance and control for you [12:25] to tie into so that you can uh you know, get the  the reusability, but but also just the trust and [12:34] and accuracy and repeatability that you  want to drive uh across the process. [12:43] So, I want to shift gears a little bit and and  you know, what So, you start to pull this together [12:53] and what does it mean uh to actually, you know,  go out and build and implement? And that's where, [13:02] you know, this term forward deployed engineer  has, you know, really uh become quite the the [13:10] the zeitgeist term in 2026. I think every major  uh hyperscaler, Google included, has announced [13:19] significant forward deployed engineering programs.  Um and, you know, it's it's it's become the uh [13:26] it's become almost the site reliability engineer  of 2026 in regards to this role that just kind of [13:32] popped up that now everybody everybody wants to  have and everybody already has to have and it's [13:36] starting to be interpreted you know a bunch of  different ways and and how it's being applied. [13:42] I think if you apply it like a glorified  sales engineer then you're doing it wrong. [13:49] Um you know it it it really is about it's it's not  a new step and then you graduate and you move into [13:59] your traditional software development life cycle.  You really want to orient the software development [14:05] life cycle towards uh you know small use  cases in production. That's the biggest [14:13] That's the if you want to take one thing away  from this that would be the biggest thing [14:18] for FDE versus all of the mini lab experiments  and little demos and things that everybody's [14:23] done around AI or around AI which is a forward  deployed engineer works in production. And maybe [14:32] that you know freaks some people out and you're  like well how the hell do you do that or what's [14:36] the control mechanism around that? The control  mechanism is is kind of blast radius or scale. [14:42] They they work they start by working with a very  small group of people. Maybe it's just one person. [14:46] Maybe it's the best person in in the procurement  department the person who knows the process the [14:52] most or or really has you know their best at all  the swivel chair computing and all the different [14:56] stuff that they have to do. The FDE goes in and  they build tools for them to use to do their job. [15:04] They don't build tools that sit in a you know with  with test data in a in a sandbox lab. They build [15:13] tools that help them do their job and you layer  on the controls and the governance and what you [15:23] need as you start to push it out beyond that user,  right? You're going to go to a You want to go to [15:27] the other members on their immediate team. You're  now you're working with five people. You want to [15:31] go to You want to go with 10 people. Uh you want  to start to You want to start to push it out. [15:35] You're starting to encounter more more more corner  cases, et cetera. And that's where a lot of the [15:43] kind of, you know, {quote} {unquote} magic comes  from relative to a lot of the timelines that you [15:47] see. You're like, "Oh, four deployed engineers,  we we did something in weeks uh in production." [15:54] Yeah, you did it in weeks. You did it in weeks for  um for a relatively small small number of users. [16:00] Uh at least I hope that you did. Uh if, you  know, from a from a from a risk perspective. So, [16:10] the the In the talk intro, it mentioned the word  super agent. Uh what's a what's a super agent? [16:18] You know, it it's really kind of embodying um all  the stuff that that I've talked to getting here [16:25] to date, right? That it uh has the ability to  um you know, manage risk at a process level. Uh [16:35] that it has the has a a shared workspace between  human and agent. I guess I haven't talked about [16:42] that yet, have I? The idea, like as you're working  through this process that you're that you're [16:48] that the agent is you're kind of flipping  the script around what I was talking about [16:53] earlier with the the agents being a an an  exoskeleton for your information workers, [16:59] we're now saying if our agent is responsible  for orchestrating and managing the workflow, [17:03] then the or then the agent should be delegating  to people. Right? It's saying like, "Look, [17:07] I don't have an agent that complete this task.  I need this I'm I need this task completed in [17:13] order to complete the workflow." Delegating that  to a person, uh you know, giving uh the person [17:20] and and the agents a shared work service for them  to to actually be able to do the work, accomplish [17:26] and get it done. And you know, this is really  starting to just you know, change the dynamic [17:31] around how we think about AI agents and and how  we're going to drive what they're able to do. [17:39] So, I'll go on the last slide as I have 90  seconds left on my time. To try and sum up um [17:48] you know, you want so FTE, right? You're  starting focused. So, I I covered FTE last, [17:54] but it starts with FTE, right? It starts with  that forward deployed engineer going out, [17:59] picking a person to work with and or or  having a person picked for them to work with [18:05] that they go out, they and they  actually build alongside of, right? [18:10] That you're deploying in production, that you're  deploying in a governed way, then you know, you're [18:15] building all the hooks that that we talked in in  the lead-up that got us here. And and then and [18:21] then you're going to kind of scale that smartly,  right? You're scaling that up throughout the team, [18:27] you're scaling the governance and the controls as  you move out and build out. All right. So, with [18:34] that, I thank everybody for sticking around and  not too many of you looking at your phones, really [18:39] appreciate it. And if anybody has any questions,  you know, glad to chat with you afterwards.