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吞吐量增长超过一半。本文中的所有数据都来自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吞吐量提升了一半以上。
• 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在运行时层提供了更好的东西，我们会删除我们的版本，但框架保持不变。

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是运行时。我们封装它有3个原因：

• 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.我们希望拥有自己的框架。运行时正变得商品化。框架是我们的理念所在：如何评估代理、插件如何组合、如何与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.不使用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 fabricAmazon 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不仅仅是获取令牌的地方。它让我们能够运行数百个代理，同时不失去对成本、安全性和容量的掌控。大规模部署代理的大多数运营需求已经是Amazon Bedrock的功能：

• Application Inference Profiles route every model call, so cost tracking and capacity planning stay in one place.应用程序推理配置文件路由每个模型调用，因此成本跟踪和容量规划保持在一个地方。
• 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和日记/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 PR中有十九个自动合并，不是跳过审查，而是通过每个关卡，批准的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关于作者