Die wichtigsten Erkenntnisse
- Wir sind von einem echten Kunden-Schmerzpunkt ausgegangen. Snyk Assist wurde entwickelt, damit Kunden schnell und präzise Antworten erhalten können, ohne in Dokumentation, Support-Inhalten und Kontosystemen suchen zu müssen.
- Wir haben Vertrauen und Zugriffskontrolle als zentrale Produktanforderungen behandelt. Da Snyk eine Sicherheitsplattform ist, wurde der Agent so konzipiert, dass er innerhalb der Berechtigungen eines Nutzers bleibt und beweisen musste, dass er sicher, zuverlässig und korrekt ist, bevor er breiter ausgerollt wurde.
- Wir haben ihn so gebaut, dass er nützlich, messbar und skalierbar ist. Eine einzige LangGraph-Runtime betreibt mehrere Oberflächen, während LangSmith-Evaluierungen dem Team helfen, Regressionen zu erkennen, Antworten zu verbessern und mit Zuversicht weiter zu liefern.
Snyk ist eine AI Security Platform. Die Plattform findet und behebt Schwachstellen in Code, Open-Source-Abhängigkeiten, Containern und Cloud-Konfiguration und ist dort verankert, wo Entwickler bereits arbeiten: in der IDE, im Pull Request und in der Pipeline.
Wir entwickeln Sicherheitsprodukte für Entwickler, was bedeutet, dass unsere Kunden schwierige, spezifische Fragen stellen. Sie wollen Antworten zu Schwachstellen, Kontokontext, Support-Themen und Produktverhalten – oft mitten in der eigentlichen Arbeit. Vor Snyk Assist waren diese Informationen über Produktdokumentation, Support-Artikel, Release Notes, Lerninhalte und Kontodaten verteilt. Die richtige Antwort zu finden bedeutete meist, mehrere Seiten zu lesen oder ein Ticket zu erstellen und zu warten.
Snyk Assist ist ein konversationeller Agent, der auf LangChain und LangGraph aufbaut und dessen Observability in LangSmith verwaltet wird. Er hilft Kunden, Antworten in natürlicher Sprache zu finden, und kann in ihrem Namen handeln. Er kann offene Issues nachschlagen, ein Paket auf bekannte Schwachstellen prüfen, direkt aus dem Gespräch einen Support-Case eröffnen oder eine Feature-Anfrage loggen, wenn der gewünschte Workflow noch nicht unterstützt wird.
Er begann als internes Tool für unser eigenes Support-Team. Im September 2026 haben wir ihn in das Kernprodukt von Snyk integriert, wo ihn jeder zahlende Kunde nutzen kann.
In diesem Beitrag zeigen wir, wie wir Snyk Assist entwickelt haben – vom ursprünglichen internen Support-Anwendungsfall bis zum kundengerichteten Produkterlebnis. Wir behandeln auch die zugrunde liegende Architektur, einschließlich wie wir bei der Skalierung Berechtigungen, State, Guardrails und Evaluierung gehandhabt haben.
Die Herausforderung: Support, der nicht skalierte, und ein hoher Maßstab beim Ausliefern von KI
Unser Support-Team bearbeitet alle paar Wochen Tausende von Cases. Jeder einzelne musste gelesen, nach Produkt, Schweregrad und Verantwortlichem klassifiziert und an die richtige Stelle weitergeleitet werden. Mit wachsender Kundennachricht stellte dies eine Skalierungsherausforderung dar. Ein Agent war die naheliegende Lösung, aber da wir Sicherheitssoftware entwickeln, muss alles, was wir Kunden vorlegen, denselben Standards entsprechen, die wir an den Rest unseres Produkts anlegen. Wir mussten drei Dinge beweisen: dass der Agent korrekt antwortet, das ablehnt, was er ablehnen soll, und niemals etwas zurückgibt, das der Nutzer nicht ohnehin sehen durfte.
„Das Schwierige beim Bauen von Agenten ist nicht, was das Modell kann, sondern zu beweisen, dass der Agent tatsächlich funktioniert. Wir führen jede Änderung durch Evalos in LangSmith, und wenn sie die Messlatte nicht erfüllt, wird sie nicht ausgeliefert.“
—Bailey Millns, AI Engineer, Snyk
Statt den Agenten direkt im Produkt zu starten, begannen wir mit internen Tests im eigenen Team. Dieser Ansatz stellte sicher, dass anfängliche Fehler innerhalb von Snyk blieben, anstatt zahlende Kunden zu beeinträchtigen. Er ermöglichte uns auch, riskantere Funktionen sicher zu testen und das Verhalten des Agenten zu beobachten, bevor er breiter ausgerollt wurde.
Diese interne Phase ermöglichte es uns, unser Betriebsmodell mit LangSmith zu etablieren, bevor wir kundengerichtete Funktionen einführten. Jeder Trace aus diesen frühen Sitzungen floss direkt in unsere Evaluierungs-Sets ein und gab uns ein starkes Verständnis dafür, wie der Agent performen würde, bis wir ihn im Support-Portal starteten.
Phase 1: interne Tooling
Etwa ein Jahr lang lief Snyk Assist als internes Tool für das Kundensupport-Team, sowohl als Case-Triage als auch als virtueller Agent, wobei Snyk-Mitarbeiter die einzigen Nutzer waren. Das interne Testen des Agenten ermöglichte es uns, Randfälle aufzudecken, die in Offline-Tests nicht auftraten, und der Feedback-Zyklus wurde in Stunden statt in Release-Zyklen gemessen.
Phase 2: das Support-Portal
Im April 2026 haben wir Snyk Assist für Kunden in unserem Support-Portal eingeführt. Zu diesem Zeitpunkt konnte er Nutzer beim Namen begrüßen, den Kontokontext verstehen, einen Health Check beim Login durchführen und jederzeit ein Ticket erstellen, ohne auf einen Menschen warten zu müssen.
Phase 3: das Kernprodukt
Am 1. September 2026 zog Snyk Assist in das Kernprodukt von Snyk – zusammen mit unserer neuen Navigation – als Panel in der oberen Leiste jeder Seite, für jeden zahlenden Kunden.
Wir haben dieselbe Agent-Runtime durch jede Phase beibehalten. Das Einzige, was sich änderte, war die Oberfläche davor.
Eine Runtime, viele Eingänge
Snyk Assist ist ein einzelner LangGraph-Agent hinter mehreren Oberflächen: einer Slack-App, einer Web-App und direktem API-Zugang – alle über dasselbe abgesicherte Framework geroutet.
Wir haben uns für LangChain entschieden wegen seiner großen Community, seines robusten Ökosystems und seines Status als Industriestandard für den Bau von Agenten.
„LangChain hatte mit Abstand die größte Community und das größte Ökosystem und wurde schnell zum De-facto-Standard für den Bau von Agenten. „
—Jada Ross, AI Engineer, Snyk
Als kleines Team wollten wir eine einzige Runtime haben, damit wir Bugs beheben, Features ausliefern und auf Vorfälle reagieren können – alles von einem Ort aus. Diese Einfachheit ermöglichte es uns, schnell zu skalieren, ohne unsere Architektur zu fragmentieren.
Darüber hinaus bot die Verwendung von LangChains Middleware anstelle einer eigenen Lösung definierte Integrationspunkte für Kontext, Guardrails und Modell-Fallbacks. Dieses Setup ermöglicht es uns, Funktionen mit einfachen Ein-Zeilen-Änderungen zu aktualisieren oder umzuordnen, statt umfangreiche Code-Rewrites vorzunehmen.
Hier sind die vier Designentscheidungen, die das System praktikabel für den Produktivbetrieb machten:
- Tools als typisierte Funktionen, pro Benutzer registriert. Wir binden Tools zur Anfragezeit basierend auf den Berechtigungen an, die der angemeldete Benutzer tatsächlich hat. Das bedeutet, dass der Agent nur auf Daten zugreifen kann, die der Benutzer bereits sehen könnte. Die meisten Tools sind separate Microservices, wodurch wir sie unabhängig skalieren und Funktionen hinzufügen können, ohne die Agent-Schleife zu ändern.
- Middleware statt Verdrahtung. Kontextverwaltung, Guardrails und Modell-Fallbacks greifen an definierten Punkten im Lebenszyklus des Agenten an, statt von Hand durch die Schleife gezogen zu werden. Hinzufügen oder Umordnen von Verhalten erfordert nur eine Ein-Zeilen-Änderung an einer Liste, keine vollständige Neuschreibung.
- Status durch den Checkpointer gehandhabt. Der Konversationsverlauf wird in PostgreSQL persistiert und nach Sitzung verschlüsselt, sodass Multi-Turn-Gedächtnis, Skalierung über Pods hinweg und die Wiederaufnahme einer Konversation alle ohne zusätzliche Verkabelung funktionieren.
- Die Schleife als interne Plattform. Da ein Agent nur ein Modell, Tools, ein Prompt, Middleware und ein Checkpointer ist, gibt eine gemeinsame Factory den kompilierten Graphen zurück und jedes Team liefert seine eigene Konfiguration. Die meisten neuen Workflows sind eine Konfigurationsänderung statt einer neuen Architektur.
„Aus Entwicklungssicht gab uns LangChain eine fertige Agent-Abstraktion, sodass wir uns auf die Wirkung und Fähigkeiten unseres Agenten konzentrieren konnten, statt Orchestrierung, Tool-Aufrufe, Streaming und State neu zu erfinden.“
—Matt Jarvis, Director of AI Engineering, Snyk
Wie wir jede Änderung evaluieren
Jeder Modellaufruf, Tool-Aufruf und Entscheidungspunkt wird seit dem ersten Entwicklungstag in LangSmith nachverfolgt. Diese Trace wurde die Grundlage dafür, wie wir ausliefern.
Wir verwenden zwei Ebenen der Evaluierung.
Offline-Evaluierung führt Sätze von Testfragen in LangSmith aus. Die erste sind echte Fragen mit bekannten guten Antworten, markiert von einem zweiten Modell, sodass wir schnell erkennen können, ob eine Prompt- oder Modelländerung die Antwortqualität verschlechtert hat. Die zweite ist eine automatisierte Red-Teaming-Übung, bei der Menschen versuchen, den Agenten dazu zu bringen, Anweisungen zu ignorieren oder Geheimnisse preiszugeben.
CI als Gate bedeutet, dass jeder Pull Request den echten Agenten gegen diese Suiten laufen lässt und bei vereinbarten Schwellenwerten, die im Repository hinterlegt sind, blockiert.
Online-Evaluierung bewertet jeden Produktionslauf mit einem geplanten Job. Wir prüfen zwei Dinge: ging es um Snyk und hat die Antwort die Frage beantwortet? Diese Bewertungen geben uns eine gemessene Deflectionsrate statt einer Schätzung. Wir kategorisieren außerdem jede Frage nach Produktbereich, Thema, Sprach-Ökosystem und Fehlertyp, was Produktmanagern eine Live-Karte gibt, wo Kunden Schwierigkeiten haben.
Schließen der Schleife geschieht innerhalb unserer Coding-Agenten über den LangSmith MCP server. Wenn wir eine schlechte Trace finden, können wir sie untersuchen und in einen Datensatz umwandeln, ohne die IDE zu verlassen.
Da jeder Schritt in LangSmith nachverfolgt wird, können wir Änderungen an echten Fragen testen, Regressionen vor dem Ausliefern abfangen und schlechte Traces schnell in neue Datensätze umwandeln. Das gibt uns eine schnellere Feedback-Schleife und macht es viel einfacher, mit Zuversicht auszuliefern.
Die Wirkung: weniger Tickets, schnellere Antworten
Seit Snyk Assist im April 2026 für Kunden live ging:
- 60,000+ Anfragen bearbeitet
- 500+ Kundenkonten
- 85%+ der Sitzungen ohne Support-Ticket gelöst, was dem Support-Team Hunderte von Stunden erspart
- 250+ Fälle vom Agenten automatisch erkannt und direkt an das richtige Team eskaliert
Jede Konversation wird bewertet und kategorisiert, sodass wir sehen können, welche Teile des Produkts die meiste Verwirrung stiften. Das hilft uns, die Dokumentation zu verbessern.
Wichtigste Erkenntnisse und Ausblick
Snyk Assist begann als Tool für das eigene Support-Team von Snyk. Heute hat es mehr als 60,000 Kundenanfragen bearbeitet und löst über 85% der Sitzungen, ohne ein Support-Ticket zu erstellen. Seit September ist Snyk Assist Teil des Produkts selbst und auf jeder Seite verfügbar, neben der Arbeit, die Kunden bereits erledigen. Wir möchten, dass es ein nützlicher Teil des Snyk-Erlebnisses für jeden Kunden ist.
Link: https://docs.snyk.io/navigate-the-snyk-web-ui#snyk-assist