Most AIOps platforms rest on a flawed assumption: that every incident is a bug waiting to be patched.

In production, that's rarely true. Some incidents come from architectural limits no patch can fix. Others come from business processes, operational decisions, or third-party dependencies that engineering can't fix at all. Auto-generating a fix for those creates a dangerous illusion: the patch ships, the alert clears, and the real problem is still there.

We built a prototype agent to test a different premise that an agent should understand a problem before it acts on it. It gathers evidence across systems, forms competing hypotheses, validates them against observed behavior, and only then decides what to do: write a fix, flag an architectural weakness, or escalate to whoever can actually resolve it.

The architecture is deliberately vendor-neutral: an evidence layer over the telemetry you already have, a hypothesis engine, a validation gate, and a narrow action surface. None of it depends on a specific model provider or managed agent runtime. Our reference implementation runs on Amazon Bedrock; we'll show what the provider boundary looks like and what actually has to change to move it.

This is a build report, not a product pitch. We'll walk through the architecture, show where the agent reasoned well, and show in detail, where it failed: hypotheses it defended past the evidence, escalations it should have made and didn't, and the guardrails we had to add. Those failures turned out to be the most useful thing we learned.

You'll leave with:

A reasoning-first agent architecture you can implement on any cloud
The specific failure modes that break AIOps agents, and how we caught them
A practical rule for deciding what an agent should never be allowed to auto-remediate