Workato Chief Bhaskar Roy Cuts Enterprise AI Costs via MCP Layer

Workato负责人Bhaskar Roy通过MCP层降低企业AI成本 企业AI支出激增却未能带来投资回报，根源在于企业面临的是执行与治理问题，而非模型推理缺陷。 在本次演讲中，Bhaskar Roy解释称，企业若想走出“试点炼狱”，关键在于解决执行挑战而非模型推理问题。他批评点对点智能体架构引发了管理混乱，并介绍了基于企业技能（Enterprise Skills）与可组合企业MCP构建的统一控制平面。通过规范权限治理、借助GEARS框架实现弹性的系统错误处理，以及将逻辑执行与大语言模型（LLM）的Token消耗解耦，企业能够在确保成本不增加的同时安全扩展AI应用。 阻碍企业AI获得投资回报率的主要瓶颈是执行问题，而非模型推理问题。 (0:04) 迈向生产环境需要确定性的工作流、精细化治理，以及可在全企业范围内推广的可复用基础组件。 (0:04) 各独立AI工具与企业软件之间的点对点连接会造成运维混乱、安全孤岛和高昂的Token成本。 (4:05) 企业AI的规模化落地受到三大架构差距的阻碍：控制差距、执行差距和扩展差距。 (4:05) 智能体必须严格代表已登录用户执行操作，并完整继承其对象级和行级安全权限。 (6:55)

Workato Chief of AI Bhaskar Roy argues that enterprise AI initiatives stall in 'pilot purgatory' due to an execution breakdown rather than limitations in model reasoning. To scale production AI cost-effectively, organizations must shift from fragmented point-to-point connections to an orchestrated control layer powered by deterministic workflows and governed Model Context Protocol (MCP) integrations. The Execution Problem and Point-to-Point Chaos (0:04) While organizations have widely adopted AI experimentation, few successfully transition mission-critical business processes like order-to-cash into production. Roy asserts this bottleneck is fundamentally an execution failure: core financial and enterprise workflows cannot depend on probabilistic guesswork or hallucinated steps. Instead, systems require deterministic workflows, granular governance that restricts data access by user roles, and reusable foundational components to support enterprise scale. A major impediment to this shift is the proliferation of point-to-point architectures. As business units independently integrate tools such as ChatGPT, Claude, Cursor, and Salesforce Agentforce directly into core software like ERPs and CRM platforms, each tool creates an isolated silo for compliance, guardrails, and observability. This creates a control gap in tracking audit trails and data access, an execution gap in running multi-step logic, and a scale gap that introduces operational gridlock as new tools are added. Bridging Gaps with Enterprise MCP and Skills (6:55) To eliminate integration chaos, Roy outlines an architecture centered on a unified control plane. Within this system, agents operate strictly under the context of the logged-in user, inheriting exact row- and object-level permissions—such as an account executive only viewing and modifying their own sales opportunities. System evaluations are tracked against operational results and business KPIs rather than raw model outputs. This control plane relies on Enterprise Skills and Composable Enterprise MCPs rather than raw API wrappers. Standard MCP implementations treat APIs as basic CRUD endpoints, forcing an LLM through costly, repetitive tool calls to execute a single task. In contrast, Composable Enterprise MCPs bundle orchestrated cross-system actions—such as 'Expedite Offer' or 'Create Invoice'—into single composite calls. Encapsulating established procedures into deterministic skills reduces token consumption and eliminates the need for models to improvise multi-step execution plans. Operational Resilience via the GEARS Framework (13:24) Production integrations require robust exception handling beyond basic API connectivity. Standard AI agents frequently crash or loop when encountering temporary endpoint downtime. Enterprise-grade connectors are designed to pause, track availability, and flush accumulated backlogs in chronological sequence once systems recover, avoiding manual administrative intervention. Roy proposes the GEARS framework to operationalize enterprise AI: Governance (tailoring department-level compliance and data boundaries, such as separating HR and Sales), Enablement (equipping business units to build their own workflows and MCP tools), Adoption (establishing deployment blueprints for daily employee workflows), Run (monitoring continuous agent execution and handling failures gracefully), and Scale (reusing established blueprints across the enterprise without linear cost growth). Decoupling Adoption from Token Costs (17:30) Evidence from Workato's internal deployment of Anthropic's Claude demonstrates that establishing an execution layer can detach increased AI usage from model expenses. Initial rollouts generated modest usage for basic text drafting. After deploying custom Enterprise MCP servers aligned with business workflows, employee usage expanded significantly, yet total LLM spend remained flat because task orchestration was handled at the integration layer instead of consuming model tokens. Specific optimization tactics include output control to return concise text rather than verbose unstructured JSON, and connector-level field filtering, such as reducing a 100-field Salesforce Account record to only the 30 relevant attributes. Tool call chaining also compresses multi-step logic into single actions, an approach adopted by a major telecommunications provider using Workato as its underlying MCP and governance layer. Roy's presentation concludes that controlling enterprise AI costs and escaping pilot purgatory depends on offloading deterministic orchestration and security enforcement from the language model to an intermediate control plane, though the framework relies heavily on adopting centralized integration infrastructure.

Workato人工智能负责人Bhaskar Roy指出，企业AI投资难以兑现商业回报的症结不在于基础模型的推理能力，而在于工程执行层面的短板。企业若要走出试验泥潭并避免大模型成本失控，必须依托统一的企业级控制平面，以确定性工作流替代概率推测，并终结混乱的点对点集成模式。 破解试验炼狱与点对点架构的混乱 (0:04) Roy在演讲中表示，大多数企业已经积极开展AI概念验证，但极少数能够顺利推向生产环境。像订单到现金（order-to-cash）等核心商业流程直接关联财务账目，绝不能依赖生成式模型的概率猜测或幻觉步骤。企业要跨越“试验炼狱”，必须具备三大基石：确保业务流程完全无差错的确定性工作流、能够精准控制账簿和客户数据查看权限的细粒度治理，以及可跨组织复用的企业级通用组件。 与此同时，企业在引入ChatGPT、Claude、Cursor或Salesforce Agentforce等多种智能体工具时，各团队往往自行直接对接底层系统，形成了盘根错节的“意大利面式”点对点集成。这种架构不仅分散了监控与合规体系，还导致三大结构性鸿沟：无法集中审计权限与优化Token支出的控制鸿沟、无法端到端编排多步复杂逻辑的执行鸿沟，以及随应用接入而引发运维瘫痪的规模化鸿沟。 企业级MCP与确定性技能控制平面 (6:55) 为了弥合执行缺口，Roy主张建立统一的控制平面。在该架构下，智能体代表已登录的用户执行操作，必须严格继承该用户在系统中的行级与对象级权限。例如，客户经理只能通过智能体查看和编辑自己名下的销售机会，严禁跨权限访问他人数据；同时，智能体的效能评估必须以业务KPI和运营成果为准，而非单纯检验模型生成的文本质量。 该控制层的核心是将标准模型上下文协议（MCP）升级为“企业级MCP”与“企业技能（Enterprise Skills）”。普通的MCP仅作为基础CRUD接口，促使大模型发起数十次串行工具调用，耗费大量计算资源尝试摸索流程；企业技能则将成熟的多步骤流程封装为确定性模块，企业级MCP更可将“加速报价”或“创建发票”等跨系统端到端编排整合为单次复合工具调用，同时无缝打通现代SaaS应用与本地老旧数据仓库。 异常韧性处理与GEARS落地运营框架 (13:24) 企业级连接器的稳定运行不仅依赖API连通性，更取决于严苛的容错与异常处理机制。当目标业务系统出现临时故障时，常规智能体通常会陷入死循环或直接报错崩溃；而高韧性企业连接器能够主动优雅暂停，持续监测目标系统可用性，并在系统恢复后按时间顺序自动冲销积压任务，全程无需管理员手动介入或执行补丁脚本。 为了将这些能力系统化推广至全企业，演讲介绍了“GEARS”运营框架：G（Governance，治理）代表针对人事、销售等不同部门量身定制安全规则与数据边界；E（Enablement，赋能）代表支持最熟悉业务场景的业务线团队自行开发智能体与MCP工具；A（Adoption，采纳）通过标准化实施蓝图推动员工日常使用；R（Run，运行）强调面对边缘情况时的自愈与持续监控；S（Scale，规模化）确保智能体蓝图在组织内横向扩展时，复杂度与成本不会呈线性飙升。 Token成本解耦策略与企业实证 (17:30) Workato在自身部署Anthropic Claude的案例证明，控制执行层能够成功打破业务采用率攀升与模型费用暴增之间的绑定关系。在初期阶段，Claude仅被用于邮件起草与基础文本生成；随后Workato为各业务线部署了定制的企业级MCP服务器，驱动员工使用频次爆发式增长，但在调用量激增的情况下，LLM总体支出却维持平稳。其核心原因在于工作流编排与具体逻辑由控制层承载，避免了消耗昂贵的模型Token。 演讲归纳了三大具体Token优化举措：一是输出控制，将动态模型输出过滤为规范凝练的文本，避免模型反复解析大段非结构化JSON响应；二是字段过滤，在连接器层对API返回数据进行裁剪，例如将包含100个字段的Salesforce对象过滤为业务仅需的30个字段；三是工具链合并，将跨系统多步交互浓缩为单次MCP调用。Roy提到，一家大型电信运营商已基于此架构，将Workato作为底层核心治理平台与MCP执行中枢，安全运行大规模定制智能体流程。 Bhaskar Roy强调，破解企业AI落地困局的关键在于由概率推理转向确定性执行控制，但在企业复杂多变的多系统环境中，如何平衡业务团队自主构建工具与IT部门集中治理之间的张力，仍是持续面临的实践考验。

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=MhjUbED89vw&t=4s) 试点炼狱：企业 AI 并不缺采纳，缺的是投产落地能力 大会步入尾声，作为全天的最后几场演讲之一，Workato AI 负责人 Bhaskar Roy 开场对现场坚持到底的与会者表达了真诚的感谢，并祝愿大家返程平安。他在开门见山展示 Workato 公司概况的同时，点出了本次分享的核心背景：Workato 在与众多《财富》500 强企业的深度合作中，持续观察这些企业究竟是如何将 AI 真正推向生产环境、如何突破规模化瓶颈并切实获取业务价值的。 Roy 指出，当前行业内讨论最激烈的“采纳率”其实是个伪命题。企业上下都在积极尝试、探索各种 AI 工具与用例，真正卡住所有人的难题出在底层——如何将试点项目推向实际生产环境。现实中，能够顺利跨越试点阶段、迈入生产环境并带来可量化 ROI 的项目占比极低，绝大多数企业都深陷在无休止的“试点炼狱”（Pilot Purgatory）之中。 - 行业共识反差：AI 采纳率与尝试意愿极高，但试点转化为生产级上线的成功率极低。 - 核心痛点转移：企业面临的挑战不是顶层的“用不用”，而是底层的“如何投产见效”。 --- ### [01:38](https://www.youtube.com/watch?v=MhjUbED89vw&t=98s) 并非推理问题，而是执行困境：确定性、治理与企业级扩展 针对业界普遍对底层大模型能力的执念，Roy 给出了截然不同的诊断。当前各种基础模型的演进速度令人惊叹，推理能力每天都在迭代提升，人们用它们构建出形形色色的 Agent 和动态工作流，“问题根本不在于推理，我们称之为执行问题（Execution Problem）”。当一个基于良好推理的 Agent 需要面对严苛的企业级生产环境时，单纯的提示词工程与模型推理无法支撑实际运转，企业必须具备三大支柱： 第一是确定性工作流（Deterministic Workflows）。企业核心流程绝不能容忍模型幻觉，例如在“从订单到现金”（Order-to-Cash, O2C）流程中，如果完全依赖模型自主发挥，一旦出现幻觉导致记账错误，整个财务账目将陷入崩溃。第二是严格的企业治理（Governance）。以财务或客户数据 Agent 为例，必须有清晰的权限管控：谁能调用该 Agent？Agent 能看到哪些维度的敏感数据？没有治理，规模化无从谈起。第三是企业级规模化（Enterprise Scale）。AI 的价值在于普适赋能全公司的海量流程，企业必须搭建可复用的标准积木块，以支撑组织范围内的平滑扩展。 - 确定性保障：核心业务（如财务记账、订单处理）必须依赖刚性工作流，杜绝模型幻觉污染业务账本。 - 权限治理前置：Agent 访问系统与读取数据必须遵循企业现有的数据隔离与权限边界。 - 架构可扩展性：提供通用的执行组件，使 AI 能够平稳切入全企业的各条业务线。 --- ### [04:05](https://www.youtube.com/watch?v=MhjUbED89vw&t=245s) 点对点连接与工具孤岛：架构“混沌”催生三大鸿沟 在展示一张被戏称为“视力检查表”（Eye Chart）的复杂架构图时，Roy 剖析了多数企业当前的 AI 架构现状：内部同时接入多个大模型（如 ChatGPT、Claude 等），团队使用各类 Agent 工具（如 Codex、Claude Code、Salesforce Agentforce 等）各自搭建专属应用。这种做法直接导致了严重的架构“混沌”（Chaos）： ```mermaid flowchart TD accTitle: 点对点混乱架构与统一执行层对比 subgraph Chaos["现状：点对点网状混乱 (Chaos)"] A1["Agent 1 (Claude)"] -->|"点对点连接"| S1["Salesforce"] A1 -->|"点对点连接"| S2["ERP / NetSuite"] A2["Agent 2 (Agentforce)"] -->|"独立鉴权/监控"| S1 A2 -->|"独立连接"| S3["自研数据库"] A3["Agent 3 (ChatGPT)"] -->|"独立连接"| S2 end subgraph Factory["解法：AI 工厂三层架构"] AG["各类 Agents / LLMs"] --> CP["控制层 Control Plane\n(用户身份代理 / 统一鉴权 / 审计)"] CP --> EP["执行层 Execution Plane\n(企业级技能 / 确定性工作流 / 企业级 MCP)"] EP --> ES["企业所有系统 (SaaS / 本地数据库 / 遗留系统)"] end ``` 这种混沌主要体现在两个维度：首先是连接的网状爆炸，每个 Agent 工具都通过独立的连接器或插件直连底层系统，形成无数脆弱的点对点通路；其次是治理的彻底碎片化，每个工具都自带一套独立的可观测性、护栏（Guardrails）和管控策略，企业不得不分别维护。这种架构一旦新增应用，对网络和底层系统的压力将是灾难性的。由此，企业在 AI 落地中撞上了三大鸿沟： 1. **控制鸿沟（Control Gap）**：涉及全局治理、身份鉴权、合规审计以及 Token 成本优化。 2. **执行鸿沟（Execution Gap）**：业务动作无法保障确定性交付，动态链路失控。 3. **扩展鸿沟（Scale Gap）**：架构缺乏标准化组件，无法向全组织横向复制。 --- ### [06:48](https://www.youtube.com/watch?v=MhjUbED89vw&t=408s) 架构设计的核心：代理身份受控、端到端编排与结果级评估 为了填补控制鸿沟与执行鸿沟，Roy 提出了关键的架构设计准则。在控制层面，Agent 在执行数据读取或业务操作时，必须严格“代表用户身份（Work on behalf of the user）”运行。Roy 指着台下在场的同事开玩笑道：“比如我是一名销售代表，我只能查看和更新分配给我的 Salesforce 客户及商机；如果我让 Agent 去修改现场另一位销售 Erin 的商机，Erin 绝对会很不高兴，这在合规上也是完全错误的。”同时，所有 Agent 的操作链路必须具备完整的日志审计与实时告警能力，确保异常发生时能迅速介入。 在执行层面，业务流程必须实现真正的端到端编排，保证每次触发都能获得一致、确定的结果。Roy 强调，业界目前大量在模型层（提示词、响应质量）做评估（Evals）的方向存在偏差，企业真正需要的是在业务结果和 KPI 层设置评估标准，检验底层系统中的数据是否被正确写入、业务目标是否真正达成。此外，企业的资产不仅存在于现代 SaaS，更多沉淀在本地部署（On-prem）的自研系统、传统数据库与私有数据仓库中，Agent 必须具备无缝接入并操作这些本地遗留系统的能力。 - 最小特权执行：Agent 不得拥有上帝视角的全局系统服务账号，必须继承发起请求的终端用户权限。 - 端到端审计告警：全链路行为皆可追踪，异常行为即刻告警。 - 业务级评估（Evals）：告别纯文本层面的模型打分，转向检验底层系统数据流与业务 KPI 是否达标。 - 全异构系统支持：打破纯云端 SaaS 局限，打通本地数据库与专有系统的连接。 --- ### [09:41](https://www.youtube.com/watch?v=MhjUbED89vw&t=581s) 企业级技能与企业级 MCP：杜绝低效的动态规划与 Token 浪费 针对目前 Agent 构建中广泛采用的模型端技能（如 Claude Skills），Roy 深入分析了其隐患。使用自然语言定义技能虽然门槛低，但存在两大致命软肋：一是执行缺乏绝对确定性，AI 无法每次都百分之百正确编排步骤；二是这类动态工作流在推理和规划时会反复与规划系统交互，消耗海量 Token，成本极高。 为此，Workato 提出了“企业级技能”（Enterprise Skills）与“企业级 MCP”（Enterprise MCP）的概念： | 对比维度 | 传统 MCP / 原生技能 | 企业级 MCP (Enterprise MCP) | |:--- |:--- |:--- | | **暴露形式** | 简单 API 包装，以单一 CRUD 原子操作为主 | 将端到端的多系统工作流封装为单一高级工具 | | **调用模式** | LLM 频繁在多个工具间反复推理、猜测调用顺序与依赖 | LLM 仅需触发一次业务动作调用（如“开具发票”或“加速审批”） | | **执行机制** | 动态、非确定性的模型自主规划 | 底层执行引擎刚性、确定性编排，零幻觉 | | **Token 消耗** | 多轮循环与大段上下文解析，Token 消耗巨大 | 单次明确调用，Token 消耗极低且成本可控 | Roy 解释道，企业内部诸如“创建发票”、“加速报价”等流程，本身具有极其清晰规范的业务逻辑，根本不需要让 AI 去即兴发挥。企业应当在执行层将跨系统的业务流预先配置好，再以可组合的 MCP 工具形态暴露给 AI。AI 只需要在理解用户意图后发起一次确定性的工具调用，剩下的多系统交互全部交由执行层稳健完成。 --- ### [13:24](https://www.youtube.com/watch?v=MhjUbED89vw&t=804s) 生产级连接器：从“报错中断”到“智能暂停与恢复” 利用 AI 快速编写连接器是当前的一大技术亮点，它让开发者免于繁琐的手写代码和深入研读 API 文档。然而 Roy 警示道，衡量连接器是否具备生产级可用性，核心不在于“能否连通”，而在于“异常与错误处理（Error and Exception Handling）的能力”。 Roy 举了一个极具代表性的企业故障场景：Agent 正在执行跨系统流程，此时目标系统突发宕机。脆弱的连接器会直接抛出错误并彻底中断退出；即便开发者为其加入了轮询（Polling）重试机制，当系统恢复后，Agent 往往只能从恢复时刻开始处理新事件，而宕机期间堆积的大量积压数据则被遗漏，运维人员不得不手动编写补偿脚本去“冲洗”（Flush）并补录数据。而一个真正的生产级连接器在遇到系统故障时应当优雅地“暂停”（Pause），保留上下文并进入等待；待目标系统恢复后，能够自动识别故障窗口期内的积压数据，平稳完成消费与同步。 - 韧性暂停机制：遇到下游系统不可用时自动挂起等待，而非直接报错崩溃退出流程。 - 自动背压与数据冲洗：下游系统恢复后，自动拉取并按序处理宕机期间积压的业务数据，无需人工介入补数。 - 全方位异常防御：将网络波动、接口限流、数据格式不一致等真实生产异常纳入连接层默认能力。 --- ### [15:32](https://www.youtube.com/watch?v=MhjUbED89vw&t=932s) 落地框架 GEARS：从技术构建走向组织级规模化运营 光有技术平台无法保障 AI 的成功，企业必须拥有一套完整的方法论来推动组织协同。Roy 介绍了 Workato 总结的“GEARS”运营框架，帮助企业跨部门建立 AI 工厂机制： - **G - Governance（治理）**：在业务前线建立差异化管控。营销与销售部门对数据的开放度与 HR 部门的隐私合规要求大相径庭，治理策略必须精细化分层。 - **E - Enablement（赋能）**：将构建能力下沉至一线业务运营（Ops）团队。运营人员最懂业务全流程，赋能他们利用低门槛平台自行搭建符合规范的 Agent、工作流和专属 MCP。 - **A - Adoption（采纳）**：制定系统的推广蓝图。Roy 直言：“不要以为自己做出了一个超赞的 Agent 并推到生产环境，员工就会自发去用。”采纳必须经过刻意的运营与推动。 - **R - Run（运行）**：构建稳健的运维体系。明确系统中断时的容灾策略，确保自动化与 Agent 在长期运行中坚固可靠。 - **S - Scale（扩展）**：将经过验证的模式固化为企业级标准，实现全组织的跨职能横向扩张。 --- ### [17:30](https://www.youtube.com/watch?v=MhjUbED89vw&t=1050s) Workato 内部实证与 Token 优化：打破调用量与账单的绑定 在演讲最后两分多钟的冲刺阶段，Roy 首次公开了 Workato 内部采购部署 Claude 的真实脱敏数据。在引入 Claude 的前 5 到 6 个月内，全员使用量（蓝线）始终处于低位平原期，员工仅将其作为撰写邮件、起草文案的辅助工具；而当 Workato 面向内部业务场景上线了定制的企业级 MCP 服务器后，员工得以在日常工作流中直接借助 Claude 操控业务系统，Claude 的使用活跃度呈现出指数级的垂直飙升。 更引人注目的是代表模型开销的红线（Spend）。在使用量暴涨的过程中，API 账单金额并没有等比例同频激增，曲线极为平缓。这种“调用量与成本脱钩”的奇迹完全归功于控制层与执行层实施的 Token 极度优化策略： 1. **输出控制（Output Control）**：大模型往往默认输出庞大杂乱的 JSON 结构，后续环节若要解析需要耗费大量 Token。Workato 在执行层拦截并将数据精炼为仅包含核心关键值的纯文本，极大压降了解析成本。 2. **字段过滤（Field Filtering）**：以 Salesforce 中的客户（Account）对象为例，原生对象往往包含上百个字段；若一股脑扔给 AI，AI 上下文将被垃圾数据塞满并浪费海量 Token。通过在执行层配置字段过滤，仅向 Agent 喂入业务真正需要的 30 至 40 个核心字段。 3. **工具调用链固化（Tool Call Chaining）**：将原本需要多次往返推理的多步骤、跨系统工作流压制为单一确定性调用。 在演讲的最后 10 秒，Roy 快速引用了一家全球顶级电信运营商（Telco）的案例：该客户在顶层自由搭建多类交互式 Agent，但中间全量依托 Workato 提供 MCP 封装、API 网关、权限治理与异构系统直连，通过将繁重的业务逻辑从大模型卸载到执行层，成功摆脱了失控的 Token 账单，跨越了试点炼狱。 ## Video description Bhaskar Roy - Chief of AI, Workato Why is enterprise AI spend so high while ROI stays so low? Most companies are stuck in pilots, paying for AI projects that never reach production. The gap isn't better models, it's the absence of an Operating Model. We'll introduce the AI Factory: a repeatable system that turns agentic work into governed, scaled outcomes, with reach across every enterprise system. We’ll also share blueprints on how enterprises moved from experiments to production and realized ROI from their AI investments. [Source](https://www.youtube.com/watch?v=MhjUbED89vw)

[0:04] Bhaskar Roy: It is not a reasoning problem. We call it an execution problem... It is all about how do you really execute after the model does the reasoning.

[0:04] Thank you for joining us for this session. I know  it's the last day, one of the last sessions, so [0:10] totally appreciate you being here. And hopefully  you have a safe ride back. So, you know, uh we [0:19] We are Workato. My name is Anan Bhaskar Roy. I  lead AI there. Just a snapshot of who we are as [0:25] a company, but the key thing that I wanted to talk  about in this slide is we've worked with a number [0:30] of uh you know, Fortune 500 companies looking at  how they have been rolling out AI to production. [0:37] What are the things that they are doing in order  to really scale and ramp things up on their side [0:44] and get value from it. So, this session is mainly  going to be, you know, around our learnings [0:50] from from those, right? And hopefully these  are learnings that we can all take away. [0:56] So, the first thing that you will see over  here, it's um This is not a stat that you're [1:01] not familiar with. I'm pretty sure you would have  seen this in multiple places. It's really not an [1:07] AI adoption problem. I know the panel before was  talking about adoption, but if you look at it, [1:12] people are trying various things around AI. They  are adopting. They are trying various things. The [1:17] challenge is not on the top. The challenge is  mainly what does it take for you to really roll [1:24] this out to production, and that percentage is  actually pretty small. So, how many pilots really [1:31] go out to production? Really starts it so that you  can see value from it. That's the main challenge. [1:38] And this is a challenge which we see across  across the board in pretty much all the companies [1:43] uh that we work with. So, the second part that we  have realized is the AI models are just so good. [1:56] Right? And they keep getting better day over  day. That is just you try something and and [2:01] you feel really good and empowered as to how much  improvement that is happening. The problem isn't [2:08] reasoning. Reasoning is happening a lot, right?  People are building various kind of agents. [2:14] They're even trying the various simple workflows.  I would say the dynamic workflows, etc. that these [2:19] models provide. It is not a reasoning problem. We  call it an execution problem. Which is you've done [2:27] that well, models have reasoned well, but then  you're still when you have to roll something out [2:33] to production, there are things that you need  in order to make things really work. One is [2:40] I would say deterministic workflows. Means you  cannot rely on a model to do your order to cash. [2:47] All of a sudden your books are wrong and  everything is goes wrong if it there is [2:52] some hallucination in it, right? So, it has to  be deterministic. You need to make sure that it's [2:57] governed. I'll go back to the finance use case.  Who can if you build out a finance agent, who has [3:02] access to that agent? What kind of data can they  see? Including even say customer data, who has [3:08] access to that data? Governance is a key part for  you to be able to scale this in your organization. [3:15] And the final part of it is enterprise scale,  right? So, it is means AI is one of those broad [3:22] things that you all know that can be applied to  various workflows, various use cases across your [3:28] enterprise. Can you put those building blocks in  place so that your entire organization can scale [3:36] as a part of this? Um so, those are  the challenges that we see when we do [3:42] or we start talking to customers, it is not  about models about Seems like the mic is going [3:51] on and off. It is all about how do you really  uh uh execute after the model does the reasoning [3:58] and how do you put things in place so that  you can scale AI throughout your company. [4:05] This is an eye chart. But this is typically  the diagram that we go when we start talking to [4:12] customers we see they are using multiple models.  As you can see over there, they would have built [4:18] used multiple agentic tools to build agents. There  are two challenges I'll call out in this. One is [4:26] obvious, it's all the multiple connections each  of those are making and these are point-to-point [4:32] connections. Right? So think about whether you're  using Cloud or ChatGPT, you use the connectors or [4:37] apps as a part of it to make a point connection.  You build another agent with some other thing uh [4:43] say Codex or Cloud Code or whatever or Agent  Force is making yet another one connection to it. [4:48] So every system which has the context or you want  to take action on, there are these point-to-point [4:53] connections that happen. The second part of  it is the graphical representation on the top. [5:01] Every tool has their own set of observability,  the own set of the way you put guardrails, [5:09] own set of ways as to how you do things  and what that does is all of a sudden [5:15] if you have multiple tools doing multiple  connections to your uh to your enterprise systems, [5:21] you have to start managing those two separately  in terms of observability, the governance, all [5:27] of those things separately in and then also manage  these connections separately. We call this chaos. [5:36] And and the and because if you think about it, if  I add another application that you need to access, [5:43] you can imagine the kind of hit that you would  take on your network starting from your network to [5:49] all the systems that will be there. And that's not  something that you can use in order to scale. So, [5:56] we call this there are three gaps. One is what we  call control gap. The second one is the execution [6:04] gap, and the third is scale gap. It's pretty  obvious if you think about it. The control gap [6:10] is related to everything around your governance,  token costs, token, you know, optimization is also [6:18] a part of that. So, everything that you need to do  in order to govern your entire systems. The second [6:24] is execution, which is when you're going to go  execute to these specific workflows or use cases, [6:31] what does that look like? And some of In some of  these cases, you want these workflows to be very [6:36] deterministic. In some cases, you're okay if  it is not fully deterministic. So, those are [6:42] things that you need to figure out. The third one  is scale as to how you scale uh scale overall. [6:48] I'll quickly put it in terms of this, but  the core thing that you will see over here is [6:55] on the control side, it is agents when they go  to take action, especially when they take action [7:03] or if they are to read, you know, they  should always work on behalf of the user. [7:09] I'll give an example. Say if I'm a an account  exact uh as a sales rep, and I have access to [7:15] certain parts of my sales force. If I ask  for something, I should only see my view [7:20] and be able to take action on the opportunities  and accounts that I have rather than go [7:25] take I know I cannot should not be able to  say I see one of our sales rep there Erin, [7:30] uh go update Erin's opportunity. He won't like  it. And that's not the right thing to do. So, [7:35] it should always work on behalf of the user. I'll  just call out few things. Everything should be [7:41] auditable. Everything should be logged so that  you know exactly what happens and especially if [7:46] things go wrong, it should alert you so that  you know what to do about it. Execution, um [7:53] every process that you have and I think the  panel before us was also talking about it. [7:59] That should be done orchestrated end-to-end,  right? And it should be done in a way [8:04] so that you can get the same results every time  that you run that particular process. It is not [8:12] that you're relying on AI and saying that, "Okay,  I'll give it to you." But you don't know if the [8:18] end results are there every single time. And  what that means is even when you set eval's, [8:24] you should not be setting it at the model level.  You should be setting at the result and the KPI [8:30] level where you can actually see what happened in  the system and if it did the right thing or not. [8:37] So, this is the way to think about the  architecture and also the various components [8:46] of this architecture. There are a number  of things over here, but I'll call out a [8:52] a few few elements of this which may be which  may be of more importance. But before I go there, [8:59] you know, when you look at any kind  of system, whether it be, you know, [9:05] especially in enterprises, there are a lot of  still on-prem home-grown systems. There are still [9:11] a lot of databases, data warehouses which are  still something that you own. And you should be [9:17] able to leverage even those on-prem systems as a  part of your agentic workflows, right? So, that's [9:23] a that's a key part that needs to be looked at,  but you should not just think of SAS. You should [9:28] think of your entire systems, everything which is  there and which agent can access what and be able [9:34] to do that. Now, if you there are a few things,  um that I would like to call out over here. [9:41] One is this notion of enterprise skills.  Uh I'm pretty sure all of you know about [9:46] skills in general, which is Claude skills, etc.  that you can use in order to define workflows. [9:53] The challenge with that it it it's actually  pretty good that you can just go define it [9:58] in natural language and it works the way it  is. The challenge with that are two. One is [10:05] it if it is trying to figure out how to execute  those workflows, but sometimes it may not be able [10:13] to do it deterministically every single time the  right way. That's the first problem. The second [10:19] problem is I don't know if you have tried uh these  dynamic workflow capabilities of these companies, [10:27] it uses a lot of tokens. Right? Because it's  trying to figure out what you are trying to say [10:32] and then trying to figure out how to go to those  planning systems in order to do it, it it really [10:38] uses a ton of tokens. Not the best use. So, we  have this notion of what we call enterprise skills [10:45] and that is on the execution layer. Think of this  as a workflow that you have very prescriptively [10:53] defined. Right? So, in this case you can see that  it's creating an invoice and something happens, [10:59] it goes, creates an invoice, and does something.  Now, that's a workflow. That's a workflow that you [11:04] all know and you use on a regular basis, you don't  have to have AI create that workflow for you. [11:12] You can create that workflow with whatever tools  you have. All you have to do is just make sure [11:18] that when that particular tool is or this  workflow is to be called, it's called straight [11:24] in a deterministic way. So, for example, if you  go to say for to any agent or even uh, Claude or [11:30] ChatGPT and say, "Hey, create an invoice." You  just have to make sure that your workflow is [11:35] called and it's not trying to figure out all the  various things in order to create that invoice. [11:42] Now, the second part of this, which brings  this together, is what we call enterprise MCP. [11:50] The top diagram is what typically happens.  Right? MCPs are today are all API wrappers. [12:01] You provide the CRUD operations predominantly,  you make it available to your AI, and then when [12:08] you start executing a workflow, I say, going back  to the create invoice, it is trying to figure out [12:13] through all the various MCPs which thing to call,  which tool to call, in what particular sequence [12:20] in order to do that. And it looks like the top  diagram. The ideal scenario for you to scale [12:28] what we call enterprise MCP is you expose the  workflow that we just talked about as a tool call, [12:37] and that particular tool call is called by AI only  once. So, when you go and say, "Create invoice." [12:43] it knows, or in this particular  case, it is the expedite offer, [12:49] it knows that, "Hey, there's a tool which  cuts across multiple systems in order to do [12:54] the workflow deterministically, makes one call  in order to execute that particular workflow." [13:01] So, what that essentially means is every company  is different. So, what that means is your MCPs [13:08] that you take on should be composable in nature.  You should be able to build these workflows [13:14] and make those available as MCP tools as a part of  your MCP, uh, strategy. So, that's enterprise MCP. [13:24] Now, the next part is, uh we all know that,  you know, AI does a really good job in building [13:34] connectors to various applications. And that is  fantastic. Because what that means is you can [13:40] create connectors to all the various systems and  your applications which are there. You can scale [13:44] fast. You don't have to rely on actually coding  or understanding APIs to be able to do that. [13:51] Now, the thing to think about as you look at  those connectivity is not whether the connector [13:59] was built, but can it do error handling the  right way? The problems always are in error [14:06] and exception handling. I'll give you a quick  example. An agent wants to go execute a workflow [14:13] and it's connecting to a system, what  if that system is down for that time? [14:20] The agent will say, "I sorry, I cannot do this  anymore. I'm done." But then, once it comes back [14:25] up, agent might be pulling. If you build that  pulling capability, it can do certain things. But [14:31] then, there would be a lot of records. Say it was  down for a period of time, it could have processed [14:37] a lot of records. You have to write a separate  script to figure out how to flush those records [14:42] because agent will pick it up from the time it  came back up. It does not know what else happened. [14:48] Ideally, what the connector should do is not  stop. It should pause. That, "Okay, I'm not [14:54] able to connect to this system. I'll pause over  here. When it comes back, it understands what what [14:59] what happened during that period of time, takes  it, flushes it. You don't have to worry about it." [15:04] So, one kind of error. But there are multiple  of these kind of errors and exception handling [15:09] that happens that you should factor in when  you're building these kind of connectors. [15:15] So, essentially, it comes down to what you  want is the a and execution plane, which is [15:24] able to take all of these various conditions  and and help you scale those to production. [15:32] Now, technology is not enough. A platform is  never enough in order to build those things out. [15:41] You need a framework for people to be able to  adopt it means across your organization. We call [15:48] this the gears framework and you can see what that  means. Essentially, the it starts with governance. [15:54] So, as you're putting governance in place, what  does that look like? A governance in terms of [15:59] what the marketing and sales department  will be very different than say HR. [16:04] Pardon me. So, how do you put the governance  in place so that you can scale throughout? [16:09] The second part of it is [16:14] Pardon me. Um enabling essentially all the various  systems and tools in your organization to be able [16:21] to actually start building it themselves, right?  So, enabling the entire team or your entire [16:27] organization, especially say operations team,  who are very tuned to the various processes that [16:32] they do, so that they can actually build their own  agents or their own workflows as a part of this or [16:38] even their own MCPs. The third part of it is adopt  adoption is always a key thing. So, coming up with [16:46] a blueprint of adoption, what that looks like,  and this is something that we have worked with [16:51] our customers quite a bit. So, if you think that,  "Hey, we built this kickass agent, everything is [16:57] working, it's in production." Doesn't mean that  people will start using it. So, how do you really [17:03] drive overall adoption? That's a key part to  think about as you put the framework in place. [17:10] Run it. Once it runs and it's starting to  operate, what does it look like when things break? [17:16] How sound is it as things come together? The  key part to think about. And then finally, [17:24] how you scale this throughout your organization.  So, I'm seeing that I only have 2 and 1/2 minutes [17:30] left, so I'll go a little bit faster. This  is This is the data that we see internally [17:37] at Workato. I'll spend just 20 seconds on  this. If you look at it, we licensed Claude. [17:44] And the blue line is usage. Right? So, we  lost a license Claude for a good 5-6 months. [17:51] You know, there was people were using it, but not  as much, right? Because you would be doing all of [17:55] this around, say, email content generation, mainly  around content that people were using it for. [18:00] Then we started rolling out our MCP servers, which  were very specific business use case oriented. So, [18:07] people could actually do their work that  they do on a daily basis using just Claude [18:12] AI, right? As the As the interface.  And you saw the usage that I'm talking [18:18] The second part of it that you will notice  is the red line is the spend line. Our spend [18:24] did not grow proportionally as a part of this,  mainly because everything was being done in the [18:29] controller and execution layer, not at the model  layer. So, token tokens were getting optimized. [18:37] Um these are some of the stats again that  we see as how token optimization works. [18:44] So, for example, output control. This is a  little bit of technical side of things that [18:49] typically when you ask AI to give you something,  it will give you everything. So, you get a ton [18:54] of JSON. And now AI has to parse and figure those  things out. Guess what? Takes tokens to be able [19:00] to do that. Whereas, if you give it in plain text  one simple thing that AI needs to know and execute [19:08] is just as you can imagine, less tokens as a  part of that. Similarly around field filtering, [19:16] what I've got a way to think about field  filtering is if you go and ask AI to say, [19:21] "Hey, I want to see all my account data." Means  bring me information about this particular account [19:27] specifically in these particular areas so  that I can take action. Very simple use case. [19:32] When it goes to Salesforce, your account object  in Salesforce might have 100 fields turned off, [19:39] but it will return all 100 fields. All of a sudden  now you're feeding AI with a ton of data that [19:45] it now needs to parse. Whereas if you had the  ability to say, "I'm only interested in these [19:51] 30 40 fields in the account data." and asked it  to return just those, then it's a less number of [19:59] fields that it needs to parse. So those kind  of things that that are that happen, tool call [20:04] chaining chaining we already talked about which  is essentially multi-step, multi-system workflows. [20:10] So how those things work. So with 10  seconds left, this is not just us saying [20:18] our customers, this is one of the largest telcos.  What they're doing is they have built out a layer [20:23] on top where you can use it to build any kind  of agents, but their entire thing is in the [20:30] middle they use Workato for their MCPs, for their  APIs, for their governance and control, accessing [20:37] systems, and and you know the models that are  These are some of the results that we see.