Xebia Cuts Cruise Line Support Times 83% With Bedrock AI Agents

Xebia借助Bedrock AI智能体将邮轮客服支持时间缩短83% 通过多智能体系统实现邮件工作流自动化，使人工干预减少95%，并在数分钟内解决客户咨询。 为解决一家大型邮轮公司每日超过1万封邮件积压的问题，Xebia利用大语言模型与多智能体编排构建了一个包含8个阶段的自动化处理流水线。该系统负责处理宾客验证、个人身份信息（PII）去标识化、摘要生成、意图分类以及包含人机协同审查的CRM记录归档。这一向AWS原生多智能体架构的转型，将处理时间从30分钟缩短至5分钟，人工干预减少了95%，并将SLA违规率降低了80%。 企业 AI 架构正从单体 LLM 问答和 RAG 知识检索，演变为基于协议集成与工具调用的多智能体（Multi-Agent）协同系统。 (0:26) 某大型邮轮运营商此前每日面临超 10,000 封客户邮件涌入，近 200 名顾问人工处理导致回复周期积压长达 24 至 36 小时。 (0:52) Xebia 为其构建了 8 阶段 AI 处理流程，涵盖垃圾过滤、身份验证、隐私信息（PII）脱敏、意图分类及 CRM 自动写入，并通过人机协同机制保障最终审核。 (13:09) 方案最终演进为基于 AWS Bedrock Agents 的多智能体编排架构，将单封邮件处理耗时从 30 分钟压缩至 5 分钟，人工介入减少 95%，SLA 违约降低 80%。 (17:48)

Diederik Greveling, CTO of Xebia Data & AI Benelux, outlines how enterprise AI architectures are shifting from single LLMs to multi-agent networks, illustrating the model with a customer service transformation for a major cruise line operator. Evolution from Basic LLMs to Multi-Agent Networks (0:26) Enterprise generative AI has advanced across five key architectural stages. The initial deployment of standalone large language models yielded prompt-and-response interactions with novelty but limited business return. To increase practical value, organizations incorporated Retrieval-Augmented Generation (RAG) for internal context, followed by action triggers requiring user sign-off and tool execution through protocols such as Model Context Protocol (MCP). According to Greveling, the current state of the art involves multi-agent systems where specialized, autonomous agents collaborate across functional domains. Rather than relying on a monolithic prompt interface, these architectures allow discrete agents to hand off sub-tasks dynamically to complete complex operational workflows. Customer Service Bottlenecks in Cruise Operations (0:52) The operational limits of manual processing were highlighted in a deployment for one of the world's largest cruise line operators. The organization received over 10,000 incoming customer emails daily regarding itinerary adjustments, ticket purchases, and general support questions. A team of approximately 200 cruise consultants managed these manual queues, leading to turnaround times spanning 24 to 36 hours per inquiry. Beyond drafting replies, consultants spent significant time reading, categorizing, and manually updating CRM records for every customer touchpoint. This high overhead prompted the implementation of an automated, agentic AI foundation to streamline ticket routing and communication. Deploying an Eight-Stage Processing Pipeline To handle incoming customer communications reliably, Xebia designed an eight-step pipeline balancing automation, data governance, and compliance. The workflow begins by running deterministic and LLM-based filters to discard spam, followed by CRM lookups to validate guest profiles and PII anonymization to strip sensitive identifiers such as passport numbers and birth dates in compliance with regulations like GDPR. Downstream stages distill emails into structured summaries, classify intent into primary queues like sales bookings versus service adjustments, and determine whether action is needed or if threads can be closed automatically. Summaries and actions are written back into the enterprise CRM, and generated draft responses are presented to consultants for one-click approval or manual rejection. Core Implementation Safeguards and Technical Constraints (8:27) Greveling notes that agentic deployments require mitigating the inherent non-determinism of LLMs, where identical inputs can yield divergent outputs. Addressing this variability requires strict validation frameworks, clear guardrails, and a clean single source of truth within the client's CRM foundation to prevent cascading data errors. Equally critical are observability stacks encompassing tracing, logging, and performance tracking to detect operational drift as customer language patterns change over time. The system also requires dedicated human-in-the-loop workflows from day one to maintain quality control while gathering feedback for continuous model improvement. System Architecture Transition and Operational Gains (17:48) Initially deployed with a centralized middleware engine calling task-specific LLMs, the platform evolved into an AWS-native multi-agent architecture built on Amazon Bedrock Agents, Amazon EKS, and API Gateway. In this decoupled setup, an orchestrator agent delegates narrow tasks to focused domain agents. The deployment delivered significant efficiency gains: average email processing times fell from 30 minutes to 5 minutes, representing an 83 percent reduction. Backlogged emails exceeding the 48-hour SLA dropped by 80 percent, and necessary manual human feedback intervention declined by 95 percent as system confidence matured. Greveling emphasizes three core rules for scaling enterprise agentic AI: embedding human-in-the-loop validation early, maintaining comprehensive observability and logging to catch drift, and keeping individual agent scopes small, focused, and simple.

Xebia 数据与人工智能首席技术官 Diederik Greveling 指出，大型企业正通过从独立大模型向多智能体协作系统的架构演进，化解传统客户服务中的运营瓶颈。以全球大型邮轮运营商的实践为例，结合严格数据治理与人机协同的自动化流水线成功将单封邮件处理时间缩减了83%，并大幅降低了服务响应延迟。 企业AI架构的五阶段演进 (0:26) 根据 Greveling 的梳理，企业级生成式人工智能的应用经历了清晰的演进路径。早期的第一阶段仅依赖独立的大语言模型（LLM）进行单次提示词与回复交互，虽具备技术新颖性但产生的实际业务价值有限。为解决准确性问题，企业进入第二阶段，通过检索增强生成（RAG）引入内部知识库作为事实锚点；随后进一步演进到产生操作触发（Action Triggers）以及通过模型上下文协议（MCP）与外部工具和API无缝整合的自动化阶段。 当前最前沿的形态则是第五阶段的多智能体系统（Multi-Agent Systems）。在该体系下，各具专长的自主智能体能够围绕多步骤业务流程进行动态协作与任务分工。这一演变使 AI 从单纯的被动问答系统，转变为能够承接复杂跨系统工作流的企业级协同引擎。 业务运营痛点与四大工程支柱 (0:52) 在该案例中，某全球大型邮轮运营商每日需接收超过1万封客户咨询邮件，涵盖船票预订、行程变更以及通用服务。由于此前完全依赖近200名邮轮顾问进行人工阅读、撰写回复并向客户关系管理系统（CRM）登记数据，导致服务响应时间长达24至36小时，积压严重。 针对该业务场景落地自动化系统时，工程团队必须跨越模型固有缺陷与系统集成的多重挑战。团队为此确立了四大部署支柱：首先是通过稳健的软件架构化解大语言模型的非确定性（Non-Deterministic）输出；其次是依托CRM建立治理规范的单一真实数据源（Single Source of Truth）；第三是部署涵盖跟踪与日志记录的全套可观测性技术栈，以及时发现客户表达演化带来的模型漂移；最后则是从方案设计首日就必须设立并配备运营资源的人机协同（Human-in-the-Loop）机制。 八阶段合规与意图处理流水线 (13:09) 为保障客户沟通处理的高可靠性，Xebia 构建了一套结合确定性规则、隐私合规脱敏、模型摘要以及人工复核的八阶段端到端邮件流水线。进入系统的邮件首先会经过垃圾过滤以剔除无效内容，随后通过比对CRM系统记录验证发件人是否为现有客户，并在第三阶段根据欧洲通用数据保护条例（GDPR）等区域隐私法规，对护照号码和出生日期等个人身份信息（PII）进行匿名化擦除。 完成数据预处理后，流水线将非结构化长文本转化为结构化摘要，并将意图细分至主要队列——重点区分为新预订等销售类需求与改签等服务类需求。接着系统确定具体行动策略（如自动归档单纯致谢邮件或起草回复草稿），将处理结果自动同步登记至CRM，最后将草稿推送给人工顾问进行一键审核或拒绝；若审核被拒，则流转至人工介入处理。 云原生架构转型与量化成效 (17:48) 在技术架构上，该项目初期采用调用专有模型的集中式中间件方案，随着系统成熟，逐步迁移为基于 Amazon Bedrock Agents、Amazon EKS 与 API Gateway 的云原生多智能体平台，由主协调智能体将子任务分配至对应领域的专用智能体处理。该方案上线后取得了显著的业务收益：单封邮件的平均处理时间从30分钟缩减至5分钟（降幅达83%），超过48小时未回复的违约事件减少了80%，且随着模型置信度与信任度提升，需要人工干预审核的比例累计下降了95%。 Greveling 据此提出了企业规模化部署智能体 AI 的三条准则：从项目初期就对人工反馈闭环进行重度投入；部署完善的监控、追踪与日志记录体系；并确保每个独立智能体的功能边界保持小巧、专注与清晰。 该实施方案证明了多智能体协作与云原生基础设施结合能够显著提升劳动密集型客服的运营效率，但其成效与可持续性高度依赖于底层CRM数据治理的质量、对模型非确定性输出的持续监测，以及在自动化规模扩大过程中始终保持有效的人工闭环监督。

## Background 该内容由 Ai4 于 2025 年 8 月 28 日发布在 YouTube 平台上。视频简介指出，本次演讲由 Xebia 云与数据解决方案 CTO Diederik Greveling 主讲，深入探讨了一家大型邮轮公司如何利用 AWS Bedrock Agents 和 Anthropic Claude 结合的智能体 AI（Agentic AI）重塑客户服务体系，将邮件处理时间从 30 分钟缩短至 5 分钟并大幅降低 95% 的人工干预。 ## TL;DR 演讲梳理了企业级 AI 从简单 LLM 问答到多智能体（Multi-Agent）系统的演进路线，并分享了 Xebia 帮助全球顶尖邮轮公司解决每日 10,000+ 封客服邮件堆积难题的真实案例。通过构建包含过滤、验证、PII 脱敏、摘要、意图分类与 CRM 集成在内的 7 步自动化工作流，结合闭环反馈机制（Feedback Loop），不仅极大地减轻了近 200 名邮轮顾问的操作负担，还将 SLA 违约率降低了 80%。最后，演讲者总结了企业规模化落地 Agentic AI 需关注的数据治理、监控日志以及“小步快跑”的黄金法则。 ## Atmosphere & style 整个演讲沉稳专业且富有战略视野，演讲者以技术型高管的亲和力娓娓道来，既有对业界前沿技术演进的宏观把控，又有扎实的企业级实践数据支撑。现场氛围严谨务实，将技术架构的严密逻辑与业务落地的切实痛点紧密结合，给听众带来既具启发性又极具可落地指导价值的观赛体验。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=siTQxGxPjUo&t=4s) 生成式 AI 正推动企业流程优化、高效扩展与服务质量提升，成为 C-level 管理层规避被淘汰风险的核心驱动力。 - [00:26](https://www.youtube.com/watch?v=siTQxGxPjUo&t=26s) 企业级 AI 架构经历了从基础 Prompt 问答、RAG 检索增强、Action 工具调用，到多智能体（Multi-Agent）系统分工协作的演进。 - [00:49](https://www.youtube.com/watch?v=siTQxGxPjUo&t=49s) 顶级邮轮巨头面临每天超 10,000 封邮件的巨大吞吐量，200 名顾问人工处理导致平均响应延迟高达 24 至 36 小时。 - [00:08](https://www.youtube.com/watch?v=siTQxGxPjUo&t=8s) Agentic AI 解决方案的核心在于通过自动化分类、摘要提取、CRM 深度集成与人机闭环反馈，全面解放重复性劳动力。 - [00:10](https://www.youtube.com/watch?v=siTQxGxPjUo&t=10s) 企业落地 Agentic AI 面临四大非技术与技术挑战：模型非确定性、缺乏单一事实来源的数据底座、性能漂移监控以及组织变革管理。 - [13:09](https://www.youtube.com/watch?v=siTQxGxPjUo&t=789s) 系统设计了涵盖垃圾过滤、客户验证、PII 隐私脱敏、摘要提取、意图分类、CRM 自动登记与 HITL 反馈校验的 7 步严密工作流。 - [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) 基于 AWS Bedrock Agents 与 Anthropic Claude 模型构建编排 Agent，配合 Amazon EKS 与 API Gateway 实现端到端任务动态调度。 - [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) Agentic AI 系统上线后效果显著：单封邮件处理时间从 30 分钟缩短至 5 分钟，SLA 违约率降低 80%，人工干预率锐减 95%。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=siTQxGxPjUo&t=4s) 个人背景介绍与演讲核心主题 Xebia Cloud and Data Solutions 的 CTO Diederik Greveling 开场向现场听众致意，并介绍了本次演讲的主题：一家知名旅游企业如何借助人工智能（AI）实现客户服务的全面转型。Diederik 简要分享了自己的专业背景，他拥有超过 10 年的 AI 与数据领域经验，最初从数据工程师做起，自认偏向技术型管理人才。虽然本次分享偏向高层战略与应用架构，但他欢迎听众在会后交流具体的底层技术细节。 随后，Diederik 探讨了当今企业普遍引入 AI 的核心动力。AI 在过去十年中蓬勃发展，特别是近年生成式 AI 的爆发，为企业带来了流程优化、规模化扩展与服务质量提升的巨大机遇。当下的董事会和 C-level 管理层对 AI 抱有极高热情，同时也普遍存在某种“被技术浪潮抛在身后”的焦虑感。演讲将通过具体的实际案例，向大家证明企业级 AI 系统的落地价值。 - 演讲者：Diederik Greveling（Xebia 数据与 AI Benelux 地区 CTO） - 从业经历：10 年以上数据与 AI 经验，数据工程师出身 - 核心观点：生成式 AI 正在推动企业流程的优化、高效扩展与质量提升，C-level 管理层需积极拥抱变化 --- ### [00:26](https://www.youtube.com/watch?v=siTQxGxPjUo&t=26s) 从基础 LLM 到多智能体（Multi-Agent）系统的演进 Diederik 梳理了生成式 AI 在过去几年中的技术架构演进轨迹。最早期阶段，绝大多数应用场景仅依赖单一的大语言模型（LLM）配合基础 Prompt，用户输入问题，模型返回文本回答。这种方式虽然展示了 AI 的潜能，但能创造的实际业务价值十分有限。 ``` [ 单一 LLM + Prompt ] ──> [ LLM + RAG (检索增强) ] │ ▼ [ 多智能体系统 (Multi-Agent) ] <── [ LLM + RAG + Tooling/MCP ] ``` 随着技术发展，行业演化出了 RAG（检索增强生成）技术，让 LLM 能够结合企业内部知识库给出更准确的回答；接着在此基础上引入了“动作/执行（Actions）”机制，使模型不仅能回答问题，还能发起具体的业务操作。发展到当前阶段，通过 MCP（Model Context Protocol）和工具调用的结合，AI 已经发展为**多智能体（Multi-Agent）系统**——多个具备特定功能的 AI Agent 分工协作，共同完成复杂的端到端业务任务。 - **第一阶段（基础 Prompt）**：单模型简单问答，业务价值有限。 - **第二阶段（RAG 增强）**：结合外部/内部知识库，提供精准信息。 - **第三阶段（Action & Tooling）**：连接企业内部工具与系统（如 MCP），自动执行具体动作。 - **第四阶段（Multi-Agent 协作）**：多 Agent 各司其职、协同作业，处理复杂业务工作流。 --- ### [00:49](https://www.youtube.com/watch?v=siTQxGxPjUo&t=49s) 邮轮巨头面临的邮件处理痛点 Diederik 分享了 Xebia 服务的一家全球顶尖邮轮公司（Cruise Line Operator）的真实案例。该公司每天需要处理海量的客户来邮，涉及票务咨询、行程变更、服务预约等极为复杂的业务逻辑。由于缺乏自动化手段，客户服务部门陷入了严峻的运维困境。 每天入站的客户邮件高达 10,000 多封，虽然其中包含部分垃圾邮件，但绝大多数都是高精度的具体业务诉求。此前，该公司安排了近 200 名专业的“邮轮顾问”（Cruise Consultants），他们的全天工作基本被人工阅读、回复邮件以及同步 CRM 系统所填满。极高的工作负荷导致邮件平均响应时间长达 24 至 36 小时，极大地影响了客户体验与满意度。 - 每日邮件处理量：**10,000+ 封** - 客户服务团队规模：**近 200 名邮轮顾问** - 旧流程响应延迟：**24 至 36 小时** - 主要业务痛点：耗费大量人力、响应缓慢、CRM 手动录入繁琐 --- ### [00:08](https://www.youtube.com/watch?v=siTQxGxPjUo&t=8s) Agentic AI 解决方案的核心组件与业务目标 为了解决邮件堆积与人工疲惫问题，Xebia 团队为其量身打造了一套基于 Agentic AI 的自动化系统。该系统不仅要能精准理解邮件内容并自动生成高质量回复，还需要彻底解放这 200 名邮轮顾问，让他们能够从机械的邮件回复中抽身，转向更高价值的业务服务。 ``` 入站邮件 ──> [ 意图分类 ] ──> [ 摘要提取 ] ──> [ CRM 联动与追踪 ] │ ▼ [ 人类专家确认 (反馈环) ] <── [ 自动生成回复与动作 ] ``` 该套解决方案主要由四大核心组件构成： 1. **自动意图分类**：识别邮件主题并准确定义后续所需的处理动作。 2. **智能摘要提取**：从不同撰写风格（长篇大论或过于简短）的自由格式邮件中提取关键信息。 3. **CRM 系统深度集成**：将提取出的数据与处理状态实时推送到 CRM 平台中，实现业务全流程追踪。 4. **闭环反馈机制（Feedback Loop）**：引入人工审核与持续追踪机制，确保系统回答质量并实时校准模型表现。 - 核心目标：降低人工干预比例、缩短响应周期、自动同步 CRM 数据 - 自动化关键步骤：分类 $\rightarrow$ 摘要 $\rightarrow$ CRM 系统录入 $\rightarrow$ 回复生成与人工确认 --- ### [00:10](https://www.youtube.com/watch?v=siTQxGxPjUo&t=10s) Agentic AI 落地过程中的挑战与应对策略 Diederik 坦言，在企业级环境部署 Agentic AI 系统并非一帆风顺，团队面临着四大非技术与技术层面的严峻挑战： 首先是**模型的非确定性（Non-deterministic）**问题，相同的输入可能产生不同的输出，必须通过构建鲁棒的系统架构来约束模型行为。其次是**数据质量与基础建设**，如果企业缺乏完善的数据治理和“单一事实来源（Single Source### 演讲者背景与企业 AI 的崛起 演讲者 Diederik Greveling（现任 Xebia 云与数据解决方案/数据与 AI 部门 CTO）首先向观众致以问候，并介绍了自己的背景。作为在 AI 与数据领域从业 10 余年的资深专家，他最初担任数据工程师，自认更倾向于技术型管理角色。本次演讲旨在深入探讨某大型旅游企业如何利用 AI 彻底重塑其客户服务体系。虽然整体 presentation 偏向高层战略，但也随时欢迎深入的技术讨论。 Greveling 回顾了过去 8 到 10 年间 AI 的迅猛发展，尤其是生成式 AI（Gen AI）在过去几年带来的深刻变革。随着系统智能化程度不断提高，企业在优化流程、扩展业务、提高运作效率以及提升整体交付质量方面迎来前所未有的机遇。如今，企业董事会与 C-level 高管对 AI 的态度非常明确：要么对其蕴含的巨大价值充满极高兴趣，要么极度焦虑担忧被技术浪潮淘汰。 - **演讲者背景**：Diederik Greveling，Xebia Benelux 部门 CTO，10+ 年 AI & Data 领域经验。 - **核心驱动力**：AI 已从概念验证走向企业生产落地，帮助公司优化流程、规模化扩张并提升交付质量。 --- ### [02:36](https://www.youtube.com/watch?v=siTQxGxPjUo&t=156s) 智能体 AI（Agentic AI）的技术演进路线 Greveling 详细拆解了企业级 AI 从最初简单的 LLM 问答演进到多智能体（Multi-Agent）系统的五个阶段。如果有人到今天还没听过 Agentic AI，那简直就是“一直生活在石头底下”。这种演进代表了自动化能力的根本性飞跃： 1. **基础 LLM + Prompt**：最早期阶段，用户输入 Prompt，模型给出回答。虽然展示了 LLM 的潜力，但业务附加值极低。 2. **LLM + RAG（检索增强生成）**：结合外部知识库，让模型能够基于特定数据给出更准确、更有依据的回答。 3. **LLM + RAG + Actions（触发行动）**：不再局限于“回答问题”，而是能根据生成的答案直接触发具体的操作指令。 4. **Agentic System（单智能体 + 工具集成）**：引入 Model Context Protocol (MCP) 和 Tooling 机制，将 AI 与企业内部工具及系统深度对接，实现自动化任务执行。 5. **Multi-Agent Systems（多智能体系统）**：当前的最前沿形态。多个专有职能的 Agent 各司其职、协同作业，共同完成复杂的端到端业务目标。 Xebia 的核心业务模式正是帮助企业构建通用的 AI 底座（AI Foundations），并在其上部署能够解决具体业务痛点的 Agent，协助客户贯穿业务部门与 IT 部门的落地实施。 --- ### [05:40](https://www.youtube.com/watch?v=siTQxGxPjUo&t=340s) 案例背景：顶级邮轮公司的客服邮件困境 本次分享的技术落地案例来自 Xebia 的真实客户——全球最大的邮轮公司之一（Cruise Line Operator）。该公司在客户服务环节面临着极其沉重的运营压力： - **极高的邮件吞吐量**：每天收到超过 10,000 封客户邮件，内容涵盖服务咨询、船票预订、行程变更等。 - **极其繁重的响应迟滞**：处理一封邮件平均需要 **24 到 36 小时**，严重影响客户体验。 - **高昂的人力成本**：配备了近 **200 名邮轮顾问（Cruise Consultants）** 专门处理邮件回复与分类。 - **低效的操作流程**：顾问们不仅要手动撰写回复，还必须逐一登录 CRM 系统手动记录操作日志，造成严重的人力资源浪费与操作疲劳。 企业迫切需要建立一套能够精准理解邮件内容、自动生成回复、并自动完成 CRM 数据登记的智能化系统，让 200 名顾问从重复性劳动中解放出来，转而专注于高价值的客户服务。 --- ### [08:27](https://www.youtube.com/watch?v=siTQxGxPjUo&t=507s) 系统核心组件与企业级落地挑战 为了解决上述痛点，Xebia 打造了一套结合先进语言模型与自动化工作流的 Agentic 架构，其核心业务组件包括： - **自动邮件分类（Categorization）**：精准识别邮件意图，将其归类至对应业务模块（如 Sales 或 Service），并定义后续动作。 - **智能文本摘要（Summarization）**：由于邮件格式自由且长短不一，必须精准提取核心要点，过滤噪音，为下游 Agent 提供高纯度的上下文。 - **CRM 深度集成**：将提取的数据与拟定的操作自动推送到 CRM 系统，实现全流程追踪。 - **闭环反馈机制（Feedback Loop）**：构建人机协同的 Validation 环节，持续追踪并纠正模型表现。 同时，Greveling 强调了在构建 Agentic AI 系统时面临的四大关键挑战： ``` [挑战 1: 非确定性] ──> 构建 Robust 架构 / 容错机制 [挑战 2: 数据质量] ──> 建立 Single Source of Truth 与数据治理底座 [挑战 3: 性能漂移] ──> 引入 Logging / Tracing / Monitoring 监控栈 [挑战 4: 变革管理] ──> 建立人机协作的 Feedback 流程 (人机协同) ``` - **非确定性（Non-deterministic Nature）**：LLM 针对相同的输入可能给出不同输出，必须依靠强健的系统架构来约束。 - **数据质量底座（Data Foundation）**：许多企业缺乏统一的“单一事实来源（Single Source of Truth）”和完善的数据治理，这是导致 AI 系统不稳定的根本原因。 - **监控与追踪（Monitoring & Tracing）**：由于用户提问方式和业务场景会随时间发生漂移，必须建立完善的日志与监控体系。 - **组织变革与资源分配**：引入 Agent 会改变员工的工作方式，如果未事先配置好反馈机制的人力资源，项目极易走向失败。 --- ### [13:09](https://www.youtube.com/watch?v=siTQxGxPjUo&t=789s) 7 步智能邮件处理工作流 针对邮轮公司的业务特点，Xebia 设计了一套严密的 7 步处理流程，实现了从邮件接收到自动发送的全生命周期管理： ``` +-------------------+ +-------------------+ +-------------------+ | 1. 垃圾邮件过滤 | --> | 2. 客户身份验证 | --> | 3. PII 隐私数据脱敏| +-------------------+ +-------------------+ +-------------------+ | +-------------------+ +-------------------+ v | 6. CRM 自动登记 | <-- | 5. 意图分类与动作 | <-- +-------------------+ +-------------------+ | 定义 (Sales) | | 4. 智能邮件摘要 | | +-------------------+ +-------------------+ v +-------------------+ +-------------------+ | 7. 人机协同反馈 | --> | 8. 自动发信 / 兜底 | | (HITL 校验) | | (在信任建立后) | +-------------------+ +-------------------+ ``` 1. **邮件过滤（Filtering）**：基于预定义规则剔除无用邮件与垃圾信息。 2. **客户验证（Guest Validation）**：校验发件人是现有预订客户还是潜在新客。 3. **PII 隐私数据脱敏（PII Anonymization）**：去除护照号、信用卡等敏感信息。例如，当客户邮件包含护照号时，系统在 CRM 中完成登记，但在生成给客户的回复邮件中会进行脱敏掩码处理。 4. **邮件摘要（Summarization）**：提取核心诉求，大幅降低下游 Agent 输入噪音，显著提升后续处理质量。 5. **分类与动作定义（Categorization & Action）**：将邮件划分为 **Sales**（如新客预订邮轮）与 **Service**（如咨询关联机票信息）两大类，并判定是否需要后续动作（如纯感谢信则直接结案）。 6. **CRM 状态登记**：将识别出的意图与拟定动作自动写回 CRM 数据库。 7. **人机协同校验（Human-in-the-Loop Feedback Loop）**：系统生成拟回复内容后推送到邮轮顾问界面，顾问只需点击“同意”即可自动发送；若系统无法准确分类，则上报失败（Failure）由人工接管。 随着系统预测准确率的不断提升，企业逐步放宽对高置信度邮件的人工审核，最终实现了完全自动化的邮件发送。 --- ### [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) AWS 技术架构演进与显著业务成效 在技术架构实现上，团队早期使用 AWS 构建了调用 LLM 的 Middleware 服务层；随后全面升级为基于 **AWS Bedrock Agents** 与 **Anthropic Claude** 系列模型的 Agentic 架构，并利用 **Amazon EKS** 与 **API Gateway** 进行动态扩展与任务编排，通过编排 Agent（Orchestration Agent）统筹多个专项子 Agent 完成复杂任务，极大提升了系统的扩展性与灵活性。 该 Agentic AI 系统的上线为邮轮公司带来了极其惊人的业务 ROI 与运营指标改善： - **单封邮件处理时间**：从原先的 **30 分钟大幅缩短至 5 分钟**。 - **SLA 违约率极速下降**：未能在 48 小时内得到回复的邮件数量**降低了 80%**。 - **人工干预率锐减**：随着反馈闭环的持续优化，需要人工介入处理的邮件比例**降低了 95%**。 Greveling 在演讲结尾总结了在企业中规模化落地 Agentic AI 的三大“黄金法则”： 1. **大力投资反馈闭环（Feedback Cycle）**：人机协同是提升 Agent 准确率的唯一捷径。 2. **建立全方位的监控与日志体系（Monitoring & Logging）**：及时捕获异常与性能漂移。 3. **保持简单，小步快跑（Keep it Simple, Start Small）**：职责单一的“小 Agent”在实际业务中的表现远比庞大复杂的通用 Agent 更稳定高效。 <ElicitationsGroup message="要进一步了解此案例的具体实现细节，您可以选择以下方向："> <Elicitation label="深入了解 AWS Bedrock Agents 与 Claude 在此架构中的具体编排细节" query="请详细解释在此邮轮案例中，AWS Bedrock Agents 与 Claude 是如何进行多智能体编排和任务分发的？"/> <Elicitation label="探讨如何为传统企业设计 PII 脱敏与数据治理方案" query="在企业落地 Agentic AI 时，如何设计符合 GDPR/欧洲与美国标准的 PII 隐私脱敏和数据治理方案？"/> </ElicitationsGroup> ## Notable quotes > [00:26](https://www.youtube.com/watch?v=siTQxGxPjUo&t=26s) 大家可能觉得自己在某种程度上被技术浪潮抛在了身后（FOMO），但请相信，企业级 AI 的实际落地价值是完全可以被证实的。 — Diederik Greveling > [02:36](https://www.youtube.com/watch?v=siTQxGxPjUo&t=156s) 如果到了今天你还没有听过 Agentic AI，那简直就像是‘一直生活在石头底下’。 — Diederik Greveling > [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) 单封邮件的处理时间从原先的 30 分钟大幅缩短至仅仅 5 分钟。 — Diederik Greveling > [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) 未能在 48 小时内得到回复的邮件数量降低了 80%。 — Diederik Greveling > [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) 需要人工干预处理的邮件比例锐减了 95%。 — Diederik Greveling > [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) 大力投资反馈闭环（Feedback Cycle）：人机协同是提升 Agent 准确率的唯一捷径。 — Diederik Greveling > [17:59](https://www.youtube.com/watch?v=siTQxGxPjUo&t=1079s) 保持简单，小步快跑（Keep it Simple, Start Small）：职责单一的‘小 Agent’在实际业务中的表现远比庞大复杂的通用 Agent 更稳定高效。 — Diederik Greveling ## Mentioned Diederik Greveling, Xebia, Xebia Cloud and Data Solutions, AWS Bedrock Agents, Anthropic Claude 3.7, Anthropic Claude 4, Amazon EKS, Amazon API Gateway, CRM, RAG, MCP (Model Context Protocol) ## Video description Diederik Greveling, CTO, Xebia Cloud and Data Solutions, Xebia Abstracts We’re diving into how Agentic AI is redefining enterprise workflows—through the lens of a real-world travel industry case study powered by AWS Bedrock Agents and Anthropic Claude 3.7/4. Facing 10,000+ daily customer emails, the company tackled SLA breaches, manual fatigue, and lost revenue by deploying an agentic AI system that fused advanced language models with automated categorization, summarization, and CRM workflows. You’ll see how AWS-native services—including Amazon EKS, API Gateway, and Bedrock Agents—enabled dynamic, scalable task orchestration. The outcome? Emails Processed 30 Min -- 5 Min Decrease in manual email intervention 95% Discover how Agentic AI goes far beyond chat—acting as an orchestration layer across business systems while learning in real time from human feedback. We’ll unpack the technical and change management strategies behind successful deployments—and show you how to spot and scale high-value agentic AI use cases in your own organization. Don’t miss this session. The future of enterprise AI is already here. [Source](https://www.youtube.com/watch?v=siTQxGxPjUo)

[0:26] Diederik Greveling: 大家可能觉得自己在某种程度上被技术浪潮抛在了身后（FOMO），但请相信，企业级 AI 的实际落地价值是完全可以被证实的。 [2:36] Diederik Greveling: 如果到了今天你还没有听过 Agentic AI，那简直就像是‘一直生活在石头底下’。 [17:59] Diederik Greveling: 单封邮件的处理时间从原先的 30 分钟大幅缩短至仅仅 5 分钟。 [17:59] Diederik Greveling: 未能在 48 小时内得到回复的邮件数量降低了 80%。 [17:59] Diederik Greveling: 需要人工干预处理的邮件比例锐减了 95%。 [17:59] Diederik Greveling: 大力投资反馈闭环（Feedback Cycle）：人机协同是提升 Agent 准确率的唯一捷径。 [17:59] Diederik Greveling: 保持简单，小步快跑（Keep it Simple, Start Small）：职责单一的‘小 Agent’在实际业务中的表现远比庞大复杂的通用 Agent 更稳定高效。

[0:04] Diederik Greveling: Boardrooms and C-suite executives are either eagerly pursuing AI opportunities or worried about being left behind. [0:04] Diederik Greveling: Putting enterprise deployment numbers into production guarantees real business ROI. [0:26] Diederik Greveling: Initial Generative AI implementations relied on standalone LLMs handling direct prompt-and-response interactions, which offered impressive capabilities but limited real business value. [0:26] Diederik Greveling: The architectural evolution then progressed from RAG to action-oriented systems, and eventually to automated tool integration via protocols like Model Context Protocol (MCP). [0:26] Diederik Greveling: Today's cutting-edge setup is the multi-agent system, where specialized agents collaborate dynamically to resolve complex enterprise tasks. [0:52] Diederik Greveling: Xebia builds generic AI foundations on top of which multi-agent networks are deployed across business units. [8:27] Diederik Greveling: Building an automated customer support solution required addressing fundamental technical and organizational challenges inherent in LLM deployments. [8:27] Diederik Greveling: LLMs and agents produce variable outputs for similar inputs, requiring robust validation and guardrails. [8:27] Diederik Greveling: High-quality agentic responses depend on a clean 'single source of truth' CRM foundation. [8:27] Diederik Greveling: Comprehensive tracing, logging, and monitoring are required to detect operational drift as customer language evolves. [13:09] Diederik Greveling: To process incoming customer communications reliably, Xebia engineered an 8-stage pipeline combining strict rules, privacy filters, LLM summarization, CRM integrations, and human oversight. [17:48] Diederik Greveling: The project initially launched with a centralized middleware engine invoking task-specific LLMs. [17:48] Diederik Greveling: Over time, as team confidence grew, the architecture evolved into a fully flexible AWS-native multi-agent system powered by Amazon Bedrock Agents, Amazon EKS, and API Gateway. [17:48] Diederik Greveling: Keep agent responsibilities small, focused, and simple.

[0:04] Zo, hello en welkom everyone. Eh today [0:07] we talking about how a travel company [0:10] transformed customer service with AI. [0:13] But before we go into that a little bit [0:14] about myself. So my name is DCK [0:16] Geveling. I'm currently the CTO of XCBI [0:18] data and AI Beneluxe. Eh I been working [0:21] in the field of AI and data for the last [0:23] 10 plus years. Started off as a data [0:26] engineer. So I'm actually more technical [0:29] I would say eh management as they call [0:31] it. Eh this this presentation will be a [0:34] little bit more high level but if you [0:36] have technical questions of course raise [0:38] them. [0:39] you know look me up afterwards we can [0:41] have a nice technical discussion as well [0:45] before we are actually going to go into [0:47] the use case the question is so why why [0:50] are we here today right so of course ai [0:52] at least for me it has been booming [0:53] already for the last e to 10 years right [0:56] especially the last few years hè with [0:58] the with the introduction of you know [1:00] gen ai those systems becoming better and [1:02] better we basically seeing a lot more [1:05] opportunities being generated add [1:11] using AI effectively. [1:14] AI nowads can be used to improve your [1:16] process to basically scale it you know [1:19] scale it in a better way right also [1:22] process can become more more efficient [1:25] as well as generally you're able to you [1:27] know improve the quality of whatever [1:30] you're you're doing within your [1:31] organization with the help of AI. [1:34] Of course, we've put in some numbers [1:37] here, right? So, you know, so basically [1:40] having you know, having worked in this [1:42] field for the last ja for the last e [1:45] years what I can tell you as well, few [1:47] numbers on the screen are always nice, [1:49] right? But mainly weve we we've been [1:51] putting a lot of use case into [1:53] production. Eh and from that ja I can [1:56] guarantee you that you will get value [1:59] from from these type of AI systems. But [2:00] nowadays if you look at know what's [2:02] happening in the boardroom essentially [2:05] is that most of the organization out [2:07] there most of seal level of management [2:09] as well are either extremely interested [2:12] within within AI or they are worried [2:15] that and that AI is somehow going to [2:18] catch up to them. Ehm so yeah and today [2:21] we're going to show you a use case. [2:24] where we basically [2:26] we will show you the value of of AI [2:30] which also kind of shows why these [2:32] statistics make sense. [2:36] So what is entic AI right? So if you [2:39] haven't heard about that yet I'm [2:41] assuming you have been living under a [2:43] rock ehm ehm and especially since you're [2:46] on this conference but eh ja we have [2:48] been going to quite some transformations [2:51] already in the last few years. Right? So [2:54] hè when we started out with basically [2:56] genitive AI then and most of the use [2:58] case that you saw were just a specific [3:01] LL specific LM you did a prompt right so [3:04] you ask it a question and then you got [3:06] an answer back and whilst that was quite [3:09] interesting because it showed how [3:10] powerful these systems could be eh there [3:13] wasn't a lot of added you know there [3:16] wasn't a lot of added value there yet [3:18] right so then we start to extend them by [3:20] basically adding adding racks [3:26] LMW [3:30] more informed answers [3:33] based upon these let better answers that [3:37] weve got we actually started actions not [3:40] only could I ask LM something and get a [3:43] good reply back but then I then we [3:46] basically said ok let's now take an [3:47] action upon the answer that I'm getting [3:50] back from LM that is basically eh ja [3:54] that's basically that's basically LM [3:56] plus retrieve plus plus actions and then [3:59] the next step is that we said oké so now [4:02] that I'm able to you know get the [4:04] correct answer out I I able to define an [4:08] action let's let's actually hook it up [4:10] to to a system so that these actions can [4:14] you know be be be made automatically and [4:16] this is what MCP is en tooling [4:18] effectively right so [4:21] zo so basically on aicent right it not [4:24] only you know performs a certain request [4:28] you you also connect it to your tooling [4:30] within within your organization and then [4:32] we get to where we are now right and [4:34] that is multi-agent systems where we [4:35] basically have multiple agents that all [4:38] have a specific purpose which basically [4:40] work to to to together to get a certain [4:43] task done effectively and today we're [4:46] going to focus a little bit on the last [4:48] two. [4:52] SL [4:55] what do to give little bit of context [4:59] basically builds these type of systems [5:02] right so we tend to build relatively [5:05] generic foundations in in this case AI [5:09] foundation on which we deploy multiple [5:12] agents which [5:14] which should solve business use cases [5:16] for you and then and then XB works [5:20] across the line of business to an it [5:23] effectively. So we not only help you [5:24] with shaping the use Swart but we also [5:27] actually implement it for you of course [5:30] take into consideration certain business [5:32] KPIs that that you would want to achieve [5:36] when we basically implement such a use [5:37] case. [5:40] So let's go more into the interesting [5:42] part. So the actual use case right. So [5:45] basically ja so how did a travel company [5:48] transform customer service with with AI? [5:51] So in this case, this was an extra [5:52] client from Mixibia. Ehm they had the [5:56] issue that they got a lot of emails per [5:59] day requesting, you know, their [6:01] services, requesting tickets, eh [6:04] requesting eh changes, etc. etc. and en [6:07] and in this case it was one of the [6:09] largest cruise line operators within [6:12] within the world. So to put this down [6:13] into numbers, we saw that they were [6:16] receiving on on every 10000s per day. [6:19] There was quite some well garbage in in [6:22] there but a lot of those emails were [6:24] also highly specific. It took them you [6:27] know between 24 to 36 hours to respond [6:31] to a single email right? Whenever I [6:35] as as a customer would send an email, [6:37] you know, it would take them at least a [6:39] day to get back to to to my question as [6:44] as well as almost 200 they call it [6:46] cruise consultants working on just [6:49] answering these emails and making sure [6:52] that ja basically you know people got [6:55] the right answer based on their [6:57] requests. So as you can see if you have [7:00] these type of numbers right you know it [7:02] would be nice we can at least automate [7:04] or use automation to improve this well [7:09] to basically bring these numbers down [7:11] right and so what what was actually [7:15] needed so we need to create a system [7:16] which is which is able to you know you [7:19] know basically accurately [7:22] in interpreted emails but also be be [7:24] able to generate an answer on email [7:27] automatically [7:31] errorsing [7:36] automated [7:37] from 200 [7:40] consult focus basically other work in [7:44] instead of answering emails all day was [7:47] another ask where said oké so if you [7:50] look at the general answering email [7:53] process then what most of those consults [7:56] did they answer email then they needed [7:58] to log into a need to log into a CRM [8:01] system and then they needed to also jail [8:07] that they and that they answered right [8:10] and that they also wanted to have [8:11] automated so not only was it about you [8:14] know automatically answering emails but [8:17] also making sure that hè the systems [8:19] where you basically needed to lock [8:20] certain information that that would be [8:23] be done in an automated way. [8:27] What are the key components [8:29] of such solution? One thing we need to [8:32] be able to automatically categorize [8:34] emails right. So basically say whenever [8:37] there was a question with email we would [8:39] say ok this question is about this topic [8:42] and we need to define this action [8:44] effectively. [8:46] Another thing which you needed to do was [8:48] ja be be able to summarize on on email [8:51] correctly right because as you probably [8:53] know I mean emo is a free format right [8:56] people write people have different [8:58] writing styles. Some write very short [9:00] emails and others write very long [9:03] emails. So we need to to to have a [9:06] system that could automatically and that [9:07] could automatically extract the right [9:09] points from the from the email and and [9:12] then we would be able to process the [9:14] email better. hard and of course we need [9:17] to build integration with the with the [9:20] you know with the CRM such that we could [9:22] push data forward and we could ja we [9:24] could basically track the process within [9:26] the within the CRM as well and then of [9:28] course finally we need to have some type [9:31] of feedback look right because and and [9:33] I'm going to go into detail more about [9:35] this but basically when you build these [9:37] type of systems is extremely important [9:40] that you keep tracking about how they [9:42] perform right and generally [9:49] syeming [9:54] emails [9:57] what are the challenges [10:00] with system so first and foremost you [10:03] know lms and also [10:06] agents they are they are non they [10:08] neterministic right meaning that i can [10:12] you know i can input [10:21] order basically handle this need to [10:24] build [10:25] robot system [10:27] that can basically tackle this challenge [10:31] another so another challenge is of [10:34] course data quality and this is what we [10:35] generally tend to forget is that if you [10:38] want to get the most use out ofentic [10:41] system or or out [10:44] do [10:50] that [10:52] what we still see a lot of organizations [10:54] that even having that data foundation [10:57] you know in a state with proper data [10:59] governance that you can point to is [11:01] single source of tooth right for certain [11:04] values that you that you need is [11:06] generally already quite complicated for [11:08] for a lot of companies and in order to [11:12] make these systems stable, right? To get [11:14] most value out of it, you do need to [11:16] have a good data foundation in place. [11:20] Then of course you know since these [11:23] systems are nonetonistic [11:25] you do want to have a good you know you [11:28] do want good stack in place for proper [11:31] monitoring for tracing for logging right [11:34] such that you are always guaranteed [11:36] about the performance of your of your [11:39] system because also performance might [11:40] drift over time because you know die for [11:43] example in the case of emails die die [11:45] die title request might change right So [11:50] it's extremely important that you have a [11:52] good stack in in place that and that's [11:54] able to track this and then of course [11:57] the of course the feedback process right [11:59] so of course implementing from the [12:02] technical side a feedback process is [12:05] relatively well it's you know it's [12:07] doable but also within your organization [12:10] you need to enable this feedback process [12:12] right so it will become a different way [12:14] of working for basically your basically [12:17] your employees whenever you you build [12:19] such system or if it's user facing it's [12:22] generally also extremely valuable to [12:25] have users also be be able to give [12:28] feedback right it can be very easy with [12:30] a f up and down icon or or function but [12:34] it can also be more extensive where [12:37] where your customers can give feedback [12:39] in terms of text for example but the [12:41] same holds for your for your for your [12:43] employee setting up this process is [12:45] generally one of the harder part so we [12:48] always say that we generally never start [12:50] on start onentic use case without [12:53] without our clients and already having [12:56] allocated this process the right [12:58] resources etc etc because chances are [13:02] that you know ehm you know the process [13:05] will fill if if you don't have something [13:07] like this in place [13:09] so what did we actually ended up [13:12] building or what did the what did the [13:14] workflow look like so the first two [13:17] steps that we [13:18] that we had in our system was first [13:20] filtering out emails, right? So we had [13:23] quite a lot of emails which were not [13:25] applicable eh or there was just some [13:28] just some garbage in there. So we [13:29] defined a set of rules that for our LM [13:32] ok filter out these type of systems. And [13:35] the next was guest validation, right? So [13:38] checking if an email actually is is [13:41] basically from a guest or a customer [13:43] that we that we that we already knew, [13:46] right? Or whether it's a new guest or a [13:49] new customer. [13:51] Then next we needed to we we we we [13:53] needed to filter out any PI data right [13:56] so we define a list with our client [13:58] about what is PI data and what is not P [14:01] PPI data. It turns out that differs per [14:04] company and also per region. So in [14:06] Europe we do stuff different than in the [14:08] US. POVs are are fine by the way but the [14:11] point is that you do need to get this on [14:13] on paper. And then basically we removed [14:16] any type of data which could be [14:18] classified as PII. So for example one of [14:22] the use cases that we had where people [14:24] would would send over their passport [14:26] number right and that passport number [14:28] needed to be registered in one of the [14:31] systems. So the reply to the email [14:33] didn't really say we have we have [14:35] registered this password number for you [14:37] and then mention the password number if [14:40] was just we have we have registered this [14:42] passport number right or or we have [14:45] registered die the die the die the die [14:46] the die the password number for you so [14:49] that was the first step that we needed [14:51] to do and the fourth step was basically [14:53] ja being being able to properly [14:56] summarize on on email so as it turned [14:59] out right if if if we were able to [15:01] create a better summar sum summarization [15:04] of of an email then the next step for [15:07] the for the agent became ja became a lot [15:10] easier right so the quality went up [15:13] because ehm ja because there's just [15:15] basically less garbage that we're [15:17] putting into eh into the lm so with this [15:22] that's a emo summarization we were we [15:25] were able to categorize [15:28] every emo water in this case we had [15:30] multiple categories [15:32] the largest ones they were sales and [15:34] service. So sales were actions that [15:36] needed to be taken upon new clients. So [15:38] for example booking cruise tickets where [15:41] service was more request about eh for [15:44] example die you know the you know the [15:46] airplane ticket tied to the tied to the [15:48] cruise ticket and the questions about [15:50] that. So we basically use the LM to to [15:54] categorize these and these type of [15:57] emails. Once we had the categorization [16:00] we could decide ja we we could create an [16:02] action as well right so do so do we even [16:05] need to take an action because some [16:07] emails j ok thank you and you know thank [16:10] you for thank you for helping us out [16:12] right and then the system just cut off I [16:15] don't need to take an action anymore but [16:17] of course for most emails we did need to [16:20] make an action and after we have define [16:23] the action we we would basically also [16:25] register it within the within the CRM [16:29] Then after we also define on action, we [16:32] also needed to register and this action [16:34] and this was the most important part. We [16:36] basically build this system [16:39] where we would register actions and then [16:42] basically tell the cruise the cruise [16:45] consultants we and we were successfully [16:47] able to categorize this and this email. [16:50] This is the this is the answer. Do you [16:52] do you do you agree with it? Once the [16:55] cruise once cruise consult says yes. [16:58] Basically the email would be sent out [17:00] automatically and sometimes the system [17:02] could not categorize it correctly and [17:06] then it would then it would report a [17:08] failure and and in that case ja the [17:10] cruise consult would just dwema [17:14] themselves. [17:15] So what was very nice about this is that [17:18] we were basically ja we we created a [17:21] system where you know we had a good [17:23] feedback cycle we were able to improve [17:26] the performance of the system as as well [17:29] as over time die and the company became [17:31] more sure about eh ja about the [17:35] performance of this system meaning that [17:36] we could we could slowly start removing [17:39] this feedback cycle and then emails [17:41] could be sent out automatically n I'm [17:44] skipping a little bit but this is dit en [17:46] dit is basically what the feedback loop [17:48] look like right h so basically die the [17:50] operator would get a message yes or no [17:53] eh is is it good good message if if no [17:56] it would be able to give extra feedback [17:59] I'm going to skip a little bit die die [18:01] die die AWS architectures but from the [18:03] high level right we we build a [18:05] middleware service that would call LMs [18:09] for [18:10] for the different functions right and [18:12] this was our very first implementation [18:15] worked later on [18:18] creating a system more agas [18:22] we had organization agent [18:25] that would basically use different [18:27] agents to to perform certain tasks and [18:30] these are now working together to to [18:33] basically perform these emo tasks and [18:36] they are far more flexible than the and [18:38] the workflow ag than the the previous [18:41] setup because we can tie into multiple [18:44] systems [18:48] a [18:51] sy we were able to decrease processing [18:53] time 30 minutes to 5 minutes [18:57] we we were able to decrease the amount [19:00] of emails that were not answered with [19:02] within 48 hours by 80% and eh ja we we [19:07] were able to decrease the manual [19:10] feedback that we got du and due to our [19:12] feedback cycle with with almost 95% so [19:16] extremely powerful and what were the [19:18] lessons learned so definitely and [19:21] definitely invest in the feedback cycle [19:23] eh always set up proper monitoring and [19:26] logging and maybe the golden rules keep [19:28] it simple start small en and smaller [19:31] agents tend to perform better anyway my [19:34] name is Geeveling thank you for your [19:36] time and I hope you join the session [19:38] please download our AI maturity white [19:41] paper