How We Learned to Trust an AI Agent to Triage Production Incidents

At 2:33 AM PDT on a Sunday, an availability alarm fired for a frontier model. Production responses were stalling mid-stream, and monitoring opened a ticket automatically.

By 2:46 AM PDT, 13 minutes and 35 seconds later, a defensible diagnosis sat on the ticket: streams stalling silently from either a production bug or capacity scaling, customers affected, every competing hypothesis ruled out, and a recommended next action written out with supporting evidence.

The on-call engineer typed one sentence: "file the escalation" or "address the production bug." The real contribution was reading the finished brief, weighing the judgment call it surfaced, and deciding.

The investigator was an AI agent running on Kiro CLI. This post is about how our team, one of the frontier teams redesigning how work gets done around agents, has learned to trust an agent with a production ticket queue, and what we still don't let it do.

Our team runs the data plane for Kiro, the serving path that carries every agentic chat request from Kiro's IDE, CLI, web, iOS, and Kiro Crew to a fleet of models (Anthropic, OpenAI, GLM, Qwen, DeepSeek, and MiniMax, hosted on Amazon Bedrock) across multiple regions, each with its own availability, latency, throttling, cache, and synthetic-probe alarms.

When an alarm fires, someone must triage it: is it real, what broke, who is affected? One availability dip might be a capacity event, a fraud attack, a bad deployment, or a mistuned alarm, and each hypothesis lives in a different log group, account, and query language. Good triage is knowing which five of five hundred questions to ask first, because each result determines the next query.

Triage is a hypothesis search, and an agent with tools is built for exactly that. Years of runbooks, alarm wikis, and post-incident notes were already an investment in agent context. The work is read-heavy: 96.9% of the agent's tool calls are reads (safe, reversible, parallelizable); the rest can be gated. And triage repeats: an agent that writes down what it learned compounds the system's knowledge. A tired human at 3 AM cannot.

There is no orchestration framework, no fine-tuned model, no bespoke agent runtime. The system is Kiro CLI, the same CLI we ship to customers, pointed at our own operations and configured with three kinds of plain files our engineers write and review like code:

• An agent config: the model, the tools, and a markdown steering file of operational rules, each a human judgment made once and applied thereafter.
• Model Context Protocol (MCP) servers: allow agents to connect to tools (AWS accounts as ReadOnly, logs, tickets, pipelines, code review, and Slack).
• Skills and knowledge: the interesting part, covered next.

Around the harness sits one long-running dispatcher that watches the ticket queues and spawns one headless Kiro CLI session per ticket. The model is a runtime parameter, not an architecture decision: the lead investigator runs on the strongest model available, fan-out work goes to a swarm of sub-agents on fast, inexpensive models, and genuinely ambiguous judgment calls are posed in parallel to a council of models from three providers, with disagreement treated as a signal to gather more evidence.

In contrast, a skill is a markdown playbook for one situation. The agent's context carries only the index of all 107 skills; when a ticket matches, it reads the full playbook for that one skill. Stuffing everything into the system prompt fails at about the tenth runbook, when the context fills with instructions for the 99 alarms that didn't fire. Following is an example of a condensed excerpt, written after a rate-limiting incident:

Knowledge is layered by cost: always-needed facts stay loaded, playbooks load on demand, and hundreds of compiled past investigations sit in a searchable archive. The layering enables survival: long investigations die of context exhaustion before anything else.

Back to that 2:33 AM alarm. Every step the agent takes is logged, and every claim it posts links to the query that produced it.

The deeper value is the work nobody does by hand. A week earlier, an alarm on another new model looked like a model-wide capacity event. Joining every stream error to its routing record by request ID, the agent found 96.5% of errors came from just 2 of our isolated serving cells; the rest had zero errors. The surviving hypothesis, "uneven per-cell quotas", was checked with ReadOnly credentials and exposed a latent bug in an upstream dependency. An engineer could do all of that, but not on a weekend night, mid-incident, across dozens of accounts.

What improves this system every week is the loop around it: engineers guide the agent and curate what it learns.

Four mechanisms keep it turning:

• Corrections become lessons. Each correction is stored once and injected into every future session (hundreds of corrections against thousands of completed runs reducing memory needs), and the agent patches the documentation that misled it, since the prompt bug originated from a doc bug.
• Investigations become knowledge. Closed tickets are distilled into the archive that future sessions query first.
• The agent drafts skills; humans review them. After a novel incident, the agent drafts a new playbook or a delta; the rate-limit playbook gained its per-cell step this way, the same night. Engineers and a nightly job curate the library just like another codebase.
• Shared state across agents. A conditional-write escalation tracker means ten parallel agents observing the same incident file just one upstream ticket, not ten.

On the other hand, the loop has also failed us. The lesson-capture pipeline once accepted whatever text was pending at session end, so interrupted sessions wrote raw ticket comments into the corrections store verbatim, and future sessions incorrectly studied them as operational wisdom. The fix was schema validation before writing, plus a nightly prune. Unless curated and carefully managed, a learning pipeline compounds garbage as efficiently as knowledge.

Kiro meters the agent in credits, the same unit our customers buy: a representative month produced about 250 investigations, completed unattended at a median of 13.6 minutes. Spend is not bounded by restraint, but by structure: session timeouts, stuck-detection, a concurrency cap, and inexpensive models for fan-out. All in, the monthly bill is equivalent to nine of our own top-tier subscriptions, and the reclaimed hours go into reviewing briefs, correcting the agent, and fixing root causes.

Agents inherit your documentation's bugs at machine speed. One stale line in a reference doc propagated into multiple tickets before a human caught it. Our fix was not related to a better model, but a new habit: when a session goes wrong, correct it, ask what misled it, and fix that document. Five minutes spent once beats five minutes lost every week.

Confident half-answers cost more than wrong answers. One steering rule helped more than any model upgrade: the agent must test and rule out competing hypotheses before it states a conclusion. Automated checks for arithmetic, alarm state, and duplicates then removed whole categories of errors that humans earlier had to catch in review. People trust output they can verify, not claims about accuracy.

Conciseness builds trust. Early agents posted their full step-by-step work into customer-visible threads. The content was accurate, but the experience was noisy. Now one short post goes to the visible thread and the full details go to the worklog. Partner teams judge the agent by its worst comment, not its best investigation.

There is no single autonomy setting. In one week, we corrected the agent in both empowerment and restraint: "stop asking permission to draft a code review; the review is the approval," and "never resolve a ticket or change severity; only humans do that." Every action needs its own rule, and the agent's steering file is the list of those rules.

Security comes from infrastructure, not just prompts. Every unattended session defaults to ReadOnly through a role allowlist, and a request for Admin privileges returns an error. Each credential is minted for one session and scoped to the task the agent declared, so a session can only call the APIs it requested.

Today, the agent does the triage. Increasingly, it also repairs - drafting code reviews for fixes and threshold tuned behind a mandatory human review, on the same harness. And because the whole system is made of markdown, MCP servers, and a stock Kiro CLI, every improvement we make for ourselves is relevant for the product we ship.

The on-call rotation still exists, but the job has changed: you no longer start investigations at 2:33 AM; instead you review finished ones at 2:46. The pager of the on-call engineer is becoming a decision queue for work an agent already did. Swami Sivasubramanian's post on frontier teams lists "invest in agent context" as the first step for development teams; our ticket queue is an example of investing in agent for operations.

That's day one in the new life of a frontier engineer, and there is more to come.