KI-Agenten im Unternehmen: Was braucht es, damit sie schnell und verlässlich arbeiten?

In der Nacht zum 17. September stieß einer unserer Agenten um 23:27 Uhr auf einen Widerspruch. Er sollte seine eigene Arbeit testen, brauchte dafür ein bestimmtes Werkzeug, durfte es aber nicht benutzen: Sein Zugang hat bewusst keine Administratorrechte. Zwei ältere Beschlüsse schienen einander auszuschließen.

Hier hätte die Arbeit bis zum nächsten Morgen liegenbleiben können. Stattdessen las die Orchestrierung nach, also die Steuerung, die unsere Agenten verteilt und ihre Aufträge verwaltet. Es fehlte kein dritter Beschluss, sondern nur das Wie: Es gibt eine Betriebsart des Werkzeugs, die ohne Administratorrechte auskommt. Um 00:23 Uhr entschied die Steuerung das innerhalb des bereits beschlossenen Rahmens, mit ausdrücklicher Widerspruchsmöglichkeit. Den anderen, weitergehenden Weg verwies sie als Sicherheitsentscheid an einen Menschen zurück.

56 Minuten, ohne jemanden zu wecken, und mit einer klar benannten Grenze.

Dass das funktioniert, liegt nicht an der KI. Es liegt daran, dass vorher schriftlich feststand, welche Art von Entscheidung im Rahmen liegt und welche nicht.

Die Geschichte hat allerdings eine Fortsetzung, und die gehört dazu. Die Umstellung brachte das Werkzeug zum Laufen, legte aber den Dienst lahm, der die Aufträge an die Agenten verteilt: Ab 00:41 Uhr startete über ihn kein einziger Lauf mehr. Gefunden und benannt hat das die Flotte selbst, keine Stunde später. Zurückgenommen wurde die Einstellung um 02:37 Uhr und um 02:53 Uhr als behoben gemessen.

Eine Entscheidung im richtigen Rahmen ist also noch keine richtige Entscheidung. Was sie brauchbar macht, ist die Messung danach. Darauf kommen wir bei Voraussetzung 4 zurück.

Unser Tipp: Halten Sie schriftlich fest, was ein Agent ohne Rückfrage entscheiden darf und was an einen Menschen zurückgeht.

In einer Besprechung am frühen Nachmittag fiel ein Wunsch: ein eigener Zugang mit Leserechten, der zeigt, welche KI-Konten gerade frei sind und wann sie wieder frei werden. Um 14:23 Uhr legte die Steuerung daraus einen Arbeitsauftrag an.

Agenten bauten daraus eine Anwendung aus unserer Hausvorlage, mit Tests und allem, was zum Einbau gehört. Parallel lief allerdings eine Kundenvorführung, und bei der darf nichts dazwischenkommen.

Die Leitplanke, die dafür galt, nannte eine Uhrzeit: bis 18:01 Uhr Programmieren und Testen ja, aber nichts auf den laufenden Server bringen und nichts in die Produktionsdatenbank schreiben. Ab 18:01 Uhr zog die Steuerung die zweite Hälfte nach. Um 18:28 Uhr stand die Anwendung im System.

Vier Stunden und fünf Minuten, mit einer Kundenvorführung mittendrin.

Der Unterschied liegt in der Formulierung. Hätte die Regel nur gelautet, während der Vorführung nichts anzufassen, wären vier Stunden Arbeit liegengeblieben. Eine Leitplanke, die sagt, was bis wann erlaubt ist, hält Agenten produktiv, statt sie anzuhalten.

Unser Tipp: Formulieren Sie Einschränkungen mit Uhrzeit oder Bedingung, ab der sie enden, statt pauschal zu stoppen.

Schnelligkeit allein ist kein Qualitätsmerkmal. Was einen Bericht für uns brauchbar macht, sind die Stellen, an denen ein Agent etwas einräumt.

Um 16:14 Uhr meldete ein Agent eine Rechtelücke (eine Stelle, an der die Software nicht richtig prüft, wer was sehen oder ändern darf) in einer gemeinsamen Programmbibliothek, also in Code, den mehrere Anwendungen gemeinsam nutzen. Um 16:36 Uhr lag der Auftrag, um 17:14 Uhr der Vorschlag, um 17:43 Uhr die fertige, getestete Fassung bereit zum Einbau. Rund siebzig Minuten vom Auftrag bis zum fertigen Paket, abgesichert durch 367 automatische Tests.

Dazu kam eine Gegenprobe: Der Agent baute den Fehler noch einmal ein und zeigte, dass die neuen Tests dann tatsächlich fehlschlagen. Ein Test, der nie rot wird, prüft nichts.

Interessanter ist aber, was der Agent nicht getan hat. In den Auftrag hatte die Steuerung eine Abnahmebedingung geschrieben, die vernünftig klang und unerfüllbar war: die betroffenen Zugänge vorher und nachher im laufenden Betrieb messen. Ein Nachher gibt es dort vor dem Einbau nicht, weil die Anwendungen ihre Bibliothek jeweils mitgeliefert bekommen.

Der Agent hat das Vorher echt gemessen, das Nachher auf einem Testsystem erbracht und die Grenze ausdrücklich hingeschrieben, statt sie stillschweigend zu füllen. Im Bericht steht wörtlich: gemessen, nicht erzählt, Grenze offen gesagt.

Ein zweites Beispiel aus demselben Muster: Bei einem Umbau, der am selben Tag in Betrieb ging, meldete der erste Prüflauf einen Fehler, der keiner war. Das automatische Prüfprogramm klickt auf eine feste Bildschirmposition, und weil im laufenden Betrieb lange Modellnamen die Spalte daneben breit gezogen hatten, traf es dort einen Verweis statt der Schaltfläche. Das steht so im Bericht, statt weggelassen zu werden. Und jede Stelle, die nicht umgestellt wurde, ist einzeln begründet, statt pauschal als Rest abgetan zu werden.

Wer liefert und dabei eine Grenze benennt, ist wertvoller als wer jedes Häkchen setzt. Das gilt für Menschen und es gilt für Maschinen.

Unser Tipp: Akzeptieren Sie „nicht messbar“ als gültiges Ergebnis. Wer nur Häkchen akzeptiert, bekommt nur Häkchen.

Erinnern Sie sich an die Anwendung aus Voraussetzung 2, die um 18:28 Uhr im System stand? Eine halbe Stunde später lief ein Zieltest darüber, also eine Prüfung am echten System statt auf dem Entwicklungsrechner. Sein Ergebnis: am Ziel gemessen, nicht abnehmbar.

Ein Zugang mit ausschließlich Leserecht bekam vom System eine Zugriffsverweigerung, und die Antwort enthielt noch Felder, die dort nichts zu suchen hatten. Ausgerechnet der Kern des Wunsches funktionierte also noch nicht. Abgenommen wurde die Anwendung fünf Tage später.

Das ist kein Schönheitsfehler in der Geschichte, sondern ihr Punkt. Das Tempo bringt die Sache ans Ziel. Ob sie taugt, sagt die Kontrolle danach.

Der vierte Vorgang zeigt, was passiert, wenn diese Kontrolle fehlt. In der Nacht zum 11. September stand unsere Arbeitsverteilung von 01:38 bis 03:34 Uhr still. Fast zwei Stunden, 57 Fehlermeldungen im Protokoll, kein einziger Auftrag verteilt. Der Vorgang, den die Steuerung um 03:36 Uhr anlegte, trägt den Titel „Gemeldet hat es nichts und niemand“.

Bestellt wurde daraufhin eine Überwachung, die genau eine Frage beantwortet: Wann hat die Verteilung zuletzt einen Durchlauf beendet? Um 04:34 Uhr war sie gebaut, eingebaut und gemessen. 58 Minuten ab der Meldung.

Bemerkenswert sind die zwei Minuten davor. Zwischen dem Einbau einer Überwachung und dem ersten Durchlauf, den sie beobachten kann, liegt zwangsläufig eine Lücke. In dieser Lücke hat die neue Überwachung nicht etwa „alles in Ordnung“ gemeldet, sondern „nicht messbar“, mit den beiden möglichen Gründen dazu. Zwei Minuten später, mit dem ersten echten Durchlauf, meldete sie „läuft“.

Eine Überwachung hat eine Einführungslücke. Was sie in dieser Lücke sagt, entscheidet darüber, ob man ihr danach glauben kann.

Und die fast zwei Stunden davor? Die sind der eigentliche Grund für diesen Abschnitt. Eine Störung, die niemand meldet, kostet nicht die Zeit, die sie dauert, sondern die Zeit, bis jemand zufällig hinsieht.

Unser Tipp: Prüfen Sie, ob Sie merken würden, wenn ein Agent eine Stunde lang nichts tut.

• Ist schriftlich festgelegt, was ein Agent ohne Rückfrage entscheiden darf?
• Haben Ihre Einschränkungen eine Uhrzeit oder Bedingung, ab der sie enden?
• Darf ein Agent „nicht messbar“ melden, ohne dass das als Fehler gilt?
• Prüft nach jeder Lieferung eine Kontrolle, die unabhängig vom Agenten arbeitet?
• Würden Sie es merken, wenn ein Agent eine Stunde lang nichts tut?

Keine dieser fünf Fragen ist in erster Linie technisch. Das ist die wichtigste Erkenntnis aus den vier Vorgängen: Was KI-Agenten im Unternehmen schnell und verlässlich macht, sind Entscheidungen, die vorher getroffen wurden, und Kontrollen, die danach greifen.

Was ein solcher Agent im Betrieb kostet und warum der größte Posten das wiederholte Vorlesen des bisherigen Verlaufs ist, haben wir in einem eigenen Beitrag über KI-Agenten und ihre Kosten gemessen.

Unsere KI-Fachleute richten genau das bei Kunden ein. Wie unsere eigene Flotte aufgebaut ist und arbeitet, zeigen wir auf koflott.de (öffnet in neuem Fenster). Alle Zeitangaben in diesem Beitrag stammen aus Vorgängen und Protokollen unseres eigenen produktiven Betriebs.

Was ist ein KI-Agent?

Ein KI-Agent ist ein Programm, das ein Sprachmodell nutzt, um eine Aufgabe in mehreren Schritten selbstständig zu erledigen. Anders als ein Chatfenster, das antwortet und wartet, darf ein Agent Werkzeuge benutzen: Dateien lesen, Befehle ausführen, Ergebnisse prüfen und daraus den nächsten Schritt ableiten.

Was bedeutet Orchestrierung bei KI-Agenten?

Die Orchestrierung ist die Steuerung über den einzelnen Agenten. Sie nimmt Anliegen entgegen, schneidet sie in Aufträge, verteilt diese an die passenden Agenten und sammelt die Ergebnisse wieder ein. Ohne sie wäre jeder Agent ein Einzelkämpfer ohne Überblick.

Wie schnell können KI-Agenten Software liefern?

Die vier Stunden oben betrafen einen kleinen, klar umrissenen Wunsch in einer Umgebung, in der Vorlage, Tests und Einbauweg bereits standen. Genau das ist der Punkt: Das Tempo entsteht aus der Vorarbeit, nicht aus der KI. In einer Umgebung ohne diese Vorarbeit wäre derselbe Wunsch deutlich langsamer. Und auch hier lagen zwischen der Anwendung im System und der Abnahme noch fünf Tage.

Was passiert, wenn ein KI-Agent einen Fehler macht?

Dasselbe wie bei einem Menschen, mit einem Unterschied: Der Weg zurück ist protokolliert. Jede Änderung läuft über dieselben Prüfungen und denselben Einbauweg. In Voraussetzung 1 ist das passiert, die Nebenwirkung war nach keiner Stunde gefunden und nach knapp zwei Stunden zurückgenommen. Ohne diese Wege würden wir Agenten nicht an Produktivsysteme lassen.

Braucht man für KI-Agenten eine eigene KI-Infrastruktur?

Für den Einstieg nicht. Sinnvoll ist, klein anzufangen: ein klar umrissener Ablauf, ein Einbauweg, der schon funktioniert, und eine Leitplanke, die sagt, was erlaubt ist. Zunächst reichen Cloud-Modelle oder Anbieter mit Rechenzentren in der EU, eigene Hardware lohnt sich erst später. Was dafür heute in Frage kommt, steht in Lokale KI ist 2026 produktionsreif.

Wie viele Menschen braucht man für KI-Agenten?

Weniger, als man denkt, aber nicht null. Es braucht jemanden, der Rahmen setzt und Berichte liest. Bei uns steuern fünf Menschen über 170 umgesetzte Anforderungen pro Tag (Stand September 2026). Wo diese Rolle fehlt, entstehen sehr schnell viele Ergebnisse, die niemand einordnet.

Eignen sich KI-Agenten auch für Unternehmen ohne eigene Softwareentwicklung?

Die Beispiele hier stammen aus der Softwareentwicklung, weil das unser Betrieb ist. Die vier Voraussetzungen oben gelten aber für jeden Ablauf, der bisher Abstimmung gekostet hat.

Was ist ein Zieltest?

Ein Zieltest prüft eine fertige Anwendung dort, wo sie später wirklich läuft, nicht auf dem Entwicklungsrechner. Erst dort zeigt sich, ob Rechte, Zugänge und Nachbarsysteme zusammenpassen. In unserem Fall war genau das der Test, der die Anwendung trotz vier Stunden Tempo zurückwies.