Monte Carlo’s Reinforcement Loop paves the way for self-improving agents

Ask any engineering team running AI in production what they’d want most, and some version of self-improvement comes up for nearly everyone. The dream is to have agents that catch their own failures, learn from them, and come back sharper the next time without a team of engineers having to file ticket after ticket.

When we think about agentic self-improvement, our first instinct is to perhaps classify this as a sci-fi impossibility, at least for the moment. This is not true; we are very close to achieving this with our current technology.

The second instinct is, I have often seen, to treat the model as the ultimate determinant for self-improvement. Get a capable enough model, a smart enough framework, and self-optimization turns on.

This is also not true. Self-improvement isn’t a switch that gets flipped when a new model comes to town. It’s much more akin to building infrastructure, and, at its most basic form, requires three components: a blueprint, a labor force, and a foundation.

The blueprint: a reinforcement loop

Most data and AI engineers are familiar with reinforcement learning, which has a clear shape: an agent observes a state, takes an action, gets a reward, and updates its policy. When you run that loop enough times against a good signal, the agent’s performance will improve.

The algorithm is not the hard part when it comes to applying this to our agents; the environment is. You need something that can produce different states and rewards, cheaply, and at volume.

Luckily, if you run agents in production, you already have those signals:

• Traces — every tool call, model invocation, error, and retry
• Evals — continuous benchmark scores from grading outputs
• Operational context — filed tickets, merged PRs, resolved incidents

Individually, each is a partial picture that alone cannot build a reinforcement loop. But connected, they form a real-time reward signal.

For most organizations, these exist in siloed systems and nothing joins them, which is why going from noticing an issue to remediating and optimizing the agent based on the issue’s diagnostic signal is still an entirely manual job.

We are changing that paradigm at Monte Carlo with the Reinforcement Loop, the latest agentic capability within our agent trust platform.

The Reinforcement Loop is what connects the various signals that your team needs to integrate in order to quickly understand agent health and performance, diagnose issues, remediate them, and apply a fix with each run. Under the hood, our Reinforcement Loop does exactly all of that: it ingests all three signal types, detects the failures that look normal, verifies what’s real and not already fixed, explains root cause along with the fix, and closes the loop by outlining a fix.

Then the cycle repeats on the agent’s next run, which is what makes it a loop rather than a report. Today’s fix becomes tomorrow’s input. Each cycle’s fix becomes the next cycle’s baseline, its new beginning state. Each improvement is incremental as the agent improves upon itself again and again.

The labor: an agentic fleet

A blueprint only helps if something executes it. And here is where most teams stall: in a human-led loop, every station in the cycle is a place where an engineer is involved doing manual work.

While that might be ok when you have three agents you need to optimize, it certainly does not work at a hundred, a thousand, or ten thousand agents. Humans are the bottleneck at enterprise scale; they can’t operate at that kind of speed or volume. What’s more, the loop needs to run continuously in order to function as intended for agents to truly self-optimize, and people can’t operate like that.

So Monte Carlo builds each station as an agent in its own right. A few examples of these include:

• Monitoring Agent — watches every run, and the data underneath it
• Triage Agent — confirms what’s real, still unfixed, and worth acting on
• Troubleshooting Agent — roots out cause across spans, code, and pipelines
• Remediation Agent — writes the draft PR, the ticket, or the monitor

Alongside them, dedicated Cost and PII/Compliance agents watch the dimensions that tend to go unwatched until they become incidents.

The loop runs 24/7, and no step waits on a person. Here’s the difference in practice:

	Traditional AI ops	Reinforcement Loop
Ingest	Traces, evals, and your backlog sit in three systems. Nothing joins them.	Reads all three every day — including your merged PRs.
Detect	You hear about it from a user. The worst failures return normal status codes.	Deterministic detectors catch failures that look healthy.
Verify	Severity gets decided by vibes at standup — then you find out it was fixed last sprint.	Confirms it’s real, and checks your PRs to see if it’s already fixed.
Explain	An engineer loses hours sifting through traces.	Root cause, cited evidence, and a concrete fix.
Act	The engineer writes the fix, the tests, and the ticket.	Draft PR, ticket, or monitor — human clicks Approve.

Four stations run autonomously: detect, prioritize, diagnose, recommend. Right now, validate and deploy stay with the person – an engineer approves the fix before it ships. While that is intentional, we are not too far from a future where even that stage is executed by agents.

The foundation: cohesive observability

This is the layer that many people skip, and doing so can be very expensive. If you supply the foundation with incomplete data, you will be optimizing your agent around an incomplete truth.

In reality, no single signal sees a whole failure:

• Telemetry alone shows you the agent, but not the data underneath it
• Evals alone show you a score, but not the behavior that produced it
• Telemetry and evals with no code or PR connection means no operational context — you can’t tell real, live issues from what has long since been fixed.

A reward signal worth optimizing against needs a single view across the four dimensions of observability: Context (is the data input correct?), Performance (slow, costly, or broken?), Behavior (right tools, right order?), and Outputs (are they fit for use?).

Which is the quietly good news in all of this. What a self-improving system needs to run on is something many teams have already been building. Trust infrastructure — a cohesive view across context, performance, behavior, and outputs — turns out to be exactly what the loop needs to stay reliable.

What’s available today

Now:

• The Reinforcement Loop is available on custom agents built with LangGraph and similar frameworks.
• It’s also available for Snowflake Cortex agents, with platform-specific detection rather than a filtered generic view.
• Monitoring, triage, troubleshooting, and remediation running as agents — the detect-through-recommend steps are all autonomous.
• Drafting a PR, filing a ticket, or creating a monitor for each issue is triggered on your approval.
• The feature also provides an optional source-code connection, which materially improves how well findings are grounded.

Coming next:

• Databricks Genie support.
• Autonomous action — triggering tickets, monitors, and changes without the click, always reviewable and reversible.
• Deeper eval integration, and direct links from any finding to the exact trace spans behind it.

If you’re running agents in production and your current answer to “why did that happen?” is a person and an afternoon, we should talk. Schedule a demo.