Kiro AI Agent Incident Triage: A 13m 35s Diagnosis

A 2:33 AM alarm, diagnosed in 13 minutes 35 seconds

An AI agent put a diagnosis on the ticket 13 minutes and 35 seconds after a 2:33 AM PDT availability alarm. Triage is the job of deciding, once an alarm fires, whether it is real, what broke and who is affected. Kiro's team gives that job to the agent.

On a Sunday at 2:33 AM PDT, an availability alarm fired for a frontier model. Production responses were stalling partway through, and monitoring opened a ticket on its own.

By 2:46 AM PDT the ticket held a diagnosis: streams stalling silently, either from a production bug or from capacity scaling, with customers affected. The agent had ruled out every competing hypothesis and written down a next action with its evidence.

Kiro writes that the work is read-heavy: 96.9% of the agent's tool calls are reads, which Kiro calls safe, reversible and parallelizable. The post adds that the rest can be gated.

"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 work is read-heavy: 96.9% of the agent's tool calls are reads (safe, reversible, parallelizable); the rest can be gated."(opening and The job sections)
View official source →

How it is built: the Kiro CLI, MCP servers, and a 107-skill index

The agent is the Kiro CLI that Kiro ships to customers, aimed at its own operations. Kiro built no orchestration framework, no fine-tuned model and no custom agent runtime. The setup has three parts.

MCP, short for Model Context Protocol, is the shared way an agent connects to outside tools. A steering file is the list of operating rules the agent follows. A skill is a markdown playbook for one situation.

The three parts that set up the agent

Component Contents
Agent config The model, the tools and a markdown steering file of operational rules
MCP servers Connections to tools: AWS accounts as ReadOnly, logs, tickets, pipelines, code review and Slack
Skills and knowledge Markdown playbooks for single situations, plus an archive of past investigations

The agent's context holds only the index of all 107 skills, and it reads the full playbook only for the skill a ticket matches. Kiro says that putting every runbook into the system prompt stops working around the tenth one, because the context fills with instructions for the 99 alarms that did not fire. Kiro adds that this layering is what lets long investigations survive, since they otherwise die of context exhaustion first.

"There is no orchestration framework, no fine-tuned model, no bespoke agent runtime."/"Model Context Protocol (MCP) servers: allow agents to connect to tools (AWS accounts as ReadOnly, logs, tickets, pipelines, code review, and Slack)."/"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."/"The layering enables survival: long investigations die of context exhaustion before anything else."(The system and Skills sections)
View official source →

Read-only by default, and humans still resolve the tickets

Kiro says every unattended session starts with read-only access, granted through a role allowlist. A request for Admin privileges returns an error. Each credential is issued for one session and limited to the task the agent declared.

The steering file also holds two rules that Kiro wrote after correcting the agent in opposite directions within one week. The first tells it to stop asking permission to draft a code review, because the review is the approval.

The second forbids resolving a ticket or changing its severity; Kiro leaves both to humans. Kiro's summary is that no single autonomy setting exists, so each action needs its own rule.

"Every unattended session defaults to ReadOnly through a role allowlist, and a request for Admin privileges returns an error."/"\"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.\""(What we got wrong section)
View official source →

Cost: 250 investigations a month for nine top-tier subscriptions

Kiro reports that a representative month produced about 250 investigations, all completed unattended, with a median time of 13.6 minutes. Kiro meters the agent in credits, the same unit its customers buy.

Kiro says spending is kept in check by session timeouts, stuck detection, a cap on concurrent sessions and inexpensive models for fan-out work. The monthly bill comes to the equivalent of nine of Kiro's own top-tier subscriptions. The hours the agent frees up go to reviewing briefs, correcting the agent and fixing root causes.

"a representative month produced about 250 investigations, completed unattended at a median of 13.6 minutes."/"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."(What it costs section)
View official source →

What went wrong: a lesson-capture pipeline and a stale reference doc

Kiro publishes a failure of its own: the pipeline that saves lessons once accepted whatever text was pending when a session ended. Sessions that were interrupted wrote raw ticket comments into the corrections store, and later sessions treated those comments as operational wisdom.

The fix was schema validation before writing, plus a nightly prune. Kiro's conclusion is that a learning pipeline piles up garbage as efficiently as knowledge unless someone curates it.

A second problem came from documentation. One stale line in a reference doc spread into several tickets before a human noticed. Kiro states that agents inherit a document's bugs at machine speed, and its fix was a habit: when a session goes wrong, correct it, ask what misled it and repair that document.

The last lesson is that confident half-answers cost more than wrong ones. Kiro says one steering rule did more than any model upgrade: the agent has to test and rule out competing hypotheses before it states a conclusion.

"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."/"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."/"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."(The flywheel and What we got wrong sections)
View official source →

FAQ

How fast did the agent produce a diagnosis?
The alarm fired at 2:33 AM PDT on a Sunday. A diagnosis was on the ticket by 2:46 AM PDT, 13 minutes and 35 seconds later, with competing hypotheses ruled out and a next action recommended.
Did the team build a custom agent platform?
No. Kiro says the setup is the same Kiro CLI it ships to customers, configured with markdown operating rules, MCP servers and skill playbooks. It uses no orchestration framework and no fine-tuned model.
What is the agent still not allowed to do?
It may not resolve a ticket or change severity; Kiro leaves both to humans. Unattended sessions default to ReadOnly through a role allowlist, and a request for Admin privileges returns an error.