Ein Energieversorger in Süddeutschland wollte seine Nacht- und Wochenendbereitschaft für IT-Störungen entlasten. Nicht ersetzen — entlasten. Der Wunsch war konkret: Wenn ein Monitoring-Alert ausgelöst wird, soll automatisch geprüft werden, ob das Problem einem bekannten Muster entspricht, ob ein Neustart des betroffenen Dienstes ausreicht, und erst dann soll ein Mensch geweckt werden, wenn das Problem eskaliert.
Das ist kein Chatbot-Anwendungsfall. Das ist ein Agentensystem.
Der Unterschied zwischen einem LLM-Call und einem Agenten
Ein Large Language Model, das per API aufgerufen wird, beantwortet eine Frage. Es nimmt einen Input, verarbeitet ihn und liefert einen Output. Damit endet der Prozess.
Ein KI-Agent erhält ein Ziel — und arbeitet darauf hin. Er zerlegt das Ziel in Teilschritte, ruft Werkzeuge auf (APIs, Datenbanken, externe Dienste), wertet Ergebnisse aus und entscheidet, ob weitere Schritte nötig sind. Dieser Ablauf kann mehrere Iterationen umfassen — der Agent hört auf, wenn die Aufgabe abgeschlossen ist, nicht wenn er eine Antwort generiert hat.
Konkret bedeutet das: Ein LLM beantwortet „Ist mein Server ausgefallen?“. Ein Agent prüft den Server-Status, startet ihn bei Bedarf neu, wartet auf Bestätigung, dass der Dienst wieder läuft, und sendet erst dann einen Statusbericht.
Eine praxistaugliche Architektur: Orchestrator und spezialisierte Worker
Das Muster, das sich bei Agentensystemen in der Praxis bewährt hat, ist die Trennung von Orchestrierung und Ausführung.
Der Orchestrator nimmt eine eingehende Aufgabe, analysiert sie und verteilt sie an spezialisierte Sub-Agenten. Er hat keine eigenen Ausführungswerkzeuge — seine Fähigkeit ist delegation. Er weiß, welcher Agent für welchen Aufgabentyp zuständig ist, formuliert klare Aufträge und konsolidiert die Ergebnisse.
Spezialisierte Worker-Agenten übernehmen klar abgegrenzte Domänen. Jeder hat Zugriff nur auf die Werkzeuge, die für seinen Bereich relevant sind — kein Toolsprawl, kein Überlappen von Zuständigkeiten. Das reduziert Fehleranfälligkeit und macht das System auditierbar.
Diese Architektur hat einen praktischen Vorteil: Sie skaliert in beide Richtungen. Wer mit einem einzigen Agenten für einen konkret definierten Prozess startet, kann denselben Orchestrator später um weitere Worker erweitern, ohne die bestehende Logik anzufassen.
Konkrete Anwendungsfälle nach Branche
Stadtwerke und Energieversorger
IT-Operations und Störungsmanagement: Ein Monitoring-Agent überwacht Systemstatus, interpretiert Alerts gegen eine Wissensbasis bekannter Störungsmuster und führt definierte Erstmaßnahmen aus. Eskalation an menschliches Personal nur bei nicht zuordenbaren oder persistenten Problemen. Das entlastet die Bereitschaft und verkürzt die mittlere Entstörungszeit für Standardprobleme messbar.
Kundenkommunikation außerhalb der Servicezeiten: Ein Agent, der eingehende Kundenanfragen nach Thema klassifiziert, sofort lösbare Anfragen bearbeitet (Zählerstand-Bestätigung, Terminerinnerungen, Statusabfragen) und komplexe Anfragen mit vollständigem Kontext für den nächsten Arbeitstag für den Sachbearbeiter vorqualifiziert.
Meldewesen und Berichtspflichten: Energieversorger haben regelmäßige Meldepflichten gegenüber Regulierungsbehörden. Ein Agent, der aus Betriebsdaten automatisch Berichtsentwürfe generiert, relevante Kennzahlen aggregiert und Abweichungen markiert, kann Sachbearbeiter von Routinearbeit entlasten — ohne die finale Prüfung zu ersetzen.
Telekommunikationsunternehmen
Netzwerkmonitoring und Kapazitätssteuerung: Agenten können Netzwerkmetriken kontinuierlich auswerten, Kapazitätsengpässe frühzeitig erkennen und sowohl Reportings als auch Handlungsempfehlungen automatisch generieren.
Churn-Prävention: Ein Agent, der Vertragsdaten, Supporthistorie und Nutzungsverhalten auswertet und Risikokunden identifiziert, bevor sie kündigen — mit vorbereiteten Gesprächsleitfäden für den Vertrieb.
KMUs
Für kleinere Unternehmen liegt der Einstieg typischerweise bei internen Prozessen: Dokumentenverwaltung (eingehende Belege klassifizieren und weiterleiten), CRM-Pflege (Kontakte und Follow-ups automatisch aktuell halten) oder Support-Triage (eingehende Anfragen nach Dringlichkeit und Thema sortieren und vorbereiten).
Was ein Agentensystem braucht, um zu funktionieren
Drei Voraussetzungen, die in der Praxis oft unterschätzt werden:
Saubere Tool-Definitionen: Ein Agent ist nur so gut wie die Werkzeuge, die ihm zur Verfügung stehen. Werkzeuge brauchen klare Beschreibungen, eindeutige Eingabeparameter und zuverlässige Ausgaben. Undokumentierte oder fehleranfällige APIs machen einen Agenten unzuverlässig — der Agent optimiert auf das, was seine Werkzeuge leisten, nicht auf das, was sie leisten sollen.
Definierte Eskalationspfade: Jedes Agentensystem braucht einen Mechanismus, der erkennt, wann die Aufgabe den definierten Rahmen übersteigt — und dann zuverlässig an einen Menschen übergibt. Agenten, die im Unklaren weiter halluzinieren, sind gefährlicher als solche, die transparent eskalieren.
Auditierbarkeit: Besonders in regulierten Branchen muss nachvollziehbar sein, welche Entscheidungen ein Agent auf Basis welcher Daten getroffen hat. Das betrifft die Logging-Architektur von Beginn an — nicht als nachträgliche Anforderung.
Kosten und Aufwand realistisch einschätzen
Agentensysteme sind günstiger zu betreiben als die meisten Unternehmen erwarten. Moderne Sprachmodelle in der „kleinen“ Variante (wie Claude Haiku oder GPT-4o mini) liegen für eine typische Agent-Ausführung im Cent-Bereich. Ein Agent, der 100 Mal täglich eine Aufgabe ausführt, kostet im Monat oft weniger als 20 Euro Modell-Kosten.
Der eigentliche Aufwand liegt nicht im Betrieb, sondern im Aufbau: saubere Anforderungsanalyse, Tool-Entwicklung, Testing über realistische Szenarien und Eskalationslogik. Ein klar definierter Einzelagent ist in vier bis acht Wochen produktiv — wenn die Anforderungen stehen.
Ein Multi-Agent-System mit Orchestrator und mehreren Workern ist ein längeres Projekt. Es sollte nicht mit dem Ziel gebaut werden, sofort alles zu automatisieren, sondern schrittweise zu wachsen — mit einem Worker, der funktioniert, bevor der zweite beginnt.
Fazit
Autonome Agentensysteme sind keine Labordemonstration mehr. Die Technologie ist produktionsreif, die Frameworks sind ausgereift, die Kosten sind kalkulierbar.
Der Unterschied zu einem Chatbot ist strukturell: Ein Chatbot beantwortet. Ein Agent handelt. Für repetitive, regelbasierte Prozesse mit klar definierten Werkzeugen ist das heute umsetzbar — und für Stadtwerke, Energieversorger und KMUs mit begrenzten Personalressourcen ein relevanter Effizienzfaktor.
Wenn Sie einen Prozess in Ihrem Betrieb haben, der regelmäßig Aufmerksamkeit bindet, regelbasiert ist und eine definierbare Eskalationslogik hat: Das ist wahrscheinlich ein guter Einstiegspunkt für einen ersten Agenten. Sprechen Sie mich an — ich schätze den Aufwand ein, bevor ein Angebot auf dem Tisch liegt.
