Zusammenfassung

Der Übergang von zustandslosen KI-Interaktionen zu langlebigen, autonomen Agenten erfordert robuste Architekturen für die Zustandshaltung. Durch Techniken wie Durable Execution (z. B. Temporal.io) und das Virtual Actor Model wird sichergestellt, dass Agenten über Wochen hinweg konsistent operieren und nach Systemausfällen exakt am Unterbrechungspunkt fortfahren können. Ansätze wie InfiAgent ergänzen dies durch eine strikte Trennung von flüchtigem Reasoning-Kontext und persistenter, dateibasierter Speicherung, was die kognitive Stabilität bei komplexen Langzeitaufgaben auch bei begrenzten Kontextfenstern garantiert.

Zur Optimierung der Token-Ökonomie und zur Vermeidung von Leistungsdegradierung setzen moderne Systeme auf Context Engineering und Standards wie das Model Context Protocol (MCP). Durch Verfahren wie kognitive Destillation, Graph-based Pruning und dynamisches Token-Budgeting wird der „Mental Drift“ minimiert – das Risiko, dass Agenten bei langen Ketten das Ziel aus den Augen verlieren. Die Integration formaler Verifizierung mittels mathematischer Beweise (z. B. FormalJudge) ermöglicht es zudem, die Korrektheit von Reasoning-Ketten in sensiblen Bereichen wie der Cybersicherheit signifikant zu steigern.

Die horizontale Skalierung erfolgt über einen Agentic Mesh und standardisierte Agent-to-Agent (A2A) Protokolle, die eine herstellerübergreifende Zusammenarbeit spezialisierter Agenten in Form von Schwärmen ermöglichen. Blackboard-Architekturen fördern dabei die lose Kopplung und Resilienz, während Human-in-the-Loop-Schnittstellen eine kontrollierte Autonomie gewährleisten. Insgesamt verschiebt sich der Fokus vom reinen Modell-Output hin zu einem komplexen Systems-Engineering, das Persistenz, Sicherheit und Interoperabilität als fundamentale Säulen langlebiger KI-Systeme etabliert.

Einleitung

Die Evolution der künstlichen Intelligenz hat einen kritischen Wendepunkt erreicht, an dem die bloße Generierung von Text durch zustandlose Interaktionen einer neuen Ära weicht: der Ära der langlebigen, autonomen KI-Agenten. Während frühere Iterationen von KI-Systemen primär als reaktive Orakel fungierten, die auf isolierte Prompts antworteten, fordern moderne Anwendungsfälle Systeme, die über Tage, Wochen oder sogar Monate hinweg konsistente Fortschritte erzielen. Diese Verschiebung von kurzlebigen Chat-Sitzungen zu "Long-Running AI Agentic Systems" stellt Ingenieure vor fundamentale Herausforderungen in Bezug auf das Gedächtnis, die Zustandsverwaltung und die kognitive Stabilität. Ein Agent, der komplexe Aufgaben wie Penetration Testing oder großangelegte Software-Entwicklung übernimmt, darf nicht bei jeder Unterbrechung der Internetverbindung oder jedem Neustart der Infrastruktur sein gesamtes Wissen verlieren. Die Fähigkeit, einen kohärenten Kontext über extrem lange Zeiträume aufrechterhalten zu können, ist das Bindeglied zwischen einem Spielzeug und einem produktiven Werkzeug [1].

State Serialization: Vom flüchtigen Snapshot zum "Durable Agent"

In der Welt der klassischen Softwareentwicklung ist der "Zustand" (State) oft eine klar definierte Variable in einem Arbeitsspeicher. Bei KI-Agenten hingegen umfasst der Zustand eine hochkomplexe Mischung aus dem aktuellen Plan, der bisherigen Konversationshistorie, den Ausgaben genutzter Werkzeuge und den internen Reflexionen des Modells. Um einen Agenten "langlebig" zu machen, muss dieser Zustand so serialisiert werden, dass er jederzeit eingefroren und auf einer anderen Maschine oder zu einem späteren Zeitpunkt wieder zum Leben erweckt werden kann.

Strukturierte Serialisierung mit JSON und Pydantic

Der erste Schritt zur Persistenz ist die Überführung des mentalen Modells des Agenten in ein maschinenlesbares Format. Hier haben sich Frameworks wie Pydantic als Industriestandard etabliert. Pydantic ermöglicht es, komplexe Datenstrukturen durch Python-Klassen zu definieren, die eine strikte Typisierung und Validierung erzwingen. Dies ist für Agenten entscheidend, da eine fehlerhafte Serialisierung dazu führen könnte, dass der Agent nach einem Neustart mit inkonsistenten Informationen aufwacht. Wenn ein Agent beispielsweise im Rahmen eines Pentests mit PentestGPT eine Liste von gefundenen Schwachstellen speichert, stellt eine Pydantic-basierte Serialisierung sicher, dass jede Schwachstelle die korrekten Attribute wie Schweregrad, URL und Exploit-Status behält [2]. Ein einfaches "Snapshotting" – das Speichern des Zustands am Ende jeder Interaktion – reicht jedoch oft nicht aus. In komplexen Systemen kann ein Agent inmitten einer langwierigen Berechnung oder eines API-Aufrufs abstürzen. Hier tritt das Konzept des "Durable Agents" in den Vordergrund. Ein Durable Agent speichert nicht nur das Ergebnis seiner Arbeit, sondern den gesamten Ausführungspfad [1].

Das folgende Beispiel zeigt, wie ein Agentenzustand typisiert, validiert und ohne Informationsverlust serialisiert werden kann:

1from datetime import datetime
2from pathlib import Path
3from typing import Literal
4
5from pydantic import BaseModel, Field
6
7
8class Finding(BaseModel):
9	# Jede Schwachstelle ist streng typisiert und validierbar.
10	severity: Literal["low", "medium", "high", "critical"]
11	url: str
12	exploit_status: Literal["new", "validated", "blocked"] = "new"
13
14
15class AgentState(BaseModel):
16	# Der serialisierte Zustand enthält Plan, Verlauf und operative Metadaten.
17	agent_id: str
18	goal: str
19	current_step: str
20	findings: list[Finding] = Field(default_factory=list)
21	last_checkpoint_at: datetime = Field(default_factory=datetime.utcnow)
22
23
24state = AgentState(
25	agent_id="pentest-42",
26	goal="Prufe das Zielsystem auf SQL-Injection und schwache Authentisierung.",
27	current_step="Login-Flow analysieren",
28	findings=[
29		Finding(
30			severity="high",
31			url="https://target.local/login",
32			exploit_status="validated",
33		)
34	],
35)
36
37# JSON ist hier nicht nur Austauschformat, sondern auch Restart-Vertrag.
38snapshot_path = Path("state/agent_state.json")
39snapshot_path.parent.mkdir(parents=True, exist_ok=True)
40snapshot_path.write_text(state.model_dump_json(indent=2), encoding="utf-8")
41
42# Beim Neustart wird der exakte Zustand wieder geladen und erneut validiert.
43restored_state = AgentState.model_validate_json(snapshot_path.read_text(encoding="utf-8"))
44print(restored_state.current_step)

Ein passendes Ablaufbild dazu ist die Trennung zwischen Laufzeit, Serialisierung und Wiederherstellung:

Durable Execution Frameworks: Temporal.io und die Persistenz des Workflows

Durable Execution Frameworks wie Temporal.io stellen einen Paradigmenwechsel für die Orchestrierung von Agenten dar. Anstatt den Zustand als separates Objekt zu behandeln, das mühsam zwischen Datenbank und Modell hin- und hergeschoben wird, integriert Temporal den Zustand direkt in den Workflow-Code. Wenn ein Agent eine Aufgabe ausführt, wird jeder Schritt – jeder LLM-Call, jeder Werkzeugaufruf – in einer unveränderlichen Ereignishistorie (Event History) aufgezeichnet [3], [4]. Der entscheidende Vorteil dieser Architektur ist die Fehlertoleranz. Sollte der Server, auf dem der Agent läuft, ausfallen, kann Temporal den Workflow auf einem anderen Server exakt an der Stelle fortsetzen, an der er unterbrochen wurde. Dies geschieht durch ein "Replay": Der Code wird erneut ausgeführt, aber anstatt die API-Aufrufe tatsächlich zu wiederholen, werden die Ergebnisse aus der gespeicherten Historie geladen. Für einen langlaufenden Agenten bedeutet dies, dass er niemals "vergisst", wo er steht, selbst wenn die zugrunde liegende Infrastruktur instabil ist [4].

Das Kernelement von Durable Execution ist nicht ein gespeicherter Python-Stack, sondern eine deterministische Wiederholung des Workflows anhand der Event History:

Ein passendes Beispiel für einen Temporal-Workflow könnte so aussehen:

1from datetime import timedelta
2
3from temporalio import workflow
4
5
6@workflow.defn
7class SecurityReviewWorkflow:
8	@workflow.run
9	async def run(self, target_url: str) -> dict:
10		# Jede Activity ist ein wiederaufnehmbarer Schritt im Workflow.
11		scan_result = await workflow.execute_activity(
12			"run_port_scan",
13			target_url,
14			start_to_close_timeout=timedelta(minutes=5),
15		)
16
17		# Der LLM-Aufruf liegt ebenfalls hinter einer Activity-Grenze.
18		triage = await workflow.execute_activity(
19			"triage_findings_with_llm",
20			scan_result,
21			start_to_close_timeout=timedelta(minutes=2),
22		)
23
24		# Fällt der Worker hier aus, replayt Temporal den Workflow.
25		# Bereits abgeschlossene Activities werden aus der Event History gelesen.
26		report = await workflow.execute_activity(
27			"build_report",
28			triage,
29			start_to_close_timeout=timedelta(minutes=2),
30		)
31		return report

Das Virtual Actor Model und die Abstraktion der Identität

Ein weiteres wegweisendes Konzept für die Skalierung langlebiger Agenten ist das Virtual Actor Model, wie es in Frameworks wie Microsoft Orleans oder Dapr verwendet wird. In diesem Modell wird jeder Agent als ein "Actor" betrachtet – eine eigenständige Einheit mit eigenem Zustand und Verhalten. Ein "virtueller" Actor existiert konzeptionell immer. Wenn er nicht aktiv ist, wird sein Zustand in einer Datenbank (z. B. PostgreSQL oder Redis) "schlafen gelegt". Sobald eine neue Nachricht für diesen Agenten eintrifft, wird er vom Framework automatisch aktiviert, sein Zustand wird geladen, und er setzt seine Arbeit fort [5], [6]. Diese Architektur ermöglicht es, Millionen von Agenten gleichzeitig zu verwalten, ohne dass sie permanent Ressourcen verbrauchen. In der Praxis bedeutet dies für ein System wie CAI (Cybersecurity AI), dass für jedes zu testende Ziel ein eigener Actor instanziiert werden kann, der über Tage hinweg seine Umgebung erkundet, ohne dass der Entwickler sich um das Session-Management kümmern muss [5], [6], [7].

Die Identität des Actors bleibt stabil, auch wenn seine Prozessinstanz kommt und geht:

In Python-nahem Pseudocode lässt sich das Aktivierungsmodell so lesen:

1class TargetActor:
2	def __init__(self, actor_id: str, state_store):
3		self.actor_id = actor_id
4		self.state_store = state_store
5		self.state = None
6
7	async def activate(self) -> None:
8		# Beim Aktivieren wird der letzte Zustand geladen.
9		self.state = await self.state_store.load(self.actor_id) or {
10			"visited_hosts": [],
11			"current_phase": "recon",
12		}
13
14	async def handle_message(self, message: dict) -> dict:
15		# Der Actor bearbeitet nur Nachrichten für seine eigene Identität.
16		if message["type"] == "host_discovered":
17			self.state["visited_hosts"].append(message["host"])
18
19		result = {
20			"actor_id": self.actor_id,
21			"phase": self.state["current_phase"],
22			"known_hosts": len(self.state["visited_hosts"]),
23		}
24
25		# Vor dem Deaktivieren wird der neue Zustand persistiert.
26		await self.state_store.save(self.actor_id, self.state)
27		return result

InfiAgent und die Externalisierung des Zustands in das Dateisystem

Ein radikalerer Ansatz zur Lösung des Persistenzproblems wird im InfiAgent-Framework der University of Hong Kong verfolgt. Forscher stellten fest, dass das Anhäufen von Informationen im Prompt (dem Kontextfenster) unweigerlich zu "Context Rot" führt – einer Degradierung der Modellleistung bei steigender Token-Anzahl. InfiAgent schlägt daher eine strikte Trennung zwischen dem persistenten Aufgabenzustand und dem flüchtigen Reasoning-Kontext vor [8]. Anstatt die gesamte Historie im Prompt mitzuführen, nutzt InfiAgent eine "file-centric state abstraction". Der Agent betrachtet ein dediziertes Verzeichnis auf dem Dateisystem als sein "Langzeitgedächtnis". Bei jedem Entscheidungsschritt rekonstruiert der Agent seinen Arbeitskontext aus einem Snapshot dieses Verzeichnisses und einem kleinen, festen Fenster der letzten Aktionen. Dies stellt sicher, dass das Kontextfenster des LLMs niemals überläuft, egal wie lange die Aufgabe dauert. Experimente zeigen, dass dieser Ansatz bei komplexen Deep-Research-Aufgaben, die hunderte von Schritten umfassen, deutlich stabiler bleibt als herkömmliche, kontextzentrierte Architekturen [8].

Hier ist die zentrale Idee: Das Langzeitgedächtnis liegt nicht im Prompt, sondern im Arbeitsverzeichnis des Agenten:

Ein minimales Python-Beispiel zeigt die Trennung zwischen persistenten Dateien und flüchtigem Prompt-Fenster:

1from pathlib import Path
2import json
3
4
5WORKDIR = Path("agent_workspace")
6WORKDIR.mkdir(exist_ok=True)
7
8
9def reconstruct_context(last_actions: list[str]) -> str:
10	# Nur stabile Artefakte aus dem Dateisystem werden als Faktenbasis gelesen.
11	notes = (WORKDIR / "notes.md").read_text(encoding="utf-8") if (WORKDIR / "notes.md").exists() else ""
12	findings = json.loads((WORKDIR / "findings.json").read_text(encoding="utf-8")) if (WORKDIR / "findings.json").exists() else []
13
14	# Das Prompt-Fenster bleibt klein und reproduzierbar.
15	return "
16".join(
17		[
18			"SYSTEM: Arbeite nur mit aktuellen Projektfakten.",
19			f"NOTES:
20{notes}",
21			f"FINDINGS:
22{json.dumps(findings, ensure_ascii=False, indent=2)}",
23			"RECENT ACTIONS:",
24			*last_actions[-5:],
25		]
26	)
27
28
29def persist_new_fact(title: str, content: str) -> None:
30	# Neue Erkenntnisse werden dauerhaft ausserhalb des LLM-Kontexts geschrieben.
31	with (WORKDIR / "notes.md").open("a", encoding="utf-8") as handle:
32		handle.write(f"
33## {title}
34{content}
35")

Context Routing & Selective Attention: Die Kunst der Token-Ökonomie

Selbst wenn wir den Zustand eines Agenten perfekt speichern können, bleibt das Problem der Kontextbeschränkung bestehen. Ein LLM kann nur eine begrenzte Anzahl von Token gleichzeitig verarbeiten. Kontext ist in diesem Sinne der "Arbeitsspeicher" (RAM) des Agenten, während die Persistenzschicht die "Festplatte" darstellt. Effektives Context Engineering bedeutet daher, zu jedem Zeitpunkt genau die Token auszuwählen, die für die aktuelle Entscheidung am relevantesten sind.

Das Model Context Protocol (MCP) als universeller Standard

Um den Zugriff auf externen Kontext zu standardisieren, hat sich das Model Context Protocol (MCP) als entscheidender Baustein etabliert. MCP entkoppelt die KI-Anwendung von den Datenquellen. Ein Agent kann über MCP-Server auf Datenbanken, Dateisysteme oder APIs zugreifen, ohne dass diese Informationen permanent im Prompt stehen müssen. Dies ermöglicht ein "Just-in-Time"-Laden von Kontext: Der Agent fordert spezifische Informationen erst dann an, wenn er sie für einen Reasoning-Schritt benötigt [9], [10].

Ein Diagramm macht den Unterschied zwischen statisch überladenem Prompt und gezieltem Kontextabruf gut sichtbar:

Ein Python-Beispiel mit einem MCP-ähnlichen Client illustriert den Ablauf:

1async def load_relevant_context(mcp_client, target_id: str, phase: str) -> dict:
2	# Der Agent fragt nicht nach allem, sondern nach Kontext für den aktuellen Schritt.
3	response = await mcp_client.call_tool(
4		"security_context.lookup",
5		{
6			"target_id": target_id,
7			"phase": phase,
8			"fields": ["open_findings", "recent_decisions", "allowed_actions"],
9		},
10	)
11	return response["structuredContent"]
12
13
14async def plan_next_step(llm, mcp_client, target_id: str) -> str:
15	context = await load_relevant_context(mcp_client, target_id, phase="privilege_escalation")
16
17	# Nur der selektiv geladene Kontext geht in den Prompt.
18	prompt = f"""
19	Ziel: Plane den nächsten sicheren Schritt.
20	Offene Findings: {context['open_findings']}
21	Letzte Entscheidungen: {context['recent_decisions']}
22	Erlaubte Aktionen: {context['allowed_actions']}
23	"""
24	return await llm.ainvoke(prompt)

Context Pruning und Compaction: Die kognitive Destillation

Wenn ein Agent über Tage hinweg läuft, wird seine Historie unweigerlich zu groß für das Kontextfenster. "Compaction" (Verdichtung) ist hier die Lösung. Dabei wird die bisherige Historie durch ein LLM zusammengefasst. Ein entscheidender technischer Aspekt ist hierbei die Unterscheidung zwischen unwichtigen Details (z. B. rohe Tool-Ausgaben eines Portscans) und kritischen Erkenntnissen (z. B. die Identifizierung einer spezifischen Schwachstelle). Effektive Compaction-Algorithmen bewahren die "High-Fidelity"-Details wie Architekturentscheidungen oder ungelöste Bugs, während redundante Nachrichten verworfen werden [9]. Ein fortgeschrittener Ansatz besteht darin, den Suchprozess als Zustands- oder Angriffsgraphen zu modellieren und redundante Pfade beziehungsweise Zyklen aus der Trajektorie zu entfernen. Dadurch bleibt die aktive Arbeitsmenge kleiner und die Suche fokussierter [11].

Die praktische Frage lautet also nicht, ob verdichtet wird, sondern was bewusst erhalten bleiben muss:

1HIGH_FIDELITY_TAGS = {"architecture_decision", "validated_finding", "open_risk", "blocked_path"}
2
3
4def compact_history(events: list[dict]) -> tuple[list[dict], str]:
5	# Kritische Fakten bleiben als strukturierte Fakten erhalten.
6	preserved = [event for event in events if event.get("tag") in HIGH_FIDELITY_TAGS]
7
8	# Rauschanfällige oder repetitive Ereignisse werden in eine Kurzfassung überführt.
9	noisy_events = [event for event in events if event.get("tag") not in HIGH_FIDELITY_TAGS]
10	summary = "
11".join(
12		f"- {event['timestamp']}: {event['message']}" for event in noisy_events[-20:]
13	)
14	return preserved, summary
15
16
17history = [
18	{"tag": "tool_output", "timestamp": "10:00", "message": "Portscan mit 6 offenen Ports"},
19	{"tag": "validated_finding", "timestamp": "10:03", "message": "SQL-Injection auf /search bestätigt"},
20	{"tag": "blocked_path", "timestamp": "10:08", "message": "RCE-Versuch durch WAF blockiert"},
21]
22
23preserved_facts, compact_summary = compact_history(history)

Als Graph gedacht ist Compaction im Kern eine Reduktion auf informative Knoten und Kanten:

Dynamic Token Budgeting und die Vermeidung von "Overthinking"

Ein oft übersehenes Problem bei langlebigen Systemen sind die Kosten und die Latenz, die durch unnötig lange Reasoning-Ketten entstehen. Moderne Modelle neigen zum "Overthinking" – sie generieren tausende von Token für Aufgaben, die eine einfache Antwort erfordern würden. Systeme wie "Certaindex" adressieren dies durch ein dynamisches Token-Budgeting. Certaindex misst den Fortschritt des Reasonings und ermöglicht einen "Early Exit", sobald eine stabile Antwort gefunden wurde. In Multi-Agenten-Systemen ermöglicht dies eine intelligente Ressourcenallokation: Einem Agenten, der an einer hochkomplexen Aufgabe arbeitet, wird ein größeres Token-Budget zugewiesen, während Routineaufgaben mit minimalem Aufwand abgeschlossen werden [12].

Ein einfaches Steuerungsmodell für dynamische Budgets kann so aussehen:

1def allocate_token_budget(task_complexity: float, uncertainty: float, remaining_quota: int) -> int:
2	# Komplexe und unsichere Aufgaben erhalten mehr Budget, aber nie unbegrenzt.
3	proposed = int(800 + task_complexity * 2200 + uncertainty * 1800)
4	return max(300, min(proposed, remaining_quota))
5
6
7def should_exit_early(confidence: float, budget_spent: int, max_budget: int) -> bool:
8	# Bei hoher Antwortstabilität wird früh beendet, um Kosten zu sparen.
9	return confidence >= 0.92 or budget_spent >= max_budget
10
11
12budget = allocate_token_budget(task_complexity=0.7, uncertainty=0.4, remaining_quota=2400)
13print({"assigned_budget": budget, "early_exit": should_exit_early(0.94, 1100, budget)})

Ergänzend zum Token-Management rückt Agentic FinOps in den Fokus: Langlebige Workflows benötigen 'Hard Quotas' auf Workflow-Ebene. Ein Agent, der über 48 Stunden autonom operiert, muss bei Erreichen eines Kosten-Limits automatisch in den 'Deep Freeze State' versetzt werden, anstatt unkontrolliert Ressourcen zu verbrauchen.

Das "Mental Drift" Problem & Goal Guarding

Ein langlebiger Agent, der über Tage autonom agiert, läuft Gefahr, unter einem Phänomen zu leiden, das als "Mental Drift" bezeichnet wird. Mit jedem Schritt in einer langen Kette von Interaktionen können sich kleine Ungenauigkeiten oder Fehlinterpretationen aufsummieren, bis der Agent völlig das ursprüngliche Ziel aus den Augen verliert. Da LLMs primär darauf trainiert sind, das nächste Token basierend auf statistischen Mustern vorherzusagen (Pattern Matching) und nicht zwangsläufig die Wahrheit zu finden, ist dieser Drift systemimmanent [9].

System Prompt Anchoring und Self-Correction

Die einfachste Form der Gegenmaßnahme ist das "Anchoring" (Verankerung). Hierbei wird die ursprüngliche Aufgabe und die wichtigsten Regeln in jedem Turn prominent im System-Prompt platziert. Doch bei wirklich langen Laufzeiten reicht dies nicht aus. Der Agent benötigt Mechanismen zur Selbstkorrektur. Ein Agent wie LuaN1ao nutzt dafür eine dedizierte "Reflector"-Rolle. Der Reflector auditiert die Arbeit des "Planners" und des "Executors" und sucht nach logischen Fehlern oder Anzeichen dafür, dass sich der Agent in einer Sackgasse befindet [1], [13].

Die Rollenverteilung zwischen Planer, Executor und Reflector lässt sich gut als Kontrollschleife darstellen:

Ein kleines LangGraph-inspiriertes Beispiel zeigt, wie diese Schleife im Code aussieht:

1from typing import TypedDict
2
3
4class AgentLoopState(TypedDict):
5	goal: str
6	plan: str
7	execution_result: str
8	reflection: str
9
10
11def planner(state: AgentLoopState) -> AgentLoopState:
12	# Der Zielanker wird in jedem Planungsschritt erneut berücksichtigt.
13	state["plan"] = f"Ziel: {state['goal']} | Nächster Schritt: prüfe Session-Handling der App"
14	return state
15
16
17def executor(state: AgentLoopState) -> AgentLoopState:
18	# In der Praxis würde hier ein Tool oder ein LLM-Aufruf stehen.
19	state["execution_result"] = "Session Cookie ist nicht HttpOnly"
20	return state
21
22
23def reflector(state: AgentLoopState) -> AgentLoopState:
24	# Der Reflector prüft, ob Ergebnis und Ziel noch sauber ausgerichtet sind.
25	if "HttpOnly" in state["execution_result"]:
26		state["reflection"] = "Kein Drift: Ergebnis ist relevant für Authentisierungssicherheit."
27	else:
28		state["reflection"] = "Drift erkannt: Zurück zur Planung."
29	return state

Policy-as-Code und Guardrails

Um die Autonomie des Agenten innerhalb sicherer Grenzen zu halten, kommen "Policy-as-Code"-Ansätze zum Einsatz. Systeme wie CAI validieren Agentenaktionen gegen eine vordefinierte Menge an Regeln und Sicherheitsgrenzen. Wenn ein Pentesting-Agent beispielsweise angewiesen wurde, niemals die Verfügbarkeit eines Systems zu beeinträchtigen, kann eine solche Policy-Layer verhindern, dass er einen gefährlichen Denial-of-Service-Exploit ausführt, selbst wenn seine interne Logik dies vorschlagen würde [7].

Ein Guardrail-Layer ist technisch nichts anderes als ein verpflichtender Policy-Check vor jeder Aktion:

1POLICIES = {
2	"allow_destructive_actions": False,
3	"allowed_network_scope": ["10.0.0.0/24", "app.internal.local"],
4}
5
6
7def validate_action(action: dict) -> None:
8	# Policy-as-Code macht Sicherheitsregeln explizit und testbar.
9	if action["type"] == "dos_test" and not POLICIES["allow_destructive_actions"]:
10		raise PermissionError("DoS-Tests sind durch Policy verboten.")
11
12	if action["target"] not in POLICIES["allowed_network_scope"]:
13		raise PermissionError("Ziel liegt ausserhalb des genehmigten Scopes.")
14
15
16candidate_action = {"type": "dos_test", "target": "app.internal.local"}
17validate_action(candidate_action)

Formal Verification: Die mathematische Garantie der Korrektheit

Der wohl bedeutendste Fortschritt für die Zuverlässigkeit von Agenten im Zeitraum 2025-2026 ist die Integration der formalen Verifizierung. Im Gegensatz zu herkömmlichen Evaluationen, die auf statistischer Wahrscheinlichkeit basieren, nutzt die formale Verifizierung mathematische Beweise, um die Korrektheit von Reasoning-Ketten sicherzustellen. Systeme wie "FormalJudge" zerlegen die Argumentation eines Agenten in atomare Fakten und prüfen diese mithilfe von SMT-Solvern (Satisfiability Modulo Theories). Ein Agent, der Code schreibt oder komplexe Sicherheitsanalysen durchführt, muss seine Schlussfolgerungen in einer strukturierten Sprache (wie Dafny oder Lean) formulieren. Der Verifizierer kann dann mathematisch garantieren, dass die Logik des Agenten keine Widersprüche enthält. Studien zeigen, dass Agenten, die durch formales Feedback gesteuert werden, ihre Genauigkeit in komplexen Aufgaben von 70,7 % auf 99,8 % steigern können [14].

Das formale Oversight sitzt dabei zwischen Reasoning und Freigabe:

Ein stark vereinfachtes Python-Muster zeigt die Datenform, die ein Verifizierer benötigt:

1def extract_atomic_claims(agent_rationale: str) -> list[dict]:
2	# In echten Systemen wäre dies ein strukturierter Parser statt String-Splitting.
3	return [
4		{"claim": "input_is_sanitized", "value": False},
5		{"claim": "sql_query_uses_user_input", "value": True},
6	]
7
8
9def verify_claims_with_solver(claims: list[dict]) -> bool:
10	# Ein echter Solver würde logische Konsistenz prüfen.
11	facts = {item["claim"]: item["value"] for item in claims}
12	return not (facts["input_is_sanitized"] and facts["sql_query_uses_user_input"])
13
14
15claims = extract_atomic_claims("Unsanitized input reaches SQL query")
16is_consistent = verify_claims_with_solver(claims)
17print({"verified": is_consistent, "claims": claims})

Agentic Observability: Den "Ghost in the Machine" verstehen

Die größte Herausforderung langlebiger Autonomie ist die Fehlersuche. Wenn ein Agent über 72 Stunden hinweg tausende Reasoning-Schritte durchläuft, ist ein klassischer Stack-Trace wertlos. Moderne Architekturen setzen daher auf Reasoning Trace Analysis und spezialisierte Agent-Observability-Stacks. Sie erlauben es uns, den Zustand des Agenten zu jedem Zeitpunkt "zurückzuspulen". Wir sehen nicht nur, was der Agent getan hat, sondern welchen State-Snapshot er zu diesem Zeitpunkt im Kopf hatte. Diese "Forensik für Agenten" ist die Voraussetzung dafür, langlebige Systeme in regulierten Industrien überhaupt produktiv setzen zu dürfen [5], [7].

Praktisch bedeutet Observability, dass jede Entscheidung mit Prompt-Version, Snapshot und Tool-Kontext nachvollziehbar sein muss:

1def log_agent_step(trace_store, *, step_id: str, state_snapshot: dict, prompt_hash: str, tool_call: dict, outcome: str) -> None:
2	trace_store.append(
3		{
4			"step_id": step_id,
5			"prompt_hash": prompt_hash,
6			"state_snapshot": state_snapshot,
7			"tool_call": tool_call,
8			"outcome": outcome,
9		}
10	)
11
12
13trace = []
14log_agent_step(
15	trace,
16	step_id="step-103",
17	state_snapshot={"phase": "enumeration", "open_findings": 2},
18	prompt_hash="sha256:abc123",
19	tool_call={"name": "http_probe", "args": {"path": "/admin"}},
20	outcome="403 Forbidden",
21)

Dual-Audit Mechanismen und hierarchische Supervision

In hochsensiblen Umgebungen wird oft ein Dual-Audit-Modell implementiert. Hierbei überwachen zwei unabhängige Agenteninstanzen den Prozess. Dies ist vergleichbar mit dem Vier-Augen-Prinzip in der menschlichen Arbeitswelt. In der PentestGPT v2 Architektur wird dies durch ein "Task Difficulty Assessment" (TDA) ergänzt. TDA schätzt die Erfolgswahrscheinlichkeit eines Pfades basierend auf vier Dimensionen [11]:

1. Horizon Estimation: Wie viele Schritte sind noch nötig?
2. Evidence Confidence: Wie sicher sind die bisherigen Beweise?
3. Context Load: Ist das Kontextfenster bereits zu überlastet für präzises Denken?
4. Historical Success: Wie erfolgreich waren ähnliche Aktionen in der Vergangenheit?

Wenn TDA signalisiert, dass ein Pfad zu unsicher wird, erzwingt das System ein Backtracking oder eine Neuausrichtung des Agenten [11].

Ein Bewertungsmodell für TDA lässt sich als explizite Entscheidungsfunktion ausdrücken:

1def estimate_path_risk(horizon: float, evidence_confidence: float, context_load: float, historical_success: float) -> float:
2	# Hoher Horizont und hohe Kontextlast erhöhen das Risiko.
3	return (
4		0.35 * horizon
5		+ 0.30 * context_load
6		+ 0.20 * (1.0 - evidence_confidence)
7		+ 0.15 * (1.0 - historical_success)
8	)
9
10
11risk = estimate_path_risk(
12	horizon=0.8,
13	evidence_confidence=0.55,
14	context_load=0.9,
15	historical_success=0.4,
16)
17
18if risk > 0.65:
19	print("Backtracking oder menschliche Freigabe erforderlich")

Scaling Autonomy: Agentic Mesh & Swarms

Wenn ein Problem so groß wird, dass ein einzelner Agent es trotz aller Persistenzmechanismen nicht mehr bewältigen kann, müssen wir das System horizontal skalieren. Dies führt uns weg von monolithischen Agenten hin zu verteilten Systemen, die als "Agentic Mesh" oder "Swarms" (Schwärme) bezeichnet werden.

Blackboard Architectures und lose Kopplung

Die "Blackboard Architecture" ist ein klassisches Designmuster der KI, das in der Ära der LLMs eine Renaissance erlebt. Mehrere spezialisierte Agenten arbeiten zusammen, indem sie Informationen auf ein gemeinsames "Blackboard" schreiben und von dort lesen. Es gibt keinen starren, vordefinierten Workflow; stattdessen reagieren die Agenten opportunistisch auf neue Informationen. Ein Agent für Reconnaissance schreibt eine Liste offener Ports auf das Blackboard, woraufhin ein Exploit-Spezialist-Agent diese Information aufgreift und nach Schwachstellen sucht. Diese lose Kopplung macht das System extrem robust gegenüber dem Ausfall einzelner Komponenten [15].

Ein Blackboard ist besonders gut visualisierbar, weil die Zusammenarbeit nicht über direkte Punkt-zu-Punkt-Kopplung läuft:

Das Datenmodell dazu ist oft bewusst simpel, damit viele Agenten gleichzeitig darauf arbeiten können:

1blackboard = {
2	"open_ports": [],
3	"validated_findings": [],
4	"pending_tasks": [],
5}
6
7
8def publish_fact(topic: str, value) -> None:
9	# Jeder Agent publiziert nur Fakten oder Aufgaben in das gemeinsame Board.
10	blackboard[topic].append(value)
11
12
13def consume_tasks() -> list[dict]:
14	# Ein spezialisierter Agent zieht sich nur die für ihn relevanten Aufgaben.
15	return [task for task in blackboard["pending_tasks"] if task["owner"] == "exploit-agent"]
16
17
18publish_fact("open_ports", {"host": "10.0.0.15", "port": 443})
19publish_fact("pending_tasks", {"owner": "exploit-agent", "task": "Prüfe TLS-Konfiguration"})

Der Agentic Mesh: Das Internet für Agenten

Ein Agentic Mesh ist eine verteilte Infrastruktur, die Agenten über standardisierte Protokolle verbindet. Es fungiert als "kognitives Gewebe", das Identität, Governance und Kommunikation auf Infrastrukturebene bereitstellt. Ähnlich wie ein Service Mesh bei Microservices verwaltet der Agentic Mesh die "Diplomatie" zwischen den Agenten [16]. Ein modernes Agentic Mesh besteht aus mehreren Schichten:

• Agent Runtime: Die isolierte Ausführungsumgebung (z. B. Docker oder serverlose Container).
• Identity Layer: Eindeutige DIDs (Decentralized Identifiers) für jeden Agenten, um sicherzustellen, dass nur autorisierte Agenten sensible Daten austauschen.
• Communication Fabric: Der Nachrichtenbus, der Protokolle wie A2A oder MCP unterstützt.
• Model Abstraction: Eine Schicht, die den Zugriff auf verschiedene LLMs (OpenAI, Anthropic, lokale Modelle) vereinheitlicht.
• Safety & Observability: Überwachung der Entscheidungswege und Durchsetzung von Sicherheitsrichtlinien in Echtzeit.

Hier lohnt sich ein Schichtenbild, weil der Mesh-Begriff sonst schnell zu abstrakt bleibt:

A2A Protocols: Die Sprache der Zusammenarbeit

Damit Agenten verschiedener Hersteller zusammenarbeiten können, bedarf es eines standardisierten Protokolls. Das "Agent-to-Agent" (A2A) Protokoll hat sich hierbei als führend erwiesen. Im Gegensatz zu MCP, das die vertikale Verbindung (Modell zu Werkzeug) regelt, ermöglicht A2A die horizontale Kommunikation zwischen Agenten [10], [17]. Der A2A-Interaktionsprozess ist hochgradig strukturiert und ähnelt einem Geschäftsprozess:

1. Discovery: Ein Agent findet einen Partner über dessen "Agent Card" (eine JSON-Datei, die Fähigkeiten und Endpunkte beschreibt).
2. Negotiation: Die Agenten handeln Bedingungen aus (Inquiry, Proposal, Agreement).
3. Task Delegation: Die eigentliche Aufgabe wird übertragen.
4. State Tracking: Der Fortschritt wird asynchron über SSE (Server-Sent Events) oder Webhooks gestreamt.

Der Ablauf eignet sich direkt für ein Sequenzdiagramm:

Ein minimales Python-Schema zeigt, wie eine Delegation aus Sicht des aufrufenden Agenten aussehen kann:

1import httpx
2
3
4async def delegate_task(agent_card_url: str, task_payload: dict) -> dict:
5	async with httpx.AsyncClient(timeout=30.0) as client:
6		# Discovery: Zuerst Fähigkeiten und Policy des Zielagenten lesen.
7		agent_card = (await client.get(agent_card_url)).json()
8		if "financial-analysis" not in agent_card["skills"]:
9			raise ValueError("Zielagent kann die Aufgabe nicht bearbeiten")
10
11		# Delegation: Danach die eigentliche Aufgabe an den A2A-Endpunkt senden.
12		response = await client.post(agent_card["task_endpoint"], json=task_payload)
13		response.raise_for_status()
14		return response.json()

Diese Standardisierung erlaubt es beispielsweise einem Forschungs-Agenten, einen spezialisierten Finanz-Agenten zu "beauftragen", eine Bilanzanalyse durchzuführen, ohne dass beide Agenten vom selben Entwickler stammen müssen. Die Integrität der Interaktion wird dabei etwa durch signierte Agent Cards und andere abgesicherte Identitätsmechanismen gestützt [10], [17].

Human-in-the-Loop 2.0: Orchestrierte Unterbrechungen

Wahre Autonomie bedeutet nicht die Abwesenheit des Menschen, sondern die Fähigkeit des Systems, zu wissen, wann es Hilfe braucht. In einer langlebigen Architektur wird dies durch Dynamic Interrupts gelöst. Anstatt den Prozess hart abzubrechen, nutzt der Agent spezialisierte Human-in-the-Loop-Schnittstellen. Der Workflow-Zustand wird währenddessen in der Durable Execution Layer (z. B. Temporal) geparkt und nach der Freigabe wieder aufgenommen. Dies verhindert den "Autonomy-Bias", bei dem Agenten versuchen, Probleme zu lösen, für die sie keine Berechtigung oder kein Kontextwissen haben [4].

Das Muster ist konzeptionell einfach: pausieren, auf Signal warten, exakt denselben Workflow fortsetzen:

Ein Temporal-naher Workflow zeigt diese Orchestrierung recht klar:

1from temporalio import workflow
2
3
4@workflow.defn
5class ApprovalWorkflow:
6	def __init__(self) -> None:
7		self.approved = False
8
9	@workflow.signal
10	def approve(self) -> None:
11		# Das Signal wird extern von einem Human-Review-UI gesetzt.
12		self.approved = True
13
14	@workflow.run
15	async def run(self, action: dict) -> str:
16		if action["risk"] == "high":
17			# Der Workflow wartet deterministisch auf eine Freigabe.
18			await workflow.wait_condition(lambda: self.approved)
19
20		return "Aktion freigegeben und ausgeführt"

Die Herausforderung der State Migration

Ein oft übersehener Aspekt ist die Evolution des Codes. Wenn wir die kognitive Architektur eines langlebigen Agenten verbessern, müssen bestehende Instanzen "migriert" werden. Ein Agent, der mit Version 1.0 eines Prompts gestartet wurde, kann inkonsistent reagieren, wenn er plötzlich mit den Tools von Version 2.0 konfrontiert wird. Das Management von Agent State Versioning wird daher zu einer Kernkompetenz im Agentic Platform Engineering.

State Migration braucht deshalb einen expliziten Versionspfad statt impliziter Feldannahmen:

1def migrate_state(state: dict) -> dict:
2	version = state.get("version", 1)
3
4	if version == 1:
5		# Beispiel: In V2 wird aus einem String-Feld eine strukturierte Policy-Liste.
6		state["policies"] = [{"name": state.pop("policy", "default"), "mode": "enforced"}]
7		state["version"] = 2
8		version = 2
9
10	if version == 2:
11		# Beispiel: In V3 wird die Zieldefinition in objective statt goal gespeichert.
12		state["objective"] = state.pop("goal")
13		state["version"] = 3
14
15	return state
16
17
18old_state = {"version": 1, "goal": "Analysiere Login-Sicherheit", "policy": "safe-mode"}
19new_state = migrate_state(old_state)
20print(new_state)

Zusammenfassung und Ausblick

Der Aufbau langlebiger KI-Agenten ist keine reine Frage der Modellstärke, sondern eine Herausforderung des Systems-Engineerings. Die Fähigkeit, den Zustand über Tage hinweg präzise zu serialisieren, den Kontext intelligent zu filtern und den kognitiven Drift durch formale Methoden zu unterbinden, bildet das Fundament für die nächste Generation produktiver KI. Langlebige Agenten transformieren unsere Arbeitsweise, indem sie Aufgaben übernehmen, die bisher menschliche Ausdauer erforderten. Ob in der Cybersicherheit, wo Systeme wie PentestGPT v2 oder Shannon Schwachstellen über komplexe Angriffsvektoren hinweg verfolgen, oder in der Forschung, wo InfiAgent hunderte von Dokumenten korreliert – der Schlüssel liegt in der Persistenz. Für die Praxis bedeutet dies:

• Setzen Sie auf Durable Execution (z. B. Temporal), um Ihre Workflows unzerstörbar zu machen.
• Nutzen Sie das Virtual Actor Model, um Skalierbarkeit und Ressourceneffizienz zu vereinen.
• Implementieren Sie hierarchische Überwachungsstrukturen und formale Verifizierung, um die Zuverlässigkeit zu garantieren.
• Bereiten Sie Ihre Systeme auf den Agentic Mesh vor, indem Sie offene Standards wie MCP und A2A unterstützen.

Die Reise von einfachen ReAct-Loops zu autonomen, langlebigen Protokollen hat gerade erst begonnen. Die hier beschriebenen Architekturen sind die Werkzeuge, mit denen wir diese Zukunft gestalten.

Weitere Beiträge

• KI-Agenten 01 - Mehr als nur Automatisierung: Entwurf kognitiver Architekturen für KI-Agenten
• KI-Agenten 02 - Das Architekturspektrum agentischer Systeme
• KI-Agenten 03 - Selbstreflexion in Agentischen Systemen
• KI-Agenten 04 - Architektonische Persistenz: Effizientes Management von Kurz- und Langzeitgedächtnis in langlebigen agentischen Systemen
• KI-Agenten 05 - Die Architektur der Ausdauer: Long-Running Context Persistenz und Kontext-Optimierung in agentischen Systemen