Aquí va mi tesis, sin rodeos: la arquitectura de agentes que Anthropic acaba de publicar como un avance es la arquitectura que PHP nos ha impuesto desde el principio, y la mayoría estamos construyendo agentes que la tiran a la basura. En un post de ingeniería titulado "Scaling Managed Agents: Decoupling the brain from the hands", Lance Martin, Gabe Cemaj y Michael Cohen describen cómo despedazaron su agente de contenedor único en tres piezas independientes: el harness que itera sobre el modelo, el sandbox donde corre el código generado y la sesión como un log durable de solo escritura al final. El resultado: time-to-first-token p50 reducido en torno a un 60 por ciento, p95 en más de un 90 por ciento, y una clase entera de ataques de robo de credenciales vuelta estructuralmente imposible. Quítale el vocabulario de IA y tienes delante un proceso sin estado que reconstruye su mundo desde almacenamiento externo cada vez que despierta. Eso es una petición PHP. Lo llevamos haciendo desde mod_php.

El diseño original era lo que el folclore de infraestructura llama una mascota: un contenedor con el bucle del modelo, el sandbox de código y el log de eventos, todo acurrucado junto. Rápido de construir, miserable de mantener. Depurar implicaba entrar por shell a una máquina que también contenía datos de usuario, así que en la práctica nadie podía depurar nada. Llegar a la red privada de un cliente exigía peering de red o self-hosting, porque el harness asumía que todo vivía en la puerta de al lado. Y lo peor: el código que generaba el modelo corría en el mismo contenedor que las credenciales — una inyección de prompt no necesitaba un exploit, solo necesitaba pedirle al modelo que leyera sus propias variables de entorno. Si alguna vez has commiteado un archivo .env o has visto a un plugin de WordPress comprometido leer wp-config.php, sabes exactamente cómo termina esa historia.

El arreglo le sonará a déjà vu a cualquiera que haya escalado una aplicación PHP. El harness pasó a ser desechable: arranca con wake(sessionId), reproduce el log vía getSession, añade pasos nuevos con emitEvent y no guarda nada digno de llorar cuando se cae. Ese es todo el truco de PHP-FPM: el proceso no vale nada, el almacén de sesiones es sagrado. El sandbox solo se aprovisiona cuando una llamada a herramienta realmente lo necesita, que es exactamente por lo que los números de latencia se movieron con tanta violencia: en el diseño acoplado cada sesión pagaba el arranque del contenedor y el clonado del repo antes del primer token, incluso las sesiones que jamás ejecutaban una línea de código. El aprovisionamiento perezoso no es una idea novedosa. Es la razón por la que no abres una conexión a base de datos en el bootstrap de tu framework para una ruta que sirve una página cacheada.

El patrón de credenciales es la parte que me tatuaría en cada base de código de agentes, sea PHP o no. Anthropic usa dos movimientos: empaquetar la credencial dentro del recurso en el momento del setup — el token de Git se usa exactamente una vez para clonar y configurar el remote, y luego se descarta, de modo que push y pull funcionan sin que el agente lo tenga jamás — o aparcar los tokens en un vault detrás de un proxy. El modelo llama a una herramienta MCP con un token de sesión de corta vida; el proxy lo intercambia por la credencial OAuth real y hace la llamada saliente. El harness ni siquiera llega a conocer el secreto. Compara eso con la aplicación media en Laravel o Symfony que llama hoy a la API de OpenAI o de Anthropic: la clave vive en el mismo proceso que interpola input de usuario en los prompts. Si estás dejando que un LLM genere y ejecute código — y la mitad de los tutoriales de agentes dirigidos a equipos PHP hacen exactamente eso con shell_exec y una plegaria — el token no debería ser alcanzable desde ese runtime. Punto.

Ahora el contraargumento honesto, porque es potente: tres interfaces significan tres modos de fallo, saltos de red y fronteras de serialización donde un proceso único tenía llamadas a funciones. Anthropic opera una plataforma gestionada para miles de tenants; tú quizá tienes un solo agente que hace triaje de tickets de soporte para una empresa. Para eso, el script monolítico es genuinamente la decisión correcta hoy — un sistema distribuido que no necesitas es una mascota peor que la mascota. Te lo concedo sin pestañear. Pero aun así me quedo del lado desacoplado para cualquier cosa que pienses conservar, por una razón que el post clava: cada harness codifica suposiciones sobre lo que el modelo todavía no sabe hacer. Sonnet 4.5 cerraba tareas antes de tiempo cuando se le llenaba el contexto, así que añadieron reinicios de contexto; con Opus 4.5 el comportamiento desapareció y los reinicios se convirtieron en peso muerto. Tu workaround ingenioso tiene una vida media más corta que tus interfaces. Acoplarlo todo significa que la morralla acaba siendo estructural.

Hay además una idea más silenciosa en el post que merece más atención que la gráfica de latencia: la sesión no es la ventana de contexto. Todo arreglo estándar para el desbordamiento de contexto — resumir, recortar, compactar — destruye información antes de que sepas si vas a necesitarla. Anthropic, en cambio, mantiene el log de eventos completo fuera de la ventana y deja que el harness extraiga porciones posicionales, rebobine hasta el preludio de una decisión, remodele eventos para conseguir hits de la caché de prompts. El log solo promete durabilidad; toda la astucia vive en una capa que puedes reescribir. Eso es event sourcing, y el mundo PHP tiene herramientas maduras para ello: EventSauce, Prooph, Broadway. Si estás metiendo funcionalidad de agentes en una aplicación PHP, una tabla de eventos append-only que puedes reproducir le gana a un resumen acumulativo con pérdidas en casi todos los casos, y ya sabes operarla.

Esta filosofía se cuela incluso en su superficie de API. El 22 de julio de 2026, el endpoint de listado de memorias de Managed Agents empezó a ignorar los parámetros order_by y order y a devolver resultados en un orden estable definido por el servidor, invalidando los cursores de página antiguos para que reinicies desde la primera página. A primera vista, una nota al pie. En realidad es el mismo principio: una interfaz estrecha que la plataforma puede garantizar en toda implementación futura le gana a una configurable que no puede garantizar. Sé dogmático con las interfaces, humilde con las implementaciones — lo cual, por cierto, es también el mejor resumen en una línea de por qué las interfaces PSR envejecieron mejor que la mayoría de las bibliotecas concretas que las implementaron primero.

Así que aquí es donde quiero que me lleves la contraria. Mi afirmación es que la disciplina shared-nothing que PHP nos metió a martillazos — el proceso muere, el estado vive en otra parte, los secretos quedan fuera del runtime — es el mejor cimiento posible para la arquitectura de agentes, y que el daemon de agente stateful y de larga vida que enseñan la mayoría de los tutoriales es una regresión hacia la que caminamos con los ojos abiertos. Pero quizá estoy sobreajustando a la plataforma que amo. Si has llevado un agente a producción desde un stack PHP: ¿lo construiste como un bucle sin estado y reanudable sobre un log de eventos, o como un proceso bendito que ahora cuidas a las 2 de la madrugada — y sabiendo lo que cuesta, cuál construirías la próxima vez?