Richtlinie in der Nutzlast: Gut ausgerüstet für KI-Agenten-Architekturen

KI-Agenten sind nicht einfach intelligente Anwendungen. Sie verändern grundlegend, wie Anwendungen arbeiten, Entscheidungen treffen und sich anpassen. Im Unterschied zu traditionellen Systemen reagieren Agenten nicht nur auf Verkehrsregeln, sie bringen eigene mit. Jede von ihnen gesendete Anfrage enthält nicht nur Daten, sondern auch eingebaute Logik: Was passieren soll, wie sich der Fallback verhält und wann Erfolg erreicht ist.

Diese Veränderung verlagert die Entscheidungsfindung von statischen Steuerungsebenen direkt in die Laufzeit. Sie hebt die langjährige Trennung zwischen Steuerungs- und Datenebene auf und zwingt die Verkehrsinfrastruktur – Load Balancer, Gateways, Proxys –, pro Anfrage Richtlinien zu interpretieren, statt nur passiv vorkonfigurierte Routen auszuführen.

In diesem Beitrag untersuchen wir, wie Agentenarchitekturen wesentliche Annahmen im Traffic Engineering infrage stellen – von Gesundheitsprüfungen und Fallback-Mechanismen bis hin zu Beobachtbarkeit und Sicherheitsdurchsetzung. Wir zeigen auf, warum traditionelle Konstrukte wie statische Pools und gesundheitsbasierte Durchschnittswerte in einer Umgebung mit anfragebasierter Absicht nicht mehr ausreichen. Zudem argumentieren wir, dass sich die Layer-7-Infrastruktur weiterentwickeln muss, um nicht zur bloßen Standardtechnik zu verkommen – zuverlässig, aber strategisch unsichtbar. Um sich anzupassen, sollten Sie Ihren Traffic-Stack neu denken: machen Sie ihn zur Laufzeit programmierbar, kontextbewusst und kompatibel mit agenteninternen Protokollen wie dem Model Context Protocol (MCP). Dazu gehört, Fallback-Mechanismen zu überarbeiten, semantische Beobachtbarkeit zu integrieren und die Umsetzung agentenbasierter Richtlinien zu unterstützen. Innovative Werkzeuge wie Echtzeit-Datenkennzeichnung spielen dabei eine Schlüsselrolle und bieten entscheidende Unterstützung für diese Transformation.

Kurz gesagt: In Zukunft geht es bei der Datenverkehrsverwaltung nicht nur darum, Pakete zu liefern, sondern Absichten umzusetzen.

Agentenarchitekturen eröffnen ein neues Betriebsmodell, bei dem autonome, generative KI-gestützte Komponenten – sogenannte Agenten – zielgerichtet Aufgaben ausführen, Entscheidungen in Echtzeit treffen und den nötigen Kontext mitbringen, um ihre Ausführung flexibel anzupassen. Diese Agenten funktionieren ähnlich wie Service Chaining heute, allerdings ohne auf vorab konfigurierte Abläufe angewiesen zu sein. Sie bestimmen den optimalen Ablauf zur Laufzeit anhand der Ziele, des Umfelds und der beobachteten Ergebnisse.

Wir bewegen uns weg von herkömmlichen, zentral gesteuerten Systemen mit festen Abläufen hin zu dezentralen, dynamischen Systemen, die Ausführungspfade in Echtzeit gestalten. Anstelle statischer Microservice-Ketten setzen wir auf flexible, zielgerichtete Entscheidungen, die durch aktuelle Daten und Ziele gesteuert werden.

Agentenbasierte Systeme zeichnen sich durch Folgendes aus:

• Zielgerichtete Ausführung: Agenten erledigen Aufgaben anhand von Eingaben oder Missionen statt fester Abläufe. Sie wählen APIs aus, passen Parameter an und steuern um, um ihr Ziel sicher zu erreichen.

  Beispiel: Ein Agent, der eine Kundenbeschwerde bearbeitet, ruft je nach früheren Ergebnissen unterschiedliche APIs für Abrechnung, Konto und Messaging auf.

• Tragbarer Kontext: Agenten tragen eigene Erinnerungen, Zustände und Richtlinien mit sich. Mit dem Model Context Protocol (MCP) oder strukturierten Metadaten betten sie diesen Kontext in jede Anforderung ein.
• Laufzeitanpassung: Statt auf Entscheidungen der Infrastruktur zu warten, reagieren Agenten sofort: Sie wiederholen, leiten um, eskalieren oder passen Ausführungspfade in Echtzeit an.
• Integrierte Beobachtbarkeit: Jede Aktion beschreibt sich selbst. Agenten legen offen, warum sie einen bestimmten Datenpfad gewählt haben, was sie bewertet haben und ob ein Ziel erfüllt wurde. Das ist Beobachtbarkeit als Verhalten, nicht nur Protokolle und Kennzahlen.

Gemeinsam verwandeln sie die Anwendungslandschaft von etwas Vorhersehbarem in etwas Anpassungsfähiges und Dynamisches.

Heutige Systeme zur Datenverkehrsverwaltung arbeiten mit klar definierten Grenzen:

• Die Steuerungsebene legt fest, was gilt: welche Endpunkte zulässig sind, welche Pfade bevorzugt werden und welche Richtlinien Sie anwenden.
• Die Datenebene setzt Entscheidungen um: leitet Anfragen, sorgt für Sicherheit und verteilt die Last.

Dieses Modell funktioniert seit Jahrzehnten effektiv, vor allem in serviceorientierten Architekturen und Microservices-Umgebungen. Es geht davon aus, dass sich Verkehrsflüsse im Voraus planen lassen und Arbeitslasten sich vorhersehbar entwickeln.

Beispiele:

• Ein Load Balancer lenkt /api/login zu einem Pool und /api/images zu einem anderen.
• Gesundheitsprüfungen zeigen an, ob Knoten verfügbar oder ausgefallen sind.
• Statische Schwellenwerte legen die Bedingungen für den Failover fest.

Diese Systeme beruhen auf:

• Enger Zusammenhang von Richtlinien und Konfiguration mit statischen Ressourcen, wie bestimmte Pools und Mitglieder
• Statische Strukturen wie Pools und Mitglieder
• Determinierte Anforderungsweiterleitung basierend auf Pfad, Header oder Protokoll
• Zentrale Orchestrierung zur Serviceerkennung, Gesundheitsprüfung und Ausweichlogik

Agentenbasierte Systeme bringen Fluidität, Autonomie und selbstgesteuerte Logik, die diese Annahmen über den Haufen werfen.

In Agentenarchitekturen verschmelzen die traditionelle Trennung zwischen Steuerungsebene und Datenebene zunehmend. Agenten führen Anfragen nicht nur aus; sie integrieren die Logik, die bestimmt, was die Anfrage ist, welche Bedingungen Fallbacks auslösen, wie Erfolg gemessen wird und welchen Weg die Anforderung bevorzugt nehmen soll. Diese Aufgaben gehören üblicherweise zur Steuerungsebene, aber Agenten kodieren sie in Header, Tokens oder Metadaten, die direkt mit der Anfrage über die Datenebene wandern.

Diese Konvergenz verlangt, dass die Datenebene nicht länger nur passiv zentrale Entscheidungen ausführt. Sie muss Richtlinien aktiv und unmittelbar interpretieren. Die Anfrage ist nicht mehr einfach ein Paket, sondern ein Ausdruck der Richtlinie. Deshalb müssen Load Balancer, Gateways und Routing-Ebenen sich von reaktiven Komponenten zu Echtzeit-Interpretern der vom Agenten übermittelten Absichten entwickeln.

Dieser Wandel erschüttert die grundlegende Annahme der Architektur, dass die Steuerungsebene statisch und zentralisiert ist. Stattdessen verteilt, überträgt und personalisiert sich die Entscheidungslogik, folgt jeder Anforderung und wird zur Laufzeit ausgeführt. Dabei ändert sich nicht nur das Bereitstellungsmodell, sondern auch der Ort und die Art, wie Entscheidungen getroffen werden.

Damit schließen wir konsequent an das an, was Kubernetes begann, indem es die zugrunde liegende Infrastruktur – Netzwerk, Speicher und sogar L4-Datenverkehrssteuerung – abstrahierte und als „Rohrleitungen“ hinter einer deklarativen Steuerungsoberfläche verborg. Es hat diese Ebenen nicht beseitigt, sondern sie auf eine untergeordnete Rolle reduziert. Sie sind unsichtbar, automatisiert und einem neuen, zielorientierten System untergeordnet.

Agentenarchitekturen arbeiten genau wie bei der Infrastruktur, allerdings für den gesamten Stack.

Um diese Störungen anschaulich zu machen, betrachten Sie eine lokale Anwendungslieferung:

Beispiel: Ein regionales E-Commerce-Unternehmen verwendet einen ADC, um den internen API-Datenverkehr zu steuern. Wir setzen einen KI-Agenten ein, der die Geschwindigkeit der Auftragserfüllung optimiert. Er stellt fest, dass ein bestimmter API-Endpunkt, z. B. /api/inventory/check, wegen gestiegener Komplexität der Anfragen und Konkurrenz im Backend-Datenbanksystem schlechtere Leistung zeigt. Traditionelle Lastverteilungsalgorithmen, auch „schnellste Antwort“, erfassen diese Verlangsamung nicht ausreichend, weil sie Leistung als allgemeinen Durchschnitt aller Antworten eines Pool-Mitglieds berechnen, statt auf einzelne Aufgaben oder Aufrufe heruntergebrochen.

Um das SLA einzuhalten, leitet der Agent die Anfragen zur Bestandsprüfung an eine alternative Knotengruppe weiter, die für Transaktionsabfragen optimiert ist. Er markiert jede Anfrage mit einem Kontextheader wie X-Task-Profile: inventory-sensitive. Ein korrekt konfigurierte Load Balancer kann dies erkennen und den Datenverkehr gezielt steuern. Da diese Knoten allerdings nicht im statischen Pool für /api/inventory vorab zugewiesen sind, müssen Verkehrssteuerungsdienste Anweisungen des Agents berücksichtigen und das Routing dynamisch auflösen können, ohne starr auf statische Zuordnungen zu bauen.

Dieses Szenario zeigt klar, wo statische Konstrukte wie Pools an ihre Grenzen stoßen und warum Sie eine kontextbewusste, dynamisch programmierbare Steuerung des Datenverkehrs benötigen.

Agentenbasierte Systeme stellen mehrere grundlegende Annahmen der Datenverkehrsverwaltung infrage:

Konvergenz von Steuerungs- und Datenebene: Routing-Entscheidungen basieren jetzt direkt auf der Anfrage, statt auf statischen Regeln. So vereinfachen wir die bisherige Durchsetzungslogik grundlegend.

Absichtsbasiertes Routing: Agenten leiten den Datenverkehr basierend auf Zielen weiter, nicht nur auf Endpunkten. Ein einziger Endpunkt wie /api/process kann je nach Anweisungen des Agenten Hunderte unterschiedlicher Abläufe steuern.

Statische Pools verlieren an Relevanz: Konventionelle Pools setzen auf festgelegte Rollen. Agenten benötigen aber mal GPU-Zugriff, dann wieder CPU-Optimierung – deshalb ist die Poolzugehörigkeit oft zu starr.

Fallbacks und Failover entwickeln sich zu strategischen Maßnahmen: Failover bedeutete früher einfach „den nächsten Server versuchen“. Heute beurteilen Agenten die Leistung in Echtzeit sowie frühere Ergebnisse und entscheiden strategisch, wie sie vorgehen.

Verkehrsmuster entwickeln sich, sie wiederholen sich nicht: Agenten erstellen Workflows genau dann, wenn Sie sie brauchen. Sie können nicht alle Wege im Voraus festlegen; sie entstehen jeweils passend zum Bedarf.

Solche Störungen fordern Load Balancer, Gateways und Observability Stacks heraus, sich flexibel und in Echtzeit auf den Datenverkehr einzustellen.

Gesundheits- und Leistungskennzahlen bilden stets die Grundlage für die Verwaltung des Datenverkehrs. Lastenausgleich setzt voraus, dass Sie wissen, ob ein Server verfügbar ist, wie schnell er reagiert und wie stark er ausgelastet ist. Bei agentengesteuerten Systemen lässt sich der Gesundheitszustand nicht nur als Ja oder Nein bewerten, und die Leistung darf nicht pauschal über große Kategorien gemittelt werden. Die Kennzahlen müssen ausdrücken , ob ein Ziel für eine spezifische Aufgabe geeignet ist, nicht nur, ob es aktiv ist.

Warum das zählt: Gesundheitsmetriken bestimmen direkt die Datenverkehrssteuerung, Failover-Entscheidungen und Leistungsoptimierung. In einer agentenbasierten Umgebung verfolgt jede Anfrage ein eigenes Ziel und braucht womöglich einen anderen Datenpfad oder garantierte Antwort. Traditionelle Methoden erfüllen diesen Anspruch nicht, weil:

• Sie setzen auf einfache aggregierte Werte (z. B. durchschnittliche Reaktionszeit), die aufgabenspezifische Schwankungen verdecken.
• Sie bewerten die Gesundheit lediglich aus Serversicht und haben keinen Einblick in den Erfolg oder die Zufriedenheit auf Agentenebene.
• Sie gehen von einer Einheitlichkeit des Datenverkehrs aus, die nicht zutrifft, wenn Entscheidungen zur Anforderungsbearbeitung zur Laufzeit getroffen werden.

Beispiel: Ein Pool von API-Servern besteht Gesundheitsprüfungen, doch einer schafft es nicht, für X-Task-Profile: bestandskritische Anfragen konsequent Antworten unter 100 ms zu liefern. Ein Agent, der genau dieses Latenzprofil erwartet, wertet das als Ausfall, selbst wenn die Infrastruktur normal läuft.

Was Sie benötigen:

• Wir bieten Ihnen eine Echtzeit-Telemetrie pro Anfrage, die Absichten und tatsächliche Ergebnisse klar widerspiegelt.
• Aufgabenspezifische Gesundheitsbewertung, die erkennt, wenn ein Knoten für bestimmte Aufgaben beeinträchtigt ist, auch wenn er für andere einwandfrei funktioniert.
• Wir integrieren das vom Agenten gemeldete Ergebnis von Erfolg oder Misserfolg in die Anforderungsweiterleitung und Priorisierung.

Tools zur Datenkennzeichnung spielen eine entscheidende Rolle, indem sie den fließenden Datenverkehr markieren und Leistung sowie Kontext passend erfassen. So können Systeme nicht nur nachvollziehen, was passiert ist, sondern auch ob das Ziel des Akteurs, der es initiiert hat, erreicht wurde.

Bei herkömmlicher Infrastruktur setzen wir Fallback-Mechanismen wie Wiederholungen, Umleitungen zu Backup-Knoten oder das Auslösen von Leistungsschaltern auf der Infrastrukturebene um. Load Balancer, Proxys und Gateways nutzen vordefinierte Grenzwerte (z. B. Timeouts, Fehlerquoten), um festzulegen, wann sie die Anforderungsweiterleitung zu einem Ziel stoppen und eine Alternative versuchen.

Agentenarchitekturen kehren diese Denkweise um.

Agenten bringen ihre eigenen Fallback-Strategien mit. Sie integrieren Wiederholungsrichtlinien, Eskalationslogik und zielgerichtete Prioritäten direkt in die Anforderung. Das erhöht die Komplexität und kann Konflikte mit Failover-Mechanismen auf Infrastrukturebene verursachen.

Warum das für Sie relevant ist:

• Die Infrastruktur könnte einen Fehler als behebbar einstufen, während der Agent ihn als nicht akzeptabel betrachtet (oder umgekehrt).
• Agenten und Infrastruktur können gleichzeitig einen Fallback einleiten, was zu unnötigen Wiederholungen, längeren Verzögerungen oder Datenverkehrsschleifen führt.
• Leistungsschutzschalter, die für durchschnittlichen Datenverkehr ausgelegt sind, können den Zugriff auf Dienste blockieren, die ein Agent weiterhin als optimal ansieht.

Zentrale Risiken:

• Doppeltes Fallback: Agent und Infrastruktur versuchen es beide erneut, was unnötige Belastungen verursacht.
• Race Conditions: Der Agent wechselt zu einer teureren oder weniger sicheren Option, obwohl das System das Problem in Millisekunden gelöst hätte.
• Unterbrechung beim deterministischen Failover: Statische Richtlinien erfassen nicht die Details der Agentenfunktionen.
• Beschädigung: Agenten-Metadaten sind fehlerhaft, fehlen oder lassen sich nicht lesen.

Hinweise zur Anpassung:

• Die Infrastruktur muss agentenspezifische Fallback-Prioritäten erkennen und berücksichtigen (z. B. über X-Fallback-Order, X-Timeout-Preference).
• Wir müssen Leistungsschalter absichtsbewusst gestalten, damit sie aufgaben- oder agentenspezifische Logik statt globaler Schwellenwerte unterstützen.
• Führen Sie eine verhandlungsfähige Failover-Logik ein, bei der Agenten bevorzugte Strategien vorschlagen und Gateways auf Grundlage von Systemzustand, Auslastung und Richtlinien entscheiden.
• Verkehrssysteme müssen die Standardausführungslogik unterstützen, wenn Agent-Metadaten fehlen, unvollständig sind oder die Schemavalidierung nicht bestehen, damit sie sich trotzdem stabil verhalten.
• Die Infrastruktur muss selbstverstärkende Schleifen und widersprüchliche Agentenwiederholungen erkennen und verhindern, die bei einer Verschlechterung des Systems den Datenverkehr erhöhen könnten.

Beispiel: Ein Agent, der eine Echtzeit-Betrugsprüfung durchführt, verlangt eine Antwort innerhalb von 50 ms. Seine Fallback-Logik zieht ein zwischengespeichertes Teilergebnis einer langsamen vollständigen Abfrage vor. Eine Infrastrukur ohne dieses Wissen leitet trotzdem an das vollständige Backend weiter, was für den Nutzer spürbare Verzögerungen verursacht. Ein kooperativeres Modell würde die Priorität des Agenten bei der Fallback-Lösung berücksichtigen und die schnellere, reduzierte Antwort liefern.

Wenn Entscheidungen in den Stack aufsteigen, müssen Sie die Fallback-Strategien ebenfalls anpassen. Circuit Breaker und Wiederholungslogiken dürfen nicht starr oder undurchsichtig bleiben; sie müssen sich an die Angaben der Agenten anpassen und dabei Sicherheit sowie Fairness im System gewährleisten.

Auch wenn Agentenarchitekturen die Entscheidungsfindung und Koordination in die Anforderungsschicht verlegen, sorgt die zugrunde liegende Infrastruktur weiterhin für die Zuverlässigkeit des Kernsystems. Deshalb bleiben Hochverfügbarkeit (HA) und Failover-Mechanismen auf Infrastrukturebene unverzichtbar. Mit zunehmendem dynamischem und autonomem Verhalten der Systeme werden sie sogar noch wichtiger.

Agenten lenken den Datenverkehr anhand von Zielen und Kontext, vertrauen jedoch weiterhin auf das Netzwerk, um die Erreichbarkeit und Belastbarkeit der Dienste auch bei Störungen zu gewährleisten. Load Balancer erkennen nicht erreichbare Knoten, ausgefallene Dienste oder beeinträchtigte Umgebungen und leiten den Datenverkehr in Echtzeit um – unabhängig von der Fallback-Strategie des Agenten.

Unveränderliche Kernverantwortlichkeiten:

• Überwache Poolmitglieder und den Gesundheitszustand von Backend-Diensten
• Erkennen Sie Netzwerkpartitionen oder Routingfehler
• Leiten Sie den Datenverkehr basierend auf Systemaktivität, Verfügbarkeit oder Leistungsverschlechterung um
• Erhalten Sie bei Bedarf die Hochverfügbarkeit zustandsbehafteter Dienste oder Sitzungen

Agenten treffen Entscheidungen darüber, „was als Nächstes passiert“, doch der Load Balancer kontrolliert, „wie schnell wir wieder einsatzbereit sind, wenn ein Knoten ausfällt“.

Adaptive, agentenbewusste Routing-Logik darf nie auf Kosten der betrieblichen Stabilität gehen. Eine gut ausgestaltete Infrastruktur muss sicherstellen:

• Sofortiges Failover und Neubalance des Datenverkehrs bei unerreichbaren Knoten
• Robuste HA-Topologien, die Ihre Agenten und Dienste vor Ausfällen in vorgelagerten Systemen schützen
• Schnelle, automatisierte Wiederherstellung, die die Fallback-Logik des Agents unterstützt, statt ihr entgegenzuwirken

Kurz gesagt, agentenbasierte Architekturen heben den Bedarf an Failover nicht auf – sie erhöhen allerdings die Anforderungen. Die Infrastruktur muss jetzt schneller reagieren, dabei kontextbewusster handeln und darf kein Hindernis für autonomes Verhalten darstellen.

Die Umstellung auf agentenbasierte Architekturen verändert grundlegend, wie Systeme wie Load Balancer und Gateways den Datenverkehr steuern müssen. Während herkömmliche Systeme ihre Entscheidungen anhand vorkonfigurierter Richtlinien trafen – oft unabhängig von der Anfrage – integrieren agentengesteuerte Systeme diese Richtlinien direkt in die Anfrage. Das bildet die Basis des Model Context Protocol (MCP), das die anfragebasierte Ausführung eingebetteter Richtlinien ermöglicht.

Wir nennen dieses Modell „Richtlinie in der Nutzlast“. Anstatt zentrale Systeme jeden Grenzfall analysieren zu lassen, kodiert der Agent wichtige Richtlinienentscheidungen (wie Fallback-Strategie, Knotenvorlieben, Fehlertoleranz oder Datenschutzanforderungen) direkt in jede Anfrage. Die Infrastruktur muss diese Richtlinienanweisungen dann in Echtzeit auslesen, verstehen und umsetzen.

Dieses neue Ausführungsmodell wandelt die Rolle der Komponenten für Netzwerk-Datenverkehrsverwaltung grundlegend um:

• Von der Entscheidungsfindung zur Umsetzung: Die Infrastruktur legt nicht mehr fest, wohin der Datenverkehr gelenkt wird; sie setzt die Entscheidung des Agents durch.

  Beispiel: Ein Load Balancer, der X-Route-Preference: gpu-optimized liest, muss den Datenverkehr entsprechend weiterleiten – auch wenn dieser Knoten nicht im ursprünglichen Pool war.

• Zur Laufzeit programmierbar: Sie müssen iRules und Richtlinien so gestalten, dass sie Header wie X-Intent, X-Context oder X-Goal auswerten. So verlagern Sie die Logik von statischen Pfaden auf eine dynamische Inline-Interpretation.
• Kontextbasierte Anforderungsweiterleitung: ADCs und vergleichbare Dienste müssen anhand von Identität, Absicht und Kontext weiterleiten, nicht nur basierend auf Host oder Pfad.
• Semantische Beobachtbarkeit: Protokolle sollten nicht nur zeigen, was geschehen ist, sondern auch warum: „Agent aufgrund der Überschreitung des Latenzlimits umgeleitet“ ist aussagekräftiger als einfach „an Pool B weitergeleitet“.

Datenlabeling-Technologien und ähnliche Werkzeuge helfen Ihnen, den Kontext von Echtzeitanfragen zu markieren und zu klassifizieren, sodass Sie semantisches Routing und Beobachtbarkeit praktisch umsetzen können.

KI-Agenten arbeiten nicht isoliert. Sie vernetzen sich mit Altsystemen, nutzen bewährte APIs, steuern Geschäftslogik in Unternehmensdatenbanken und greifen sowohl auf monolithische Backends als auch Microservices zu. Für Unternehmen heißt das: Sie starten nicht neu, sondern entwickeln sich weiter.

Enterprise-Stacks bestehen aus einer Kombination von:

• Selbst nach Jahrzehnten setzen Finanzdienstleister weiterhin auf SOAP-APIs
• RESTful-Dienste hinter Webanwendungen
• Nachrichtenwarteschlangen für asynchrone Bestandsverwaltungssysteme
• Cloud-native Microservices
• SaaS-APIs mit Begrenzung der Zugriffsrate und komplexer Authentifizierung
• LLMs und speziell angepasste Agenten

Agenten müssen lernen, mit allen Elementen zu arbeiten. Ihre Infrastruktur muss dabei in Echtzeit vermitteln und kontextbezogen Richtlinien durchsetzen.

Agenten brauchen nicht fünf Endpunkte, sondern ein klares Ziel. Stellen Sie Geschäftsfunktionen wie „Bestellstatus abrufen“ über Abstraktionsschichten oder API-Kompositionen so bereit, dass Agenten sie über einen einzigen, verständlichen Einstiegspunkt nutzen können.

Vorbereitungsschritt: Setzen Sie API-Gateways oder Service Meshes ein, um aufgabenorientierte Endpunkte mit klar definierten Eingabe- und Ausgabeschnittstellen zu bündeln.

Traditionelles Logging erfasst Methode, Pfad und Antwortzeit. Agenten messen jedoch vor allem:

• Worin bestand die Aufgabe
• Welcher Fallback-Versuch wurde durchgeführt
• Ob Sie das Ziel erreicht haben

Vorbereitungsschritt: Setzen Sie auf semantische Observability-Tools, die den Datenverkehr mit Labels wie X-Intent, X-Task-Type und X-Agent-Outcome versehen.

Agenten übermitteln Fallback-Anweisungen, Timeout-Vorgaben und Sicherheitsanforderungen mit der Anfrage. Bestehende Infrastrukturen ignorieren diese Daten.

Vorbereitungsschritt: Erweitern Sie Verkehrsrichtlinien, damit sie Agentenmetadaten analysieren und darauf reagieren (z. B. X-Route-Preference, X-Fallback-Order, X-Data-Class). Beginnen Sie mit iRules oder einer ähnlichen Laufzeitskriptsprache.

Agenten arbeiten autonom. Darauf sollten Sie achten:

• Welcher Agent handelt im Auftrag von wem
• Zu welchen Tools haben Sie Zugriff
• Welche Datenbereiche dürfen Sie bearbeiten

Vorbereitungsschritt: Integrieren Sie identitätsbasierten Zugriff und attributbasierte Richtlinienkontrollen (ABAC) statt nur IP-Whitelist oder statisches RBAC.

Infrastruktur und Agenten dürfen sich bei der Wiederherstellung nicht gegenseitig überholen. Verlasse dich darauf, dass der eine die Laufzeitziele verfolgt, während der andere systemweite Schutzmaßnahmen durchsetzt.

Vorbereitungsschritt: Trennen Sie deutlich den Fallback-Bereich der Agenten (ihre Zuständigkeit) vom Failover der Infrastruktur (Ihr Verantwortungsbereich). Legen Sie Verhandlungsregeln und Bedingungen für Überschreibungen fest.