Agentic Behavior: Wie Sie zuverlässige KI-Agenten für den Betrieb bauen

Als wir bei Hyground begannen, KI-Systeme für die Incident-Analyse zu bauen, machten wir einen klassischen Fehler: Wir schrieben unglaublich detaillierte Prompts. Schritt-für-Schritt-Anweisungen. Entscheidungsbäume. Behandlung von Sonderfällen. Die Prompts wurden länger. Die Ergebnisse wurden schlechter.

Es dauerte eine Weile, bis wir verstanden, warum.

Das Labyrinth-Problem

Incident-Analyse ist nicht wie das Befolgen eines Rezepts. Sie ist wie das Navigieren durch ein Labyrinth. Sie wissen nicht, welcher Pfad zur Root-Cause führt, bis Sie ihn erkundet haben. Jede Entdeckung verändert, wo Sie als Nächstes suchen sollten. Die Anzahl der Schritte ist unbekannt, und der nächste Schritt hängt vollständig davon ab, was Sie gerade gelernt haben.

Genau hier scheitert klassisches Prompting. Ein Prompt läuft, bevor Sie irgendetwas gelernt haben. Sie können keine Anweisungen für ein Labyrinth schreiben, das Sie noch nicht gesehen haben.

Und genau hier kommen KI-Agenten ins Spiel.

Was einen Agenten unterscheidet

Ein Chatbot ist reaktiv: Prompt rein, Antwort raus, fertig. Ein Agent läuft in einer Schleife.

Das Muster, ReAct genannt (Reasoning + Acting), sieht so aus:

Chatbot: ein Durchlauf, Pfad vorab festgelegt. Agent: mehrere Durchläufe, Pfad zur Laufzeit entdeckt.

Der Agent fragt ein Tool ab, interpretiert das Ergebnis und entscheidet, was als Nächstes zu tun ist. Er prüft vielleicht Logs, findet etwas Verdächtiges, fragt einen verwandten Service ab, entdeckt eine Abhängigkeit und verfolgt diese stromaufwärts. Alles, ohne dass ihm die konkreten Schritte vorab genannt wurden.

Agenten bewältigen "offene Probleme, bei denen sich die Anzahl der nötigen Schritte schwer oder gar nicht vorhersagen lässt." Wenn Sie alle Schritte ausformulieren könnten, hätten Sie einen Workflow. Wenn Sie das nicht können, brauchen Sie einen Agenten.

Eine Agenten-Analyse in der Praxis

Hier ein vereinfachtes Beispiel aus unserem System. Ein Monitoring-Alert schlägt an: Die API-Latenz ist auf 2,3 s gestiegen.

Schritt	Think	Act	Observe
1	Latenzspitze – prüfen, welche Endpoints betroffen sind	Metrics-API abfragen	/checkout-Endpoint, andere normal
2	Einzelner Endpoint – könnte ein nachgelagerter Service oder die Datenbank sein	Logs des Checkout-Service prüfen	Connection-Timeouts zum Payment-Service
3	Problem beim Payment-Service – dessen Health prüfen	Metrics des Payment-Service abfragen	Gesund, niedrige Latenz
4	Payment-Service in Ordnung, aber Verbindungen laufen in Timeouts – Netzwerk oder Connection-Pool?	Connection-Pool-Metrics prüfen	Pool erschöpft, 0 verfügbare Verbindungen
5	Pool erschöpft – was hält die Verbindungen?	Aktive Transaktionen abfragen	47 Transaktionen hängen wartend an fraud_check
6	Gefunden – warum hängt fraud_check?	Fraud-Service prüfen	Vor 23 Min. deployt, neue Version hat einen Deadlock

Root-Cause: Ein Deployment hat einen Deadlock eingeführt. Sechs Schritte, der Pfad von Anfang an nicht vorhersehbar.

Ein Prompt kann nicht codieren: "Wenn der Payment-Service gesund ist, aber Verbindungen in Timeouts laufen, prüfe die Connection-Pools und verfolge dann, was sie hält." Jeder Schritt hängt davon ab, was der vorherige offengelegt hat.

Warum längere Prompts die Sache verschlechtern

Was uns überrascht hat: Je detaillierter unsere Prompts wurden, desto schlechter wurden die Ergebnisse. Drei Gründe:

1. Sie codieren einen Algorithmus für ein Problem, das keinen hat

Komplexe Analyse ist nicht algorithmisch. Wenn Sie einen 2000-Wörter-Prompt schreiben, der jedes Szenario abdecken soll, sagen Sie dem LLM im Grunde "genau so wird das gelöst" für ein Problem, das Exploration und Urteilsvermögen verlangt. Das LLM folgt Ihren starren Anweisungen, statt darüber zu schlussfolgern, was es tatsächlich beobachtet.

2. Aufmerksamkeit ist ein Budget, und Sie geben es für Anweisungen aus

LLMs behandeln nicht jeden Text gleich. Forschung zeigt, dass sie Informationen am Anfang und Ende von Prompts besser abrufen als in der Mitte. Jedes "IMPORTANT" und "CRITICAL", das Sie hinzufügen, um die Aufmerksamkeit zu lenken, zehrt in Wirklichkeit am Aufmerksamkeitsbudget. Bei einem mehrseitigen Prompt fällt es dem Modell schwer, sich auf das zu konzentrieren, was im eigentlichen Problem zählt.

3. Context-Windows sind nicht so groß, wie sie scheinen

87 % des Context-Windows wurden allein von Tool-Definitionen verbraucht. Fügen Sie einen ausführlichen Prompt und Zwischenergebnisse aus jedem Tool-Aufruf hinzu, und Sie haben Ihren nutzbaren Context aufgebraucht, bevor die interessante Arbeit beginnt.

Eine Studie aus 2024 zeigt, dass "die Reasoning-Leistung etwa ab 3.000 Tokens nachlässt." Das liegt deutlich unter den technischen Grenzen. Context ist kostbarer Arbeitsspeicher, kein unbegrenzter Speicher. Seit der Veröffentlichung hat sich der Leistungsabfall stark verbessert, doch das Prinzip gilt weiterhin. Coding-Agenten etwa erzwingen eine Context-Verdichtung, lange bevor das tatsächliche Context-Limit erreicht ist.

Was tatsächlich funktioniert

Die zentrale Erkenntnis: Sagen Sie dem Agenten nicht, wie er das Problem lösen soll. Geben Sie ihm die Tools und lassen Sie ihn schlussfolgern.

Kurze, fokussierte Prompts, die das Ziel und die Rahmenbedingungen definieren. Nicht den Algorithmus. Den Pfad findet der Agent selbst.

Das erfordert:

• Tool-Zugriff: APIs, Datenbanken, Log-Systeme, die der Agent abfragen kann
• Klare Abbruchbedingungen: Wann ist die Aufgabe abgeschlossen?
• Guardrails: Welche Aktionen erfordern eine menschliche Freigabe?

Für die Incident-Analyse heißt das: dem Agenten Zugriff geben, um Logs zu beobachten, Metrics abzufragen und Abhängigkeiten zu verfolgen. Und ihn dann analysieren lassen. Es können 3 Schritte sein oder 30. Der Agent entscheidet anhand dessen, was er findet.

Die Grenzen sind real

Wir behaupten nicht, dass Agenten alles lösen. Aktuelle LLMs wie Opus 4.5, Gemini 3 und GPT-5.x stehen kurz davor, komplexe Analyseaufgaben zuverlässig zu bewältigen. Sie glänzen beim Sammeln von Informationen und bei der iterativen Verfeinerung. Schwer tun sie sich mit wirklich neuartigem Reasoning.

Zuverlässigkeit bleibt eine fortlaufende Herausforderung. Derselbe Prompt kann bei verschiedenen Durchläufen unterschiedliche Ergebnisse liefern. Fehler in frühen Schritten verstärken sich nachgelagert. Produktivsysteme brauchen umfassende Observability und menschliche Aufsicht bei folgenschweren Entscheidungen.

Wie es weitergeht

Single-Agent-Architekturen stoßen an eine Grenze, wenn Probleme groß werden. Der Context füllt sich. Der Umfang der Analyse übersteigt, was ein einzelner Agent verfolgen kann.

Die Lösung sind Multi-Agent-Systeme. Spezialisierte Agenten, die zusammenarbeiten, jeder mit fokussiertem Context und klaren Verantwortlichkeiten. Die Muster für die Orchestrierung mehrerer Agenten behandeln wir in unseren nächsten Beiträgen.