Forter konnte rund 200 Personen innerhalb eines zweiwöchigen praktischen Sprints in die Entwicklung von KI-Agenten einbinden, nachdem das Unternehmen eine Umgebung geschaffen hatte, die den Bedarf an Programmierkenntnissen reduzierte und es Analysten und Ingenieuren ermöglichte, ihre Ideen schnell auszuprobieren. Ben Maraney, leitender Ingenieur des Unternehmens, beschreibt die Erfahrung als eine Lektion darin, unnötige Komplexität zu beseitigen, statt zu versuchen, alle Herausforderungen der Agentenentwicklung auf einmal zu lösen.
Der Anfang: ein praktischer Sprint mit einer Frist von fünf Wochen
Ziel war es, die Forschungs- und Entwicklungsteams darin zu schulen, eigene Agenten zu erstellen, darunter Analysten mit juristischem, psychologischem und wissenschaftlichem Hintergrund, von denen einige zuvor noch nie SQL geschrieben hatten. Das Team musste die Umgebung innerhalb von fünf Wochen bereitstellen und anschließend einen zweiwöchigen Entwicklungssprint durchführen. Daher konzentrierte sich das Design auf drei Bereiche: Werkzeuge, Plattformen und die Beseitigung von Hürden für die Nutzer.
Ein zentraler MCP-Server statt verstreuter Werkzeuge
Forter setzte auf einen internen Server auf Basis des MCP-Protokolls, den das Unternehmen Toolchain nannte. Der Server stellte eine einheitliche Schnittstelle bereit, um Werkzeuge zu entdecken und auszuprobieren sowie Verbindungen für die einzelnen Agenten herzustellen. Außerdem konnten Nutzer nur die Werkzeuge auswählen, die der Agent benötigte, statt ihm weitreichenden Zugriff zu gewähren, der ihn verwirren oder dazu führen konnte, ungeeignete Werkzeuge zu verwenden.
Die Zahl der Werkzeuge stieg von rund 20 bei der Gründung des Teams auf knapp 60 zum Beginn des Sprints und anschließend innerhalb von zwei Wochen nach dessen Ende auf nahezu 100. Die Vereinheitlichung des Repositorys sowie klare Beispiele und Konfigurationsdateien halfen dabei, neue Werkzeuge schnell hinzuzufügen. Gleichzeitig standen Governance-Funktionen wie die Überwachung des Token-Verbrauchs und der Werkzeugnutzung zur Verfügung.
Statt innerhalb kurzer Zeit ein eigenes Retrieval-Augmented-Generation-System (RAG) zu entwickeln, verband das Unternehmen Toolchain mit der Plattform Glean, die für die Suche in internen Quellen wie Confluence, Asana, Jira, Slack und Salesforce genutzt wird. Es stellte drei Arten von Werkzeugen bereit: die Suche nach relevanten Dokumenten und Abschnitten, das vollständige Lesen eines Dokuments sowie dessen Zusammenfassung anhand einer vom Agenten festgelegten Frage oder eines Schwerpunkts.
Von einer No-Code-Plattform zu anpassbaren Lösungen
Forter nutzte LibreChat, um eine schnelle, weitgehend codearme Chat-Erfahrung bereitzustellen. Die Nutzer konnten sehen, welche Werkzeuge der Agent aufgerufen hatte, welche Abfragen und Parameter er gesendet hatte und welche Ergebnisse er erhalten hatte. Dies half dabei, das Verhalten der Agenten zu verstehen und Probleme frühzeitig zu erkennen, obwohl die MCP-Integration mitunter instabil war und die Kontrolle über Versionen und Anpassungen begrenzt blieb.
Für komplexere Fälle stellte das Unternehmen Vorlagen-Repositories bereit, die Entwicklern vollständige Kontrolle über den Code sowie das Hinzufügen von Werkzeugen und Unteragenten ermöglichten. Für Analysten waren sie jedoch langsamer einzurichten und bereitzustellen. Später entwickelte Forter eine interne Oberfläche namens AI Hub, über die sich das Modell auswählen, die Systemnachricht verfassen und die Werkzeuge festlegen ließen. Anschließend konnte der Agent in wenigen Schritten geteilt werden.
Für nicht interaktive Agenten wurden das Strands-Framework und Argo Workflows eingesetzt, um sie nach Zeitplänen oder Ereignissen wie der Erstellung von Jira- und Asana-Tickets auszuführen. Maraney weist darauf hin, dass ein bereits vorhandenes Planungs- und Ausführungssystem den Bedarf an einer neuen, speziell für Agenten konzipierten Architektur beseitigen kann.
Was wurde tatsächlich entwickelt?
Zu den Einsatzbereichen gehörten Agenten, die Analysten dabei halfen, bessere Hypothesen und Experimente zu formulieren, Postmortem-Berichte zu überprüfen und Leistungsrückgänge bei Händlern mithilfe von Snowflake und Databricks-Notebooks zu analysieren. Außerdem entwickelte das Unternehmen Expertenagenten wie Layla und Penny, die auf Code, Konfigurationen und Daten zugreifen und Fragen zu Transaktions- und Abrechnungsentscheidungen beantworten konnten. Die Nutzung von Layla weitete sich auf die Teams für Customer Success und Support aus, nachdem ihr Wissen über das System umfangreicher geworden war als das jedes einzelnen Mitarbeiters.
Zu den Beispielen für nicht interaktive Agenten gehörten das Vorschlagen anfänglicher Einstellungen für einen neuen Händler auf Grundlage ähnlicher Händler, die Vorbereitung erster Recherchen beim Eingang eines Support-Tickets sowie die Analyse von Anomalie-Warnungen und deren Verknüpfung mit Codeänderungen. Forter testete außerdem einen Agenten für die Vorfallreaktion, stellte jedoch fest, dass dessen scheinbar hervorragende Ergebnisse im Wesentlichen darauf beruhten, bereits zuvor von Menschen in BetterNext-Berichten verfasste Ursachenanalysen zu kopieren.
Was verändert sich in der Praxis?
Diese Erfahrung zeigt, dass Beobachtbarkeit kein nebensächliches Merkmal ist. Die Anzeige der Werkzeuge, Parameter und Ergebnisse, auf die sich der Agent stützte, war entscheidend, um festzustellen, dass der Agent für die Vorfallreaktion die eigentliche Grundursache nicht tatsächlich herleitete. Deshalb fügte Forter später Langfuse hinzu, um Agentensitzungen, Tool-Aufrufe und den Arbeitsablauf zu verfolgen.
Die Erfahrung zeigt außerdem, dass der Einsatz mehrerer Plattformen beabsichtigt sein kann: eine No-Code-Plattform für schnelle Experimente, softwarebasierte Lösungen zur Anpassung sowie ereignis- oder zeitplanbasierte Agenten. Gleichzeitig hatte das Unternehmen Probleme mit dem Modell, für jeden Agenten ein eigenes Repository anzulegen, und kehrte anschließend zu einer geringeren Zahl von Repositories zurück, die miteinander verbundene Agenten enthielten. Dadurch wurde die Einführung gemeinsamer Funktionen wie der Nachverfolgung erleichtert.
Maraney warnt außerdem davor, dass allgemeine Bewertungsmetriken wie Relevanz, Kohärenz und Sicherheit einen falschen Eindruck von Qualität vermitteln können. Eine nützliche Bewertung sollte die Richtigkeit der Antwort, die Verwendung geeigneter Werkzeuge und den Abruf des richtigen Kontexts prüfen. Diese Aspekte sind schwieriger und erfordern ein genaues Verständnis davon, was eine gute Antwort ausmacht. Daher können fortgeschrittene Bewertungen bei internen Experimenten, in denen der Mensch weiterhin Teil der Entscheidungsschleife ist, zunächst zurückgestellt werden. Sie sollten jedoch nicht als dauerhafter Ersatz für eine Bewertung betrachtet werden.
Initiativen zur Ausweitung benötigen außerdem eine frühzeitige Einbindung der Rechts- und Sicherheitsteams, insbesondere hinsichtlich des Ortes, an dem Daten verarbeitet und gespeichert werden. Maraney zufolge half die Nutzung eines Cloud-Dienstes wie Amazon Bedrock zusammen mit der Dokumentation von Richtlinien zur Nichtaufbewahrung von Daten dabei, diese Bedenken innerhalb der Kontrollen des Unternehmens zu berücksichtigen, statt jeden Agenten zu einem eigenen Genehmigungsfall zu machen.