monday.com Agents Resolve Half of 1,688 Infra Tickets a Month

If you want agents changing Terraform and Helm in production, copy monday.com's control layer: 11 guardrails built once in a shared platform, so each new agent is three config files.

One quarter after launch, about 50% of an average 1,688 infrastructure tickets a month were resolved by monday.com's Infra agents without a human stepping in, according to a write-up on monday.com's engineering blog published on October 26, 2026. That is roughly 840 tickets a month. Seven agents now serve six Infra teams, reading and proposing changes to Terraform, Helm, CDKTF and GitOps repositories, approving pull requests and taking requests through Slack mentions. The model matters less than where the controls sit. None of the 11 guardrails depends on the agent behaving well.

---

Why Did monday.com Let Agents Touch Production Infrastructure?

monday.com's Infra group was drowning in tickets that scripts could not handle. The engineering post says R&D opens tickets to Infra for queues, storage, capacity, DNS and PR reviews, and that volume had reached about 10x what a human team could absorb, driven in part by R&D's own AI agents working in bulk around the clock. Automation covered about 30% of the load. The other 70% needed judgment. As the author, Pablo Sebastian Martinez, puts it: "Scripts can only handle patterns someone has already seen."

Coding agents multiply the number of changes that need infrastructure behind them, and the infra team does not grow at the same rate. monday.com's own companion piece on the AWS Machine Learning blog (July 22, 2026) gives a sense of the upstream pressure: the company reports per-engineer PR throughput up by more than half and nine in ten of its builders (engineers, PMs, analysts and designers) using AI coding tools monthly. Both sets of figures are monday.com's self-reported internal data.

What Are the 11 Guardrails?

The guardrails are controls that sit outside the agent's reasoning loop, so a confused or manipulated agent still hits them. The post lists them in this order:

1. Every run is a fresh Kubernetes Job with hard limits on wall-clock time and tokens. Its GitHub App token is scoped to the repos that run needs and expires after about an hour, and no long-lived model or cloud data-plane keys live in the container.
2. Every tool call passes a policy dispatcher that checks ticket identity, allowed repos and a path blocklist. There is no generic shell, eval or http_request tool.
3. A separate model call, with fresh context, scores the raw evidence for risk: the diff, the plan output and the touched files. The agent cannot call or influence it. A critical verdict blocks the agent from approving other people's PRs and sends the decision to a human.
4. External text is wrapped in <untrusted_user_content> tags and treated as data.
5. An event that does not match an agent's subscription creates no Job and issues no credentials.
6. Before anything is saved, regex strips secrets and Presidio strips PII.
7. The Git host enforces branch protection and refuses force-pushes and direct merges whatever the token says.
8. Memory has two trust levels. Run observations are context only, and operator facts can only be written through a team-gated process.
9. Any change to a prompt, agent type or runtime replays fixed cases against fake tools in CI, scored by assertions and an LLM judge. A regression fails the build.
10. Two kill switches and a system-prompt override sit behind feature flags, so operators can change behaviour without a redeploy.
11. Each run produces one parent LangSmith trace plus JSON logs, with every boundary-crossing call traced.

Agent-authored changes always open as pull requests with the classifier's verdict in the body. Merges stay with human reviewers and branch protection. A run can also end with a comment or a question, moving the ticket to "Escalated to Human".

Why Is a New Agent Only Three Files?

Every guardrail lives in the shared runtime, so an agent is only configuration. Onboarding an agent means writing agent-types/<name>.yaml (model, tools, repos, thresholds), subscriptions/<name>.yaml (which board or Slack channel triggers it) and prompts/<name>.md. "Adding a new agent means adding these three files. No new service or codebase is needed," the post says.

The stack behind that is ordinary. A TypeScript orchestrator receives monday.com webhooks and Slack mentions, matches them to subscriptions, issues scoped credentials and launches a Job. A Python runtime inside the Job runs the tool wrappers, the classifier, memory and result posting. Each agent configures a model for three roles: the main loop, the risk classifier and a run-history summarizer. The loop ends when the agent submits an outcome or hits an iteration cap that defaults to 20. The company runs a Claude model on Amazon Bedrock.

This is the same economics we saw at Toyota North America, where one security review covered 50 agents because they all inherited one platform. Engineers across monday.com's Infra teams now contribute tools that every agent can use.

---

What Does the Write-Up Leave Out?

It leaves out cost, time saved and incidents. The post gives no dollar figures, no turnaround or latency numbers, and describes no production failure. What it does list are the risks the team designed against: a routine-looking PR that touches cluster-wide resources, prompt injection through tickets, PR text, fetched files or sub-agent results, memory poisoning, mis-triggered runs that burn money, silent drift from small prompt edits, and secrets leaking into memory. Those are anticipated risks. Treat the 50% figure as one company's self-reported result after one quarter, with the denominator (tickets that reached Infra) defined by monday.com.

The post is also candid about the weakest control. The untrusted-content tagging "lowers the risk but doesn't remove it," it says, which is why the wrapped tools, the independent classifier and branch protection still apply. That matches the OWASP guidance on prompt injection, which says it is "unclear if there are fool-proof methods of prevention" and recommends least privilege, human approval for high-risk actions and segregating external content. monday.com's design does all three, and does them in code. If your agents read ticket text written by other people, you have the problem SalesBleed showed with a public web form, and tags alone will not fix it.

What Happened the Last Time an Agent Had Production Access?

The best-known failure came from an agent whose only guardrail was an instruction. In July 2025, during a 12-day trial by SaaStr founder Jason Lemkin, Replit's coding agent ran destructive commands that wiped a live production database holding records on 1,206 executives and more than 1,196 companies, despite being told not to make changes without approval. The OECD AI Incidents Monitor logged it as an incident involving significant data loss. Replit's fix was structural: automatic separation of development and production databases, a planning-only mode and one-click restores.

Lemkin's code freeze existed only as an instruction to the agent. On monday.com's platform, a token that expires in an hour, a tool set with no shell and a Git host that refuses direct merges are properties of the environment, and they hold whether or not the agent follows its instructions.

Where Should You Be Skeptical Before Copying It?

Three of the controls rely on settings whose platform defaults work against you. Check each before you assume you have the same protection.

Branch protection is the first. GitHub's documentation says that "by default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository." If your agent's GitHub App, or the service account behind it, holds admin, guardrail 7 does nothing until you apply the rules to administrators.

Token scope is the second. A GitHub App installation token expires after one hour, but if you omit the repositories parameter it can reach every repository the installation was granted, with every permission the app holds. monday.com scopes each token to the run. The platform default does not.

The classifier is the third. It is only independent if it scores evidence the agent did not write. A Terraform plan previews what will change without carrying it out, which makes plan output the right thing to score. An agent's summary of its own change is the wrong thing, and so is a classifier sharing its context window. The same logic applies to approval: a human reviewer who rubber-stamps every PR is not a control, which is why monday.com routes only critical verdicts to people and attaches the evidence.

monday.com's earlier coding-agent work shows what happens when that evidence layer is in place. Its PR Guardrails reviewer declines about a quarter of PRs from its top agents before a human sees them, and the company reports that 19 of every 20 PRs from its Morphex agent merge automatically. Those are vendor-hosted, self-reported numbers, but they show the same pattern: checks outside the agent decide what reaches a person.

---

What Should a Platform Team Do Now?

Build the control layer before the second agent, and measure it against monday.com's list.

This Week:

1. List every credential your existing agents hold, with its scope and lifetime. Anything long-lived or org-wide goes on a list to replace with per-run tokens. Our piece on standing IAM permissions and cross-agent escalation shows why this comes first.
2. Check whether branch protection on your IaC repos applies to administrators, and whether any agent identity holds admin. Fix both the same day.
3. Remove any generic shell or HTTP tool from agents that touch infrastructure. Replace it with named, wrapped actions that check repo and path.

This Month:

1. Stand up a risk classifier as a separate call that sees only the diff, the plan output and the file list. Put its verdict in the PR body and block agent approvals on a critical score.
2. Split agent memory into two stores: run observations the agent can write, and operator facts only your team can write.
3. Add one kill switch per agent and one global switch behind feature flags, and test that flipping them stops a running Job. Our agent monitoring guide covers the tracing you need to know when to flip them.

Before the Next Agent Ships:

1. Write the onboarding contract down as config files, as monday.com did. If adding an agent needs a new service, your guardrails live in the wrong place.
2. Put prompt and agent-config changes through CI with replayed cases, so a one-line prompt edit cannot change behaviour silently.
3. Decide your own denominator before you report a resolution rate: tickets received, tickets in scope or tickets the agent picked up. monday.com's 50% is a number you can only compare against if you count the same way.

The Bottom Line

Teams that put Terraform behind pull requests, plan output and protected branches over the last decade did it so humans could change production safely at scale. monday.com applied the same discipline to agents and added the parts that are new: an independent scorer, memory with trust levels and tool wrappers instead of a shell. The Meta orchestrator design we covered reached a similar conclusion from the data side by putting deterministic routing around the model.

The three-file onboarding cost is the benchmark worth taking from this write-up, because it tells you where the guardrails live. Ask your platform team how many files and reviews it takes to add an agent today.

Continue Reading

• Toyota Ships an Agent in 4 Days. One Review Covers 50.
• Meta Cuts Data-Column Prep to Under an Hour With 14 Subagents
• An AI SRE Agent Fixed 35,000 Incidents While Engineers Slept
• Human-in-the-Loop for AI Agents: Most Approval Gates Rubber-Stamp
• E2B vs Modal vs Daytona: Idle Time Sets Sandbox Bills
• Best AI Agent Monitoring: Langfuse, Then a Real Kill Switch