Wrong, not broken

For 20 years, software operations has been built around one question: Is it broken?

We’ve gotten very good at answering it. Metrics, logs, and traces. Distributed tracing that can follow a single request through dozens of services.

And all of it rests on one sensible assumption: When software fails, the failure eventually shows up as something a machine can measure.

Now picture an AI agent handling refund requests. It answers in 600 milliseconds. The error rate is zero. And it tells a customer they’re owed $40 when the policy says $140, because the document it retrieved was last quarter’s version.

Every dashboard is green. Nothing appears to be broken.

It’s wrong.

This week we launched Amazon CloudWatch Omni to observe agents, applications, and infrastructure together, and I wanted to give an inside look at the shift behind it and why it matters.

Correctness now has to be measured at the level of the run. Software has always been capable of being wrong. What changes with agents is how much of the behavior we care about is resolved while the software is running.

An agent adds another set of variables. The same agent, running the same code, can get one request right and the next one wrong. The outcome depends on how the question was phrased, what context was retrieved, which path it took through its tools, and what the model generated.

So “is it doing the right thing?” can no longer be answered fully before release. Some of the answer has to come from production, continuously, across the runs themselves.

That doesn’t replace the questions observability has always answered. It adds new ones alongside them.

Was the work any good? The test suite that ran before launch still matters, and now a live measurement can sit alongside it. Did the agent pick the right tool? Did it route the request correctly? When those scores sit on the same trace as latency and token counts, a team can see that a prompt change didn’t slow anything down but did make retrieval answers noticeably worse.

This creates a second problem: Quality has to become explicit enough to measure.

Human organizations can operate with a surprising amount of tacit judgment. People learn what a good answer sounds like from examples, colleagues, and experience. Not all of it has to be formalized.

An evaluator needs something more concrete. What counts as a correct refund decision? When should the agent escalate?

Building evaluations therefore forces teams to turn some of that tacit judgment into an operational definition of good. In practice, deciding what should be measured can be as useful as the measurement itself.

Where in the chain did it go wrong? Go back to the wrong refund. Maybe the model reasoned badly. Or maybe it did everything right, and a payments service three hops downstream was running an old configuration.

The team investigating it needs to follow one chain of cause and effect, from the customer’s question, through the agent’s decisions, into the services underneath. Agents are becoming components inside applications, so their behavior needs to be visible alongside the rest of the system.

What’s different about the bad runs? Dashboards remain useful because they make important signals continuously visible. They are especially good when a team already knows what it wants to watch.

Agentic systems add important questions that might only become obvious after something unusual happens. Why did refund accuracy drop for European customers this week? Did anything change in retrieval, tool selection, or the services downstream?

Being able to ask those questions directly and have the observability system assemble the relevant telemetry changes how an investigation can begin.

Did the fix actually work? A bad run in production doesn’t need to end as an incident report. The traces where an agent got something wrong can become a dataset. A team can try a change against those examples, compare the new version with the old one, deploy it, and then see whether production behavior actually improved.

That creates a much tighter connection between operating an agent and developing it. The same evidence used to understand a failure becomes part of the test for whether it has been fixed.

More autonomy requires more evidence. Agents get more valuable as they take on more authority. What holds organizations back is whether they can answer a few plain questions. What did the agent do? Was it right? Would we know if that changed?

Authority tends to be extended in steps, much like it is with a new colleague. First, every action gets approved. Then only the unusual ones. Then someone reviews a sample. Eventually, the work gets checked after the fact.

Safety works the same way. Permissions still set the outer boundary, and an agent that isn’t allowed to issue refunds won’t. But permissions describe what’s possible, not whether a particular choice was a good one. A policy can say the agent is allowed to issue refunds. It can’t say whether this refund, to this customer, for this amount, was right. More and more of what matters happens inside that boundary. The way to understand it is the same as for quality: Look at what actually happened.

Put simply, the authority an organization can comfortably give its agents depends on how clearly it can see what they do.

That relationship could eventually become dynamic. Today, the decision about how much authority an agent gets is still largely made by people. Looking further ahead, it doesn’t need to stay static. If quality signals are live, autonomy could widen as an agent establishes a track record, and narrow when quality slips, until someone understands why. We are not there yet, but the pieces needed to build systems like this are starting to exist.

Where we’re investing. This week, we launched Amazon CloudWatch Omni, and it’s our first big step in this direction. It puts agent traces, application services, and infrastructure in one view. It scores agent behavior with 17 built-in evaluators (for things like correctness, faithfulness, and tool selection). Teams can also turn production traffic into datasets and experiments. AWS DevOps Agent joins incident investigations and works from the same telemetry the engineers see. Developers see in their IDE the same traces that operators see in production. The experience is built around OpenTelemetry, with agent instrumentation using OpenInference and AWS Distro for OpenTelemetry (ADOT). It works with agents built on LangGraph, CrewAI, Strands, and other frameworks. It’s early, and we will learn a lot from how customers use it.

Parting thoughts. For higher-consequence work, many agents in production still have people approving important actions. As we build evidence that those systems behave reliably, more of that work can move from approval to review, sampling, and exception handling.

Everything we already know how to observe still matters. Agents run on services, databases, networks, queues, and infrastructure, and all of those systems still need to be understood when something goes wrong.

What’s being added is a new set of questions. Alongside understanding whether the system is running as intended, we increasingly need to understand whether the work it is doing is good.

The teams that can answer both will be able to give their agents more responsibility with greater confidence.

That’s what we’re building toward with CloudWatch Omni.