Circle K's triage agent cuts incident response to under 15 minutes

AWS published a customer story on 2 November 2026, co-written with Marek Klatowicz, a Cloud DevOps Engineer at Circle K, describing an agent that investigates production alerts and posts a summary to Slack. Circle K runs more than 17,200 convenience and fuel stores in 27 countries. The post says mean triage time fell from 45–60 minutes to under 15 minutes, a 67–75 percent reduction based on the team's internal incident-response metrics. It is vendor-published and the figures are not independently checked.

How the first version worked

A Grafana alert goes to Amazon SNS, then an SQS queue, and a Lambda function starts the workflow. According to the post, two agents run in parallel: one checks ECS task status, load balancer health and CloudWatch across several AWS accounts, and one queries OpenSearch for application logs and traces. The OpenSearch agent is kept separate because it returns large volumes of data, which would crowd the other agent's context window.

A third agent then searches the affected service's GitHub repositories, infrastructure definitions and recent commits. It runs last so it knows what to look for. A final model call with no tools turns all three outputs into a structured summary: probable root cause, evidence, owner and next steps. The post says the whole run takes 5–15 minutes.

Why it moved to AgentCore

The post says the Flows version worked for months and handled simple incidents in under 10 minutes. Then log volumes and the knowledge base grew, and some investigations needed longer than one Flow node allowed. Filtering logs harder, shortening context and splitting services into separate Flows helped only for a while.

In April 2026 the team merged the three agents into one containerised agent on Amazon Bedrock AgentCore Runtime, which the post says supports sessions of up to 8 hours. AgentCore Gateway exposes OpenSearch, the knowledge base and GitHub as tools. The post credits session state, OpenTelemetry traces in CloudWatch and framework flexibility. It reports 5–8 minutes for straightforward incidents and under 15 for complex multi-service ones.

The four lessons the team lists

• Put log content in the prompt. Early versions gave only log group names and let the agent query CloudWatch, which added latency and returned too much; pre-querying in Lambda worked better.
• Use the default knowledge-base configuration. After testing the options, the team found it worked best for their data.
• Narrow the code search with log findings, because a search with no lead returns too many results.
• Keep prompts, tool definitions and analysis steps separate from the orchestration layer, so the move to AgentCore needed no rewrite of the triage logic.

What it leaves out

The post does not give the model used, the monthly cost, how often the root cause was wrong, or how triage time was measured before and after. It does not say how many incidents the system has handled. The worked example, a connection pool exhausted by a marketing campaign, is illustrative.

The control is worth noting. Today the agent recommends and an engineer acts. The team plans to add simple remediations, such as restarting a task, scaling a service or rolling back a deployment, with an engineer approving each action in Slack before it runs. It also plans to add Jira, Confluence and runbooks as context.