monday.com has offered a detailed look at how it runs production AI agents for software delivery on Amazon Bedrock, giving the market a concrete case study in what “agentic AI” looks like inside a large enterprise SaaS environment rather than a demo environment.

The disclosure comes through an AWS Machine Learning Blog post and an AWS news item, so the information is largely vendor-controlled. Even so, it is notable because monday.com is describing not only model usage, but the systems, queues, storage layers, review flows, and operational safeguards required to let internal AI agents interact with Slack, GitHub, and monday workflows in production. For AI builders and enterprise buyers, the significance is less about one benchmark and more about the architecture choices behind reliability, replay, auditability, and human oversight.

According to AWS’s account of monday.com’s setup, the company organizes its internal “AI Teammates” in three levels. At the first layer, humans use AI coding tools as assistants. At the second, teams create reusable skills and sub-agents for repeated work. At the third, agents take on end-to-end delivery tasks while humans orchestrate and review. AWS says monday.com’s internal system, called Sphera, gives agents stable identities across systems so they can be assigned work, reviewed, or deactivated in ways that resemble human teammates.

From coding assistant to managed agent workflow

The most interesting part of monday.com’s description is that it frames AI adoption as an operational progression rather than a single product rollout. AWS says monday.com uses Cursor for quick pair-programming tasks and Claude Code for heavier engineering work, which the company categorizes as its L1 assistant layer. It then moves toward reusable internal agents at L2 and multi-agent delivery at L3.

That matters because many enterprise AI deployments stall between “copilot” experiments and production automation. monday.com’s account suggests the gap is not solved by better models alone. It is solved by wrapping model access in an orchestration layer that understands work assignment, session memory, tool use, code review, replay, and failure handling.

In monday.com’s system, an agent can be triggered from three channels: a Slack mention, a monday item assignment, or a GitHub pull request review request. AWS says all three routes land in the same agent session, sharing the same memory and disk workspace. That design appears intended to avoid fragmented context across different collaboration tools.

The central agent highlighted in the post, called Atlas, is described as a software engineer agent that can pick up tickets, write pull requests, and ship features. AWS presents Atlas as one member of a broader team structure inside Sphera, where agents have a defined role, scope, manager, and performance score. That framing may sound cosmetic, but monday.com says it is actually part of the operating schema for how agents are addressed and governed.

Why the AWS stack matters here

The architecture monday.com disclosed is notable partly because it is not a single monolithic agent platform. Instead, AWS says monday.com built a layered system across standard cloud services, with Amazon Bedrock handling model access and a broader eventing and storage stack doing most of the operational work.

According to the post, external triggers first land in Amazon SNS, which then fans out to Amazon SQS queues. Consumers running on Amazon EKS pull messages, resolve which agent should own them, and hand work to an agent runner pod. monday.com says this pub/sub plus queue setup gives it retries, dead-letter queues, back-pressure when Amazon Bedrock throttles, durable replay for testing patched builds, and concurrent fan-out.

That is an important point for teams planning AI agents in production. The hard part is often not generating code or text. It is managing bursty workloads, rerunning jobs after failures, tracing what happened, and recovering safely when dependencies or model endpoints become unavailable. monday.com’s architecture shows a bias toward boring but proven infrastructure patterns.

The company also says it wraps the Claude Agent SDK rather than relying on it directly. AWS attributes three reasons to monday.com: preserving provider neutrality at the call site through Amazon Bedrock, reducing cold-start latency with prewarmed caches, and keeping control of what it calls the “harness” layer where evaluation, plugin composition, communications, and review logic live. That is a useful signal for builders. It suggests the model runtime may be interchangeable, while the control plane and workflow logic become the durable internal advantage.

Storage, memory, and the less glamorous engineering choices

A second lesson from the disclosure is that agent systems need several kinds of state, and those states do not belong in one database.

AWS says monday.com keeps live state such as current task, heartbeat, locks, and message logs in Amazon ElastiCache for low-latency access. Session memory and working files are stored on Amazon EFS, while durable records such as transcripts, artifacts, snapshots, and evaluations go to Amazon S3. Amazon RDS is listed among the services used, though the post extract does not spell out its specific role. AWS Secrets Manager is used for per-session secret handling.

This breakdown matters because many agent prototypes treat memory as a single abstraction. In practice, coding agents need something closer to a conventional distributed system: fast ephemeral state, a shared file system for tools that expect POSIX semantics, and long-term storage for audits and evidence.

AWS says monday.com chose Amazon EFS over object storage for active sessions because the Claude Agent SDK and common developer tools like git and npm expect a real file system. It also allows a session to resume on a different Amazon EKS pod by mounting the same path. That is a pragmatic choice, and one that reflects the reality that software agents often depend on the same file and process assumptions as human developers.

For enterprise AI teams, this is one of the more credible aspects of the story. It moves beyond the marketing shorthand of “memory” and shows that persistent workspaces, resumability, and deterministic tooling environments are central to agent reliability.

Evidence, claims, and what remains unverified

Because the source material comes from AWS and the AWS Machine Learning Blog, the strongest performance and adoption claims should be treated as vendor-reported. AWS says all figures in the post come from monday.com’s internal production data.

Those claims include that nine in ten builders at monday.com use AI coding tools every month, up from roughly half a year ago, and that per-engineer pull request throughput is up by more than half. AWS also says this L2 layer of skills and sub-agents is where most of monday.com currently operates.

Those are meaningful claims if accurate, but readers should note what is not provided in the available evidence. There is no independent methodology, no raw denominator for “builders,” no baseline period beyond broad relative language, and no breakdown of whether higher pull request throughput translated into better cycle time, fewer incidents, or different review burdens. Nor does the material quantify cost, defect rates, or how often human reviewers reject or rewrite agent output.

Similarly, AWS says Amazon Bedrock helps monday.com keep cost tracking, capacity planning, and model-call audit trails in one place through mechanisms such as Application Inference Profiles. That is plausible as a platform benefit, but the evidence here remains descriptive rather than comparative. There is no direct benchmark against alternative deployment paths.

Still, the post is stronger than many AI case studies because it spends more time on system design than on abstract transformation claims. The absence of independent validation does not erase the architectural signal; it just limits how much weight buyers should place on the productivity numbers.

What this means for builders and enterprise buyers

For software teams, the monday.com example points to a practical split in the AI stack. Products like Cursor and Claude Code can improve individual developer output quickly, but scaling beyond personal assistance requires infrastructure that looks much closer to platform engineering than prompt engineering.

For enterprise AI buyers, the case is a reminder that deploying AI agents into customer-facing software organizations raises harder requirements than chatbot rollouts. Agents that open pull requests or act on tickets need durable identity, scoped permissions, observability, rollback paths, review checkpoints, and enough audit detail to satisfy security and compliance teams.

The story also sharpens the competitive framing around Amazon Bedrock. AWS is positioning the service not merely as model access, but as a control point for capacity, governance, and cost accounting across many agents. That pitch is likely to resonate with companies already standardized on AWS, especially those that want model optionality without building their own gateway layer from scratch.

At the same time, monday.com’s own design suggests that cloud services alone do not solve the core workflow problem. The differentiating layer is the internal harness: routing, evaluation, plugin logic, review policy, and team-specific integration with Slack, GitHub, and monday itself. Enterprises buying agent platforms will need to decide how much of that harness they want to own.

What to watch next

The next signal to watch is whether monday.com or AWS provides harder evidence on software quality and operating cost, not just activity metrics. Pull request volume is useful, but enterprise buyers will want to see data on incident rates, rollback frequency, review time, and security exceptions.

A second signal is whether monday.com expands agent autonomy beyond internal engineering workflows. If agents can safely move from coding support to broader product and operations tasks, that would strengthen the argument that structured multi-agent systems can become a general enterprise pattern.

Third, watch whether AWS turns this architecture into more productized guidance or features around Amazon Bedrock, Amazon EKS, and orchestration tooling. The current description still implies significant custom engineering by monday.com.

Finally, it will be worth tracking whether competitors publish equally detailed production stories. The market has many claims around AI agents, but relatively few accounts that explain how agents actually persist context, recover from failure, and pass human review in a live enterprise stack.

Creati.ai perspective

The real news here is not that monday.com uses AI for coding. Many companies do. The more important development is that monday.com is describing a production operating model for AI agents that treats them as managed workers inside existing software delivery systems, with queues, filesystems, audit trails, and explicit review boundaries.

That is where the enterprise AI market is heading. The winners will not be the teams with the flashiest demos, but the ones that can make AI agents legible to engineering managers, security teams, finance teams, and on-call operators. monday.com’s architecture, as presented by AWS, suggests that agent adoption becomes credible when it is built like infrastructure first and intelligence second.