KI-Agenten im Web: Die neue Form des Datenverkehrs

Bis vor Kurzem gab es im offenen Web zwei grundlegende Formen von Datenverkehr. Menschliches Surfen, episodisch, aufmerksamkeitsgebunden, hart begrenzt durch die Anzahl der Seiten, die eine Person in einer Sitzung lesen kann. Und programmatisches Scraping, hochvolumig, fächerartig verteilt, größtenteils zustandslos, für den Nutzer weitgehend unsichtbar.

Eine dritte Form entsteht gerade in rasantem Tempo. Browser-nutzende KI-Agenten, Anthropics Computer Use, OpenAIs Operator, die verschiedenen quelloffenen autonomen Agenten, steuern einen echten Browser durch eine Abfolge von Seiten im Auftrag eines Nutzers. Der dabei erzeugte Datenverkehr sieht weder wie die eine noch wie die andere der bisherigen Formen aus. Websites, die sich erfolgreich gegen Scraping gewehrt haben, wissen noch nicht genau, wie sie damit umgehen sollen. Infrastrukturanbieter, die diese Agenten unterstützen, suchen noch nach den richtigen Grundbausteinen.

Dieser Beitrag ist eine Momentaufnahme dessen, wie KI-Agenten-Datenverkehr heute in der Produktion tatsächlich aussieht und wie er den Infrastruktur-Stack geprägt hat, der ihn trägt.

Wie der Datenverkehr auf Leitungsebene aussieht

Ein typischer KI-Agenten-Ablauf heute: Der Nutzer bittet den Agenten, “den günstigsten Direktflug von New York nach Tokio Ende August” zu finden. Der Agent startet ein headless Chromium, navigiert zu Google Flights, füllt das Formular aus, sendet es ab, analysiert die Ergebnisse, folgt dem günstigsten Angebot zur Website der Fluggesellschaft, navigiert zur Buchungsseite, bestätigt die Verfügbarkeit und liefert die Antwort zurück.

Das sind 8-15 HTTP-Anfragen über 30-90 Sekunden, mit folgenden Eigenschaften:

Stoßweise. Entweder null Anfragen oder eine anhaltende Abfolge, kein stabiler Zwischenzustand. Der Agent ist inaktiv, bis der Nutzer fragt, dann läuft er eine Minute lang auf Hochtouren.

Zustandsbehaftet innerhalb des Bursts. Der Ablauf des Agenten hat Cookies, eine Session, einen User-Agent. Anfrage N+1 muss aus Sicht der Zielseite wie eine Fortsetzung von Anfrage N aussehen. Ein IP-Wechsel mitten im Ablauf unterbricht die Session.

Heterogene Endpunkte. Jeder Agentenlauf besucht mehrere unterschiedliche Websites: Suchmaschine, Fluggesellschaft 1, Fluggesellschaft 2, möglicherweise ein Vergleichsaggregator. Jede Website hat ihre eigene Anti-Bot-Haltung.

Nutzergebundene Geografie. Der Nutzer möchte Flüge ab JFK, nicht von einem zufälligen Rechenzentrum. Der Datenverkehr des Agenten sollte geografisch plausibel dort verortet sein, wo der Nutzer fragt, oder zumindest dort, wo er so erscheinen möchte, als würde er buchen.

Latenzsensitiv. Der Nutzer wartet. Eine Anfrage-Latenz von 800ms statt 200ms multipliziert sich über 12 Anfragen und macht den Unterschied zwischen “der Agent hat in 30 Sekunden geantwortet” und “der Agent hat in 1,5 Minuten geantwortet”.

Diese Form entspricht weder dem Modell des menschlichen Surfens (zu schnell, zu zustandsbehaftet in Maschinengeschwindigkeit) noch dem Scraping-Modell (zu wenige Anfragen pro Session, zu sehr an Sessions gebunden, zu stark nutzerverankert).

Warum naive Infrastruktur versagt

Einige Muster, die erfahrene Daten-Teams erfolgreich einsetzen, lassen sich nicht übertragen:

Anfrage-weises Rotieren eines großen Residential-Pools. Das Standardmuster beim Scraping. Für Agenten falsch, weil die Session IP-Kohärenz, Login-Cookies, Suchzustand und Fingerprint-Bindung benötigt. Anfrage-weises Rotieren bricht die Session bei Anfrage 2.

Datacenter-Proxies für Geschwindigkeit. Verlockend wegen des Latenzprofils. Falsch, weil die Zielseiten, die der Agent besucht (Google, Fluggesellschaften, E-Commerce, Banken), Datacenter-Datenverkehr aggressiv abwehren. Die Hälfte der Agentenläufe scheitert an CAPTCHAs.

Einzelne statische Residential-IP. Verlockend wegen der Kohärenz. Falsch, weil die IP schnell verbraucht wird: Eine IP, die Tausende von Agentenläufen bedient, sieht nach den ersten 100 Läufen wie ein Scraper aus.

Das Muster, das funktioniert, ist eher Sticky Sessions auf Residential-Basis, mit einer frischen Session pro Agentenlauf, mit geografischem Targeting, das der Absicht des Nutzers entspricht, und mit einer Session, die auf die natürliche Lebensdauer des Laufs begrenzt ist.

Das funktionierende Muster

Die Architektur, auf die die meisten produktiven Agenten-Deployments konvergieren:

user_request →
  agent.spawn(
    proxy_session_id=hash(user_id, request_id),    # unique per user-run pair
    proxy_country=user_geo_or_intent,
    proxy_ttl=longer_than_expected_run,            # don't expire mid-flow
  ) →
  browser navigates target sites through that session →
  agent returns result →
  proxy session expires naturally

Die Proxy-Abstraktion erfolgt pro Lauf, nicht pro Anfrage. Innerhalb eines Laufs hat der Agent eine konsistente Residential-IP. Über Läufe hinweg erhält jeder Agentenablauf eine frische IP von einem neuen ISP aus (in der Regel) einer neuen Stadt. Die Pool-Diversität schützt davor, dass eine einzelne IP durch wiederholten Agenten-Datenverkehr verbraucht wird; die Session-Kohärenz schützt davor, dass die Zielseite den Agenten mitten im Ablauf als verdächtig einstuft.

Dies ist funktional dasselbe Muster, das ein Preisvergleichs-Bot verwenden würde: Sticky Residential Session pro Session, Kundenzuordnung zu einer stabilen sid. Die Besonderheit bei KI-Agenten ist, dass das Volumen dramatisch höher ist (jede Nutzeranfrage, die einen Agentenlauf auslöst, ist eine Session) und die Dauer kürzer ist (die meisten Agentenläufe dauern unter 2 Minuten).

Bandbreitenbasierte Residential-Infrastruktur passt dazu von Natur aus: Agentenläufe sind bandbreitenbegrenzte Transaktionen, keine parallelitätsbegrenzten. Zahlen pro GB, das die Agenten bewegen; Parallelität ist das Problem der Agenten-Laufzeit, nicht das des Proxys.

Was Zielseiten tun

Noch größtenteils nichts. Die meisten großen Websites behandeln KI-Agenten-Datenverkehr noch genauso wie Scraping-Datenverkehr: dieselben Anti-Bot-Regeln, dieselben Sperren. Das wird sich schnell in zwei Richtungen ändern:

Websites, die von Agenten-Datenverkehr profitieren, werden ihn ermöglichen. Buchungsabläufe, E-Commerce-Checkout, Preisvergleich. Der Agent ist ein echter Nutzer, der durch eine Automatisierungsschicht bedient wird; die Konversion ist trotzdem real. Kluge Websites beginnen damit, agentenfreundliche Endpunkte zu veröffentlichen, robots-ähnliche Deklarationen, die besagen: “Behandle Datenverkehr mit diesem User-Agent und diesem Header als menschlich vermittelten Agenten, blockiere nicht, drossle aber.”

Websites, die durch Agenten-Datenverkehr verlieren, werden sich absichern. Alles Werbefinanzierte hat ein echtes Problem: Agenten sehen keine Werbung, klicken keine Werbung, konvertieren keine Werbetreibenden. Nachrichtenwebsites, kostenlose Inhaltsseiten, alles, was durch Impressionen monetarisiert wird, hat einen Anreiz, Agenten-Datenverkehr gezielt zu erkennen und zu blockieren. Das wird das nächste Kapitel des Anti-Bot-Wettrüstens sein, und es wird umkämpfter sein als Scraping, weil die Agentenschicht mächtige Unternehmensunterstützer hat, die verlieren, wenn ihre Agenten blockiert werden.

Die Infrastrukturschicht in der Mitte, das sind wir und unsere Mitbewerber in Residential-Proxy-Netzwerken, befindet sich in einer interessanten Position. Wir sind die Zugriffsschicht, die Agenten den Zugang zu Websites ermöglicht, die sie noch nicht willkommen heißen. Wenn die Verhandlung zwischen Websites und Agenten-Anbietern ausgetragen wird (wahrscheinlich durch eine Mischung aus Verträgen, Zahlungsbeziehungen und überarbeiteten robots.txt-ähnlichen Protokollen), wird die Rolle reiner Infrastrukturanbieter auf dem “erlaubten” Pfad enger und auf dem “benötigt IP-Ebenen-Diversität”-Pfad breiter.

Was 2026 zu beobachten ist

Einige Signale, die es wert sind, verfolgt zu werden, wenn man auf Agenten aufbaut:

Der Anteil der Agentenläufe, die eine erneute Authentifizierung mitten im Ablauf benötigen. Heute liegt er mit ordentlichen Sticky Sessions nahe null. Wenn er zu steigen beginnt, haben Zielseiten gelernt, Agenten-Fingerprints zu erkennen, und fordern mitten in der Session heraus. Die Abhilfe erfordert entweder besseres Browser-Fingerprinting auf der Agentenseite oder andere Proxy-Strategien.

Latenz p99 bei mehrstufigen Agentenläufen. Heute ist es hauptsächlich Netzwerk- und Antwortzeit der Zielseite. Wenn Proxy-Gateways unter gleichzeitiger Agentenlast zum Engpass werden, muss die Infrastrukturschicht skalieren.

Geografische Verteilung des Agenten-Datenverkehrs. Heute ist der meiste Agenten-Datenverkehr geografisch dort verortet, wo die Agenten-Laufzeit gehostet wird (hauptsächlich US-East). Da Agenten zunehmend echte Nutzertransaktionen vermitteln (Shopping, Buchung, Banking), muss der Datenverkehr am Standort des Nutzers verortet sein, damit die Seitenlogik korrekt funktioniert. Das ist das Bullen-Argument dafür, dass stadt- und ASN-präzise Residential-Infrastruktur zum Standard wird.

Agentenfreundliche Website-Deklarationen. Achten Sie auf das Entstehen eines agents.txt-Analogons oder einer strukturierten “Ich begrüße Agenten-Datenverkehr unter diesen Bedingungen”-Deklaration. Wenn das passiert, wird die Rolle der Proxy-Schicht enger; wenn nicht, bleibt die Proxy-Schicht der Zugangsvermittler.

Das Fazit

KI-Agenten sind eine wirklich neue Form des Datenverkehrs. Sie sind kein Scraping, kein Surfen, kein RAG-Retrieval; sie teilen Merkmale mit jedem davon, entsprechen aber keinem davon vollständig. Die darunterliegende Infrastruktur muss flexibel genug sein, um Sticky Sessions pro Lauf bei Scraping-Volumen-Parallelität mit nutzerverankerter Geografie und Latenzzielen zu unterstützen, die ein Drittel dessen betragen, was Scraping toleriert.

Die gute Nachricht für Infrastrukturanbieter: Richtig aufgebaute Residential-Proxy-Netzwerke unterstützen genau diese Form bereits. Sticky Sessions pro Agentenlauf, frische IPs pro Session, geografische Präzision, Bandbreitenpreisgestaltung, die mit der Nutzung skaliert. Die Grundbausteine, die beim Bedienen von Scrapern und Preisvergleichs-Bots gereift sind, sind dieselben Grundbausteine, die Agenten benötigen.

Die Produktfrage für die nächsten zwei Jahre ist nicht, ob Agenten-Datenverkehr eine echte Kategorie sein wird, das ist er bereits. Es geht darum, wie sauber der Infrastruktur-Stack und das Ökosystem der Zielseiten auf Bedingungen konvergieren werden, mit denen beide leben können. Im nächsten Jahresbeitrag werden wir ein klareres Bild haben.