AI Teammates: how monday.com runs production AI agents on Amazon BedrockAI 队友：monday.com 如何在 Amazon Bedrock 上运行生产级 AI 智能体

AI Teammates are agentic AI on Amazon Bedrock, and few engineering organizations run them in production at the scale that monday.com does. Nine in ten Builders use AI coding tools every month, up from roughly half a year ago. Per-engineer PR throughput is up by more than half. Every figure in this post comes from monday’s own internal production data.“AI 队友”是运行在 Amazon Bedrock 上的智能体 AI。很少有工程团队能像 monday.com 这样大规模地将其应用于生产环境。如今，十分之九的开发者每月都会使用 AI 编码工具，这一比例较半年前大幅提升。每位工程师的 PR（拉取请求）处理吞吐量提高了超过 50%。本文中的所有数据均来自 monday 内部的生产环境。

In this post, we share the architecture behind those numbers, the retrofits that made it work in a decade-old code base, and the confidence-scored merge play closing the gap to full autonomy.在本文中，我们将分享支撑这些数据的架构、如何对拥有十年历史的代码库进行改造，以及如何通过基于置信度评分的合并机制来缩小通往完全自主化的差距。

This is not a greenfield这并非从零开始的绿地项目

monday.com is a decade-old code base, millions of paying users, hundreds of microfrontends and microservices, hundreds of Builders (Engineers, PMs, Analysts, and Product designers). Every PR an agent opens goes into a system millions of users expect to keep working through the next deploy. Greenfield demos are straightforward. Running agents inside an enterprise SaaS with real on-call, customers, and compliance is the work.monday.com 拥有一个十年历史的代码库、数百万付费用户、数百个微前端和微服务，以及数百名开发者（工程师、产品经理、分析师和产品设计师）。智能体提交的每一个 PR 都会进入一个系统，而数百万用户都期望该系统在下一次部署后依然能稳定运行。演示“绿地”项目很简单，但在拥有真实值班人员、客户和合规性要求的企业级 SaaS 中运行智能体，这才是真正的挑战。

Three levels of AI engineeringAI 工程的三个层级

You can frame the journey as three levels:你可以将这一历程划分为三个层级：

• L1, the assistant. Engineers use AI as a pair programmer. Cursor for the fast reflexive work, Claude Code for the heavy lifts. Adoption has nearly doubled year over year.L1 级：助手。工程师将 AI 作为结对编程伙伴。使用 Cursor 进行快速、反射式的工作，使用 Claude Code 处理繁重任务。其采用率同比几乎翻了一番。
• L2, skills and sub-agents. Teams build reusable agents for repeated work, engineers in the driver’s seat. This is where most of monday runs today, and where per-developer PR throughput stepped up by more than half.L2 级：技能与子智能体。团队针对重复性工作构建可复用的智能体，工程师处于主导地位。这是目前 monday 大部分工作的运行方式，也是每位开发者的 PR 吞吐量提升超过 50% 的原因。
• L3, multi-agent. Fully agentic. Agents own delivery end-to-end while engineers orchestrate, taking tasks from boards, talking in Slack and monday, shipping code alongside humans.L3 级：多智能体。完全自主的智能体。智能体端到端地负责交付，工程师负责协调。它们从看板获取任务，在 Slack 和 monday 中进行沟通，并与人类协作交付代码。

Agents are teammates, not jobs智能体是队友，而不是任务

Sphera is monday’s internal agent system. The first thing you see isn’t a job queue, it’s a Teams page: a mix of humans and agents, each with a profile, a manager, a scope, and a performance score. Atlas, the agent at the center of this post, is one of them: role: Software Engineer. Job: pick up tickets, write the PR, ship the feature. IDE: none. Same backlog as everyone else.Sphera 是 monday 的内部智能体系统。你首先看到的不是任务队列，而是一个“团队”页面：人类与智能体混合在一起，每个成员都有个人资料、主管、工作范围和绩效评分。本文核心提到的智能体 Atlas 就是其中之一：角色为软件工程师。工作内容：领取工单、编写 PR、发布功能。IDE：无。它与其他人共享同一个任务积压列表。

This isn’t decoration, it’s the schema. Every agent has a stable identity that flows through Slack, GitHub, and monday, so a human tags, assigns, code-reviews, or deactivates them like any other teammate. The agents that move the needle live on real teams, doing real work, accountable for the result.这不仅是装饰，更是系统的架构核心。每个智能体都有一个贯穿 Slack、GitHub 和 monday 的稳定身份，因此人类可以像对待其他队友一样对其进行标记、分配任务、代码审查或停用。那些真正推动业务发展的智能体活跃在真实的团队中，承担实际工作并对结果负责。

The architecture架构设计

Here is how the system fits together, from the inboxes an agent listens on to the AWS services that carry each event.以下是整个系统的运作方式，从智能体监听的收件箱到承载每个事件的 AWS 服务。

Three inboxes, one agent三个收件箱，一个智能体

A monday-built agent has three first-class inboxes: a Slack @mention, a monday item assignment, a GitHub PR review request. All three hit the same agent session, with the same memory and workspace on disk: three flavors of the same event, same queue, same path. We don’t run three agent systems. We run one.monday 构建的智能体拥有三个核心收件箱：Slack @提及、monday 项目分配、GitHub PR 审查请求。这三个入口都指向同一个智能体对话，共享相同的内存和磁盘工作区：即同一事件的三种表现形式，共享同一个队列和路径。我们不运行三个智能体系统，我们只运行一个。

The architecture in one diagram架构图

The seven AWS services that we used are Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Relational Database Service (Amazon RDS), Amazon ElastiCache, Amazon Elastic File System (Amazon EFS), and Amazon Simple Storage Service (Amazon S3). Alongside them, AWS Secrets Manager handles per-session secret management. Amazon Bedrock handles model calls, and monday-agent-sdk runs inside each agent runner pod.我们使用了七项 AWS 服务：Amazon Simple Notification Service (Amazon SNS)、Amazon Simple Queue Service (Amazon SQS)、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Relational Database Service (Amazon RDS)、Amazon ElastiCache、Amazon Elastic File System (Amazon EFS) 和 Amazon Simple Storage Service (Amazon S3)。此外，AWS Secrets Manager 负责处理各会话的密钥管理。Amazon Bedrock 处理模型调用，而 monday-agent-sdk 在每个智能体运行器 Pod 中运行。

Event path: From SNS to SQS to monday Builders CoWORK事件路径：从 SNS 到 SQS 再到 monday Builders CoWORK

Every external trigger lands in SNS, which fans out to per-team SQS queues by topic and routing key. The monday Builders CoWORK, a set of SQS consumers on EKS, pulls each message, resolves which agent owns it, and hands it to the right agent runner pod.每个外部触发器都会进入 SNS，SNS 根据主题和路由键将其分发到各团队的 SQS 队列。monday Builders CoWORK（一组运行在 EKS 上的 SQS 消费者）会拉取每条消息，确定归属智能体，并将其交给对应的智能体运行器 Pod。

Pub/sub plus queue gives us four things we won’t give up: retries and dead-letter queues out of the box, back-pressure when Amazon Bedrock throttles, durable replay (we re-run the last day of events against a patched build before promoting), and concurrent fan-out. If the Claude Agent SDK ships something better at the runtime layer, we delete our version. The harness stays.发布/订阅模式加上队列机制为我们提供了四项不可或缺的功能：开箱即用的重试和死信队列、Amazon Bedrock 限流时的背压处理、持久化重放（在推广补丁构建版之前，我们会针对补丁重新运行过去一天的事件），以及并发分发。如果 Claude Agent SDK 在运行时层发布了更好的方案，我们只需删除自己的版本，而底层的架构 harness 依然稳固。

monday-agent-sdk: A thin wrapper, on purposemonday-agent-sdk：刻意设计的轻量级封装

The Claude Agent SDK is the runtime. We wrap it for three reasons:Claude Agent SDK 是我们的运行时环境，我们对其进行封装主要出于三个原因：

• Provider neutrality at the call site. Agent LLM calls route into an Amazon Bedrock model endpoint.调用端的提供商中立性。智能体的 LLM 调用会路由到 Amazon Bedrock 模型端点。
• Cold-start cost. Agent runners ship with a warm node_modules and plugin caches, so the first model call goes out in usually under a second.冷启动成本。智能体运行器在发布时预置了 node_modules 和插件缓存，因此首次模型调用通常在不到一秒内完成。
• We wanted our own harness. The runtime is becoming a commodity. The harness is where our opinions live: how an agent is evaluated, how plugins compose, how it talks to Slack, monday, and GitHub, how its output is reviewed against monday standards. We keep the runtime someone else’s problem and make the harness ours.我们需要自己的控制框架（harness）。运行时正在变得商品化，而控制框架则是我们体现自身理念的地方：如何评估智能体、插件如何组合、如何与 Slack、monday 和 GitHub 对话，以及如何根据 monday 的标准审查输出。我们将运行时交给别人解决，而将控制框架掌握在自己手中。

State, memory, sessions状态、内存与会话

Agents have at least three kinds of state. Putting all three in one store costs you money, latency, or correctness. The live state move to Amazon ElastiCache. Current task, run cursor, distributed lock, heartbeat, and the agent/human message log. Sub-millisecond reads, self-expiring keys. Amazon DynamoDB would work; ElastiCache is cheaper and faster for this shape of access. Sessions and memory get stored in Amazon Elastic File System. Each active session is a directory on a shared filesystem:智能体至少有三种状态。将它们全部放入同一个存储中会带来金钱、延迟或准确性方面的代价。我们将活跃状态移至 Amazon ElastiCache，包括当前任务、游标运行、分布式锁、心跳以及智能体/人类的消息日志。它支持亚毫秒级读取和自动过期键。Amazon DynamoDB 虽然可行，但对于这种访问模式，ElastiCache 更便宜且更快。会话和内存存储在 Amazon Elastic File System 中。每个活跃会话都是共享文件系统上的一个目录：

/sessions/<session-id>/
├── repos/          # checked-out workspace
├── secrets.json    # encrypted per-session secrets
└── messages/       # chronological event log

/agents/<agent-id>/
├── MEMORY.md            # cross-session memory
└── diary/2026-04-21.md  # per-day journal

Two reasons, not S3. First, the Claude Agent SDK and most plugins expect a real POSIX filesystem (git, npm, file edits), which removes a whole class of “works in dev, breaks in worker” bugs. Second, when a run resumes on a different EKS pod, that pod mounts the same EFS path and picks up where it left off.选择 EFS 而非 S3 有两个原因。首先，Claude Agent SDK 和大多数插件期望一个真实的 POSIX 文件系统（git、npm、文件编辑），这消除了整类“在开发环境正常，在工作节点报错”的 bug。其次，当一个运行任务在不同的 EKS Pod 上恢复时，该 Pod 会挂载相同的 EFS 路径并从中断处继续。

Atlas’s daily diary is a real file. A redacted snippet:Atlas 的每日日记是一个真实文件。以下是删减后的片段：

# diary/2026-04-21.md
## In progress
- ENG-3491: rate-limit headers: verify staging, then open PR
- ENG-3502: dependency bump: blocked on Guardrails security-boundary
  rule, waiting on standard-owner review
## What I learned last session
- The accounts-api team files every new error code in the shared
  registry BEFORE the PR opens. I did it in the same PR last time
  and got reverted. Filed the registry update first this time.

That file is how Atlas resumes work the next morning. He reads it, recalls that the accounts-api team wants the errors-registry update filed separately, and gets to work. Memory is a file on a disk that more than one pod can mount.该文件是 Atlas 第二天早上恢复工作的方式。它读取文件，回忆起 accounts-api 团队希望将 errors-registry 的更新单独提交，然后开始工作。内存就是磁盘上的一个文件，可以被多个 Pod 同时挂载。

Durable records go to S3. Final transcripts, snapshots, artifacts, and evals are keyed by session ID. EFS holds working memory; S3 is the audit trail.持久化记录存入 S3。最终的记录、快照、制品和评估结果都以会话 ID 为键。EFS 保存工作内存，S3 则作为审计追踪。

Amazon Bedrock as the model fabric以 Amazon Bedrock 作为模型底座

Amazon Bedrock is more than a place to get tokens. It’s the service that lets us run hundreds of agents without losing track of cost, safety, or capacity. Most operational requirements for deploying agents at scale are already features in Amazon Bedrock:Amazon Bedrock 不仅仅是一个获取 Token 的地方，它还是让我们能够运行数百个智能体而无需担心成本、安全或容量问题的服务。部署大规模智能体的大多数运营需求在 Amazon Bedrock 中都已经作为功能存在了：

• Application Inference Profiles route every model call, so cost tracking and capacity planning stay in one place.应用程序推理配置文件（Application Inference Profiles）路由每一次模型调用，从而将成本跟踪和容量规划集中在一处。
• One audit trail for every model call: when security or a regulator asks what agents sent where in a window, we have one place to answer.针对每一次模型调用的统一审计追踪：当安全部门或监管机构询问智能体在某段时间内发送了什么时，我们有一个统一的查询入口。
• Cross-Region failover when an AWS Region throttles. Agent code doesn’t notice.当某个 AWS 区域发生限流时，支持跨区域故障转移。智能体代码对此无感。
• AWS PrivateLink endpoints keep model traffic inside our virtual private cloud (VPC).AWS PrivateLink 端点将模型流量保持在我们的虚拟私有云 (VPC) 内部。

Running on EKS运行在 EKS 上

The compute fleet is Amazon EKS, one pod per active agent session, mounting the agent’s EFS workspace. Crash isolation is per-session. Auto scaling is driven by KEDA on average active sessions across pods, measured using Datadog. We run a single worker image. Repos are cached on EFS and reused across sessions. No service mesh, no orchestrator-of-orchestrators. EKS, SQS, and the cache layer carry the load.计算集群是 Amazon EKS，每个活跃的智能体会话对应一个 Pod，并挂载该智能体的 EFS 工作区。崩溃隔离是按会话进行的。自动扩缩容由 KEDA 根据 Pod 的平均活跃会话数驱动，并使用 Datadog 进行衡量。我们运行单一的工作节点镜像。代码仓库缓存在 EFS 上并在会话间复用。没有服务网格，没有复杂的协调器。EKS、SQS 和缓存层承担了所有负载。

Five retrofits that made it all work实现这一切的五项改造

Architecture is the floor. The following five retrofits are what made agents useful inside a decade-old code base. None are exotic. All were unobvious until we hit them:架构是基础，以下五项改造是让智能体在十年历史的代码库中真正发挥作用的关键。它们并不复杂，但在我们遇到问题之前，这些方案并不显而易见：

Evals before model upgrades模型升级前的评估

“Looks fine” was the bar for Atlas’s early PRs. It broke once volume picked up. We added two eval layers: deterministic metrics (PRs merged, revert rate, zero-touch merge rate) per agent, and LLM-scored evals across five dimensions per PR: Intent & Decision, Execution & Artifact, Completeness & Usefulness, Instruction & Boundary, Efficiency. Both feed back into the harness. Across successive versions of Atlas we changed no model, no prompts, no human nudges, only the evals, and scores moved across every dimension.“看起来不错”曾是 Atlas 早期 PR 的标准，但随着工作量增加，这一标准失效了。我们增加了两个评估层：每个智能体的确定性指标（PR 合并数、回滚率、零人工干预合并率），以及每个 PR 在五个维度上的 LLM 评分评估：意图与决策、执行与交付、完整性与有用性、指令与边界、效率。两者都反馈给控制框架。在 Atlas 的后续版本中，我们没有更改模型、提示词或人工干预，仅通过改进评估标准，评分在各个维度上都有所提升。

Memory is a file, not a vector store内存是文件，而不是向量数据库

Session 1: Atlas built a feature. Session 2: he had no idea Session 1 had happened. We tried context-window stuffing and vector retrieval over past transcripts. Both worked badly. What worked: a per-agent MEMORY.md and a diary/YYYY-MM-DD.md written at session end, read at session start. Plain markdown, no embeddings, no recall scoring, no agentic-RAG ceremony.会话 1：Atlas 构建了一个功能。会话 2：它完全不知道会话 1 发生过什么。我们尝试过填充上下文窗口和对历史记录进行向量检索，效果都很差。真正有效的是：每个智能体拥有一个 MEMORY.md 文件，并在会话结束时写入 diary/YYYY-MM-DD.md，在会话开始时读取。纯 Markdown，没有嵌入，没有召回评分，没有复杂的智能体 RAG 流程。

Remote sandbox before human review人工审查前的远程沙箱

Atlas’s first dozen PRs passed local tests and broke in CI. A monday-scale code base has dependencies that only exist in real environments: feature flags, third-party services, real traffic. We gave Atlas a remote sandbox per session, and every PR auto-deploys to it. Tests, checks, and replayed production traffic run before he asks for human review: failure to fix to ship again, no human in the loop.Atlas 的前十几份 PR 通过了本地测试，但在 CI 中失败了。monday 规模的代码库拥有仅存在于真实环境中的依赖项：功能标志、第三方服务、真实流量。我们为每个会话提供了一个远程沙箱，每个 PR 都会自动部署到其中。在请求人工审查之前，测试、检查和重放的生产流量都会运行：如果修复失败，则无法发布，无需人工介入。

PR Guardrails: Automated review against monday standardsPR 防护栏：针对 monday 标准的自动化审查

Atlas was shipping more, and human review became the bottleneck. We turned every monday engineering standard into an automated reviewer: metrics tagging, feature-flag hygiene, Datadog usage, security boundaries, database and microservice conventions, test quality, documentation. A subset are blocking. Each is wired to internal knowledge through monday’s MCP servers, so the reviewer sees the same context the standard-owner team would.Atlas 交付的越来越多，人工审查成了瓶颈。我们将每一项 monday 工程标准都转化为了自动审查器：指标标记、功能标志规范、Datadog 使用、安全边界、数据库和微服务约定、测试质量、文档。其中一部分是阻塞性的。每一项都通过 monday 的 MCP 服务器连接到内部知识库，因此审查器可以看到标准所有者团队所能看到的相同上下文。

Every PR, agent- and human-authored alike, goes through Guardrails. At scale that means tens of thousands of PRs evaluated per month and hundreds of thousands of standard checks executed. Roughly one in five PRs fails at least one standard and gets bounced back, and human overrides run in the low single digits. The system manages the enforcement, not the human reviewer.无论是智能体还是人类编写的每一个 PR，都要经过防护栏的审查。这意味着每月有数万个 PR 被评估，数十万次标准检查被执行。大约五分之一的 PR 会因为至少一项标准不合格而被驳回，人工干预的比例极低。系统负责强制执行，而不是人工审查者。

Builders CoWORK: monday boards as the shared state layerBuilders CoWORK：作为共享状态层的 monday 看板

The last failure mode was the most expensive: agents in silos opened PRs no team owned. We added the CoWORK workspace, the user-facing surface of the same monday Builders CoWORK that routes events. An agent’s tasks, status, blockers, and handoffs now live on the same monday board as the team’s, so accountability stopped being a system problem: monday already solved it for humans.最后一个失效模式代价最高：智能体在孤岛中打开了无人认领的 PR。我们添加了 CoWORK 工作区，这是路由事件的 monday Builders CoWORK 的用户交互界面。智能体的任务、状态、阻塞项和交接工作现在都与团队在同一个 monday 看板上，因此问责制不再是一个系统问题：monday 已经为人类解决了这个问题。

Agents at work in a collaborative space协作空间中的智能体工作

Agents are co-workers you can ask to share information or perform tasks, like any teammate智能体是可以像其他队友一样要求共享信息或执行任务的同事

From one bottleneck to the next从一个瓶颈到下一个

By late Q1 2026 the bottleneck was no longer code generation but human review: Guardrails caught what humans used to catch, but every PR still waited on a human to approve. That wall was next.到 2026 年第一季度末，瓶颈不再是代码生成，而是人工审查：防护栏捕获了人类过去捕获的问题，但每个 PR 仍然在等待人类批准。这堵墙是下一个目标。

The first of many: Morphex众多智能体中的首个：Morphex

Morphex is monday’s first fully autonomous engineering agent, working within the same repo, CI pipeline, Guardrails, and revert protocols as every Builder. Nineteen of every twenty Morphex PRs merge automatically, not by skipping review but by passing every gate, and an approved PR ships to production with no human in the loop. It opens more PRs a month than most engineers, and a rejected PR fails for the same reasons any engineer’s does: flaky tests, ambiguous specs, unhandled edge cases.Morphex 是 monday 第一个完全自主的工程智能体，它在与所有开发者相同的代码库、CI 流水线、防护栏和回滚协议下工作。Morphex 每 20 个 PR 中就有 19 个会自动合并，这不是通过跳过审查，而是通过了每一道关卡，且批准后的 PR 无需人工干预即可发布到生产环境。它每月提交的 PR 比大多数工程师都多，被拒绝的 PR 失败原因与任何工程师相同：测试不稳定、规范模糊、未处理的边缘情况。

That 19-in-20 rate is a floor, not a ceiling. The open question: what signal tells us, ahead of time, which PRs are safe to merge without a human.19/20 的比例是起点，而非终点。悬而未决的问题是：什么信号能提前告诉我们，哪些 PR 在没有人类参与的情况下可以安全合并。

The signal: A recent rigorous cut信号：近期严谨的分析

Across our top PR-generating agents (no cherry-picking), the numbers break down cleanly: about three in ten PRs merged, roughly three-quarters of those with zero human edits, and a revert rate in the low single digits. Around a quarter of the PRs were caught and declined by Guardrails before reaching a human at all.在我们表现最好的 PR 生成智能体中（无筛选），数据清晰地呈现出来：大约十分之三的 PR 被合并，其中约四分之三是零人工编辑，回滚率在个位数水平。大约四分之一的 PR 在到达人类之前就被防护栏捕获并拒绝了。

That last number matters most. Guardrails stopped a quarter of agent PRs because the system saw they weren’t ready, leaving a pre-filtered population of merges. A low-single-digit revert rate on that population is the signal that confidence-based auto-merge is workable.最后一个数字最重要。防护栏阻止了四分之一的智能体 PR，因为系统发现它们尚未准备好，从而留下了一个经过预过滤的合并群体。该群体中极低的回滚率正是基于置信度的自动合并方案可行的信号。

Confidence-scored automatic merging基于置信度评分的自动合并

The confidence score combines four signals available the moment the PR opens:置信度评分结合了 PR 打开瞬间可用的四个信号：

• Deterministic Guardrails outcome: every blocking standard must pass.确定性防护栏结果：必须通过所有阻塞性标准。
• Per-agent eval trajectory: recent eval-score window for this version of the agent.智能体评估轨迹：该智能体版本近期的评估分数窗口。
• Per-(agent × repo × change-class) historical revert rate: near-zero reverts on dependency-bumps in a low-risk service is a different picture from a higher revert rate on monolith migrations.历史回滚率（智能体 × 代码库 × 变更类别）：低风险服务中依赖项升级的回滚率极低，这与单体迁移中较高的回滚率是完全不同的情况。
• Sandbox outcome: green from retrofit 3 is necessary, not sufficient.沙箱结果：改造 3 中的绿色通过是必要条件，但非充分条件。

Above the threshold, the PR merges automatically. Below it, it routes to a human with the specific failing signal called out. That’s the L2 to L3 transition: not removing humans, but removing humans from the cases where the system’s signal is strong enough that adding a human doesn’t improve the outcome. We’re driving one metric over the next two quarters: the fraction of merged agent PRs that ship without a human reviewer, holding revert rate flat or improving.高于阈值时，PR 自动合并。低于阈值时，它会路由给人类，并标注具体的失败信号。这就是从 L2 到 L3 的转变：不是消除人类，而是将人类从那些系统信号足够强、增加人工审查也无法改善结果的情况下解放出来。在接下来的两个季度里，我们专注于一个指标：在保持回滚率平稳或改善的前提下，提高无需人工审查即可发布的智能体 PR 占比。

AI engineering isn’t about creating perfect agents. It’s about building feedback loops that let imperfect agents be safely trusted while saving humans time.AI 工程不是关于创造完美的智能体，而是关于构建反馈循环，在节省人类时间的同时，让不完美的智能体得到安全信任。

Honest close坦诚的结语

Why we built it the monday way为什么我们选择用 monday 的方式来构建

The value isn’t the runtime, that’s only a harness around the Claude Agent SDK. It lives in everything we’ve wired around it, and that wiring is monday through and through:价值不在于运行时，那只是 Claude Agent SDK 的一个外壳。其价值在于我们围绕它所构建的一切，而这些连接完全是 monday 的风格：

• monday boards as the shared state layer: every agent’s tasks, status, and handoffs live where the rest of the business already looks.monday 看板作为共享状态层：每个智能体的任务、状态和交接工作都位于业务部门已经关注的地方。
• monday MCP servers as the substrate Guardrails and standards plug into.monday MCP 服务器作为防护栏和标准插入的底座。
• monday’s auth and identity, so every agent has a real Slack, GitHub, and monday user under the same RBAC as any human.monday 的认证和身份系统，确保每个智能体在 Slack、GitHub 和 monday 中都拥有与人类相同的 RBAC（基于角色的访问控制）权限。
• monday’s deploy pipeline so agent code ships through the same CI/CD as every other Builder.monday 的部署流水线，确保智能体代码通过与所有其他开发者相同的 CI/CD 发布。

Agents that share state, identity, and infrastructure with humans don’t need a separate governance layer. The existing one already applies. That makes the system auditable, reversible, and trustworthy by default, not by addition. A boilerplate system would have flattened all of that into someone else’s model.与人类共享状态、身份和基础设施的智能体不需要单独的治理层。现有的治理体系已经适用。这使得系统默认就是可审计、可回滚和可信的，而不是靠额外添加功能实现的。一个通用的样板系统会将所有这些简化为别人的模型。

Three things we’d do differently我们原本会做不同的三件事

Evals should have been in the system on day one, not month nine. The score lift Atlas got from them was the headline result. We over-invested in vector stores before realizing MEMORY.md on EFS was always the right answer. And the first CoWORK lived in a separate workspace that forced humans to context-switch to see what agents were doing. Moving it onto monday boards should have been the first decision, not a later correction.评估应该从第一天就纳入系统，而不是第九个月。Atlas 从中获得的评分提升是最大的亮点。我们在向量数据库上投入过多，后来才意识到 EFS 上的 MEMORY.md 才是正确的答案。此外，第一个 CoWORK 位于独立的工作区，迫使人类为了查看智能体的工作而进行上下文切换。将其直接整合到 monday 看板上应该是第一决策，而不是后来的修正。

Conclusion结论

We’re not open-sourcing monday-agent-sdk. The wrapper is small, and most of its value is the harness, which is monday-specific in ways that wouldn’t help anyone else. What we’re sharing is the architecture and the operational playbook, because the industry moves faster when the teams running production agents at scale are honest about what’s working.我们不会开源 monday-agent-sdk。这个封装很小，其大部分价值在于控制框架，而这对于 monday 来说是高度定制化的，对其他人可能没有帮助。我们分享的是架构和运营手册，因为当大规模运行生产级智能体的团队坦诚交流哪些方案有效时，整个行业进步得更快。

If you’re building agents into your engineering teams, you’ll meet most of the same walls we have, and we’ve already crossed them. Talk to us: the monday AI Engineering team, or the Amazon Bedrock team, will be happy to share our insights.如果你正在将智能体引入工程团队，你会遇到我们遇到的大多数障碍，而我们已经跨越了它们。欢迎与我们交流：monday AI 工程团队或 Amazon Bedrock 团队很乐意分享我们的见解。

Learn more了解更多

• Amazon Bedrock marketing page.Amazon Bedrock 营销页面。
• Amazon Bedrock service documentation page for the technical details behind the model calls described earlier in this post.Amazon Bedrock 服务文档页面，包含本文前面所述模型调用背后的技术细节。
• Amazon Bedrock console to get started.Amazon Bedrock 控制台以开始使用。

About the authors关于作者