BerriAI, el equipo detrás del gateway LiteLLM, open-sourceó la LiteLLM Agent Platform el 8 de mayo — una capa de infraestructura auto-alojada para correr agentes en producción sobre Kubernetes. El stack: un dashboard Next.js para CRUD de agentes y session chat, un worker process para tareas async, PostgreSQL para estado persistente de sesiones, y un cluster Kubernetes sandbox donde cada agente corre en un pod aislado vía el CRD `kubernetes-sigs/agent-sandbox`. Licencia MIT, alpha public preview, repo en github.com/BerriAI/litellm-agent-platform. La plataforma depende de un gateway LiteLLM corriendo para enrutar a 100+ proveedores LLM.
El detalle arquitectónico relevante es la primitiva de Kubernetes. `kubernetes-sigs/agent-sandbox` es un CRD que sale de los Kubernetes SIGs que estandariza "entorno aislado para ejecución de agente" como tipo de recurso Kubernetes de primera clase. Si ese CRD gana adopción, los sandboxes de agente se vuelven tan portátiles como cualquier otro workload Kubernetes. La elección de BerriAI de construir sobre ese CRD en vez de enviar su propia primitiva de aislamiento es una apuesta en la dirección del SIG. El writeup de Marktechpost no especifica si el sandbox subyacente usa gVisor, Firecracker, o solo aislamiento por namespaces — eso depende de la implementación del CRD, no de la capa de plataforma. Las variables de entorno se inyectan vía una convención de prefijo `CONTAINER_ENV_` (así `CONTAINER_ENV_GITHUB_TOKEN=ghp_...` se vuelve `GITHUB_TOKEN=ghp_...` dentro del sandbox), las sesiones persisten en Postgres, y las migraciones de esquema corren como init container al arranque.
Pon esto contra los Routines de Anthropic, anunciados a principios de esta semana: Routines corre en el cloud de Anthropic, se ata a eventos de repositorio y triggers HTTP, y no tiene precio publicado. LiteLLM Agent Platform es auto-alojado en tu cluster Kubernetes, MIT-licenciado, y provider-agnóstico vía el router de 100+ proveedores del gateway LiteLLM. Mismo problema — dónde corres agentes en producción — filosofía opuesta. Para equipos con restricciones de regulación o data-locality (healthcare, finanzas, residencia EU), auto-alojado más multi-proveedor es la única forma viable. Para equipos sin esas restricciones, el "Anthropic lo opera" de Routines es la forma low-ops. El split es más amplio de lo que el marketing de cada lado sugiere: LiteLLM Agent Platform no reclama paridad con Routines en integración first-party de tooling Claude, y Routines no reclama paridad con LiteLLM en neutralidad de proveedor.
Lunes: si estás eligiendo dónde correr agentes en producción este trimestre, la matriz es cloud-operado single-proveedor (Anthropic Routines, OpenAI Assistants, AWS Bedrock Agents) vs. auto-alojado multi-proveedor (LiteLLM Agent Platform, build-your-own en Modal o E2B). LiteLLM Agent Platform es alpha — no pongas workloads load-bearing en alpha — pero las elecciones arquitectónicas (CRD Kubernetes SIG, estado Postgres, convención de inyección de env vars) te dicen qué esperar cuando llegue a beta. Si ya corres un gateway LiteLLM para enrutamiento de proveedores, la Agent Platform es un despliegue aditivo, no una migración. Vigila `kubernetes-sigs/agent-sandbox` para madurez upstream — esa es la pregunta de lock-in, no el dashboard de BerriAI.