Introducing Issues, one problem, one thread, start to finish.

The re-triage tax

I’ve yet to meet an engineer who enjoys being on call. Some see it as a rite of passage or, at best, a learning and growth experience. However, much more has been written about why being on call sucks. I won’t rehash that here. I want to go deeper on one key point Charity Majors makes in her canonical piece on this subject.

“if you get paged about flappy alerts or the same problems week after week; of course you’ll hate it.”

When something breaks, you get paged. You start digging. Then you get paged again. The explanation has changed. An alert you looked at ten minutes ago is back. You acknowledge it again. You re-explain it in the Slack thread. You rebuild the context in your head. And the cycle continues… This is not just a tooling or thresholding problem. And it is not going away by putting AI agents on call.

In a large, dynamic environment like a microservice architecture, a single problem manifests through multiple symptoms that propagate across related entities. Not every symptom caused by the problem is present at any given moment. The environment's dynamic nature makes these symptoms flaky. They are present at one moment, gone the next. Common observability systems trigger on these symptoms via anomaly detection, but no anomaly-detection mechanism is immune to noise. Missing, spurious, and flaky symptoms are unavoidable.

This means a reasoning system can only draw a conclusion from what is present at that moment. At any point, the inferred cause is simply the explanation that best fits the current observations. And as those observations shift, the conclusion can shift with them. That's the real challenge. Knowing when the system can safely commit to a diagnosis and act on it.

It's tempting to think agents solve this by default. Agents don't get tired. They don't get annoyed. But the re-triage tax doesn't disappear when an agent takes over; it gets worse. When the symptoms or conclusions keep shifting underneath it, an agent starts over every time: it re-reads everything, reasons from scratch, and burns tokens doing it.

From cause to action

Causely already does the heavy lifting on call. It does not just process telemetry and flag anomalies; it understands how your system is connected and reasons about cause and effect across it. So instead of a hose of alerts, you get the cause. As one customer, a global bank running thousands of services, recently observed, dozens of alerts are explained by one Causely notification.

That reasoning is continuous. As observations change, the diagnosis updates to best explain them. The next challenge is deciding what action to take. In other words, confirming that the current diagnosis needs to be resolved, not just observed.

That confirmation is what a person needs to act with confidence, and what an agent needs to follow a problem through resolution. We call it an Issue.

What an Issue is

An Issue is the persistent thread that ties every diagnosis of the same underlying problem together into one thing to acknowledge, one thing to share with your team, one thing to resolve.

Here is how it works. An Issue causes anomalies, which trigger Signals: alerts, log messages, events… At any point during the life of the Issue, the system may infer a Diagnosis — the best explanation of the observations at that moment. As anomalies appear and clear, as affected services shift, as alerts fire and stop, the Signals change, and the Diagnosis updates to match.

The Issue is what holds it all together across all those changes. In each context, the odds that the same Signal is caused by two different Issues at once are very low. So, if two Diagnoses share even one Signal — present now or present at any point — they are treated as an expression of the same Issue. In other words, the Diagnosis can keep changing shape, but as long as Diagnoses keep sharing a Signal, it’s still one Issue. The Diagnosis evolves. The Issue doesn’t.

When you resolve an Issue, a leftover noise will not drag you back in. It only resurfaces if something genuinely related returns.

For on-call engineers and agents

For engineers on call: you get one stable thread for the persistent problem, start to finish. You stop re-triaging things you have already seen. And you can trust that when an Issue pings you, it is new, not the same problem wearing a different face.

For agents, this matters even more. An agent only knows what you hand it. A person can hold continuity in their head when the tooling falls short; an agent cannot. Hand it a stream of changing diagnoses, and it behaves like an inexperienced engineer who restarts the investigation every five minutes. It thrashes, repeats work, takes conflicting actions, and files two tickets for one problem.

Give an agent a stable Issue, and that stops. It has one thread to reason and act on. The diagnosis can keep evolving underneath without throwing it off, because the agent is working on the Issue, not chasing the latest hypothesis. It acts once. It does not start over. It does not burn tokens re-deriving what it already knew.

So, an agent needs a stable Issue more than a person does, not less.

One problem, one thread

The re-triage tax is what makes on-call miserable for people and wasteful for agents alike, and it isn’t solved by working faster through the same noise. It’s solved by giving whoever, or whatever, is responding to a single, stable thing to hold onto while the underlying diagnosis does its work underneath.

Issues are now live as early access. This is just the start. Issues are becoming the primary way Causely notifies you and the primary surface for agents working through MCP.

Check out Issues in your environment and tell us what you think.