Die Timeout-Krise: Warum das moderne Web unter der Last von Agentic AI zusammenbricht

Wenn Sie in letzter Zeit einen fortschrittlichen KI-Agenten verwendet haben – sei es O1 von OpenAI, Devin oder einen benutzerdefinierten Enterprise Reasoning Agent –, haben Sie ihn wahrscheinlich gesehen. Das Spinnrad, das sich genau 60 Sekunden lang dreht. Gefolgt vom leeren Bildschirm. Gefolgt von dem gefürchteten: „504 Gateway Timeout“.

Es handelt sich nicht um einen Fehler im Code. Es handelt sich nicht um einen Serverabsturz. Es handelt sich um eine grundlegende architektonische Inkompatibilität zwischen dem Internet, das wir aufgebaut haben (Web 2.0), und der Arbeitslast des Internets, das wir aufbauen (Agentische KI).

Das moderne Web steht vor einer Timeout-Krise, und um diese zu beheben, muss die Grundannahme, dass das Web „schnell“ sei, aufgegeben werden.

Der alte Vertrag: REST und die 30-Sekunden-Regel

In den letzten 20 Jahren wurde das Web auf eines optimiert: Reaktionsfähigkeit. Das vorherrschende Paradigma ist REST (Representational State Transfer). Der Vertrag zwischen Client und Server ist synchron und einfach:

1. Anfrage: Der Kunde fragt nach Daten (z. B. „Besorgen Sie mir das Benutzerprofil“).
2. Prozess: Server ruft Daten ab (Datenbankabfrage: ~50 ms).
3. Antwort: Server sendet Daten zurück.

Wenn Schritt 2 länger als 30 Sekunden (oder 60 Sekunden bei einigen Clouds) dauert, gerät die Infrastruktur in Panik. Der Load Balancer (NGINX, AWS ALB, Cloudflare) geht davon aus, dass der Server tot, „zombifiziert“ oder in einer Endlosschleife feststeckt. Es unterbricht die Verbindung, um das System zu schützen. Dies war eine Funktion, kein Fehler. Dadurch wurde verhindert, dass hängengebliebene Prozesse RAM- und CPU-Threads belegen. Es erzwang eine „Fail-Fast“-Disziplin.

Agentic AI: Die zeitraubende Arbeitsbelastung

Klassischerweise waren Computer schnell. Wenn eine Abfrage 5 Minuten dauerte, war Ihr SQL fehlerhaft. Aber Agentische KI ist nicht nur „Abfragen“. Es ist „Denken“.

Ein Argumentationsmodell der Klasse „O1“ oder ein Agentic Workflow sucht nicht nur nach Daten. Es:

1. Zerlegt eine Eingabeaufforderung in einen Plan.
2. Durchsucht das Internet (durchsucht 10 Websites).
3. Schreibt Code.
4. Führt Code in einer Sandbox aus.
5. Analysiert die Fehlerprotokolle.
6. Refaktorisieren Sie den Code.
7. Iteriert.

Dieser Vorgang wird nicht in Millisekunden gemessen. Sie wird in Minuten gemessen. Manchmal Stunden. Wenn Sie einen 5-minütigen Denkprozess in eine 30-sekündige REST-Pipe erzwingen, platzt die Pipe. Der Client (Browser) wartet noch, aber der Mittelsmann (Load Balancer) hat bereits aufgelegt. Der Agent beendet seine Arbeit 4 Minuten später, hat aber niemanden, mit dem er sprechen kann. Das Ergebnis ist eine verlorene Aufgabe, ein frustrierter Benutzer und verschwendete Rechenguthaben.

Der architektonische Wandel: Von synchron zu ereignisgesteuert

Um die Ära der Agenten zu überleben, erleben wir den bedeutendsten architektonischen Wandel seit dem Tod von SOAP/XML. Wir wechseln von Synchronous Request/Response zu Asynchronous Event-Driven Architecture (EDA).

Das „Ticket“-System

Wenn Sie im neuen Paradigma eine KI bitten, „mir eine Website zu erstellen“, hält der Server nicht die Linie.

1. Anfrage: Der Client sendet eine Eingabeaufforderung.
2. Bestätigung: Der Server antwortet sofort (HTTP 202 akzeptiert): „Ich habe es. Hier ist Ihre Ticket-ID #1234. Ich arbeite daran. Auf Wiedersehen.“
3. Die Verbindung trennen: Die HTTP-Verbindung wird geschlossen. Dem Browser steht es frei, andere Dinge zu tun.
4. Verarbeitung: Der Agent arbeitet im Hintergrund (Minuten/Stunden).
5. Benachrichtigung: Wenn Sie fertig sind, sendet der Server ein Signal.

Signalprotokolle: Woher weiß der Browser das?

Wir erleben einen Krieg der Protokolle, um Schritt 5 zu bewältigen:

• Umfrage: Der Browser fragt alle 5 Sekunden: „Sind Sie schon fertig?“ (Einfach, aber ressourcenintensiv).
• Webhooks: Der Server ruft eine bestimmte URL auf, wenn er fertig ist (ideal für Server-zu-Server, schlecht für Browser).
• Vom Server gesendete Ereignisse (SSE): Ein unidirektionaler persistenter Kanal, über den der Server Aktualisierungen weiterleitet („Scannen…“, „Code schreiben…“, „Fertig“). Dies wird zum Standard für das Streaming von LLM-Tokens.
• WebSockets: Vollständige bidirektionale Kommunikation. Übertrieben für die meisten Textgenerierungen, aber notwendig für Echtzeit-Sprach-/Videoagenten.

Dauerhafte Ausführung explodiert

Die Timeout-Krise hat den explosiven Aufstieg von Durable Execution-Plattformen wie Temporal, Inngest und Hatchet vorangetrieben.

Wenn in einem Standard-Python/Node-Skript der Server neu startet oder abstürzt, während der Agent 4 Minuten in einer Aufgabe ist, gehen diese 4 Minuten Arbeit verloren. Die KI hat „Amnesie“. Dauerhafte Ausführungs-Engines führen ein persistentes Protokoll ein. Sie speichern den „Zustand“ der Funktion bei jedem Schritt.

• Schritt 1: Plan generiert (gespeichert).
• Schritt 2: Scrape Google (gespeichert).
• ABSTURZ (Server-Neustart).
• Wiederherstellung: Der Server wacht auf, erkennt, dass Schritt 2 abgeschlossen wurde, und fährt sofort mit Schritt 3 fort.

Dies ist von entscheidender Bedeutung, da KI nichtdeterministisch und teuer ist. Sie können es sich nicht leisten, einen API-Aufruf im Wert von $2,00 erneut auszuführen, nur weil ein Pod neu gestartet wurde. Durch die dauerhafte Ausführung wird sichergestellt, dass ein einmal gestarteter Agent garantiert beendet wird.

Die Zukunft: A2A (Agent-to-Agent)

Wir nähern uns schnell einer Welt, in der der Großteil des Internetverkehrs nicht Mensch-zu-Server, sondern Agent-zu-Agent (A2A) erfolgt. Diesen Agenten ist das „Laden von Spinnern“ oder die „wahrgenommene Latenz“ egal. Sie legen Wert auf Zuverlässigkeit und Korrektheit.

Wir erleben die Entstehung neuer Protokolle (wie MCP – Model Context Protocol), die speziell darauf ausgelegt sind, es Agenten zu ermöglichen, einander über lange Zeiträume hinweg zu entdecken und miteinander zu kommunizieren. Die Ära des „Instant Web“ geht zu Ende. Das „Thoughtful Web“ beginnt. Wir müssen einfach damit aufhören, das Zeitlimit zu überschreiten.

Quellen (4)

• temporal.io Durable Execution
• platform.openai.com OpenAI: Optimizing Latency
• aws.amazon.com Asynchronous Patterns
• inngest.com Event-Driven Systems