Here's my thesis, stated up front: the agent architecture Anthropic just published as a breakthrough is the architecture PHP has forced on us since the beginning, and most of us are building agents that throw it away. In an engineering post called "Scaling Managed Agents: Decoupling the brain from the hands," Lance Martin, Gabe Cemaj, and Michael Cohen describe tearing their single-container agent into three independent pieces — the harness that loops over the model, the sandbox where generated code runs, and the session as a durable append-only log. The result: p50 time-to-first-token down roughly 60 percent, p95 down over 90 percent, and an entire class of credential-theft attacks made structurally impossible. Strip the AI vocabulary and you're looking at a stateless process that reconstructs its world from external storage on every wake-up. That's a PHP request. We've been doing this since mod_php.

The original design was what infrastructure folklore calls a pet: one container holding the model loop, the code sandbox, and the event log, all cuddled together. Fast to build, miserable to own. Debugging meant shelling into a box that also held user data, so in practice nobody could debug at all. Reaching a customer's private network meant network peering or self-hosting, because the harness assumed everything lived next door. And worst of all, code the model generated ran in the same container as the credentials — a prompt injection didn't need an exploit, it just needed to ask the model to read its own environment variables. If you've ever committed a .env file or watched a compromised WordPress plugin read wp-config.php, you know exactly how that story ends.

The fix will feel like déjà vu to anyone who has scaled a PHP application. The harness became disposable: it boots with wake(sessionId), replays the log via getSession, appends new steps with emitEvent, and holds nothing worth mourning when it crashes. That's PHP-FPM's whole deal — the process is worthless, the session store is sacred. The sandbox is only provisioned when a tool call actually needs one, which is precisely why the latency numbers moved so violently: in the coupled design every session paid for container boot and repo cloning before the first token, even sessions that never ran a line of code. Lazy provisioning is not a novel idea. It's the reason you don't open a database connection in your framework's bootstrap for a route that serves a cached page.

The credential pattern is the part I'd tattoo on every agent codebase, PHP or otherwise. Anthropic uses two moves: bundle the credential into the resource at setup time — the Git token is used exactly once to clone and wire up the remote, then discarded, so push and pull work without the agent ever holding it — or park tokens in a vault behind a proxy. The model calls an MCP tool with a short-lived session token; the proxy swaps it for the real OAuth credential and makes the outbound call. The harness never even learns the secret. Compare that to the average Laravel or Symfony app calling the OpenAI or Anthropic API today: the key sits in the same process that interpolates user input into prompts. If you're letting an LLM generate and execute code — and half the agent tutorials aimed at PHP shops do exactly this with shell_exec and a prayer — the token should not be reachable from that runtime. Full stop.

Now the honest counter-argument, because it's a strong one: three interfaces means three failure modes, network hops, and serialization boundaries where a single process had function calls. Anthropic runs a managed platform for thousands of tenants; you might be running one agent that triages support tickets for one company. For that, the monolithic script genuinely is the right call today — a distributed system you don't need is a worse pet than the pet. I'll concede that without blinking. But I still land on the decoupled side for anything you intend to keep, for one reason the post nails: every harness encodes assumptions about what the model can't do yet. Sonnet 4.5 would wrap up tasks early as its context filled, so they added context resets; on Opus 4.5 the behavior vanished and the resets became dead weight. Your clever workaround has a shorter half-life than your interfaces. Coupling everything means the cruft is load-bearing.

There's also a quieter idea in the post that deserves more attention than the latency graph: the session is not the context window. Every standard fix for context overflow — summarization, trimming, compaction — destroys information before you know whether you'll need it. Anthropic instead keeps the full event log outside the window and lets the harness pull positional slices, rewind to the lead-up of a decision, reshape events for prompt-cache hits. The log promises only durability; all the cleverness lives in a layer you can rewrite. That's event sourcing, and the PHP world has mature tooling for it — EventSauce, Prooph, Broadway. If you're building agent features into a PHP application, an append-only events table you can replay beats a lossy running summary in almost every case, and you already know how to operate one.

This philosophy even leaks into their API surface. On July 22, 2026, the Managed Agents memory-listing endpoint started ignoring the order_by and order parameters and returning results in a stable, server-defined order, with old page cursors invalidated so you restart from the first page. On its face, a footnote. Actually it's the same principle: a narrow interface the platform can guarantee across every future implementation beats a configurable one it can't. Be opinionated about interfaces, humble about implementations — which, incidentally, is also the best one-line summary of why PSR interfaces aged better than most of the concrete libraries that first implemented them.

So here's where I want your pushback. My claim is that the shared-nothing discipline PHP drilled into us — process dies, state lives elsewhere, secrets stay out of the runtime — is the single best foundation for agent architecture, and that the long-running stateful agent daemon most tutorials teach is a regression we're walking into with open eyes. But maybe I'm overfitting to the platform I love. If you've shipped an agent to production from a PHP stack: did you build it as a resumable, stateless loop over an event log, or as one blessed process you now nurse at 2 a.m. — and knowing what it costs, which would you build next time?