Den ersten KI-Agenten produktiv einsetzen

Es ist halb drei nachts und etwas läuft schief. Ein Dienst wird langsam, eine Bestellung bleibt hängen, eine Zahl im Dashboard kippt. Jemand sitzt im Halbschlaf vor drei Bildschirmen und sucht in den letzten zwölf Änderungen die eine, die alles ausgebremst hat.

Genau das ist eine Aufgabe, die ein guter KI-Agent übernehmen könnte. Belege sammeln, Verdächtige eingrenzen, eine erste These liefern, statt Sie vor einen leeren Schirm zu setzen.

Also bauen Sie einen. Sie hängen ein Modell an ein paar Werkzeuge, geben ihm eine Anweisung und sehen zu, wie es sich zur Ursache durchdenkt. In der Demo funktioniert das. Alle lehnen sich vor.

Und dann muss das Ding wirklich laufen. Nicht auf Ihrem Laptop um 15 Uhr, während Sie zuschauen. Sondern im Betrieb, nachts, allein. Das ist eine völlig andere Maschine.

Die Demo war nie der schwere Teil. Schwer ist alles, was die Demo stillschweigend überspringt.

Die Lücke, die in keiner Demo vorkommt

Eine Demo beweist, dass ein Agent denken kann. Der Betrieb fragt, ob man sich auf ihn verlassen kann. Dazwischen liegen Probleme, die auf einem Laptop in einem Meetingraum nie auftauchen.

Die Maschine, auf der der Agent läuft, stürzt mitten in der Arbeit ab und nimmt die halbfertige Untersuchung mit. Der Agent braucht Ihre Zugangsdaten zum Monitoring, und plötzlich hält ein unberechenbares Modell Schlüssel, die bis in den Betrieb reichen.

Jemand lädt die Seite neu, und die Sitzung ist weg. Der Agent kommt zu einem falschen Schluss, und Sie haben keine Möglichkeit zu sehen, warum, weil nirgends steht, was er sich in welcher Reihenfolge angesehen hat.

Bevor man das aber reparieren kann, lohnt sich ein Blick darunter. Was ist ein Agent überhaupt, wenn man die Verpackung wegnimmt?

Ein Agent ist im Kern eine Schleife

Nehmen Sie das Branding weg, dann ist ein KI-Agent eine Schleife. Das Modell bekommt ein Ziel und die Werkzeuge, die es benutzen darf.

Es schlägt eine Aktion vor, etwa die Antwortzeiten auslesen. Etwas führt diese Aktion aus und gibt das Ergebnis zurück. Das Modell sieht sich das Ergebnis an und schlägt die nächste Aktion vor, etwa die letzten Änderungen am System auflisten. Ausführen, zurückgeben, wiederholen, bis das Modell entscheidet, dass es fertig ist.

Diese Schleife ist das ganze Spiel. Das Modell selbst, über das alle reden, ist fast der einfache Teil. Sie rufen eine Schnittstelle auf, und es kommen Wörter zurück.

Schwer ist alles um die Schleife herum. Den wachsenden Gesprächsverlauf im Griff behalten. Entscheiden, was passiert, wenn das Gedächtnis des Modells voll ist. Werkzeuge sicher ausführen. Wiederholen, wenn etwas scheitert. Und den Faden nicht verlieren, wenn eine Maschine neu startet.

Daraus folgt die einzige Frage, die für Ihren ersten Agenten zählt. Wie viel von dieser Maschinerie sollten Sie selbst bauen?

Bauen Sie nur den Teil, den nur Sie bauen können

Es gibt grob drei Wege, diese Schleife zum Laufen zu bringen. Jeder Weg gibt eine Schicht der Klempnerei an jemand anderen ab.

Der erste Weg ist das nackte Modell. Ein einzelner Aufruf, volle Kontrolle und volle Verantwortung. Sie bauen die Schleife, das Gedächtnis, das Aufräumen, das Zwischenspeichern und den Betrieb von Hand. In Ordnung, solange Agenten einfach sind. Mühsam, sobald sie es nicht mehr sind.

Der zweite Weg ist ein Baukasten. Die Schleife, die Werkzeuge und der Umgang mit dem Gedächtnis kommen fertig verpackt. Hier sitzen heute die meisten Teams, und das ist ein echter Schritt nach vorn. Aber Sie betreiben es weiter selbst, skalieren es selbst und halten es selbst sicher.

Der dritte Weg sind betreute Agenten. Die Schleife selbst zieht auf gepflegte Infrastruktur um. Abschottung, Werkzeuglaufzeit, Beobachtbarkeit, Ausfallsicherheit, alles übernommen. Was bei Ihnen bleibt, ist der Teil mit Ihrem eigentlichen Wissen: die Aufgabe, die Einstellung des Agenten und Ihre eigene Werkzeuglogik.

Der Trend ist die Lehre. Bauen Sie nur den Teil, den nur Sie bauen können, und leihen Sie sich den Rest.

Es gibt einen stillen Grund, mehr zu leihen, als sich gut anfühlt. Wer eine eigene Agenten-Maschinerie auf ein bestimmtes Modellverhalten abstimmt, schaut beim nächsten Modell oft auf eine Anpassung, die nun überflüssig ist. Eine selbst gebaute Maschinerie ist keine einmalige Ausgabe, sondern eine Pflegeverpflichtung, die mit jedem Modellwechsel mitziehen muss.

Wer eine Regel schreibt, zahlt einmal. Wer eine Maschinerie pflegt, zahlt bei jedem Modellwechsel wieder.

Die eine Idee: Kopf und Hände trennen

Hier hängt alles dran. Wenn Sie aus diesem Artikel eine Sache mitnehmen, dann diese.

Im einfachsten Agenten sitzen das Denken, also die Schleife, die entscheidet, was als Nächstes passiert, und das Handeln, also der Code, der Werkzeuge ausführt und Ihre Systeme anfasst, am selben Ort. Für einen Programmier-Assistenten, der tiefen Zugriff auf Ihre Dateien braucht, ist das richtig. Für die meisten Agenten im Geschäft ist es ein Risiko.

Denken Sie an eine Chirurgin und ihre Instrumente. Die Chirurgin entscheidet, die Instrumente schneiden. Sie würden dem Skalpell nie die Kontodaten der Patientin in die Hand drücken, nur weil es gerade im Raum liegt.

Trennen Sie das Entscheiden vom Tun. Denken auf der einen Seite, Ausführen auf der anderen. Das ist die bauliche Form des Prinzips hinter jedem Ablauf, den wir bei Schwarzwald Digital aufsetzen: KI für das Urteil, Code für die Tat.

Ziehen Sie die beiden auseinander, dann verbessern sich drei Dinge auf einmal.

• Sicherheit. Die denkende Schleife hält Ihre Zugangsdaten nie. Schlüssel bleiben auf der ausführenden Seite, verschlüsselt, und werden nur im Moment der Ausführung gereicht. Ein Modell kann kein Geheimnis verraten, das es nie bekommen hat.
• Ausfallsicherheit. Stirbt die ausführende Maschine, ist das Gedachte nicht verloren. Die Schleife bleibt erhalten, eine frische Maschine macht weiter. Die Untersuchung überlebt die Infrastruktur.
• Tempo. Wenn die Schleife nicht für jede Sitzung an eine frisch hochgefahrene Maschine geschraubt ist, zahlen Sie diesen Start nicht bei jeder Anfrage als Wartezeit.

Entscheiden Sie, wo Ihr Kopf endet und Ihre Hände beginnen, und die meisten anderen Architekturfragen beantworten sich von selbst.

Drei Stücke bauen den Agenten: Agent, Umgebung, Sitzung

Mit getrenntem Kopf und getrennten Händen setzt sich ein Agent aus drei Stücken zusammen. Bleiben wir beim nächtlichen Bereitschafts-Agenten, damit es greifbar bleibt.

Der Agent ist die Definition. Welches Modell, welche Anweisung, welche Werkzeuge er erreichen darf. Unserer braucht eine erstaunlich kurze Anweisung und vier Werkzeuge, nach denen ein Mensch auch greifen würde: Kennzahlen lesen, letzte Änderungen auflisten, die Differenz einer Änderung holen, Protokolle abrufen. Die Fähigkeit kommt aus den Werkzeugen und dem Kontext, nicht aus einer zweitausend Wörter langen Anweisung.

Die Umgebung sind die Hände. Der Raum, in dem der Agent handelt, und vor allem seine Netzgrenze. Behandeln Sie diese Grenze als Erlaubnisliste, nicht als offene Tür. Wenn der Agent nur das Monitoring erreichen muss, ist das das Einzige, was er erreichen kann. Diese Umgebung kann in Ihrer eigenen Infrastruktur laufen, dort, wo Ihre Daten ohnehin liegen.

Die Sitzung ist die Bindung. Sie verbindet einen Agenten mit einer Umgebung und gibt ihm den Kontext für genau diese Aufgabe, also für uns die Protokolle und Kennzahlen dieses einen Vorfalls. Die Sitzung streamt Ihnen die Arbeit des Agenten auch live zurück. Ein Vorfall, eine Sitzung.

Der Agent weiß, wie man denkt. Die Umgebung gibt ihm einen sicheren Ort zu handeln. Die Sitzung ist dieser eine Fall, jetzt, mit diesen Daten.

Im Betrieb spricht der Agent in Ereignissen, und er wird gut gefüttert

Ein Agent in der Demo denkt in Wörtern. Eine Anfrage rein, ein Block Text raus. Ein Agent im Betrieb denkt in Ereignissen.

Jede bedeutsame Handlung, eine Nachricht, ein Werkzeugaufruf, ein Ergebnis, ein Stück Antwort, ist ein Ereignis und wird an das Protokoll der Sitzung angehängt. Das klingt nach einer Formalie. Es ist die Grundlage für drei Eigenschaften, ohne die man nicht in den Betrieb gehen sollte.

Erstens Nachvollziehbarkeit. Weil jeder Schritt ein protokolliertes Ereignis ist, sehen Sie genau, was der Agent in welcher Reihenfolge getan hat. Liegt er falsch, lesen Sie die Entscheidung nach, statt zu raten.

Zweitens Sichtbarkeit in Echtzeit. Die Ereignisse erreichen Sie, während sie passieren. Sie schauen zu, wie der Agent den Vorfall aufnimmt, die Kennzahlen liest, die Änderungen zieht, statt auf einen sich drehenden Kreisel zu starren.

Drittens Haltbarkeit. Weil die Sitzung ein Protokoll von Ereignissen ist und keine einzelne laufende Anfrage, lässt sie sich anhalten, fortsetzen und erneut abspielen. Eine tote Maschine killt die Aufgabe nicht, weil das Protokoll die Wahrheit ist.

Und noch etwas. Hier verbringen Teams, die gute Agenten ausliefern, ihre Zeit, und es ist nicht die Anweisung. Die rohe Intelligenz des Modells ist weitgehend fest. Was Sie steuern, ist das, was Sie ihm vorlegen.

Unser Bereitschafts-Agent ist nur so scharf wie die Daten, die er erreicht: die Protokolle, die Kennzahlen, die Änderungshistorie, die Differenzen. Geben Sie ihm den richtigen Kontext, und er denkt wie eine kompetente Person in Bereitschaft. Hungern Sie ihn aus, rettet keine Anweisung den Tag.

Drei Hebel machen die meiste Arbeit. Daten, die der Agent verarbeiten kann und nicht nur liest. Skills, also dokumentierte Arbeitsroutinen, in denen steht, wie frühere Fälle gelöst wurden, ist mehr wert als jede getunte Anweisung. Und Disziplin bei der Relevanz, denn mehr Kontext ist nicht besser, der richtige Kontext ist besser.

Ein Agent im Betrieb ist ein Kontext-Projekt, das eine Anweisung trägt.

Genau hier kommt auch unsere Haltung ins Spiel. Nicht alles braucht einen Agenten. Eine Regel kostet nichts, irrt nie und läuft in zehn Jahren noch. Erst wenn der Fall zu wechselhaft für eine Regel und zu urteilsabhängig für eine starre Automatisierung ist, lohnt der Agent. Das ist auch unsere Faustregel bei den Managed KI-Mitarbeitern: Ein Agent passt, wenn Sie den Ablauf einem neuen Menschen in einer Stunde erklären könnten.

Lesen darf er allein, handeln nur mit Freigabe

Ein Agent, der im Moment eines Ereignisses auf folgenschwere Dinge handeln kann, ist auch ein Agent, der sich um halb drei nachts irren kann, ohne dass jemand zusieht. Ein funktionierender Agent ist noch kein vertrauenswürdiger.

Wir halten fünf Eigenschaften, bevor etwas in den Betrieb geht, und jede knüpft an etwas an, das Sie oben schon kennengelernt haben.

• Begrenzt. Er erreicht nur, was er braucht. Erlaubnisliste im Netz und eng gefasste Werkzeuge, kein offener Zugang. Unser Vorfall-Agent liest Monitoring und Änderungen, an die Lohnabrechnung kommt er nicht.
• Belegt. Jede Aussage stützt sich auf etwas, das der Agent wirklich geholt hat, eine Kennzahl, eine Protokollzeile, eine Differenz. Kann er etwas nicht belegen, sagt er das, statt es zu erfinden.
• Freigegeben. Folgenschwere Schritte passieren erst nach einem Kontrollpunkt. Der Agent untersucht und empfiehlt frei. Vom Empfehlen zum Ausführen geht es über einen Menschen oder eine klare Regel. Lesen darf laufen, Ändern wird freigegeben.
• Beobachtet. Jeder Schritt ist hinterher sichtbar. Weil der Agent in Ereignissen spricht, ist jeder Werkzeugaufruf protokolliert und prüfbar.
• Geführt. Zugangsdaten und Verantwortung sind kontrolliert. Schlüssel berühren die denkende Schleife nie. Und der Agent hat einen Verantwortlichen mit Namen. Das Team besitzt ihn ist kein Besitz.

Mensch im Loop nur bei der Freigabe, nicht bei jedem Schritt. Genau diese Linie macht aus einer Architektur eine Disziplin.

Eine echte Nacht, vom Alarm bis zur Korrektur

02:14. Ein Signal feuert, die Antwortzeit des Bestelldienstes liegt grob zehnmal über dem Normalwert. Niemand ist wach. Der Alarm weckt den Agenten, eine Sitzung öffnet.

Er bestätigt das Symptom. Er liest die Kennzahlen, der Ausschlag ist echt, frisch und auf den Bestelldienst begrenzt. Das Aufkommen ist normal, also kein Last-Problem.

Er sucht eine Ursache. Er listet die letzten Änderungen und findet drei im Zeitfenster. Er holt die Differenz jeder einzelnen. Eine baut den Erzeuger der Bestellzusammenfassung um.

Er belegt die These. Dieser Umbau hat eine Abfrage eingeführt, die einmal pro Position läuft statt einmal pro Bestellung. Unter echtem Bestellaufkommen erschöpfen diese Abfragen den Verbindungspool zur Datenbank, Anfragen stauen sich, die Antwortzeit steigt genau so, wie die Kennzahlen es zeigen.

Er schließt die Alternativen aus. Keine Infrastruktur-Änderung im Fenster, kein Aufkommens-Sprung, die anderen beiden Änderungen betreffen unbeteiligten Code.

02:21. Der Agent meldet zurück. Ursache: erschöpfter Verbindungspool durch den Umbau der Bestellzusammenfassung. Empfehlung in Reihenfolge: die Änderung zurücknehmen, oder, wenn vorwärts, die Abfrage begrenzen und den Pool als Notbehelf vergrößern.

Und dann hört er auf.

Er nimmt die Änderung nicht von selbst zurück. Ändern im Betrieb hat Folgen, also passiert es den Kontrollpunkt. Ein Mensch liest die These, schon zusammengetragen, schon belegt, gibt die Rücknahme frei, und die Antwortzeit fällt. Aus dem Geschrammel um halb drei wurde eine Entscheidung von dreißig Sekunden.

Der Agent hat die Untersuchung gemacht. Der Mensch hat das Urteil behalten, auf das es ankommt.

Sie halten jetzt ein Bild, das die meisten Teams nie zusammensetzen. Ein Agent ist eine Schleife. Die Entscheidung, auf die es ankommt, ist Kopf gegen Hände. Drei Stücke bauen ihn, drei Gewohnheiten lassen ihn laufen, fünf Eigenschaften machen ihn vertrauenswürdig.

Der ehrliche Teil ist der gleiche, den wir jedem Team sagen. Die Architektur ist lernbar. Die Disziplin, einen Agenten begrenzt, belegt, freigegeben, beobachtet und geführt zu halten, während sich das Modell darunter ständig ändert, ist eine Praxis und kein einmaliges Aufsetzen.

Die meisten bleiben nicht stecken, weil sie das nicht verstehen. Sie bleiben stecken, weil es keine geteilte Praxis dafür gibt. Eine Person baut etwas Gutes, es lebt auf ihrem Laptop, und es wird nie zur Art, wie das Team arbeitet.

Wenn Sie zuerst sortieren wollen, wo KI in Ihren Abläufen hingehört und wo nicht, ist die AI Readiness (/readiness) der ehrliche Anfang: ein Befund mit benannten Verantwortlichen und einem ersten BrandOS-Rohgerüst, auch mit klaren nicht empfohlen Markierungen, wo ein Agent das falsche Werkzeug wäre.

Wenn Sie diese Praxis an Ihrer eigenen Arbeit lernen wollen, live und vom Gründer, führt die AI Academy (/academy) dort hin. Und wenn Sie einen fertigen Agenten lieber abonnieren und die Wartung abgeben möchten, sind die Managed KI-Mitarbeiter (/agenten) der direkte Weg. Was wir betreiben, pflegen wir.