Wie wir ein KI-Agenten-Inventar führen (mit getestetem Ausschalter)

Ein KI-Agenten-Inventar ist ein Register, das jeden KI-Agenten eines Unternehmens auflistet, mit seinem Verantwortlichen, den Systemen, auf die er zugreift, und dem Schalter, der ihn stoppt. In unserem Register ist jede Zeile der Datensatz, auf dem der Agent läuft, also ist der Schalter in der Zeile genau der, der ihn stoppt. Ein Inventar, aus dem heraus Sie nichts abschalten können, ist eine Liste von Dingen, von denen Sie hoffen, dass sie gestoppt sind.

Am Ende haben Sie ein Register aller KI-Agenten, die Ihr Unternehmen betreibt, mit den Schlüsseln, auf die jeder davon zugreift, und einem Ausschalter in jeder Zeile außer bei Umgebungen, den Sie benutzt und geprüft haben. Für ein kleines Unternehmen dauert das einen Nachmittag. Was Agent Sprawl ist erklärt das Warum; diese Seite zeigt, wie Sie Agent Sprawl in der Praxis verhindern.

Die Beispiele nutzen Kettlewick, eine fiktive Online-Kaffeerösterei, die Bohnen im Abo verkauft, und Ines, die dort den Betrieb leitet. Namen und Uhrzeiten sind erfunden; Feldnamen, Status, Regeln und Schwellenwerte sind echt.

Was Sie vor dem Start brauchen

Jeder Agent muss als Datensatz mit einem Ein/Aus-Schalter in einem System geführt werden. Wir nutzen ConvOps.

Wir führen unseres in ConvOps(wird in einem neuen Tab geöffnet), dem System, das das ganze Unternehmen mit geplanten Agenten betreibt.

Schritt 1: Die sechs Arten von Zeilen erfassen

Führen Sie das Register in den Datensätzen, auf denen die Agenten laufen. Eine zweite Kopie in einer Tabellenkalkulation veraltet an dem Tag, an dem jemand einen Agenten hinzufügt, und der Schalter steht nie in der Tabelle.

Sechs Arten von Zeilen, fünf Schalter: einen Agenten deaktivieren, einen Runner deaktivieren, seine offenen Läufe stoppen und seine Zeitpläne pausieren, einen Zeitplan pausieren, eine Familie pausieren, Secrets in einer Umgebung nur als Referenzen führen, einen Schlüssel widerrufen.

Die Registerzeile (eine kopierbare Vorlage für ein KI-Agenten-Register)

ConvOps führt die meisten dieser Felder als Datensätze. Zwei füllen Sie selbst aus: ConvOps hält einen Verantwortlichen an einer Familie fest, nicht an einem Agenten oder Runner, also tragen Sie den Verantwortlichen selbst ein, ebenso das Ergebnis des letzten Schaltertests.

name:              review-replier
kind:              agent
owner:             Ines
purpose:           drafts replies to customer reviews
runner:            cloud-runner-main
schedule/trigger:  Review replies, daily 18:00
keys it reaches:   Model key (subscription), SHOP_API_KEY (reference)
off switch:        disable (refused while Reply to reviews names it)
last switch test:  <date, what you switched, what you saw after>

Eine Liste, die jemand von Hand pflegt, sagt Ihnen, dass ein Agent existiert. Sie ist nicht das, was ihn stoppt.

Sehen Sie, wie ConvOps jeden Agenten, Runner, Zeitplan und Schlüssel als Datensatz führt, den Sie abschalten können(wird in einem neuen Tab geöffnet).

Schritt 2: Die Agenten finden, die niemand registriert hat

Nicht registrierte Agenten finden Sie über die Schlüssel und die Zeitpläne, nicht durch Herumfragen.

Beginnen Sie bei den Schlüsseln: Der Datensatz jedes Schlüssels in ConvOps listet die Runner, die ihn nutzen, mit dem Status des Credentials und nie mit seinem Wert. Gleichen Sie jeden Runner mit dem Register ab. Ein Runner ohne Zeile ist ein Agent, den niemand registriert hat.

Jeder Schlüssel listet die Runner, die ihn nutzen, und laptop-runner fehlt im Register: Er ist der Agent, den niemand registriert hat.

Bei Kettlewick listet „Model key (subscription)“ cloud-runner-main und laptop-runner. Nur der erste hat eine Zeile, also erhält laptop-runner eine, bevor irgendetwas anderes passiert.

Danach gehen Sie die Zeitpläne durch:

• Jeder Zeitplan, auch die pausierten. Der Tab „Paused“ (Pausiert) behält jede Zeile mit ihrer Regel.
• „Missed its last fire“ (letzte Auslösung verpasst). Ein wiederkehrender Zeitplan erhält diese Markierung nach einer verspäteten Auslösung.
• „No run for too long“ (zu lange kein Lauf). Die Markierung wechselt dazu nach dem 1,5-Fachen der längsten normalen Lücke des Zeitplans: 36 Stunden bei einem täglichen Job. 1,5 ist der Standardwert, einstellbar von 1 bis 10.
• Eine Familie, deren Urteil silent lautet. Der Wert silent_count sagt, wie viele Mitglieder verstummt sind.

Chatbots, die Mitarbeitende über private Konten nutzen, sind ein anderes Problem: Schatten-KI im Unternehmen.

Schritt 3: Jedem Agenten einen Ausschalter geben (einen Notausschalter für KI-Agenten, den Sie auch finden)

Jede Zeile außer einer Umgebung erhält genau einen Schalter, den Sie benennen können, und ConvOps verweigert den einen Schalter, der einen Workflow lahmlegen würde, der den Agenten noch nutzt.

Wenn Sie einen Zeitplan einer pausierten Familie zuordnen, gibt es standardmäßig eine Warnung, und er löst erst aus, wenn die Familie fortgesetzt wird. Secrets haben keinen Schalter, weil das Register sie nie speichert. ConvOps führt jedes Secret als Referenz mit einem Label und einem Status wie set und nimmt den Wert nie entgegen und gibt ihn nie aus.

Der Schalter, den ConvOps verweigert

ConvOps verweigert das Deaktivieren eines Agenten, solange ein Schritt eines aktiven Workflows auf ihn verweist. Die Ablehnung kommt als HTTP 409 mit dem Code agent_in_use, schreibt nichts und nennt jeden Workflow und Schritt, in dem der Agent eingetragen ist. Sie entscheiden: Entfernen Sie den Agenten aus diesen Schritten, oder deaktivieren Sie zuerst diese Workflows.

ConvOps verweigert das Deaktivieren von review-replier, solange der aktive Workflow Reply to reviews ihn im Schritt draft-reply verwendet, und die Ablehnung sagt, wie Sie den Weg freimachen.

Bei Kettlewick wird das Deaktivieren von review-replier verweigert, weil der aktive Workflow „Reply to reviews“ ihn im Schritt draft-reply verwendet. Ihn abzuschalten würde den Job mitten im Workflow abbrechen lassen, also lässt das System Sie zuerst entscheiden. Verweisen nur deaktivierte Workflows auf den Agenten, gelingt das Deaktivieren, und ConvOps meldet diese Workflows. Ein isolierter Runner hält jeden Lauf von Ihrem Rechner getrennt, wie in So verhindern wir, dass Claude Code Dateien löscht.

Schritt 4: Den Ausschalter testen: ein Lauf Schritt für Schritt

Einen Schalter testen Sie, indem Sie beobachten, was danach passiert, nicht indem Sie ihn umlegen. Der Beweis ist eine Auslösezeit, die vergeht, ohne dass in der Zeile etwas erscheint.

Ines testet den Schalter an „Review replies“ (täglich 18:00 Uhr, Familie „Customer care“, Runner cloud-runner-main), während eine Antwortvorlage überarbeitet wird:

Review replies wird um 17:40 Uhr pausiert, sein offener Lauf wird mit „schedule stopped“ abgebrochen, um 18:00 Uhr läuft nichts, und die Zeile behält Regel und Runner.

Die Ergebniszeile ist eine Notiz, die Sie in die Registerzeile schreiben:

off switch tested: paused 17:40, no run at 18:00, open run cancelled, restart runner cloud-runner-main

Bestanden heißt: kein Lauf nach der Auslösezeit, der offene Lauf abgebrochen und ein Neustart, der auf dem angegebenen Runner landet. Existiert der gespeicherte Runner nicht mehr, verweigert ConvOps den Neustart, bis Sie einen anderen Runner angeben oder die Angabe entfernen. Einen Runner testen Sie genauso: Pausieren Sie die Zeitpläne, die auf ihn verweisen, deaktivieren Sie ihn, stoppen Sie seine offenen Läufe und prüfen Sie, dass nichts Neues startet. Agenten zu beobachten, während sie laufen, ist KI-Agenten-Observability.

Schritt 5: Stilllegen, nicht löschen

Löschen Sie nie einen Agenten. Deaktivieren Sie ihn, behalten Sie seine Historie, und behandeln Sie das Wiedereinschalten als Teil des Schalters.

Das Wiedereinschalten gehört zum Schalter: Die zwei Regeln dafür stehen unten unter „Häufige Fehler“.

Erstellen Sie ein kostenloses ConvOps-Konto und beginnen Sie Ihr Register mit den Agenten, die Sie bereits betreiben(wird in einem neuen Tab geöffnet).

Häufige Fehler

Wir haben unsere Ausschalter dreimal falsch benutzt. Jedes Mal sah der Stopp erledigt aus, die Arbeit kam zurück, und es blieb eine Regel.

Den Zeitplan pausieren, aber nicht seine Läufe

Wir haben einen Zeitplan pausiert und seine offenen Läufe offen gelassen, und der Wiederherstellungsjob, der verstummte Läufe erneut sendet, hat sie noch einmal gesendet. Bei Kettlewick: „Old promo emails“ ist pausiert, sein offener Lauf kw-run-117 bleibt todo, und der Wiederherstellungsjob sendet ihn beim nächsten Durchgang.

Wer nur den Zeitplan pausiert, lässt seinen offenen Lauf für den Wiederherstellungsjob liegen, der ihn erneut sendet; Pausieren und Abbrechen in einer Änderung sorgt dafür, dass der Stopp hält.

Die Regel: Ein Stopp besteht aus zwei Schreibvorgängen in einer Änderung. Der Zeitplan wird angehalten, und jeder offene Lauf wird mit „schedule stopped“ abgebrochen; abgeschlossene Läufe werden nie umgeschrieben. Ein einfaches Pausieren in ConvOps erledigt beides, und aus demselben Grund stoppt der Runner-Schalter immer auch seine offenen Läufe.

Einen Runner zu veralteten Läufen zurückkehren lassen

Wir haben einen Runner nach einem Ausfall zurückgeholt, ohne seine Warteschlange zu leeren, also hat der Wiederherstellungsjob alle veralteten Läufe auf einmal erneut gesendet, und die Flut hat dem aktuellen Lauf alle Kapazität genommen. Bei Kettlewick ist das cloud-runner-cheap, der zu einer Warteschlange zurückkehrt, die niemand mehr braucht.

Die Regel: Brechen Sie veraltete Läufe ab, bevor der Runner zurückkommt.

Einen Zeitplan ohne seinen Runner neu starten

Wir haben einen Zeitplan neu gestartet, der für einen neuen Runner gedacht war, und seinen nächsten Lauf nicht geprüft, der auf dem alten Runner auslöste. Bei Kettlewick: „Monthly price research“ wird für einen neuen Runner neu gestartet, und niemand prüft, welchen Runner sein nächster Lauf genutzt hat.

Die Regel: Geben Sie beim Neustart den Runner an, und prüfen Sie, dass der nächste Lauf ihn genutzt hat. ConvOps merkt sich den Runner über eine Pause hinweg und verweigert einen Neustart, dessen gespeicherter Runner nicht mehr existiert. So wird aus einem Fehler eine Regel, bei allem, was wir betreiben.