Vom Chat zu „Always-on"-Agenten – autonome agentische Systeme im großen Maßstab

Zusammenfassung

Konversationsagenten kamen zuerst: Das frühe Muster war eine Request/Response- oder ReAct-artige Schleife, in der der Nutzer fragt, der Agent schließt, eventuell Tools aufruft und eine Antwort zurückgibt.

Mit besseren Modellen begannen diese, längere Aufgaben zu bewältigen: Aktuelle Time-Horizon-Benchmarks messen, wie lange eine Aufgabe – gemessen in der Zeit menschlicher Experten – Frontier-Modelle mit einer bestimmten Erfolgsrate erledigen können.

Diese Verschiebung drängt Systeme hin zu „Always-on"-, also autonom und dauerhaft laufenden Agenten: nicht bloß Agenten, die auf Prompts antworten, sondern Agenten, die einen Workflow im Hintergrund fortlaufend umsetzen.

Sobald Agenten always-on sind, wird die zentrale Herausforderung operativ: Teams brauchen Task-State, Memory, HITL-Kontrollen, Observability, Infrastruktur und sicherere Tool-Ausführung.

Einleitung

Die erste Welle moderner Agenten war überwiegend konversationell oder folgte dem Request/Response-Muster. Ein Nutzer sendet eine Anfrage, das Modell schließt, ruft eventuell Tools auf und gibt dann eine Antwort zurück. Einer der populärsten Ansätze sind ReAct-Agenten, die Reasoning und Handeln in einer Schleife innerhalb einer einzigen Interaktion verbinden (ReAct-Paper und Überblick von Google Research).

Mit wachsenden Modellfähigkeiten begannen Agenten, auch bei längeren und komplexeren Aufgaben gut abzuschneiden. Diese Verschiebung zeigt sich deutlich in der Grafik zu den METR-Zeithorizonten: LLMs können Aufgaben, die einen längeren Zeithorizont erfordern, erfolgreich bewältigen.

Ingenieure begannen, komplexere Systeme zu entwerfen: Statt bei einer einzelnen Antwort zu stoppen, tendieren Agenten zunehmend zu „Always-on"-, autonom laufenden Agenten – 24/7-Agenten mit einer Heartbeat-artigen Schleife, die im Hintergrund weiterarbeiten.

Der zentrale Punkt ist einfach: Autonomie ist nicht die Schleife. Autonomie ist das Betriebsmodell rund um die Schleife.

Zwei Agententypen, zwei verschiedene Aufgaben

Auf hoher Ebene unterscheiden sich die beiden Agententypen sowohl in der Architektur als auch in der Art der Aufgaben, die sie lösen.

Was sich ändert, wenn Agenten always-on werden

Sobald Agenten zu „Always-on"-, autonom laufenden Agenten werden, ändert sich die Architektur. Das System ist nicht länger nur ein Prompt-Handler mit Tools. Es muss nun Arbeit über die Zeit hinweg verwalten.

• Task-State: Jede Arbeitseinheit braucht eine stabile Identität und einen Lebenszyklus.
• Memory: Der Agent muss Erkenntnisse, frühere Tool-Ausgaben und Kontext über Läufe hinweg behalten.
• Observability: Teams brauchen Traces, Logs, Metriken und Task-Historie, um zu verstehen, was geschehen ist.
• Human-in-the-Loop-Unterstützung: Operatoren brauchen Prüf-, Freigabe-, Eingriffs- und Abbruchpunkte.
• Guardrails und Budgets: Lang laufende Systeme brauchen Grenzen für Zeit, Kosten und Seiteneffekte.
• Komplexere Infrastruktur: Hintergrundausführung braucht Queues, Worker, Retries, Scheduling und Recovery.
• Wiederaufnahmefähigkeit: Unterbrochene Aufgaben sollten inspizierbar und neu startbar sein.
• Sicherere Tool-Ausführung: Tool-Aufrufe können fortlaufende Seiteneffekte erzeugen, daher gewinnen Berechtigungen und Kontrollen an Bedeutung.
• Output-Erfassung: Ergebnisse und Zwischenschritte müssen gespeichert und später zugänglich gemacht werden.
• Verantwortlichkeit und Auditierung: Jemand muss wissen, wer die Aufgabe gestartet hat, was sie berührt hat und wer die Verantwortung trägt.

Deshalb erben autonome Agenten schnell das, was wie gewöhnliche Arbeit an verteilten Systemen aussieht. Sie brauchen Einreichungsabläufe, Lebenszyklus-Status, Output-Erfassung, Fehler-Reporting, Abbruch, Aufbewahrung, Auditierung und Verantwortlichkeit. Dieselben Kern-Primitive tauchen zudem über Frameworks hinweg immer wieder auf: State, Tools, Memory, Guardrails, Tracing, menschlicher Eingriff, Deployment, Wiederaufnahmefähigkeit und Task-Steuerung.

Wo Knowledge Graphs hineinpassen

Knowledge Graphs geben autonomen Agenten eine strukturierte Schicht für Memory und Kontext. Statt alles als rohe Historie von Tool-Ausführungen oder angehäufte Chat-Logs zu speichern, repräsentiert ein Knowledge Graph Entitäten und die Beziehungen zwischen ihnen in einer Form, die sowohl für Menschen als auch für Maschinen lesbar ist.

Das wird besonders wichtig für autonome Systeme, in denen Kontext nicht länger auf eine einzelne Interaktion begrenzt ist.

Memory. Autonome Agenten müssen behalten, was sie über die Zeit gelernt haben – nicht nur, was in der letzten Anfrage gesagt wurde. Ein Knowledge Graph verwandelt verstreute Beobachtungen in dauerhafte, abfragbare Fakten: Erkenntnisse, Entscheidungen, Abhängigkeiten und frühere Ergebnisse, die über Läufe hinweg wiederverwendet werden können.

Kontext-Management. Statt große Mengen roher Historie in jeden Prompt zu übergeben, kann der Agent nur die für die anstehende Aufgabe relevanten Entitäten, Beziehungen und Definitionen abrufen. Das hält den Kontext fokussiert, günstiger und leichter nachvollziehbar.

Gemeinsames Verständnis. Weil die Struktur explizit ist, können Menschen sie inspizieren, Operatoren sie validieren und mehrere Agenten sich auf denselben Semantic Layer stützen. Das ist entscheidend, sobald mehr als ein Agent – oder mehr als ein Team – gegen dieselbe Domäne arbeitet.

Für datenintensive Agenten verbessert ein Knowledge Graph zudem die Abfrageerzeugung. Indem er Geschäftskonzepte mit Schema-Elementen, freigegebenen Joins und Metrikdefinitionen verknüpft, verankert er den Agenten in der tatsächlichen Datenumgebung, statt ihn allein aus dem Prompt-Kontext raten zu lassen.

Fazit

Die Geschichte der Agentensysteme entwickelt sich von Konversationsschleifen zu „Always-on"-Workflows. Frühe Agenten waren überwiegend Request/Response-Systeme, inspiriert von Mustern wie ReAct. Als Modelle in der Lage waren, längere Aufgaben zu bewältigen, verschob sich das Systemdesign hin zu autonomen Agenten, die im Hintergrund weiterarbeiten.

Diese Verschiebung verändert das Engineering-Problem. Ein Konversationsagent muss gut antworten. Ein autonomer Agent muss fortbestehen, sich erinnern, berichten und unter Kontrolle bleiben. Deshalb zählt der Schlüsselsatz: Autonomie ist nicht die Schleife. Autonomie ist das Betriebsmodell rund um die Schleife.

Knowledge Graphs fügen sich natürlich in dieses Bild ein – als strukturierte Schicht für Memory und Kontext, die sowohl für Maschinen als auch für Menschen verständlich ist.