Deine Agenten-Instruktionen haben kein Backup

Grundlage sind Beobachtungen und Diskussionen aus Anwender-Communities rund um Enterprise-KI-Plattformen, anonymisiert und ohne Nennung einzelner Unternehmen.

Der Fall, der die Frage aufwirft

Diese Woche hat ein Editor-Update in einer weit verbreiteten KI-Plattform bei bestehenden Agenten-Anweisungen die Struktur entfernt. Teams, die ihre Anweisungen nach einem festen Schema gebaut hatten, mit klar getrennten Abschnitten für Rolle, Aufgabe und Regeln, fanden danach nur noch Fließtext vor. Die Agenten liefen weiter, aber sie arbeiteten nicht mehr so, wie sie sollten. Kein Rollback, kein Export, kein Hinweis vorab.

Ein betroffenes Team beschrieb das Zurückschreiben von Hand als mehrtägige Arbeit. Nicht weil der Text lang war, sondern weil niemand mehr genau wusste, wie die Anweisung vorher ausgesehen hatte.

Genau da liegt das eigentliche Problem, und es ist nicht das Problem des Anbieters.

Warum das fast überall so ist

In unseren Rollouts sehen wir dasselbe Muster in nahezu jedem Haus. Die Anweisungen der wichtigsten Agenten existieren an genau einer Stelle: in einem Eingabefeld im Tool. Über Monate ist dort etwas entstanden, das jede Prüfung als Geschäftslogik bestehen würde. Die Reihenfolge, in der ein Angebot geprüft wird. Die Ausnahmen, die eure erfahrenste Sachbearbeiterin im Kopf hat. Die Formulierung, mit der ihr Kunden absagt, ohne sie zu verlieren.

Aufgeschrieben von den Leuten, die den Prozess am besten kennen. Behandelt wie eine Notiz.

Das passiert nicht aus Nachlässigkeit. Es passiert, weil das Feld im Tool sich anfühlt wie ein Textfeld und nicht wie ein Produktivsystem. Niemand kommt auf die Idee, eine Notiz zu versionieren.

Schritt 1: Bestandsaufnahme

Der erste Schritt ist banal und deckt allein schon rund achtzig Prozent des Risikos ab. Nehmt euch eine halbe Stunde und legt ein Dokument außerhalb eures KI-Tools an. Für jeden Agenten, der produktiv im Einsatz ist, vier Felder:

1. Zweck in einem Satz. Wofür ist dieser Agent da, in der Sprache des Fachbereichs, nicht der IT.
2. Verantwortliche Person. Ein Name, keine Abteilung. Wer merkt es zuerst, wenn dieser Agent Unsinn macht?
3. Vollständiger Anweisungstext. Kopiert, nicht zusammengefasst. Genau so, wie er im Tool steht, inklusive aller Formatierung.
4. Datum der Kopie. Ohne Datum ist die Kopie später wertlos, weil niemand weiß, welche Fassung aktueller ist.

Wenn ihr an diesem Punkt merkt, dass ihr gar nicht sicher wisst, wie viele produktive Agenten es bei euch gibt, ist genau das der wertvollste Befund des Tages.

Schritt 2: Die Kopie an einen Ort legen, der überlebt

Ein Dokument in der Ablage ist besser als nichts, aber es hat dasselbe Problem wie das Tool: Es kennt nur den aktuellen Stand. Wer schon mit Versionsverwaltung arbeitet, legt die Anweisungen als einfache Textdateien dorthin, eine Datei pro Agent. Jede Änderung ist dann nachvollziehbar, mit Datum, Autor und Begründung.

Für alle anderen reicht eine simple Regel: Vor jeder Änderung an einer Anweisung wird die alte Fassung mit Datum in dasselbe Dokument kopiert, darunter die neue. Das ist unelegant und funktioniert.

Der Test dafür, ob es trägt: Könnt ihr sagen, wie die Anweisung eures wichtigsten Agenten vor sechs Wochen ausgesehen hat? Wenn nein, habt ihr keine Versionierung, sondern eine Kopie. Wo Langdock Agenten in automatisierten Abläufen ansetzen, zeigt unser Guide.

Schritt 3: Struktur bewusst wählen

Die Teams, die es diese Woche am härtesten getroffen hat, waren nicht die schlampigen, sondern die gründlichen. Sie hatten ein einheitliches Schema für alle Agenten durchgesetzt, mit klar abgegrenzten Abschnitten. Genau diese Struktur wurde bei der Migration entfernt, und weil das Schema für alle Agenten galt, traf es alle auf einmal.

Die Lehre daraus ist nicht, auf Struktur zu verzichten. Sie ist:

• Haltet die Struktur so einfach, wie sie sein kann. Überschriften und Aufzählungen überleben fast jede Migration. Exotische Auszeichnungen überleben sie oft nicht.
• Prüft nach jedem Tool-Update eure wichtigsten drei Agenten. Nicht alle, drei reichen. Wenn dort etwas kaputt ist, ist es überall kaputt.
• Testet nicht die Oberfläche, sondern das Verhalten. Eine Anweisung, die im Editor gut aussieht, kann trotzdem anders beim Modell ankommen. Der einzige verlässliche Test ist eine Aufgabe, deren richtiges Ergebnis ihr kennt.

Schritt 4: Eine Person, die es merkt

Der letzte Schritt ist organisatorisch. Jeder produktive Agent braucht eine Person, die für ihn zuständig ist, und einen festen Moment, an dem draufgeschaut wird. Einmal im Monat, fünfzehn Minuten, mit drei Fragen: Tut er noch, was er soll? Ist die Anweisung im Dokument noch die, die im Tool steht? Braucht ihn überhaupt noch jemand?

Der dritte Punkt räumt mehr auf, als die meisten erwarten. Agenten-Bestände wachsen leise. Ein Teil davon ist nach einem halben Jahr niemandes Werkzeug mehr, verbraucht aber weiter Rechte und Aufmerksamkeit.

Was das kostet und was es spart

Der komplette Aufbau kostet eine halbe Stunde Bestandsaufnahme plus fünfzehn Minuten im Monat. Dagegen stehen die mehreren Tage, die ein betroffenes Team diese Woche gebraucht hat, um wiederherzustellen, was nie gesichert war.

Wer noch einen Grund braucht: Dieselbe Sicherung ist auch die Grundlage dafür, den Anbieter überhaupt wechseln zu können. Anweisungen, die nur in einem Tool existieren, sind kein Wissensbestand. Sie sind eine Konfiguration, die jemand anderem gehört.