Schneider Electric、Vodafone 和 monday.com 如何在欧洲与中东规模化落地 Agent

该地区的代理程序正在走一条不同于受大量关注的面向消费者应用程序的路径。越来越少的团队从一个单一引人注目的聊天机器人开始。更多团队是从一个平台开始的，通常是因为他们已经在各个业务部门零散地有十几个代理概念验证，并且没有一致的方法将它们投入生产。

这是我们在不同产业中看到的一个模式，这些产业的监管压力差异很大。从能源和电信到保险、银行和零售，根本的挑战是一致的。公司发现代理易于原型设计，但操作起来要困难得多。良好的运营需要一个基础设施层，许多团队在构建第一个代理时并未预料到。

本文探讨了三家公司如何构建该基础设施层：

除了这三家公司，我们还将参考该地区更广泛的代理程序中出现的模式，涵盖从保险和安全运营到消费者零售等行业。

中央代理平台正在整合企业内碎片化的代理。目前该地区最常见的模式是，团队投资于一个平台，而不是构建单个代理。我们接触的组织中有35%将公司范围的代理平台或控制层描述为主要用途，业务部门的代理最终将在其上运行。

正在进行十多个或更多代理工作的公司往往得出相同的结论：各个团队都在重建相同的基础设施，需要有人负责共享层。这可能意味着经过验证的、可重复使用的模板或框架：https://www.langchain.com/deep-agents，防止团队重复发明基础内容，或者将分散的开发整合到一个支持全生命周期的中央AI中心。在这一阶段，一家公司拥有上百个概念验证但大多数没有明确的生产路径并不罕见。中央代理平台可以解决这个问题。

许多组织在构建用于受监管文档和后台工作的代理方面获得了投资回报率。我们交流的组织中有18%专注于理赔、承保、发票、招标、采购、工资或其他既有纸质记录又有已知每案成本的工作流程。用于保单条款审查、理赔文件分类、损失记录提取和发票验证的代理程序都已投入生产。在许多情况下，曾经需要数小时的工作现在可以在几分钟内完成。

该地区的风险、合规和安全运营用例正在增长。我们交流的组织中有12%正在构建代理，以减少在承担审计义务的职能中分析师的工作量。例如，包括对低至中等严重性的安全警报进行分类、执行二线保证和反金融犯罪测试，以及使用附带置信度评分的自动标记交易验证。

一旦工程成为瓶颈，联邦式构建便开始实施。16%的组织试图通过中央护栏帮助非工程人员构建代理。常见模式是使低代码和非技术用户能够配置代理，而工程师将有效的代理进行工业化。为实现这一目标，团队正在构建全球平台（利用如 LangSmith Fleet：https://www.langchain.com/langsmith/fleet 等产品，为企业提供无头服务），团队可以在不编写代码的情况下配置、评估和发布代理，同时中央团队执行生产所需的标准。

可观测性、评估和成本控制是规模化的基础。这是我们交流中最常见的主题。可观测性正越来越多地与治理和开支相关联，同时用于调试。团队希望在数十个用例中同时进行追踪、评估、提示管理和标注队列。团队越来越多地将 LLM 网关：https://www.langchain.com/langsmith/llm-gateway 置于路线图中心，以在赋予代理更广泛自主权之前，实现对用户、模型、令牌、开支和策略的统一可视化。

下面的三个团队展示了一家公司在完成首次试点之后，运营代理所需的条件。

施耐德电气是全球领先的能源技术公司，通过电气化、自动化和数字化推动工业、企业和家庭的可持续发展。公司拥有16万名员工，年收入约400亿欧元，公司运行着一个雄心勃勃的人工智能计划：一个由350名专家组成的内部AI中心，他们部署了60多个代理以优化能源消耗、延长资产生命周期并加速开发者生产力。

施耐德的广泛AI计划涵盖三个类别：

代理嵌入在这些目标中，在关键基础设施中运行，需遵守严格的数据驻留要求和网络安全控制。施耐德需要一个通用代理平台，帮助团队快速构建，同时保持对数据、部署和质量的控制。

“精确性的挑战、答案质量的挑战、护栏设置的挑战，都非常真实。当你大规模部署解决方案时，你需要像LangSmith这样的工具。所有与可信度和理解发生的事情相关的工具对我们来说都非常有价值。”——施耐德电气首席人工智能官菲利普·兰巴赫

施耐德的AI平台团队隶属于AI中心，提供共享基础设施，使AI小组能够在其庞大的技术生态系统中（多云，从云端到边缘，涵盖各种AI类型）可靠地交付成果。

他们围绕LangSmith：https://www.langchain.com/langsmith-platform 以及更广泛的LangChain生态系统建立了LLMOps能力，以：

施耐德在AWS EKS上自托管LangSmith，位于其自身安全边界内。其最重要的架构决策之一是为每个AI产品创建一个工作区，跨越从开发到生产的所有环境，而不是为每个环境创建单独的工作区。

这种结构化方式促进了改进循环。生产轨迹可以回流到开发数据集中进行离线评估，而领域专家可以对生产轨迹进行注释并直接推送到数据集中。

内部AI助手Jo服务于覆盖107个国家的16万名员工。每次对话都有追踪记录，生产轨迹被系统地重用于构建回归数据集和检测漂移。

施耐德在评估方面进行了三方面的投资。首先，它建立了离线评估模板，标准化了各团队的数据集规范和评估器接口。

其次，它创建了一个LLMOps成熟度框架，对其60多个产品在仪表化、离线评估、在线评估和反馈循环方面进行评分，然后使用这些评分来控制从探索阶段到工业化阶段的进程。

第三，施耐德将主题专家直接引入评估过程。现在，大约20%的AI产品至少有一个活跃的标注队列，主题专家会审核真实生产示例。其客户成功经理Copilot（由250多位CSM使用）从一开始就有专家参与，团队认为这有助于其在发布时达到高质量和高采纳率。

施耐德没有在一个集中运行环境中运行每个代理，而是标准化采用LangSmith Deployment：https://www.langchain.com/langsmith/deployment参考架构：带有Postgres和Redis的Agent Server，采用“你构建，你运行”的模式。每个AI产品运行在自己的独立堆栈上。这消除了单点故障，避免了一个有缺陷的部署影响公司所有代理。

在其数字能源部门，一个处理报价请求和规格的文档处理代理现在只需要15分钟多一点就能完成以前需要数小时甚至数天的工作。这类长时间运行的后台工作负载受益于基于任务队列的部署模型。

其代价是需要管理更多的基础设施和协调更多的升级，而施耐德已将此识别为持续投资的领域。

施耐德在LLMOps上的早期投资获得了回报。如果没有追踪级可观测性和稳固的离线评估流程，公司任何代理产品都无法达到生产准备状态。跳过早期仪表化的团队在后期调试非确定性回归问题时，由于缺乏良好的数据支持，遇到了困难。

施耐德还学会了在构建自定义功能之前依赖现成功能。构建复杂的内部框架，尤其是用于评估的框架，非常诱人。回过头来看，扩展现有工具而不是构建新工具效果更好，比如在 LangSmith SDK 上构建一个轻量 CLI，将自定义角色映射到现有权限模型，以及基于公共 API 构建的定期报告。

最终，施耐德发现 LangChain 生态系统在集成性和灵活性之间达到了良好的平衡。各工具协同工作良好（开源库、用于可观测性和评估的 LangSmith，以及带有 LangSmith Studio 的 LangSmith 部署），但它们并不互相绑定。OSS 库可以独立使用，LangSmith 也能与第三方框架无缝协作。这使施耐德能够自由组合工具，而不至于陷入困境。

了解更多：施耐德用户故事（博客：https://www.langchain.com/blog/how-schneider-electric-built-their-llmops-foundations-at-enterprise-scale-with-langsmith）

沃达丰：从运行中的管道到受监控的生产系统

沃达丰为超过 3.4 亿客户提供移动、固定、物联网和企业服务，并在欧洲运营数据中心网络。其数据和 AI 团队使用 LangChain 和 LangGraph 构建了两个内部助手，以支持在该基础设施上工作的工程师。这些助手帮助沃达丰的工程团队更高效地运维其基础设施。

性能指标监控（Insight Engine）：该助手通过将自然语言查询转换为 SQL，从数据中心监控系统中检索关键数据来分析性能指标。这为工程师和运维人员提供了动态、数据驱动的洞察，而这些以前只能通过自定义仪表板获得。

如果查询与库存数据相关，代理将把请求指向 NL2SQL 链，将自然语言查询转换为 SQL 查询并将响应发送回代理。然后代理会将请求转发给另一条查询处理链，这条链会查询库存数据库，接收结果，然后将信息传递给 LLM，根据查询响应创建图表。

从 MS-Sharepoint (Enigma) 获取信息：该助手能够高效访问数千份技术文档和资源。工程师可以提出问题以验证特定设计、检索库存详细信息或识别组织内的联系人，从而减少在文档中筛选所花费的时间。

如果查询与文档摘要相关，代理将把请求引导到适当的链条。进而，这将从多向量数据库中获取相关上下文，并向用户呈现有依据的摘要响应。

两个系统都使用 LangGraph 代理在将请求路由到适当的链条之前对用户意图进行分类。

“我们已经使用 LangChain 的组件超过一年了。它对我们从开源实验过渡到生产级 AI 系统是一种关键推动力。” — Antonino Artale，沃达丰云解决方案、编排与智能高级经理

沃达丰现在在这些系统上应用生产级可观察性。每个 Insight Engine 和 Enigma 对话都从头到尾进行跟踪，为团队提供管道中问题出现位置的可见性。

在这些多步骤系统中，错误答案可能来源于最终响应之前的多个环节，无论是意图分类错误、SQL 格式错误，还是从 SharePoint 检索到错误的文档版本。端到端跟踪使得更容易定位问题的根源，而不仅仅是调试最终输出。

随着沃达丰的生成式 AI 足迹扩大，相同的监控纪律可以扩展到更多数据源、越来越复杂的多代理工作流，以及更广泛的 AI 应用。

了解更多：沃达丰用户故事（博客：https://www.langchain.com/blog/customers-vodafone），Fastweb + 沃达丰用户故事（博客：https://www.langchain.com/blog/customers-vodafone-italy）

Sidekick 是 monday.com 的 AI 助手。它的第一个版本是一个通用代理，并配备一个不断增长的工具列表：总结项目、草拟更新、分析文件、更新看板。最初这是有用的，因为它允许团队快速行动并了解用户真正需要什么。

随后 Sidekick 进入真正的生产工作流，新的问题也随之出现。

当类似工具具有重叠描述并争夺模型注意力时，工具选择变得不那么可靠。工具模式会占用本可以用于用户实际请求的上下文。单个提示必须承载研究、写作、数据分析和董事会操作的全面指令。

故障也变得更难诊断。很难分辨不良结果是来自规划、工具选择、工具执行、检索的上下文还是最终响应。测试变成组合问题，因为引入一个新工具可能破坏与其无关的工作流程。

monday.com 围绕有限责任而不是单一大型推理循环重新构建了 Sidekick，使用 LangGraph 和 Deep Agents：https://www.langchain.com/deep-agents，为系统提供更清晰的层次：

沙箱为代理提供了一个工作场所

monday.com 发现工具和沙箱有不同的用途。工具适合有限且可审计的操作，而沙箱更适合需要迭代的工作。

如果用户上传多个 CSV 并要求 Sidekick 将它们与项目数据对账，代理可以将文件放入沙箱，检查文件，编写和运行代码，从错误中恢复，并生成结果，而无需将每个中间步骤推入模型的上下文窗口。主要代理只需要结果和所发生事件的总结。

对于 Sidekick 来说，工具提供受控访问，子代理提供专业推理，沙箱提供执行环境。

monday.com 使用 LangChain 生态系统的不同部分来支持 Sidekick 的不同层次：

当主代理委派给子代理或使用沙箱时，该活动在 LangSmith 跟踪中保持可见。这让团队能够看到失败是来自上下文检索、规划、委派、工具执行、沙箱执行还是最终响应。

对于 monday.com 来说，LangChain 的框架提供可复用的原语，同时让团队控制自己的模型、检索层、权限系统、工具和用户体验。这让工程师能将更多时间花在 monday.com 特定的内容上，而不是重建通用代理基础设施。

monday.com 了解到，增加更多工具并不一定能提高代理的能力。随着 Sidekick 的工具集不断扩展，类似的工具开始竞争模型的注意力，工具的模式占用了更多上下文，测试也变得更加困难。团队发现，为代理设定更清晰的能力边界比继续扩展单一的通用系统效果更好。

monday.com 还发现，不同类型的工作需要不同的执行环境。工具适用于有界、可审计的操作，而沙箱更适合需要在文件、代码和中间状态间进行迭代的任务。将这些职责分开，并将专业推理委派给子代理，使 Sidekick 更容易管理和评估。

团队还学会将可观测性和评估集成到架构本身中。一次成功的工具调用并不意味着用户的目标就已经实现，因此 monday.com 需要对整个执行路径有可视性，从上下文检索和计划，到委派、工具使用、沙箱执行以及最终响应。

最后，monday.com 发现，更复杂的架构并不意味着必须创造更复杂的用户体验。回顾来看，团队本可以更早地分拆成专业子代理，而不是等原本的通用代理积累了那么多职责。但即便在后台有专业代理、工具和沙箱在运行，Sidekick 仍然可以感受到像一个单一助手的体验。

了解更多信息：monday.com 用户故事，作者 Omri Bruchim（博客：https://www.langchain.com/blog/building-monday-com-sidekick-why-capable-agents-need-more-than-just-tools）

该地区代理构建者最关注的是什么

Agent programs in the region are taking a different path from the consumer-facing applications that get a lot of attention. Fewer teams are starting with a single flashy chatbot. More are starting with a platform, often because they already have a dozen agent proofs of concept scattered across business units, and no consistent way to bring them into production.

This is a pattern we’re seeing appear across industries with very different levels of regulatory pressure. From energy and telecom to insurance, banking, and retail, the underlying challenge is consistent. Companies are finding agents easy to prototype and much harder to operate. Operating well requires an infrastructure layer that many teams did not anticipate when they built their first agent.

This piece looks at how three companies built that infrastructure layer:

Alongside these three, we’ll draw on patterns emerging across a broader set of agent programs we’re seeing in the region, spanning industries from insurance and security operations to consumer retail.

Central agent platforms are consolidating fragmented agents across the enterprise. The most common pattern in the region right now is that teams are investing in a platform, rather than building single agents. 35% of organizations we speak to describe a company-wide agent platform or control plane as the primary use case, with business-unit agents eventually running on top of it.

Companies with a dozen or more agent efforts underway tend to reach the same conclusion: individual teams are rebuilding the same foundations, and someone needs to own the shared layer. That can mean vetted, reusable templates or frameworks：https://www.langchain.com/deep-agents that keep teams from reinventing the basics, or consolidating decentralized development into a central AI hub that supports the full lifecycle. At this stage, it is not unusual for a company to have hundreds of proofs of concept but no clear path to production for most of them. A central agent platform can solve this problem.

Many organizations are finding ROI from building agents for regulated document and back-office work. 18% of organizations we speak to are focusing on claims, underwriting, invoices, tenders, procurement, payroll, or other workflows with both an existing paper trail and a known cost per case. Agents for policy-wording review, claims-document classification, loss-run extraction, and invoice validation are all in production. In many cases, work that once took hours can now be completed in minutes.

Risk, compliance, and security operations use cases are rising in the region. 12% of organizations we speak to are building agents for reducing analyst workload in functions that carry audit obligations. Examples include triaging low- and medium-severity security alerts, running second-line assurance and anti-financial-crime testing, and automating flagged-transaction verification with an attached confidence score.

Federated building begins once engineering starts to become a bottleneck. 16% of organizations are trying to help non-engineers build agents with central guardrails. The common pattern is enabling low-code and non-technical users to configure agents, while engineers industrialize the ones that work. To accomplish this, teams are building global platforms (leveraging products such as LangSmith Fleet：https://www.langchain.com/langsmith/fleet, offered headless for enterprises) where teams can configure, evaluate, and publish agents without writing code, while central teams enforce the standards required for production.

Observability, evals, and cost control are the foundation for scale. This is the most common theme across our conversations. Observability is increasingly tied to governance and spend, alongside debugging. Teams want tracing, evals, prompt management, and annotation queues across dozens of use cases at once. Increasingly, teams are also putting an LLM gateway：https://www.langchain.com/langsmith/llm-gateway at the center of the roadmap to create unified visibility across users, models, tokens, spend, and policy before agents are given broader autonomy.

The three teams below show what it takes to operate agents once a company has moved beyond its first pilot.

Schneider Electric is a global energy technology leader, driving sustainability by electrifying, automating, and digitalizing industries, businesses, and homes. With 160,000 employees and roughly 40 billion euros in annual revenue, the company runs an ambitious AI program: an internal AI Hub of 350 experts who have deployed 60+ agents to optimize energy consumption, extend asset lifecycles, and accelerate developer productivity.

Schneider's broad AI program spans three categories:

Agents are embedded across these objectives, operating in critical infrastructure with strict data residency requirements and cybersecurity controls. Schneider needed a common agent platform that could help teams build quickly while preserving control over data, deployment, and quality.

“The challenge of accuracy, the challenge of quality of answers, the challenge of guardrailing, are very real. When you deploy a solution at scale, you need tooling like LangSmith. Everything linked with trustability and understanding what happens is extremely valuable for us.” — Philippe Rambach, CAIO at Schneider Electric

Schneider’s AI Platform team sits within their AI Hub and provides the shared infrastructure that enables AI squads to reliably deliver across their vast technology landscape (multi-cloud, from cloud to the edge, and all types of AI).

They’ve built LLMOps capabilities around LangSmith：https://www.langchain.com/langsmith-platform and the broader LangChain ecosystem to:

Schneider self-hosts LangSmith on AWS EKS behind its own security perimeter. One of its most important structural decisions was to create one workspace per AI product spanning every environment, from development through production, rather than creating separate workspaces for each environment.

Structuring this way facilitates the improvement loop. Production traces can flow back into development datasets for offline evaluation, while subject-matter experts can annotate a production trace and push it directly into a dataset.

One Jo , Schneider’s internal AI assistant, serves 160,000 employees across 107 countries. Every conversation is traced, and production traces are systematically reused to build regression datasets and detect drift.

Schneider has invested in evaluation on three fronts. First, it built offline evaluation templates , standardizing dataset conventions and evaluator interfaces across squads.

Second, it created an LLMOps maturity framework that scores each of its 60+ products on instrumentation, offline evals, online evals, and feedback loops, then uses those scores to gate progression from exploration to industrialization.

Third, Schneider has brought subject-matter experts directly into the evaluation process. About 20% of its AI products now have at least one active annotation queue where SMEs review real production examples. Its Customer Success Manager Copilot, used by more than 250 CSMs, was built with SMEs involved from the beginning, which the team credits with helping it reach high quality and adoption at launch.

Rather than running every agent on one centralized runtime, Schneider standardizes on the LangSmith Deployment：https://www.langchain.com/langsmith/deployment reference architecture: Agent Server with Postgres and Redis, under a “you build it, you run it” model. Each AI product runs on its own dedicated stack. This removes single points of failure where a faulty deployment could impact every agent in the company.

In its Digital Energy division, a document-processing agent that analyzes quote requests and specifications now completes work in just over 15 minutes that previously took hours or days. This type of long-running background workload benefits from a task-queue-based deployment model.

The tradeoff is more infrastructure to manage and more upgrades to coordinate, which Schneider has identified as an area for continued investment.

Schneider's early investment in LLMOps paid off. Without trace-level observability and a solid offline evaluation process, none of the company's agentic products would have reached production readiness. Teams that skipped early instrumentation were the ones who later struggled to debug non-deterministic regressions without good data to work from.

Schneider also learned to rely on out-of-the-box features before building custom ones. Building elaborate internal frameworks, especially for evaluation, was tempting. In hindsight, it worked better to extend existing tools instead of building new ones, like a thin CLI on top of the LangSmith SDK, a custom role mapped to an existing permission model, and scheduled reports built off the public API.

Finally, Schneider found that the LangChain ecosystem strikes a good balance between integration and flexibility. The tools work well together (open-source libraries, LangSmith for observability and evaluation, and LangSmith Deployment with LangSmith Studio), but they aren't locked to each other. The OSS libraries can be used on their own, and LangSmith works cleanly with third-party frameworks too. This has given Schneider room to mix and match tools without putting themselves into a corner.

Learn more: Schneider User Story ( Blog ：https://www.langchain.com/blog/how-schneider-electric-built-their-llmops-foundations-at-enterprise-scale-with-langsmith )

Vodafone: from working pipelines to monitored production systems

Vodafone serves more than 340 million customers across mobile, fixed, IoT, and enterprise services, and operates a network of data centers across Europe. Its data and AI teams built two internal assistants using LangChain and LangGraph to support engineers working across that infrastructure. These assistants help Vodafone’s engineering teams operate its infrastructure more efficiently.

Performance metrics monitoring (Insight Engine): This assistant analyzes performance metrics by converting natural language queries into SQL to retrieve key data from data centers monitoring systems. This supports engineers and operations staff with dynamic, data-driven insights that were previously accessible only through custom dashboards.

If the query is related to inventory data, then the agent will direct the request to a NL2SQL chain that will convert the NL query to a SQL query and send the response back to the agent. The agent will then forward the request to another query processing chain that will query the inventory DB, receive the result, and then pass the information to a LLM to create graphs and charts based on the query response.

Information retrieval from MS-Sharepoint (Enigma): This assistant enables efficient access to thousands of technical documents and resources. Engineers can ask questions to verify specific designs, retrieve inventory details, or identify contacts within the organization, reducing time spent sifting through documentation.

If the query is related to document summarization, the agent will direct the request to the appropriate chain. In turn, this will fetch the relevant context from the multi-vector DB and present the grounded summary response to the user.

Both systems use a LangGraph agent to classify user intent before routing the request to the appropriate chain.

“We’ve been using LangChain’s components for over a year now. It’s been a critical enabler for our transition from open-source experimentation to production-grade AI systems.” — Antonino Artale, senior manager of Cloud Solutions, Orchestration and Intelligence, Vodafone

Vodafone now applies production-grade observability across these systems. Every Insight Engine and Enigma conversation is traced end to end, giving the team visibility into where issues arise across the pipeline.

In these multi-step systems, a poor answer can originate several hops before the final response, whether from misclassified intent, malformed SQL, or the wrong document version being retrieved from SharePoint. End-to-end tracing makes it easier to pinpoint the source of the problem rather than debug only the final output.

As Vodafone’s GenAI footprint grows, the same monitoring discipline can extend across more data sources, increasingly sophisticated multi-agent workflows, and a broader range of AI applications.

Learn more: Vodafone User Story ( Blog ：https://www.langchain.com/blog/customers-vodafone ), Fastweb + Vodafone User Story ( Blog ：https://www.langchain.com/blog/customers-vodafone-italy )

Sidekick is monday.com’s AI assistant. Its first version was a single general-purpose agent with a growing list of tools: summarize a project, draft an update, analyze a file, update a board. That was useful at the beginning because it allowed the team to move quickly and learn what users actually wanted.

Then Sidekick moved into real production workflows, and new problems emerged.

Tool selection became less reliable as similar tools with overlapping descriptions competed for the model’s attention. Tool schemas consumed context that could otherwise have been used for the user’s actual request. A single prompt had to carry comprehensive instructions for research, writing, data analysis, and board operations.

Failures also became harder to diagnose. It was difficult to tell whether a bad outcome came from planning, tool selection, tool execution, retrieved context, or the final response. Testing became combinatorial as introducing one new tool could break workflows that had nothing to do with it.

monday.com rebuilt Sidekick around bounded responsibilities instead of a single large reasoning loop, using LangGraph and Deep Agents：https://www.langchain.com/deep-agents to give the system clearer layers:

Sandboxes provide the agent with a place to work

monday.com found that tools and sandboxes serve different purposes. Tools are a good fit for bounded, auditable actions, while sandboxes are better for work that requires iteration.

If a user uploads several CSVs and asks Sidekick to reconcile them with project data, the agent can place the files in a sandbox, inspect them, write and run code, recover from errors, and generate an artifact without pushing every intermediate step through the model’s context window. The main agent only requires the result, and a summary of what happened.

For Sidekick, tools provide controlled access, subagents provide specialized reasoning, and sandboxes provide an execution environment.

monday.com uses different parts of the LangChain ecosystem for different layers of Sidekick:

When the main agent delegates to a subagent or uses a sandbox, the activity stays visible in the LangSmith traces. This lets the team see whether a failure came from context retrieval, planning, delegation, tool execution, sandbox execution, or the final response.

For monday.com, LangChain’s frameworks provide reusable primitives, while leaving the team in control of its own models, retrieval layer, permission system, tools, and user experience. This lets engineers spend more time on what is specific to monday.com, rather than rebuilding generic agent infrastructure.

monday.com learned that adding more tools does not necessarily make an agent more capable. As Sidekick’s toolset grew, similar tools began competing for the model’s attention, tool schemas consumed more context, and testing became harder. The team found that giving the agent clearer capability boundaries worked better than continuing to expand a single general-purpose system.

monday.com also found that different kinds of work need different execution environments. Tools work well for bounded, auditable actions, while sandboxes are better suited to tasks that require iteration across files, code, and intermediate state. Separating those responsibilities, along with delegating specialized reasoning to subagents, made Sidekick easier to manage and evaluate.

The team also learned to build observability and evaluation into the architecture itself. A successful tool call does not necessarily mean the user’s goal was achieved, so monday.com needed visibility across the full execution path, from context retrieval and planning through delegation, tool use, sandbox execution, and the final response.

Finally, monday.com found that a more sophisticated architecture does not have to create a more complicated user experience. Looking back, the team would have split into specialized subagents earlier, before the original general-purpose agent accumulated so many responsibilities. But Sidekick can still feel like a single assistant even when specialized agents, tools, and sandboxes are working behind the scenes.

Learn more: monday.com User Story by Omri Bruchim ( Blog ：https://www.langchain.com/blog/building-monday-com-sidekick-why-capable-agents-need-more-than-just-tools )

What’s top of mind for agent builders in the region