Snyk Assist löst über 85 % der Anfragen ohne Ticket: Was der Mittelstand daraus lernt

Stellen Sie sich vor, Ihr Kundenservice-Postfach füllt sich montagmorgens mit Anfragen: „Wo finde ich die Rechnung vom letzten Monat?“, „Wie ändere ich die Lieferadresse?“, „Warum erscheint diese Meldung in Ihrer Software?“ Ein erheblicher Teil dieser Fragen ist nicht neu. Die Antwort steht irgendwo in Ihrer Dokumentation, in einem Support-Artikel oder in den Kundendaten. Trotzdem liest ein Mitarbeiter jede einzelne Nachricht, sucht die Antwort heraus und tippt sie neu.

Genau an dieser Stelle hat das Sicherheitsunternehmen Snyk angesetzt. Am 8. Oktober 2026 hat LangChain, der Anbieter des Frameworks, auf dem Snyks Lösung läuft, eine ausführliche Fallstudie veröffentlicht: Aus einem internen Support-Werkzeug wurde ein Agent namens „Snyk Assist“, den heute jeder zahlende Snyk-Kunde direkt im Produkt nutzen kann. Die Kennzahl, die dabei im Mittelpunkt steht: Mehr als 85 Prozent der Sitzungen wurden gelöst, ohne dass ein Support-Ticket entstand.

In diesem Artikel ordnen wir ein, was die Quelle tatsächlich belegt, was sie nicht belegt und was Sie daraus für Ihr eigenes Kunden-Postfach oder Ihren Support-Chat ableiten können. Dabei trennen wir bewusst zwischen dem, was Snyk berichtet, und dem, was wir daraus als Vorgehen für ein mittelständisches Unternehmen empfehlen. Der Beitrag richtet sich an Geschäftsführerinnen und Geschäftsführer, die wissen möchten, ob und wie sich ein solcher Agent für ihr Unternehmen eignet, ohne gleich ein Entwicklerteam aufbauen zu müssen.

Was LangChain am 8. Oktober 2026 veröffentlicht hat

Die Quelle ist eine Fallstudie von Oliver Armstrong auf dem Blog von LangChain, veröffentlicht am 8. Oktober 2026 unter dem Titel „How Snyk turned an internal support agent into a customer feature“. Wichtig für die Einordnung: Es handelt sich um die Darstellung eines Technologieanbieters über einen Kunden. Die Zahlen stammen aus Snyks eigenen Messungen, die LangChain wiedergibt. Eine unabhängige Prüfung durch Dritte nennt die Quelle nicht.

Snyk ist ein Anbieter von Sicherheitssoftware, die Schwachstellen in Programmcode, Open-Source-Bibliotheken, Containern und Cloud-Konfigurationen findet und behebt. Die Kundschaft stellt dort naturgemäß viele Fragen, und zwar verteilt über Produktdokumentation, Support-Artikel, Release Notes, Lerninhalte und die jeweiligen Kontodaten. Laut Fallstudie musste man für eine Antwort oft mehrere Seiten lesen oder ein Ticket eröffnen und warten. Das Support-Team bearbeitete alle paar Wochen Tausende Fälle, und jeder Fall musste gelesen, nach Produkt, Dringlichkeit und Zuständigkeit eingeordnet und weitergeleitet werden.

Snyk Assist ist die Antwort darauf: ein Agent, der Fragen in normaler Sprache beantwortet und für die Nutzerin oder den Nutzer auch handeln kann. Die Fallstudie nennt vier Tätigkeiten:

• offene Probleme nachschlagen,
• ein Paket auf bekannte Schwachstellen prüfen,
• aus dem Gespräch heraus einen Support-Fall eröffnen,
• einen Feature-Wunsch protokollieren, wenn ein benötigter Ablauf noch nicht unterstützt wird.

Das ist ein wichtiger Unterschied zu einem klassischen Chatbot, der nur Textbausteine ausgibt. Der Agent sucht, prüft und legt Vorgänge an. Zugleich ist die Liste überschaubar. Es sind klar umrissene Tätigkeiten, keine offene Handlungsvollmacht.

Die Zahlen: Was belegt ist und wie man sie liest

Seit dem Start für Kunden im April 2026 nennt die Fallstudie diese Kennzahlen:

• über 60.000 bearbeitete Anfragen,
• über 500 Kundenkonten,
• über 85 Prozent der Sitzungen ohne Support-Ticket gelöst,
• über 250 Fälle, die der Agent selbst erkannt und direkt an das richtige Team weitergegeben hat.

Zusätzlich heißt es, die Lösungsquote habe dem Support-Team Hunderte Stunden gespart. Die genaue Stundenzahl nennt die Quelle nicht. Wir rechnen deshalb in diesem Artikel auch nicht mit einer solchen Zahl, sondern zeigen weiter unten eine eigene, klar als Beispiel gekennzeichnete Überschlagsrechnung.

„The hard part of building agents isn't what the model can do, it's proving the agent actually works.“ (Bailey Millns, AI Engineer bei Snyk, in der LangChain-Fallstudie vom 8. Oktober 2026)

Dieses Zitat ist der eigentliche Kern der Geschichte, und wir kommen darauf zurück. Zunächst zur Lesart der 85 Prozent: Die Zahl beschreibt Sitzungen, die ohne Ticket endeten. Sie sagt nicht automatisch, dass jede dieser Sitzungen zur vollen Zufriedenheit der Kundschaft ausging. Laut Fallstudie bewertet Snyk jeden Produktionslauf automatisch mit zwei Fragen: Ging es im Gespräch um Snyk, und hat die Antwort die Frage beantwortet? Aus diesen Bewertungen entsteht nach Angabe der Quelle eine gemessene statt geschätzte Quote. Das ist ein solides Vorgehen, bleibt aber eine Messung des Anbieters selbst.

Auch die Übertragbarkeit ist begrenzt. Snyk ist ein Softwareunternehmen mit digital versierter Kundschaft, einer sauberen Wissensbasis und einem eigenen Team für KI-Technik. Ein Maschinenbauer mit 80 Beschäftigten und einem Service-Postfach wird nicht automatisch dieselbe Quote erreichen. Die Zahl ist ein Beleg dafür, dass der Ansatz im Produktivbetrieb funktionieren kann, nicht eine Prognose für Ihr Haus.

Wie Snyk vorgegangen ist: Intern zuerst, dann nach außen

Aus Sicht eines Unternehmens, das selbst über einen solchen Agenten nachdenkt, ist der Weg fast interessanter als das Ergebnis. Die Fallstudie beschreibt drei Phasen, die alle denselben Agenten nutzten. Nur die Oberfläche wechselte.

Phase 1: intern. Etwa ein Jahr lang lief der Agent ausschließlich als internes Werkzeug des Support-Teams, zur Einordnung von Fällen und als virtueller Assistent. Nur Snyk-Beschäftigte nutzten ihn. Laut Quelle zeigten sich im internen Betrieb Randfälle, die Tests im Vorfeld nicht gefunden hatten, und Rückmeldungen kamen in Stunden statt in Release-Zyklen. Außerdem blieben frühe Fehler so im eigenen Haus.

Phase 2: Support-Portal. Im April 2026 folgte der Start für Kundschaft im Support-Portal. Der Agent konnte Nutzer namentlich begrüßen, den Kontext des Kontos verstehen, beim Login einen Zustandscheck durchführen und jederzeit Tickets anlegen, ohne auf einen Menschen zu warten.

Phase 3: im Produkt. Am 1. September 2026 zog Snyk Assist in das Kernprodukt um und erscheint seither als Feld in der Kopfzeile jeder Seite, für jeden zahlenden Kunden.

Dieses gestufte Vorgehen ist die vielleicht übertragbarste Lehre. Es beginnt dort, wo Fehler wenig kosten, nämlich bei den eigenen Mitarbeitenden, und weitet den Kreis erst aus, wenn die Zahlen tragen. Für ein mittelständisches Unternehmen heißt das konkret: Der erste Einsatz gehört nicht in den Kundenkontakt, sondern in die interne Vorbereitung der Antworten.

Rechte pro Nutzer: Der Agent sieht nur, was die Person sehen darf

Ein Punkt der Fallstudie verdient besondere Aufmerksamkeit, weil er für jedes Unternehmen mit Kundendaten gilt. Snyk hat die Werkzeuge des Agenten nicht pauschal freigeschaltet. Sie werden laut Quelle zum Zeitpunkt der Anfrage nach den tatsächlichen Berechtigungen der angemeldeten Person registriert. Der Agent kann damit nur auf Daten zugreifen, die die Person ohnehin einsehen dürfte. Weil Snyk selbst Sicherheitssoftware herstellt, wurde das als Kernanforderung behandelt.

Übersetzt in die Praxis eines Mittelständlers: Ein Agent, der Kundenanfragen beantwortet, darf nicht mehr wissen und tun können als die Person, für die er gerade arbeitet. Wer eine Auskunft zum eigenen Auftrag verlangt, bekommt sie. Wer nach den Konditionen eines anderen Kunden fragt, bekommt sie nicht, auch wenn der Agent technisch Zugriff auf die Datenbank hätte. Genau diese Trennung gehört in jedes Konzept, bevor die erste Antwort rausgeht.

Die technische Grundlage in einfachen Worten

Die Fallstudie beschreibt eine Architektur, die für Entscheider nur in Grundzügen wichtig ist. Snyk Assist ist ein einziger Agent, gebaut mit LangChain und LangGraph, der hinter mehreren Oberflächen steht: einer Slack-Anwendung, einer Web-Anwendung und einem direkten Zugang über eine Schnittstelle. Die Beobachtung und Auswertung läuft über LangSmith, ein Werkzeug von LangChain. Der Gesprächsverlauf wird in einer PostgreSQL-Datenbank gespeichert, sodass Gespräche fortgesetzt werden können.

Vier Entwurfsentscheidungen nennt die Quelle:

1. Werkzeuge als klar definierte Funktionen, registriert pro Nutzer. Die meisten Werkzeuge sind eigenständige kleine Dienste. Neue Fähigkeiten lassen sich ergänzen, ohne den Kern des Agenten umzubauen.
2. Schutzmechanismen an festen Stellen. Kontextverwaltung, Leitplanken und Ausweichmodelle hängen an definierten Punkten im Ablauf und lassen sich ändern, ohne alles neu zu schreiben.
3. Gedächtnis über die Datenbank. Der Verlauf wird pro Sitzung gespeichert, damit Gespräche über mehrere Schritte hinweg funktionieren.
4. Ein gemeinsamer Agenten-Kern. Neue Abläufe brauchen meist eine Konfiguration statt einer neuen Architektur.

Für Sie ist daran vor allem ein Gedanke wichtig: Der Aufwand liegt nicht im „klugen Modell“, sondern in der Umgebung drumherum, also in Rechten, Werkzeugen, Gedächtnis und Kontrolle. Das ist übrigens kein Spezialfall von Snyk, sondern das Muster, das wir bei jedem Agenten sehen.

Der eigentliche Hebel: Prüfen, ob der Agent funktioniert

Zurück zum Zitat von Bailey Millns. Die Fallstudie widmet einen großen Teil dem Thema, das in vielen Pilotprojekten zu kurz kommt: dem Nachweis, dass der Agent zuverlässig arbeitet. Snyk verwendet dafür laut Quelle mehrere Ebenen.

Tests vor dem Start. Es gibt Testsätze mit echten Fragen und bekannten, richtigen Antworten. Ein zweites Modell bewertet die Antworten. So lässt sich schnell erkennen, ob eine Änderung an Anweisung oder Modell die Qualität verschlechtert hat. Dazu kommt automatisiertes „Red-Teaming“: Menschen und Werkzeuge versuchen gezielt, den Agenten dazu zu bringen, seine Anweisungen zu ignorieren oder Geheimnisse preiszugeben.

Eine Schranke bei jeder Änderung. Jede Änderung am Programmcode lässt den echten Agenten gegen diese Testsätze laufen. Wer die vereinbarten Schwellenwerte nicht erreicht, kann nicht ausgeliefert werden. Die Höhe der Schwellenwerte nennt die Fallstudie nicht. Bailey Millns wird sinngemäß so wiedergegeben: Wenn die Änderung die Messlatte nicht erreicht, geht sie nicht live.

Laufende Bewertung im Betrieb. Ein geplanter Auftrag bewertet jede Sitzung im Produktivbetrieb. Zusätzlich werden Fragen nach Produktbereich, Thema und Fehlerart eingeordnet. Dadurch sieht das Produktteam, wo Kundschaft Schwierigkeiten hat. Laut Quelle fließen diese Erkenntnisse auch in die Verbesserung der Dokumentation ein.

Aus Fehlern lernen. Ein schlechter Gesprächsverlauf kann direkt zu einem neuen Testfall werden. Auch die Aufzeichnungen aus der internen Phase speisten die Testsätze vor dem Kundenstart.

Für den Mittelstand ist die Lehre ernüchternd und beruhigend zugleich. Ernüchternd, weil „Agent einschalten“ nicht reicht. Beruhigend, weil sich das Prinzip auch im Kleinen anwenden lässt, ganz ohne Evaluations-Plattform: Sammeln Sie 30 bis 50 reale Kundenfragen mit den Antworten, die Ihr Team als richtig anerkennt. Lassen Sie den Agenten diese Fragen beantworten, bevor er live geht. Wiederholen Sie den Test nach jeder Änderung. Und sammeln Sie jede Antwort, die ein Mitarbeiter korrigieren musste, als neuen Testfall.

Verfügbarkeit: Was jetzt nutzbar ist und was nicht

Bei jeder Meldung dieser Art stellt sich die Frage, ob Sie das Gezeigte sofort einsetzen können. Hier lohnt eine genaue Unterscheidung.

Snyk Assist selbst ist laut Fallstudie für jeden zahlenden Snyk-Kunden im Produkt verfügbar. Das nützt Ihnen allerdings nur, wenn Sie Snyk einsetzen, und dann auch nur für Fragen zu Snyk. Eine Einschränkung nach Region nennt die Quelle nicht, eine ausdrückliche Bestätigung für Deutschland, Österreich und die Schweiz gibt es aber ebenso wenig. Der DACH-Status ist also unbekannt.

Das Muster dahinter ist dagegen kein Produkt, das Sie kaufen, sondern ein Vorgehen, das Sie nachbauen können: ein Agent mit festgelegten Werkzeugen, Rechten pro Nutzer, gestufter Einführung und laufender Auswertung. Die Fallstudie belegt, dass dieses Vorgehen bei einem Softwareanbieter funktioniert hat. Sie belegt nicht, dass es in Ihrem Haus mit denselben Zahlen funktioniert. Behandeln Sie die Meldung deshalb als Vorlage für ein Vorgehen, nicht als Produktversprechen.

Welcher Agent bei uns dazu passt: der Inbox-Manager

Auf amazing-agents.com ordnen wir diesen Anwendungsfall dem Inbox-Manager zu. Er sortiert nach Dringlichkeit, schreibt Entwürfe und meldet von Werbung ab. Der Unterschied zu Snyk Assist ist beabsichtigt und wichtig: Während Snyks Agent im Produkt direkt antwortet und Fälle eröffnet, arbeiten unsere Agenten mit Freigabe-Schritten an kritischen Stellen. Mails werden bei uns als Entwurf erstellt, nicht direkt versendet.

Das ist kein Widerspruch zum Snyk-Beispiel, sondern eine andere Dosierung. Bei einem Softwareanbieter mit Tausenden gleichartiger technischer Fragen kann ein Agent Standardantworten direkt ausspielen, sofern Tests und Messungen das tragen. Bei einem Mittelständler mit individuellen Kundenbeziehungen, Angeboten und Sonderkonditionen ist der Entwurf mit menschlicher Freigabe häufig der bessere Startpunkt. Die Antwort wird vorbereitet, die Entscheidung bleibt bei Ihrem Team.

So gehen wir im Audit vor

Wir beschreiben hier, wie wir ein solches Vorhaben in einem Audit angehen. Das ist unser Vorgehen und kein Ergebnisbericht:

1. Anfragen sichten. Wir lesen gemeinsam mit Ihrem Team eine Stichprobe der letzten Wochen und gruppieren die Anfragen: Welche wiederholen sich, welche brauchen Urteilsvermögen, welche betreffen sensible Daten?
2. Quellen klären. Wo steht die richtige Antwort, und ist sie aktuell? Ein Agent kann nur so gut antworten wie die Unterlagen, auf die er zugreift.
3. Grenzen festlegen. Was darf der Agent lesen, was darf er entwerfen, was darf er nie tun? Welche Fälle gehen immer an einen Menschen?
4. Freigabe-Schritt definieren. Zu Beginn werden Antworten als Entwurf vorbereitet und von Ihrem Team freigegeben. Erst wenn die Trefferquote belegt ist, wird über weniger Freigaben gesprochen.
5. Testsatz aufbauen. Aus Ihren echten Anfragen entsteht ein Satz von Prüffragen, gegen den jede Änderung gemessen wird.

Eine Überschlagsrechnung (Beispielrechnung, keine Prognose)

Damit die Größenordnung greifbar wird, hier ein ausdrücklich erfundenes Rechenbeispiel. Es beruht nicht auf Snyk-Zahlen und nicht auf einem unserer Projekte. Angenommen, Ihr Team bearbeitet 400 Kundenanfragen pro Woche, und für 40 Prozent davon liegt eine eindeutige Antwort in Ihren Unterlagen vor. Das wären 160 Anfragen. Braucht ein Mitarbeiter für das Lesen, Heraussuchen und Formulieren im Schnitt fünf Minuten, sind das etwa 13 Stunden pro Woche. Auch wenn der Agent nur die Hälfte davon als freigabefähigen Entwurf liefert, bleiben mehr als sechs Stunden, die zurück in schwierigere Fälle fließen können.

Setzen Sie die Zahlen auf Ihre Situation um: Anfragen pro Woche, Anteil wiederkehrender Fragen, Minuten pro Antwort. Dann wissen Sie, ob sich das Thema für Sie überhaupt lohnt, bevor Sie einen Cent investieren.

Was Sie diese Woche tun können

1. Zählen Sie nach. Wie viele Kundenanfragen kommen pro Woche herein, und wie viele davon sind Wiederholungen? Eine Strichliste über fünf Arbeitstage genügt.
2. Schreiben Sie die zehn häufigsten Fragen mit der richtigen Antwort auf. Das ist die Keimzelle eines späteren Testsatzes und zeigt zugleich, wo Ihre Unterlagen Lücken haben.
3. Legen Sie fest, was ein Agent nie allein entscheiden darf. Rabatte, Reklamationen, Vertragsfragen: Notieren Sie die Fälle, die immer ein Mensch bekommt.

Risiken und offene Fragen

• Herstellerangaben. Die Zahlen stammen aus einer Fallstudie, die LangChain über seinen Kunden Snyk veröffentlicht hat. Unabhängig geprüft sind sie nicht.
• Keine Aussage zur Qualität im Einzelfall. „Ohne Ticket gelöst“ heißt nicht zwingend „zur Zufriedenheit gelöst“. Die Fallstudie nennt keine Zufriedenheitswerte.
• Datenschutz. Wo Gesprächsdaten gespeichert werden und welches Modell sie verarbeitet, muss bei jedem Einsatz in der EU geklärt werden. Die Quelle trifft dazu keine Aussage für Europa.
• Pflegeaufwand. Testsätze, Unterlagen und Rechte müssen laufend aktuell gehalten werden. Ein Agent ist kein Projekt mit Enddatum.

Fazit: Der Unterschied liegt in den Grenzen

Die Snyk-Fallstudie ist kein Beleg dafür, dass Agenten Ihren Kundenservice über Nacht übernehmen. Sie ist ein gut dokumentiertes Beispiel dafür, wie ein Unternehmen vorgegangen ist: erst intern, dann nach außen; Rechte pro Nutzer statt Vollzugriff; Tests als Schranke vor jeder Änderung; laufende Bewertung im Betrieb. Das Ergebnis, über 85 Prozent ohne Ticket gelöste Sitzungen, ist das Resultat dieser Disziplin und nicht des Modells allein.

Der Unterschied, auf den es ankommt, ist der zwischen einem Agenten ohne Grenzen und einem Agenten mit Grenzen und Freigabe-Schritt. Ersterer beantwortet alles, was er kann, und merkt nicht, wenn er falsch liegt. Letzterer arbeitet in einem festgelegten Rahmen, bereitet Antworten vor und übergibt, wo ein Mensch entscheiden soll. Bei uns bedeutet das etwa, dass der Inbox-Manager Mails als Entwurf erstellt, statt sie direkt zu versenden. Für den Mittelstand ist das der Weg, bei dem Sie die Stunden zurückholen, ohne die Kontrolle abzugeben.

Quelle: LangChain-Blog, Oliver Armstrong, „How Snyk turned an internal support agent into a customer feature“, 8. Oktober 2026 (langchain.com/blog). Alle Zahlen und Zitate zu Snyk Assist stammen aus dieser Quelle und sind Angaben des Anbieters.