Meine These, gleich vorweg: Die Agent-Architektur, die Anthropic gerade als Durchbruch veröffentlicht hat, ist genau die Architektur, die PHP uns von Anfang an aufgezwungen hat — und die meisten von uns bauen Agents, die sie über Bord werfen. In einem Engineering-Post mit dem Titel "Scaling Managed Agents: Decoupling the brain from the hands" beschreiben Lance Martin, Gabe Cemaj und Michael Cohen, wie sie ihren Single-Container-Agent in drei unabhängige Teile zerlegt haben: den Harness, der über das Modell loopt, die Sandbox, in der generierter Code läuft, und die Session als dauerhaftes Append-only-Log. Das Ergebnis: p50-Time-to-First-Token rund 60 Prozent runter, p95 über 90 Prozent runter, und eine ganze Klasse von Credential-Diebstahl-Angriffen strukturell unmöglich gemacht. Zieh das KI-Vokabular ab, und du siehst einen zustandslosen Prozess, der seine Welt bei jedem Aufwachen aus externem Storage rekonstruiert. Das ist ein PHP-Request. Das machen wir seit mod_php.

Das ursprüngliche Design war das, was die Infrastruktur-Folklore ein Pet nennt: ein Container mit Model-Loop, Code-Sandbox und Event-Log, alles gemütlich beieinander. Schnell gebaut, elend zu betreiben. Debugging hieß, sich per Shell auf eine Box zu verbinden, auf der auch Nutzerdaten lagen — in der Praxis konnte also niemand debuggen. Das private Netzwerk eines Kunden zu erreichen bedeutete Network Peering oder Self-Hosting, weil der Harness davon ausging, dass alles nebenan wohnt. Und am schlimmsten: Vom Modell generierter Code lief im selben Container wie die Credentials — eine Prompt Injection brauchte keinen Exploit, sie musste das Modell nur bitten, seine eigenen Environment-Variablen zu lesen. Wenn du jemals eine .env-Datei committet oder zugesehen hast, wie ein kompromittiertes WordPress-Plugin die wp-config.php ausliest, weißt du genau, wie diese Geschichte endet.

Der Fix fühlt sich für jeden, der schon mal eine PHP-Anwendung skaliert hat, wie ein Déjà-vu an. Der Harness wurde wegwerfbar: Er startet mit wake(sessionId), spielt das Log via getSession ab, hängt neue Schritte mit emitEvent an und hält nichts, dem man beim Crash nachtrauern müsste. Das ist exakt das Prinzip von PHP-FPM — der Prozess ist wertlos, der Session-Store ist heilig. Die Sandbox wird erst provisioniert, wenn ein Tool-Call sie tatsächlich braucht, und genau deshalb haben sich die Latenzzahlen so drastisch bewegt: Im gekoppelten Design zahlte jede Session vor dem ersten Token für Container-Boot und Repo-Klonen — auch Sessions, die nie eine Zeile Code ausgeführt haben. Lazy Provisioning ist keine neue Idee. Es ist der Grund, warum du im Bootstrap deines Frameworks keine Datenbankverbindung öffnest für eine Route, die eine gecachte Seite ausliefert.

Das Credential-Muster ist der Teil, den ich mir auf jede Agent-Codebasis tätowieren würde, PHP hin oder her. Anthropic nutzt zwei Kniffe: Entweder wird das Credential beim Setup in die Ressource eingebacken — der Git-Token wird genau einmal benutzt, um zu klonen und das Remote zu verdrahten, dann verworfen, sodass Push und Pull funktionieren, ohne dass der Agent ihn je hält — oder Tokens landen in einem Vault hinter einem Proxy. Das Modell ruft ein MCP-Tool mit einem kurzlebigen Session-Token auf; der Proxy tauscht ihn gegen das echte OAuth-Credential und macht den ausgehenden Call. Der Harness erfährt das Secret nicht einmal. Vergleich das mit der durchschnittlichen Laravel- oder Symfony-App, die heute die OpenAI- oder Anthropic-API aufruft: Der Key sitzt im selben Prozess, der Nutzereingaben in Prompts interpoliert. Wenn du ein LLM Code generieren und ausführen lässt — und die Hälfte der Agent-Tutorials für PHP-Shops macht genau das, mit shell_exec und einem Stoßgebet — dann darf der Token aus dieser Runtime nicht erreichbar sein. Punkt.

Jetzt das ehrliche Gegenargument, denn es ist ein starkes: Drei Interfaces bedeuten drei Fehlermodi, Netzwerk-Hops und Serialisierungsgrenzen, wo ein einzelner Prozess Funktionsaufrufe hatte. Anthropic betreibt eine Managed-Plattform für Tausende Tenants; du betreibst vielleicht einen einzigen Agent, der Support-Tickets für eine Firma triagiert. Dafür ist das monolithische Skript heute tatsächlich die richtige Wahl — ein verteiltes System, das du nicht brauchst, ist ein schlimmeres Pet als das Pet. Das räume ich ohne Zögern ein. Trotzdem lande ich bei allem, was du behalten willst, auf der entkoppelten Seite, aus einem Grund, den der Post auf den Punkt bringt: Jeder Harness kodiert Annahmen darüber, was das Modell noch nicht kann. Sonnet 4.5 hat Aufgaben vorzeitig abgeschlossen, wenn sich der Kontext füllte, also haben sie Context-Resets eingebaut; bei Opus 4.5 verschwand das Verhalten und die Resets wurden zu totem Gewicht. Dein cleverer Workaround hat eine kürzere Halbwertszeit als deine Interfaces. Alles zu koppeln heißt, dass der Kruft tragend wird.

Es steckt auch eine leisere Idee in dem Post, die mehr Aufmerksamkeit verdient als der Latenz-Graph: Die Session ist nicht das Context Window. Jeder Standard-Fix für Kontext-Overflow — Summarization, Trimming, Compaction — zerstört Information, bevor du weißt, ob du sie noch brauchst. Anthropic hält stattdessen das vollständige Event-Log außerhalb des Windows und lässt den Harness positionale Slices ziehen, zur Vorgeschichte einer Entscheidung zurückspulen, Events für Prompt-Cache-Hits umformen. Das Log verspricht nur Dauerhaftigkeit; die ganze Cleverness lebt in einer Schicht, die du neu schreiben kannst. Das ist Event Sourcing, und die PHP-Welt hat dafür ausgereiftes Tooling — EventSauce, Prooph, Broadway. Wenn du Agent-Features in eine PHP-Anwendung baust, schlägt eine Append-only-Events-Tabelle, die du replayen kannst, in fast jedem Fall eine verlustbehaftete laufende Zusammenfassung — und du weißt schon, wie man so etwas betreibt.

Diese Philosophie sickert sogar in ihre API-Oberfläche durch. Am 22. Juli 2026 begann der Memory-Listing-Endpoint der Managed Agents, die Parameter order_by und order zu ignorieren und Ergebnisse in einer stabilen, serverseitig definierten Reihenfolge zurückzugeben, wobei alte Page-Cursor invalidiert wurden, sodass du wieder auf der ersten Seite anfängst. Auf den ersten Blick eine Fußnote. Tatsächlich ist es dasselbe Prinzip: Ein schmales Interface, das die Plattform über jede zukünftige Implementierung hinweg garantieren kann, schlägt ein konfigurierbares, das sie nicht garantieren kann. Sei meinungsstark bei Interfaces, demütig bei Implementierungen — was nebenbei auch die beste Einzeiler-Erklärung dafür ist, warum PSR-Interfaces besser gealtert sind als die meisten konkreten Libraries, die sie zuerst implementiert haben.

Und hier will ich deinen Widerspruch. Meine Behauptung: Die Shared-Nothing-Disziplin, die PHP uns eingebläut hat — Prozess stirbt, State lebt woanders, Secrets bleiben aus der Runtime raus — ist das mit Abstand beste Fundament für Agent-Architektur, und der langlebige, zustandsbehaftete Agent-Daemon, den die meisten Tutorials lehren, ist ein Rückschritt, in den wir mit offenen Augen hineinlaufen. Aber vielleicht overfitte ich auf die Plattform, die ich liebe. Falls du aus einem PHP-Stack heraus einen Agent in Produktion gebracht hast: Hast du ihn als wiederaufnehmbaren, zustandslosen Loop über ein Event-Log gebaut oder als einen gesegneten Prozess, den du jetzt um 2 Uhr nachts päppelst — und, wo du weißt, was es kostet: Welchen würdest du beim nächsten Mal bauen?