Circle K verkuerzt DevOps-Incident-Triage auf unter 15 Minuten mit Amazon Bedrock
Der DevOps-Konzern Circle K hat mit einem agentischen Triage-System auf Basis von Amazon Bedrock die Incident-Analyse von 45 bis 60 Minuten auf unter 15 Minuten reduziert. Der Beitrag beleuchtet Architektur, Migration zu Bedrock AgentCore und Skalierungserfahrungen.
Dieser Beitrag wurde gemeinsam mit Marek Klatowicz, Cloud DevOps Engineer bei Circle K, verfasst.
Viele DevOps-Teams kennen das Muster der Incident-Triage: Ein Alarm wird ausgelöst, und bevor jemand das Problem beheben kann, verbringt ein Engineer 45 bis 60 Minuten damit herauszufinden, was passiert ist. Er sichtet Logs, prüft den Zustand der Dienste und korreliert Symptome über mehrere Tools hinweg. All das geschieht, bevor mit der Behebung begonnen werden kann.
Bei Circle K skalierte diese Herausforderung mit dem Geschäft. Das Unternehmen betreibt mehr als 17.200 Convenience- und Tankstellengeschäfte in 27 Ländern. Hinter den Geschäften unterstützt eine Cloud-native Infrastruktur Kassensysteme, Loyalty-Anwendungen und Ladestationen für Elektrofahrzeuge (EV), die auf AWS laufen. Als das Unternehmen seine digitalen Operationen ausbaute, wuchs auch der Triage-Aufwand mit. Mehr Dienste bedeuteten mehr Alarme, und jeder einzelne erforderte dieselbe manuelle Untersuchung, bevor mit der Behebung begonnen werden konnte.
Um das zu lösen, baute Circle K ein automatisiertes Triage-System auf Grundlage von Amazon Bedrock, einem vollständig verwalteten Dienst, der Foundation Models (FMs) über eine einzige API bereitstellt. Zur Modellverfügbarkeit nach AWS-Region siehe Supported models by AWS Region in Amazon Bedrock. Das System nutzt eine agentenbasierte KI-Architektur, um jeden Incident autonom zu untersuchen und innerhalb weniger Minuten nach Auslösung eines Alarms eine strukturierte Zusammenfassung an Slack zu liefern. Statt roher Alarme erhalten die Bereitschafts-Engineers nun kontextbezogene, umsetzbare Informationen, sodass sie sofort handeln können, statt eine Stunde damit zu verbringen herauszufinden, was passiert ist.
Seit der Einführung dieses Systems hat Circle K die mittlere Triage-Zeit auf unter 15 Minuten gesenkt, was basierend auf den internen Incident-Response-Kennzahlen des Teams einer Reduzierung um 67 bis 75 Prozent entspricht.
In diesem Beitrag beschreiben wir die Architektur sowohl der ersten Implementierung mit Amazon Bedrock Flows als auch der Migration zu Amazon Bedrock AgentCore und teilen die Lessons Learned aus dem Skalieren des Systems.
Das DevOps-Team von Circle K überwacht die Infrastruktur über mehrere AWS-Konten hinweg mit Grafana. Ein typischer Tag bringt Alarme zu Container-Neustarts, erhöhten Fehlerquoten, Latenzspitzen und fehlgeschlagenen Deployments. Jeder Alarm ist ein nützliches Signal, aber als das System wuchs, wollte das Team den Bereitschafts-Engineers helfen, schnell zu erkennen, welche Signale mit dem richtigen Kontext Aufmerksamkeit erfordern.
Wenn ein Alarm einging, umfasste die Triage eine vertraute Abfolge manueller Schritte: Prüfung aktueller Logs in Amazon CloudWatch, Untersuchung der Traces auf Anwendungsebene in Amazon OpenSearch Service, Kontrolle des Status von Amazon Elastic Container Service (Amazon ECS)-Tasks und Abgleich der Symptome mit internen Runbooks in GitHub. Das gab den Engineers die benötigten Informationen, zeigte aber auch, wie viel repetitive Kontextsammlung nötig wäre, je mehr Dienste integriert wurden.
Das Team erkannte zwei Bereiche, in denen eine proaktive Investition helfen könnte. Erstens würden dieselben Log-Abfragen, Health-Checks und Runbook-Suchvorgänge für jeden Incident wiederholt. Zweitens könnten Tiefe und Geschwindigkeit der Triage von der Vertrautheit des Bereitschafts-Engineers mit dem betroffenen Dienst abhängen. Mit wachsendem Alarmaufkommen und zunehmender Dienstverantwortung könnte der Wechsel zwischen mehreren Tools bei jeder Untersuchung die Reaktion verlangsamen und es erschweren, die Best Practices des Teams konsistent anzuwenden.
Das DevOps-Team von Circle K startete daher eine Forschungs- und Entwicklungsinitiative (R&D), um zu erkunden, wie KI Monitoring und Incident-Triage unterstützen könnte. Ziel war es, die repetitive Kontextsammlung zu automatisieren und strukturierte, umsetzbare Erkenntnisse zu liefern und gleichzeitig das operative Urteilsvermögen der Engineers während einer Untersuchung zu unterstützen.
Das Team evaluierte vor dem Bau mehrere Ansätze, darunter Open-Source-Agentenframeworks auf selbstverwalteter Infrastruktur. Dieser Ansatz hätte bedeutet, selbst Model-Hosting, Prompt-Versionierung, Tool-Orchestrierung und Sicherheitskontrollen zu betreiben.
Mit Amazon Bedrock vermied das Team diesen Aufwand. Es konnte über eine einzige API auf Foundation Models zugreifen und Foundation Models austauschen, ohne Code umzuschreiben. Da Circle K bereits auf AWS lief, fügte sich Amazon Bedrock in bestehende AWS Identity and Access Management (IAM)-Richtlinien, Amazon Virtual Private Cloud (Amazon VPC)-Konfigurationen und Logging-Pipelines ein.
Zwei verwaltete Fähigkeiten deckten Orchestrierung und Retrieval ab. Amazon Bedrock half bei der Agenten-Orchestrierung, indem es den Agenten natives Tool Use gab, um AWS-APIs aufzurufen, Datenbanken abzufragen und Dokumente abzurufen, ohne eigenen Orchestrierungscode. Amazon Bedrock Knowledge Bases, die vollständig verwaltete Retrieval-Augmented-Generation (RAG)-Fähigkeit, übernahm Ingestion und Retrieval interner Produktkarten, sodass das Team keine separate Vektordatenbank betreiben musste. Das erlaubte dem DevOps-Team, sich auf Prompt-Design und Tool-Definitionen zu konzentrieren.
Datenschutz vervollständigte das Gesamtbild. Die Incident-Daten von Circle K umfassen betriebliche Metriken, Infrastrukturdetails und Logs, die sensible Informationen enthalten können. Amazon Bedrock teilt Kundendaten nicht mit Modellanbietern und nutzt sie nicht zum Training von Foundation Models. Für ein Team, das Produktions-Logs und interne Dienstdetails in das System einspeist, erfüllte dieser Datenverarbeitungsansatz die Sicherheitsanforderungen von Circle K.
Dieser Abschnitt beschreibt die ursprüngliche Architektur, die das Team auf Amazon Bedrock Flows aufbaute. Ein späterer Abschnitt behandelt die Migration zu AgentCore.
Die Lösung nutzt Amazon Bedrock Flows als Orchestrierungsschicht, die eine Gruppe spezialisierter Agenten koordiniert, von denen jeder einen anderen Teil der Analyse übernimmt. Die Pipeline startet, wenn ein Grafana-Alarm eine Benachrichtigung an Amazon Simple Notification Service (Amazon SNS) veröffentlicht, die diese an eine Amazon Simple Queue Service (Amazon SQS)-Warteschlange weiterleitet. Eine AWS-Lambda-Funktion fragt die Warteschlange ab, extrahiert die Alarmdaten und ruft den Flow auf.
Innerhalb des Flows werden zwei Agenten parallel aufgerufen. Der AWSResourceExplorerAgent fragt die Infrastruktur über mehrere Workload-Konten hinweg ab, die mit AWS Organizations verwaltet werden. Er prüft den Status von Amazon ECS-Tasks, den Zustand der Application Load Balancer-Targets sowie CloudWatch-Metriken und -Logs. Gleichzeitig fragt der OpenSearchExplorerAgent Amazon OpenSearch Service nach Logs auf Anwendungsebene und verteilten Traces ab. Dieser Agent läuft separat, weil OpenSearch große Mengen an Logdaten zurückgibt. Die Isolierung hält das Kontextfenster jedes Agenten beherrschbar. Er hat zudem exklusiven Zugriff auf die Knowledge Base, die Produktkarten mit der Beschreibung jedes Dienstes und seiner Abhängigkeiten enthält.
Nachdem beide Agenten ihre Erkenntnisse zurückgegeben haben, läuft der GitHubExplorerAgent. Er erhält die Ausgaben der beiden vorherigen Agenten und findet die GitHub-Repositories des betroffenen Dienstes. Anschließend durchsucht er deren Anwendungscode, Infrastrukturdefinitionen und letzte Commits, um die Ursache des Problems einzugrenzen und einen konkreten Fix vorzuschlagen. Dass er nach den parallelen Agenten läuft, bedeutet, dass er genau weiß, wonach er suchen muss, statt eine breite Abfrage durchzuführen.
Alle drei Ausgaben fließen in einen AnalysisPrompt-Knoten, ein einzelner Modellaufruf ohne zugeordnete Tools. Er erhält die AWS-Ressourcendaten, die OpenSearch-Logs und den GitHub-Kontext und erzeugt dann eine strukturierte Zusammenfassung: wahrscheinliche Ursache, stützende Nachweise, betroffener Dienst und Owner sowie empfohlene Maßnahmen zur Behebung. Die Prompt-Ausgabe verwendet ein einheitliches Format, das das Bereitschaftsteam in unter 2 Minuten erfassen kann.
Der Flow gibt diese Zusammenfassung an die aufrufende Lambda-Funktion zurück, die sie in einen Slack-Kanal postet. Der gesamte Prozess von Alarm bis Slack-Nachricht dauert je nach Komplexität des Incidents 5 bis 15 Minuten.
Das folgende Diagramm zeigt diese Architektur vollständig, vom ersten Grafana-Alarm bis zur finalen Slack-Zusammenfassung.
Abbildung 1: Architektur der automatisierten Incident-Triage von Circle K mit Amazon Bedrock Flows
Ein Grafana-Alarm: Die HTTP-5xx-Fehlerquote eines Dienstes überschreitet 5 Prozent für 3 aufeinanderfolgende Minuten.
Der AWSResourceExplorerAgent prüft den Zustand der ECS-Tasks im Zielkonto und stellt fest, dass der Datenbank-Verbindungspool erschöpft ist und der ECS-Service Neustarts versucht. Der OpenSearchExplorerAgent gibt Anwendungslogs zurück, die Fehler vom Typ connection refused vom Dienst zu seiner zugrunde liegenden PostgreSQL-Datenbank zeigen. Er ruft außerdem die Produktkarte des betroffenen Dienstes aus der Knowledge Base ab, die seine Abhängigkeit von dieser Datenbank dokumentiert. Der GitHubExplorerAgent durchsucht das Repository und die Infrastrukturdateien des Dienstes und findet die Definition des Amazon Relational Database Service (Amazon RDS). Er erkennt, dass der Dienst pro Anfrage eine neue Datenbankverbindung öffnet, statt bestehende wiederzuverwenden.
Der AnalysisPrompt empfängt alle drei Ergebnisse. Er korreliert den Zeitpunkt mit einer geplanten Marketing-Kampagne, die 10 Minuten vor dem Alarm startete. Er kombiniert das mit dem Befund des GitHubExplorerAgent und empfiehlt einen konkreten Fix auf Code-Ebene statt eines temporären Patches.
Zusammenfassung: 5xx-Fehler des XYZ Service durch Erschöpfung des Connection Pools. Ursache: Eine geplante Marketing-Kampagne sorgte für einen Traffic-Spitzenwert; das Maximum des Connection Pools (50) war für diese Last nicht ausreichend. Nachweise: OpenSearch-Logs zeigen um 14:32 UTC "connection refused"; ECS verzeichnet seit 14:30 drei Task-Neustarts.
Verantwortlich: XYZ-Team (Backend). Nächste Schritte: Amazon RDS Proxy zum Pooling der Verbindungen hinzufügen oder den Service so aktualisieren, dass er bestehende Verbindungen wiederverwendet, statt für jede Anfrage eine neue zu öffnen; für künftige Kampagnen eine Auto-Scaling-Regel in Erwägung ziehen. Skalierung auf Amazon Bedrock AgentCore: Die Amazon Bedrock Flows-Architektur funktionierte über Monate hinweg gut, und einfache Störungen wurden in unter 10 Minuten triagiert.
Im Laufe der Zeit wuchsen jedoch das Datenvolumen und der Kontext jeder Untersuchung, auch wenn die Menge der Services gleich blieb. Manche Störungen erforderten längere laufende Analysen, als ein einzelner Flow-Knoten abschließen konnte.
Das Team optimierte zunächst innerhalb des bestehenden Designs, indem es Logs aggressiver filterte, Kontextfenster verkürzte und bestimmte Services in separate Flows aufteilte. Diese Schritte halfen, aber die Log-Mengen und die Wissensdatenbank wuchsen weiter.
Amazon Bedrock AgentCore erfüllte diesen Bedarf. AgentCore ist eine Plattform, um KI-Agents mit jedem Framework oder Modell im großen Maßstab zu erstellen, zu verbinden und zu optimieren. Für diese Workload war die entscheidende Funktion AgentCore Runtime: Die vollständige Untersuchung läuft in einer einzigen Session, sodass jeder Schritt die Zeit nehmen kann, die seine Daten erfordern. AgentCore Runtime unterstützt Sessions von bis zu 8 Stunden, was weit über dem liegt, was die aktuellen Untersuchungen benötigen. Das Team containerisierte seine Agent-Logik und stellte sie auf AgentCore Runtime bereit.
Das folgende Diagramm zeigt die Produktionsarchitektur nach dem Wechsel zu Amazon Bedrock AgentCore.
Abbildung 2: Produktionsarchitektur mit Amazon Bedrock AgentCore Runtime und AgentCore Gateway
Die Analyse-Logik bleibt gleich, aber die Art ihrer Ausführung hat sich geändert. Die drei spezialisierten Agents aus der Flows-Version sind nun in einem einzigen Agent konsolidiert, der in einer AgentCore-Runtime-Session läuft. Die Lambda-Funktion startet die Session, und der Agent führt dieselben Schritte wie zuvor aus. Er fragt AWS-Ressourcen über mehrere Konten hinweg ab, ruft Logs aus Amazon OpenSearch Service ab, durchsucht GitHub und holt Produktkarten aus der Wissensdatenbank. Der Agent liefert seine Ergebnisse innerhalb von 15 Minuten an die Lambda-Funktion zurück, was innerhalb des maximalen Lambda-Timeouts liegt. Die Lambda-Funktion veröffentlicht anschließend die strukturierte Zusammenfassung in Slack.
Amazon Bedrock AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, vermittelt den Zugriff des Agents auf seine Datenquellen, darunter Amazon OpenSearch Service, Amazon Bedrock Knowledge Bases und GitHub. Das Gateway stellt jede Quelle als Tool bereit, das der Agent aufruft, was die Zugriffskontrolle zentralisiert und es dem Team erleichtert, Datenquellen hinzuzufügen oder zu ändern.
Über die längeren laufenden Sessions hinaus brachte Amazon Bedrock AgentCore Runtime drei Funktionen mit, die das wachsende Maßstab des Teams unterstützten: Session-Persistenz, auf OpenTelemetry basierende Observability und Framework-Flexibilität.
Session-Persistenz: Der Agent behält während einer Untersuchung einen Zwischenstand bei. Wenn ein erster Durchlauf über die Logs etwas zutage fördert, kann der Agent einen zweiten, gezielteren Durchlauf starten, ohne den bereits aufgebauten Kontext zu verlieren. Das passt zu der iterativen Art, wie komplexe Multi-Service-Störungen untersucht werden.
Observability: AgentCore erfasst Traces aus jeder Session nach OpenTelemetry-Standards und stellt sie über CloudWatch bereit. Das Team kann nachvollziehen, wie lange jeder Schritt dauert, welche Anfragen der Agent an die Wissensdatenbank stellt und wo Engpässe auftreten. Diese Erkenntnisse fließen direkt in das Prompt-Tuning ein.
Framework-Flexibilität: Mit AgentCore Runtime kann das Team containerisierte Agents bereitstellen, die mit einer breiten Palette von Frameworks gebaut wurden. Es kann die Agent-Logik iterieren, Triage-Schritte hinzufügen oder das Reasoning des Agents umstrukturieren, wenn sich die Anforderungen ändern, und das alles auf derselben Runtime.
Die AgentCore-Architektur läuft inzwischen in Produktion und verarbeitet das gesamte Spektrum an Störungen, von einfachen Single-Service-Warnungen bis hin zu großen Multi-Service-Untersuchungen.
Circle K stellte die AgentCore-Version des Triage-Systems im April 2026 bereit. Basierend auf den internen Incident-Response-Kennzahlen des Teams sank die durchschnittliche Triage-Zeit von 45 bis 60 Minuten auf unter 15 Minuten, was einer Reduktion von 67 bis 75 Prozent entspricht. Unkomplizierte Störungen erhalten in 5 bis 8 Minuten eine Zusammenfassung. Komplexe Multi-Service-Störungen, die zuvor manuell mehr als eine Stunde Triage benötigten, sind jetzt in unter 15 Minuten abgeschlossen.
Ingenieure starten heute mit einer Zusammenfassung, statt den Kontext selbst zusammenzutragen. Das Team beobachtet drei Veränderungen im Umgang mit Störungen:
Konsistente Triage. Jeder Bereitschaftsingenieur erhält dieselbe strukturierte Zusammenfassung, mit denselben Log-Auszügen, Referenzen auf die Wissensdatenbank und empfohlenen nächsten Schritten, unabhängig davon, wie gut er den betroffenen Service kennt.
Schnellere Eskalation. Wenn ein Problem die Unterstützung eines anderen Teams erfordert, liefert die Zusammenfassung dem Bereitschaftsingenieur den relevanten Kontext für eine zeitnahe, fundierte Eskalation.
Schnellere Behandlung von Fehlalarmen. Wenn die Analyse gesunde Services und keine korrelierten Fehler findet, kann der Ingenieur die Warnung bestätigen und weitermachen.
Der Aufbau dieses Systems erforderte mehrere Iterationen. Vier Erkenntnisse stechen hervor, die für Teams gelten, die eine ähnliche Lösung mit Amazon Bedrock bauen.
Log-Inhalte direkt in den Prompt einbinden. Frühe Versionen übergaben nur Log-Gruppennamen und Zeiträume, woraufhin der Agent versuchte, CloudWatch über Action Groups abzufragen. Das erhöhte die Latenz und lieferte oft zu viele Daten zur Verarbeitung. Circle K erzielte bessere Ergebnisse, indem Lambda-Funktionen die Logs vorab abfragen und die relevanten Zeilen direkt an den Agent übergeben. Der Agent kann schneller schlussfolgern, wenn er die tatsächlichen Fehlermeldungen lesen kann.
Retrieval und Generierung auf die Anwendungsfälle abstimmen. Die Retrieval-Konfiguration beeinflusste die Ergebnisqualität der Wissensdatenbank erheblich. Nach Tests der verfügbaren Optionen stellte das Circle-K-Team fest, dass eine Amazon Bedrock Knowledge Base mit ihrer Standardkonfiguration für ihre Daten am besten funktionierte. Amazon Bedrock übernimmt Embeddings, Indizierung und Vektor-Speicherung vollständig, sodass das Team weniger Komponenten zu warten hat. Auf der Generierungsseite sorgten ein gut gestalteter System-Prompt und ein abgestimmter Temperature-Wert für konsistente Zusammenfassungen in Slack.
Die Codesuche mit Erkenntnissen aus den Logs eingrenzen. Eine Suche nach den Repositories des Service ohne Anhaltspunkt liefert zu viele Ergebnisse, um nützlich zu sein. Das Team führt die GitHub-Suche nach der Analyse der AWS-Ressourcen und Logs aus, sodass der Agent bereits weiß, nach welchem Fehler, welcher Komponente oder welcher kürzlichen Änderung er suchen soll. In der Beispiel-Triage fand der Agent auf diese Weise heraus, dass der Service für jede Anfrage eine neue Datenbankverbindung öffnete.
Die Analyse-Logik unabhängig von der Orchestrierungsschicht halten. Die Analysezeit wächst mit dem Datenvolumen, daher sollte man einplanen, dass Untersuchungen im Laufe der Zeit länger dauern. Das Team hielt seine Prompts, Tool-Definitionen und Analyseschritte getrennt von der Flow-Struktur. Das machte es möglich, sie in einen einzigen Agent auf AgentCore Runtime zu konsolidieren, ohne die Triage-Logik neu zu schreiben.
Heute findet das Triage-System die wahrscheinliche Ursache und empfiehlt eine Lösung, und ein Ingenieur setzt die Lösung um. Als Nächstes plant das Team die Integration mit AWS DevOps Agent, damit das System auch einfache Remediations übernehmen kann. Beispiele sind der Neustart eines Tasks, das Hochskalieren eines Service oder das Zurückrollen eines Deployments. Ein Ingenieur genehmigt jede Aktion in Slack, bevor sie ausgeführt wird.
Das Team plant außerdem, dem Agent mehr Kontext zur Verfügung zu stellen:
Das Circle-K-Team ging von 45 bis 60 Minuten manueller Störungs-Triage zu unter 15 Minuten über, indem es das Zusammentragen des Kontexts automatisierte, das Ingenieure früher von Hand erledigten. Das System sammelt Daten aus Logs, AWS-Ressourcen und Code, lässt einen Agent darüber schlussfolgern und liefert eine strukturierte Zusammenfassung nach Slack.
Das Team baute die erste Version auf Amazon Bedrock Flows und Amazon Bedrock Knowledge Bases. Als die Untersuchungen größer wurden, wechselte das Team zu einem einzelnen Agent auf Amazon Bedrock AgentCore Runtime, wobei AgentCore Gateway den Zugriff auf seine Datenquellen bereitstellt.
Wenn Ihr Team den größten Teil seiner Incident-Response-Zeit damit verbringt, Kontext zusammenzutragen, statt Probleme zu beheben, lässt sich dieses Muster direkt übertragen. Für den Einstieg erkunden Sie Amazon Bedrock AgentCore und Amazon Bedrock Knowledge Bases. Für praktische Anleitung oder um Ihren Anwendungsfall mit einem AWS-Spezialisten zu besprechen, besuchen Sie die Amazon-Bedrock-Einstiegsseite oder kontaktieren Sie AWS.
Wir möchten erfahren, wie Sie Störungs-Triage angehen. Teilen Sie Ihre Erfahrung in den Kommentaren.
Marek ist Cloud DevOps Engineer bei Circle K, wo er mit AWS Cloud-Services für Enterprise-Endkunden entwirft und verbessert. In letzter Zeit verbringt er viel Zeit mit KI und baut Lösungen, die echten Geschäftswert liefern. Er glaubt an einfache Lösungen, die einfach funktionieren.
Sefat ist Solutions Architect bei Amazon Web Services, wo sie Enterprise-Kunden dabei unterstützt, KI-gestützte operative Tooling-Lösungen auf AWS aufzubauen. Sie spezialisiert sich auf generative KI-Anwendungen, Agent-Architekturen und DevOps-Automation. Außerhalb der Arbeit experimentiert sie gerne mit Kochen, Musik und Heimautomatisierungsprojekten.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
This post was co-written with Marek Klatowicz, Cloud DevOps Engineer at Circle K.
Many DevOps teams know the incident triage pattern: An alert fires, and before anyone can fix the problem, an engineer spends 45–60 minutes figuring out what happened. They pull logs, check service health, and correlate symptoms across a handful of tools. All of this happens before remediation can begin.
At Circle K, this challenge scaled with the business. The company operates more than 17,200 convenience and fuel retail stores across 27 countries. Behind the storefronts, a cloud-native infrastructure supports point-of-sale systems, loyalty applications, and electric vehicle (EV) charging applications running on AWS. As the company expanded its digital operations, the triage overhead grew with it. More services meant more alerts, and each one required the same manual investigation before remediation could begin.
To address it, Circle K built an automated triage system using Amazon Bedrock, a fully managed service that makes foundation models (FMs) available through a single API. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock. The system uses an agentic AI architecture to investigate each incident autonomously and deliver a structured summary to Slack within minutes of an alert firing. Instead of raw alerts, on-call engineers now receive actionable context, so they can act immediately rather than spending an hour figuring out what happened.
Since deploying this system, Circle K has reduced mean triage time to under 15 minutes, a 67–75 percent reduction based on the team’s internal incident-response metrics.
In this post, we describe the architecture for both the initial Amazon Bedrock Flows implementation and the migration to Amazon Bedrock AgentCore, and share lessons learned from scaling the system.
Circle K’s DevOps team monitors infrastructure across multiple AWS accounts using Grafana. A typical day brings alerts for container restarts, elevated error rates, latency spikes, and failed deployments. Each alert is a useful signal, but as the system expanded, the team wanted to help on-call engineers quickly see which signals needed attention, with the right context.
When an alert came in, the triage involved a familiar sequence of manual steps: reviewing recent logs in Amazon CloudWatch, examining application-level traces in Amazon OpenSearch Service, checking Amazon Elastic Container Service (Amazon ECS) task status, and cross-referencing symptoms with internal runbooks in GitHub. This gave engineers the information they needed, but it also showed how much repetitive context gathering would be required as more services were onboarded.
The team recognized two areas where a proactive investment could help. First, the same log queries, health checks, and runbook lookups would be repeated for every incident. Second, the depth and speed of triage could vary with the on-call engineer’s familiarity with the affected service. As alert volume and service ownership grew, switching between multiple tools for each investigation could slow response and make it harder to apply the team’s best practices consistently.
Circle K’s DevOps team therefore started a research and development (R&D) initiative to explore how AI could support monitoring and incident triage. The goal was to automate repetitive context gathering and provide structured, actionable findings, while supporting engineers’ operational judgment during an investigation.
The team evaluated several approaches before building, including open source agent frameworks on self-managed infrastructure. That approach would have meant owning model hosting, prompt versioning, tool orchestration, and security controls.
With Amazon Bedrock, the team avoided that overhead. They could access foundation models through a single API and swap foundation models without rewriting code. Because Circle K already ran on AWS, Amazon Bedrock fit into existing AWS Identity and Access Management (IAM) policies, Amazon Virtual Private Cloud (Amazon VPC) configurations, and logging pipelines.
Two managed capabilities covered orchestration and retrieval. Amazon Bedrock helped with agent orchestration, giving the agents native tool use to call AWS APIs, query databases, and retrieve documents without custom orchestration code. Amazon Bedrock Knowledge Bases, the fully managed Retrieval Augmented Generation (RAG) capability, handled ingestion and retrieval of internal product cards, so the team did not need to run a separate vector database. This let the DevOps team focus on prompt design and tool definitions.
Data privacy completed the picture. Circle K’s incident data includes operational metrics, infrastructure details, and logs that can contain sensitive information. Amazon Bedrock does not share customer data with model providers or use it to train foundation models. For a team feeding production logs and internal service details into the system, this data handling approach met Circle K’s security requirements.
This section describes the initial architecture, which the team built on Amazon Bedrock Flows. A later section covers the migration to AgentCore.
The solution uses Amazon Bedrock Flows as the orchestration layer, coordinating a set of specialized agents that each handle a different part of the analysis. The pipeline starts when a Grafana alert publishes a notification to Amazon Simple Notification Service (Amazon SNS), which forwards it to an Amazon Simple Queue Service (Amazon SQS) queue. An AWS Lambda function polls the queue, extracts the alert payload, and invokes the Flow.
Inside the Flow, two agents are invoked in parallel. The AWSResourceExplorerAgent queries infrastructure across multiple workload accounts managed with AWS Organizations. It checks Amazon ECS task status, Application Load Balancer target health, and CloudWatch metrics and logs. At the same time, the OpenSearchExplorerAgent queries Amazon OpenSearch Service for application-level logs and distributed traces. This agent runs separately because OpenSearch returns large volumes of log data. Isolating it keeps each agent’s context window manageable. It also has exclusive access to the knowledge base, which contains product cards describing each service and its dependencies.
After both agents return their findings, the GitHubExplorerAgent runs. It receives output from the previous two agents and finds the affected service’s GitHub repositories. Then it searches their application code, infrastructure definitions, and recent commits to pinpoint the source of the problem and propose a concrete fix. Running it after the parallel agents means it knows exactly what to search for rather than performing a broad query.
All three outputs feed into an AnalysisPrompt node, which is a single model call with no tools attached. It receives the AWS resource data, the OpenSearch logs, and the GitHub context, then produces a structured summary: probable root cause, supporting evidence, affected service and owner, and recommended remediation steps. The prompt output uses a consistent format that the on-call team can scan in under 2 minutes.
The Flow returns this summary to the invoking Lambda function, which posts it to a Slack channel. The entire process from alert to Slack message takes 5–15 minutes depending on incident complexity.
The following diagram shows this architecture end to end, from the initial Grafana alert to the final Slack summary.
Figure 1: Circle K automated incident triage architecture using Amazon Bedrock Flows
A Grafana alert: HTTP 5xx error rate on a service exceeds 5% for 3 consecutive minutes.
The AWSResourceExplorerAgent checks ECS task health in the target account and finds the database connection pool exhausted, with the ECS service attempting restarts. The OpenSearchExplorerAgent returns application logs showing “connection refused” errors from the service to its backing PostgreSQL database. It also retrieves the product card for the affected service from the knowledge base, which documents its dependency on that database. The GitHubExplorerAgent searches the service’s repository and infrastructure files and finds the Amazon Relational Database Service (Amazon RDS) definition. It sees that the service opens a new database connection per request rather than reusing existing ones.
The AnalysisPrompt receives all three results. It correlates the timing with a scheduled marketing campaign that started 10 minutes before the alert. It combines that with the GitHubExplorerAgent’s finding to recommend a concrete code-level fix rather than a temporary patch.
Summary: XYZ Service 5xx errors caused by connection pool exhaustion Root cause: Scheduled marketing campaign drove traffic spike; connection pool max (50) insufficient for load Evidence: OpenSearch logs show "connection refused" at 14:32 UTC; ECS shows 3 task restarts since 14:30 Owner: XYZ team (backend) Next steps: Add Amazon RDS Proxy to pool connections, or update the service to reuse existing connections instead of opening a new one per request; consider an Auto Scaling rule for future campaigns Scaling to Amazon Bedrock AgentCore The Amazon Bedrock Flows architecture worked well for months, and simple incidents were triaged in under 10 minutes. Over time, the volume of data and the context behind each investigation grew, even though the set of services stayed the same. Some incidents required longer-running analysis than a single Flow node could complete.
The team first optimized within the existing design by filtering logs more aggressively, shortening context windows, and splitting certain services into separate Flows. These steps helped, but log volumes and the knowledge base kept growing.
Amazon Bedrock AgentCore met this need. AgentCore is a platform to build, connect, and optimize AI agents at scale with any framework or model. For this workload, the key capability was AgentCore Runtime: The full investigation runs in a single session, so each step can take the time its data requires. AgentCore Runtime supports sessions of up to 8 hours, well beyond what the current investigations need. The team containerized their agent logic and deployed it on AgentCore Runtime.
The following diagram shows the production architecture after the move to Amazon Bedrock AgentCore.
Figure 2: Production architecture using Amazon Bedrock AgentCore Runtime and AgentCore Gateway
The analysis logic stays the same, but the way it runs has changed. The three specialized agents from the Flows version are now consolidated into a single agent running in an AgentCore Runtime session. The Lambda function starts the session, and the agent performs the same steps as before. It queries AWS resources across accounts, pulls logs from Amazon OpenSearch Service, searches GitHub, and retrieves product cards from the knowledge base. The agent returns its findings to the Lambda function within 15 minutes, which is within the maximum Lambda timeout. The Lambda function then posts the structured summary to Slack.
Amazon Bedrock AgentCore Gateway, a capability of Amazon Bedrock AgentCore, brokers the agent’s access to its data sources, including Amazon OpenSearch Service, Amazon Bedrock Knowledge Bases, and GitHub. The Gateway exposes each source as a tool the agent invokes, which centralizes access control and makes it simpler for the team to add or change data sources.
Beyond longer-running sessions, Amazon Bedrock AgentCore Runtime added three capabilities that supported the team’s growing scale: session persistence, OpenTelemetry-based observability, and framework flexibility.
Session persistence: The agent keeps an intermediate state throughout an investigation. If a first pass over the logs surfaces something, the agent can run a second, more targeted pass without losing the context it has already built. This fits the iterative way that complex, multi-service incidents are investigated.
Observability: AgentCore captures traces from each session using OpenTelemetry standards and surfaces through CloudWatch. The team can see how long each step takes, which knowledge base queries the agent makes, and where bottlenecks occur. These insights feed directly into prompt tuning.
Framework flexibility: With AgentCore Runtime, the team can deploy containerized agents built with a wide range of frameworks. They can iterate agent logic, add triage steps, or restructure the agent’s reasoning as their requirements change, all on the same Runtime.
The AgentCore architecture now runs in production and handles the full range of incidents, from simple single-service alerts to large multi-service investigations.
Circle K deployed the AgentCore version of the triage system in April 2026. Based on the team’s internal incident-response metrics, mean triage time dropped from 45–60 minutes to under 15 minutes, a 67–75 percent reduction. Straightforward incidents receive a summary in 5–8 minutes. Complex multi-service incidents, which previously took more than an hour to triage manually, now complete within 15 minutes.
Engineers now start from a summary instead of gathering context themselves. The team sees three changes in how incidents are handled:
Consistent triage. Every on-call engineer receives the same structured summary, with the same log excerpts, knowledge base references, and recommended next steps, regardless of how well they know the affected service.
Faster escalation. When an issue requires support from another team, the summary gives the on-call engineer the relevant context for a timely, informed escalation.
Quicker handling of false alarms. When the analysis finds healthy services and no correlated errors, the engineer can acknowledge the alert and move on.
Building this system took several iterations. Four lessons stood out that apply to teams building a similar solution with Amazon Bedrock.
Include log content directly in the prompt. Early versions passed only log group names and time ranges, then the agent attempted to query CloudWatch through action groups. This added latency and often returned too much data to process. Circle K got better results by having Lambda functions pre-query the logs and pass relevant lines directly to the agent. The agent reasons faster when it can read the actual error messages.
Tune retrieval and generation for use cases. Retrieval configuration significantly affected result quality from the knowledge base. After testing the available options, the Circle K team found that an Amazon Bedrock Knowledge Base with its default configuration worked best for their data. Amazon Bedrock handles embeddings, indexing, and vector storage end to end, so the team has fewer components to maintain. On the generation side, a well-designed system prompt and a tuned temperature setting produced consistent summaries in Slack.
Narrow the code search with findings from the logs. Searching for the service’s repositories without a lead returns too many results to be useful. The team runs the GitHub search after the AWS resource and log analysis, so the agent already knows which error, component, or recent change to look for. In the example triage, this is how the agent found that the service opened a new database connection for every request.
Keep the analysis logic independent of the orchestration layer. Analysis time grows with data volume, so plan for investigations to take longer over time. The team kept its prompts, tool definitions, and analysis steps separate from the flow structure. This made it possible to consolidate them into a single agent on AgentCore Runtime without rewriting the triage logic.
Today, the triage system finds the probable root cause and recommends a fix, and an engineer carries out the fix. Next, the team plans to integrate with AWS DevOps Agent, so the system can also handle simple remediations. Examples include restarting a task, scaling up a service, or rolling back a deployment. An engineer will approve each action in Slack before it runs.
The team also plans to give the agent more context to work with:
The Circle K team went from 45–60 minutes of manual incident triage to under 15 minutes by automating the context gathering that engineers used to do by hand. The system collects data from logs, AWS resources, and code, lets an agent reason over it, and delivers a structured summary to Slack.
The team built the first version on Amazon Bedrock Flows and Amazon Bedrock Knowledge Bases. As investigations grew larger, the team moved to a single agent on Amazon Bedrock AgentCore Runtime, with AgentCore Gateway providing access to its data sources.
If your team spends most of its incident response time gathering context rather than fixing problems, this pattern applies directly. To get started, explore Amazon Bedrock AgentCore and Amazon Bedrock Knowledge Bases. For hands-on guidance or to discuss your use case with an AWS specialist, visit the Amazon Bedrock getting started page or contact AWS.
We want to hear how you approach incident triage. Share your experience in the comments.
Marek is a Cloud DevOps Engineer at Circle K, where he works with AWS to design and improve cloud services for enterprise end customers. Lately he has spent much of his time on AI, building solutions that deliver real business value. He believes in simple solutions that just work.
Sefat is a Solutions Architect at Amazon Web Services, where she helps enterprise customers build AI-powered operational tooling on AWS. She specializes in generative AI applications, agent architectures, and DevOps automation. Outside of work, she enjoys experimenting with cooking, music, and home automation projects.