Wie ShipStation Global einen KI-IT-Helpdesk auf Amazon Bedrock AgentCore aufgebaut hat

Dieser Beitrag wurde in Zusammenarbeit mit Kenneth Salmon, Edward Boswell, Jack Armstrong, Robert Bahn und Nick Ciubotariu von ShipStation Global verfasst.

Die Beantwortung derselben IT-Fragen und die Erledigung von Routine-Tickets raubt IT-Teams Zeit, die sie anderswo verbringen könnten. Um diese Zeit zurückzugewinnen, hat das ShipStation Global Engineering Team Deckhandgebaut, einen KI-gestützten IT-Helpdesk-Agenten für Slack, auf Amazon Bedrock AgentCore.

ShipStation Global ist die führende intelligente Versand- und Logistikplattform für kleine und mittlere Versandunternehmen und verfolgt eine einfache Überzeugung: Je effizienter seine Teams arbeiten, desto besser liefert es für Kunden. Deckhand setzt diese Überzeugung in die Praxis um. Es beantwortet Routine-IT- und Unternehmensfragen aus einem kuratierten Wissensbestand, liest Screenshots von Fehlermeldungen und erstellt und aktualisiert Jira Service Management-Tickets.

In diesem Beitrag erläutern wir, wie ShipStation Deckhand architektonisch aufgebaut hat, was zur Lösung von 97,5 Prozent der eingehenden Kanal-Anfragen führte und eine positive Feedback-Bewertung von 96 Prozent durch Mitarbeiterinnen und Mitarbeiter erzielte (Abbildung 1).

Abbildung 1: 3-monatige Kanalabdeckung und positives Feedback

Geschäftliche Herausforderung

Das Problem, das Deckhand löst, kennen alle IT-Teams: Dieselben Fragen werden regelmäßig gestellt, Fehlermeldungen werden außerhalb der Geschäftszeiten gepostet, und Informationen müssen aus verschiedenen Teams zusammengetragen werden. Bei ShipStation Global fanden diese Gespräche in einem stark frequentierten Helpdesk-Slack-Kanal statt, in dem Mitarbeitende fragten und die IT Frage für Frage in einzelnen Threads antwortete. Die Antworten existierten meist bereits – in einem Confluence-Anleitungsartikel, auf einer Unternehmens-Intranetseite oder in einem Thread von vor acht Monaten. Sie zu finden war der schwierige Teil.

Die Kanaldaten machten das Ausmaß konkret. In den 12 Monaten vor dem Start:

• Mitarbeitende erstellten mehr als 1,500 Threads, und das Volumen wuchs weiter.
• Da Mitarbeitende in den USA, im Vereinigten Königreich, in Spanien, Polen, Australien und auf den Philippinen tätig sind, kam mehr als ein Fünftel der Fragen außerhalb der US-Geschäftszeiten.
• Die Antworten verteilten sich auf verschiedene Orte: Confluence-Artikel, Intranetseiten und PDFs, von der IT gepflegte Anleitungen und der eigene Verlauf des Kanals.
• Sich wiederholende Fragen kosteten Zeit, die strukturierte Self-Service-Schritte hätte bewältigen können.

„Wir haben Deckhand entwickelt, weil Hilfe so einfach sein sollte wie das Stellen einer Frage in Slack – und nicht das Entziffern eines Ticketformulars oder das Senden einer E-Mail ins Leere. Wir sind der Ansicht, dass Tickets ein Hinweis auf betriebliche Reibung und nicht auf Produktivität sind. Deckhand beantwortet häufige Fragen sofort und wandelt, wenn dies nicht möglich ist, das Gespräch mit einem Klick in ein voll kontextualisiertes Ticket um, was die Mitarbeitererfahrung verbessert und unser Team von der endlosen Wiederholung des Satzes ‚Bitte erstellen Sie ein Ticket‘ befreit.“

— Chris Collins, Senior Director IT bei ShipStation Global

Lösungsübersicht

Deckhand arbeitet in Slack wie jedes Teammitglied – es tritt Kanälen bei, liest die Konversation und zieht Kontext aus Slack-Profilen, um IT-Fragen direkt an Ort und Stelle zu beantworten. Wir betreiben es auf Amazon Bedrock AgentCore, einer Plattform zum Erstellen, Verbinden und Optimieren von Agenten in jeder Größenordnung, mit jedem Framework und Modell. Der AgentCore runtime, eine Funktion von Amazon Bedrock AgentCore, hostet den Agenten in isolierten Sitzungen, sodass wir weder Server noch Container betreiben.

Die Lösung besteht aus vier Hauptkomponenten, dargestellt in Abbildung 2:

1. Slack-Dienst: Eine FastAPI- und Slack-Bolt-Anwendung, gehostet auf AWS App Runner. Sie empfängt Slack-Ereignisse, entscheidet, ob der Bot antworten soll, und erstellt eine Benutzerkontext-Payload aus dem Slack-Profil der anfragenden Person, einschließlich Name, E-Mail, Zeitzone und Vorgesetzter.
2. Agenten-Dienst: Ein Strands-Agent, deployed als Container auf Amazon Bedrock AgentCore runtime, verwaltet die Multi-Turn-Tool-Agentenschleife unter Verwendung von Anthropics Claude in Amazon Bedrock.
3. Tools und Wissen: Eine einzelne AWS Lambda -Funktion, die über das AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, als Model Context Protocol (MCP)-Tools bereitgestellt wird, klassifiziert Anfragen, erstellt und aktualisiert Jira-Tickets und analysiert Bilder. Eine Amazon Bedrock Knowledge Base indiziert Inhalte aus Confluence, dem Firmen-Intranet, Slack und Marketingseiten und speichert sie in Amazon Simple Storage Service (Amazon S3).
4. Betrieb und Feedback. Amazon DynamoDB speichert Feedback, AWS X-Ray verfolgt Anforderungspfade mit OpenTelemetry, und die Dienste protokollieren in Amazon CloudWatch.

Abbildung 2: Architekturdiagramm, das zeigt, wie Slack-Ereignisse in den Slack-Dienst und die Amazon Bedrock AgentCore Runtime gelangen, mit separaten Pfaden zu einer Amazon Bedrock Knowledge Base, AgentCore Gateway-basierten Lambda-Tools, Jira Service Management und DynamoDB-Feedback.

Wenn ein Mitarbeiter in einem Kanal postet, in dem Deckhand Mitglied ist, stellt der Slack-Dienst den vollständigen Thread-Verlauf und den Benutzerkontext zusammen. Anschließend ruft er den Agenten über die AgentCore Runtime API auf. Der Agent durchsucht die Knowledge Base und ruft bei Bedarf Tools auf. Wenn er eine Antwort findet, gibt er eine endgültige Antwort zurück (Abbildung 3). Wenn nicht, stellt er eine Klärungsfrage oder bietet an, ein Ticket zu erstellen (Abbildung 4).

Abbildung 3: Deckhand antwortet mit Self-Service-Schritten

Abbildung 4: Deckhand bietet an, ein Ticket zu erstellen

Deckhand-Workflow

Dieser Abschnitt zeigt, wie Deckhand implementiert ist – von den Voraussetzungen bis zu einer funktionierenden Bereitstellung.

Voraussetzungen

Um dieses Muster zu implementieren, benötigen Sie Folgendes:

• Ein AWS-Konto mit Zugriff auf Amazon Bedrock, AgentCore Runtime und AgentCore Gateway.
• Eine Slack-App mit Ereignisabonnements, einem Signing Secret und einem Bot-Token, das auf Ihren Anwendungsfall zugeschnitten ist.
• Eine Container-Image-Registry wie Amazon Elastic Container Registry (Amazon ECR).
• Ein Amazon S3-Bucket und eine Amazon Bedrock Knowledge Base.
• AWS Identity and Access Management (IAM)-Rollen für jede Runtime und jedes Tool sowie AWS Secrets Manager-Einträge für Anmeldeinformationen von Drittanbietern.

Aufbau des Agenten mit Strands Agents und AgentCore

Der Agent ist bewusst schlank gehalten. Mit dem Open-Source- Strands Agents SDKbesteht ein Agent aus einem Modell, einer Reihe von Tools und einem Systemprompt. Das SDK verwaltet die Reasoning-Schleife und ermöglicht dem Modell, Tools auszuwählen, Ergebnisse zu verarbeiten und zu iterieren, bis es eine Antwort liefert. Der Agentendienst von Deckhand ist in wenigen Zeilen Python implementiert.

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client

model = BedrockModel(
    model_id=MODEL_ID,
    max_tokens=2048,
    temperature=0.3,
)

gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))

agent = Agent(
    model=model,
    tools=[gateway, retrieve],
    system_prompt=SYSTEM_PROMPT,
)

Die Modell-ID wird über eine Umgebungsvariable festgelegt, was einen Modellwechsel ohne Änderung des Anwendungscodes ermöglicht.

Tools werden auf zwei Arten in den Agenten integriert. Der Amazon Bedrock Knowledge Bables-Abruf ist ein natives Strands-Tool, das Knowledge-Base-Suche mit einem einzigen Import unterstützt. Andere Funktionen, darunter Klassifizierung, Ticketverwaltung, Benutzerauflösung und Bildanalyse, werden von einer Lambda-Funktion übernommen, die auf dem AgentCore Gateway registriert ist. Das Gateway stellt diese als MCP-Tools bereit, und die Lambda-Funktion leitet jeden Aufruf anhand des Tool-Namens weiter. Diese Trennung ermöglicht es, Tool-Logik unabhängig zu aktualisieren, und der Agent kann neue Tools vom Gateway nutzen, ohne dass ein Neuaufbau erforderlich ist.

AgentCore Runtime hostet den Agenten als Container und vermeidet damit die Notwendigkeit von Server- oder Sitzungsverwaltung. Der Slack-Dienst ruft den Agenten für jede Nachricht synchron auf, übergibt das Thread-Transkript und den Benutzerkontext und veröffentlicht die endgültige Antwort. Da der Kontext, einschließlich des Profils des Mitarbeiters, mit jeder Anforderung übermittelt wird, kann der Agent Ticketdetails automatisch vervollständigen.

Design der Knowledge Base und Antwortweiterleitung

Deckhand antwortet auf Basis einer einzigen Amazon Bedrock Knowledge Base mit zentralen S3-basierten Datenquellen:

• Artikel, die aus Confluence synchronisiert werden.
• Interne Seiten, PDFs und Veranstaltungen, die aus dem Firmen-Intranet synchronisiert werden.
• Gelöste Support-Threads aus Slack (im nächsten Abschnitt behandelt).

Jedes Dokument enthält Metadaten wie Titel, Quell-URL, Inhaltstyp und Veranstaltungsdaten. Dies ermöglicht es dem Agenten, Inhalte zu filtern, z. B. wenn Benutzer nach bevorstehenden Veranstaltungen oder wöchentlichen Mittagsmenüs im Büro in Austin fragen.

Mining des Slack-Verlaufs mit Recursive Language Models (RLMs)

Die wertvollste Datenquelle ist das Archiv gelöster Support-Threads. Bevor es Deckhand gab, war Slack der Ort, an dem Probleme gelöst wurden: jahrelange Beschreibungen von Problemen durch Mitarbeitende und die IT, die sie durch die Behebung führte. Dieser Verlauf ist eine organische Wissensbasis, validiert vom bestmöglichen Prüfer: der Person, deren Problem gelöst wurde. Er ist aber auch verrauscht: Ein Rohexport mischt Neckereien, automatisierte Warnungen und Threads, die tatsächlich nie gelöst wurden. Die Indizierung einer unbestätigten Lösung oder einer verstümmelten Zusammenfassung bedeutet, dass die Wissensbasis eine falsche Antwort mit derselben Zuversicht ausgibt wie eine korrekte, daher muss die Extraktion präzise sein.

Der Mining-Prozess folgt einer Pipeline mit drei Stufen (Figure 5):

1. Ein Skript exportiert den vollständigen Verlauf des Kanals über die Slack API, ruft vollständige Antworten für jeden Thread ab und schreibt einen strukturierten Dump, der Thread-Marker, Zeitstempel und Antwortanzahlen enthält.
2. DSPy's Recursive Language Model (RLM), das Claude auf Amazon Bedrock ausführt, behandelt diesen Export als navigierbaren Speicherraum innerhalb einer sandboxed Python read-eval-print loop (REPL) und nicht als einzelnen Prompt. Indem es iterativ über die Daten arbeitet, klassifiziert es jeden Thread als resolved, unresolved oder escalated und filtert Ankündigungen und Nicht-Fragen heraus. Strenge Kriterien halten die Qualität hoch: Ein Thread gilt nur dann als resolved, wenn die vollständige, brauchbare Lösung im Thread selbst sichtbar ist.
3. Für jeden aufgelösten Thread orchestriert das RLM rekursive Sub-LLM-Aufrufe (Large Language Model), um strukturierte Felder zu extrahieren, die jeweils gegen ein Pydantic-Modell validiert werden. Zu den Feldern gehören eine Issue-Zusammenfassung, die ursprüngliche Frage und die Lösung. Außerdem wird erfasst, ob die Behebung durch Selbsthilfe erfolgen kann oder ein Ticket benötigt wird, die Schritte zur Selbsthilfe, die betreffende Anwendung und das System, Fehlermeldungen sowie Tags. Wenn ein Sub-LLM-Aufruf etwas zurückgibt, das das Schema nicht erfüllt, fängt der codebasierte Loop des RLM den Validierungsfehler im Interpreter ab und wiederholt den Versuch. Die Ergebnisse werden als Markdown-Dokument geschrieben, das nach Issues gegliedert ist. Die Pipeline lädt es zu Amazon S3 hoch, damit die Knowledge Base es indexieren kann.

Abbildung 5: Export-, Klassifizierungs- und Extraktions-Workflow des Slack-Gesprächs

Wir wählten RLM , weil es den gesamten Slack-Verlauf in einem persistenten Sandbox-Variablenraum vorhält und so iteratives Reasoning über den Export und eine konsistente Ausgabestruktur ermöglicht. Wenn ein Mitarbeitender daher auf ein Problem stößt, das zuvor bereits von einer Kollegin oder einem Kollegen gelöst wurde, liefert Deckhand die erprobte Lösung, oft als umsetzbare, nummerierte Schritte.

Wissen, wann man nicht antworten sollte

Ein KI-Bot in einem gemeinsamen Kanal scheitert sozial, bevor er technisch scheitert. Deckhands ausgereifteste Logik entscheidet, wann er schweigen soll:

1. Die erste Entscheidung des Agents bei jeder Nachricht ist, ob es sich um eine Ankündigung, eine soziale Nachricht oder ein Gespräch zwischen Personen handelt. Wenn ja, gibt er „SKIP“ aus, und der Slack-Dienst unterdrückt die Antwort.
2. In Threads antwortet er nur der Person, die den Thread ursprünglich erstellt hat.
3. Wenn die letzte Antwort von einer anderen helfenden Person stammt, bleibt er stumm, weil ein Mensch die Sache übernommen hat.
4. Wenn eine Antwort beginnt, eine Person mit @ anzusprechen, ist die Nachricht nicht für den Bot bestimmt.

Feedback einholen

Jede Antwort enthält Feedback-Schaltflächen. Ein Daumen nach oben wird direkt erfasst, während ein Daumen nach unten ein kurzes Feld „Was ist schiefgelaufen“ auslöst. Die Bewertungen werden zusammen mit der ursprünglichen Frage und der Antwort des Bots in DynamoDB gespeichert.

Negatives Feedback ist ein wertvoller Datensatz, der genutzt wird, um den Systemprompt und das Agentenverhalten zu verbessern und falsche Informationen in der Knowledge Base zu aktualisieren.

Sicherheit und Validierung

Prompt-Regeln verbessern das Verhalten, ersetzen aber keine Zugriffssteuerungen. Die Durchsetzung erfolgt über Code und Infrastruktur:

• Die Ticketerstellung erfordert eine ausdrückliche Bestätigung. Wenn Deckhand anbietet, ein Ticket zu erstellen, fügt der Slack-Dienst eine Schaltfläche Create Ticket hinzu, und deren Auswahl sendet die Bestätigung über den Agenten. Ticket-Updates akzeptieren nur gültige Schlüssel, die dem Muster des Helpdesk-Projekts entsprechen, und weisen leere Kommentare zurück.
• Die Klassifizierung wird validiert, bevor sie ausgeführt wird. Die Anfrageklassifizierung läuft als separater Amazon Bedrock Converse API -Aufruf, der strukturierte Ticketfelder zurückgibt, die mit Pydantic validiert werden, bevor irgendetwas Jira erreicht.
• Das Bild-Tool ist auf das Herunterladen ausschließlich vom Slack-Datei-Host beschränkt. Es authentifiziert sich mit dem Bot-Token, begrenzt jede Anfrage auf fünf Bilder von jeweils bis zu 5 MB und sendet die Dateien über die Converse API an ein Vision-Modell.
• Zugangsdaten bleiben aus dem Code heraus. Slack-Tokens, das Signing Secret und Jira-Zugangsdaten liegen im AWS Secrets Manager, und jeder Dienst und jedes Tool läuft unter seiner eigenen IAM-Rolle mit eingeschränktem Geltungsbereich.
• Der Prompt erzwingt verhaltensbezogene Schutzmaßnahmen: niemals Passwörter oder Multi-Faktor-Authentifizierungs-Codes (MFA) anfordern, niemals Zugangsdaten in Ticket-Kommentaren schreiben und niemals Profil-Metadaten preisgeben, die für Ticketfelder verwendet werden.

Ergebnis

Deckhand wurde im April 2026 eingeführt. Es startete mit etwa 30 Nachrichten pro Tag und erreichte bis zum Frühsommer bis zu 100. In den ersten drei Monaten bearbeitete es 1,935 Nachrichten, startete 1,221 Agentengespräche und eröffnete 409 Jira-Tickets. Es antwortete auf 97.5 Prozent der Nachrichten. Ein Drittel der Fragen kam außerhalb der Arbeitszeiten, wenn niemand im IT-Team arbeitete, und Deckhand beantwortete 94 Prozent davon. Personen, die bis zum nächsten Morgen hätten warten müssen, erhielten noch in derselben Nacht eine Antwort.

Das Feedback verbesserte sich, während das Team daran arbeitete. Die positiven Bewertungen stiegen von 82 Prozent im April auf 96 Prozent im Juni, nachdem sie den Systemprompt und die Knowledge Base überarbeitet hatten, um die beanstandeten Punkte zu beheben.

Der deutlichste Erfolg war die Ticket-Deflection. Ein Agentengespräch ist eine Frage, die sonst zu einem Jira-Ticket geworden wäre. Von den 1,221 Gesprächen wurden nur 409 zu Tickets. Die anderen 812 wurden im Chat behandelt. Das Anlegen eines Tickets sowie dessen Bearbeitung und Schließung dauern etwa 30 Minuten. Diese 812 Gespräche summieren sich auf rund 406 Stunden über drei Monate bzw. etwa 1,600 Stunden pro Jahr. Die Mitarbeitenden behielten diese Zeit für ihre eigene Arbeit, und die IT musste sie nie für die Entgegennahme aufwenden.

Fazit

Deckhand nahm der Belegschaft wiederkehrende IT-Fragen ab und gab die Zeit sowohl an die Mitarbeitenden als auch an das IT-Team zurück. Es funktioniert, weil jeder Teil des Stacks genau eine Aufgabe hat und als Managed Service läuft: Die AgentCore Runtime hostet den Agenten, das AgentCore Gateway macht eine Lambda-Funktion zu MCP-Tools, die der Agent aufrufen kann, und Amazon Bedrock Knowledge Bases übernimmt den Abruf. Das Team brachte es an den Start, ohne Server aufsetzen oder Orchestrierungscode pflegen zu müssen.

Um eine ähnliche Lösung zu entwickeln, beginnen Sie mit einer gut gepflegten Wissensquelle und einer klar definierten Aktion. Beachten Sie die Amazon Bedrock AgentCore-Dokumentation und Strands Agents SDK für die Agentenentwicklung sowie die Amazon Bedrock Knowledge Bases-Dokumentation für die Anbindung von Inhaltsquellen.

Um einen Anwendungsfall für agentenbasierte KI in Ihrer Organisation zu besprechen, wenden Sie sich an Ihr AWS-Kontoteam.

Über die Autoren