BerriAI, l'équipe derrière le gateway LiteLLM, a open-sourcé le LiteLLM Agent Platform le 8 mai — une couche d'infrastructure self-hosted pour rouler des agents en production sur Kubernetes. Le stack : un dashboard Next.js pour CRUD d'agents et session chat, un worker process pour les tâches async, PostgreSQL pour l'état persistant des sessions, et un cluster Kubernetes sandbox où chaque agent roule dans un pod isolé via le CRD `kubernetes-sigs/agent-sandbox`. License MIT, alpha public preview, repo à github.com/BerriAI/litellm-agent-platform. La plateforme dépend d'un gateway LiteLLM en marche pour le routing à 100+ fournisseurs LLM.
Le détail architectural pertinent, c'est la primitive Kubernetes. `kubernetes-sigs/agent-sandbox` est un CRD qui sort des Kubernetes SIGs qui standardise « environnement isolé pour exécution d'agent » comme un type de ressource Kubernetes first-class. Si ce CRD gagne en adoption, les sandboxes d'agent deviennent aussi portables que n'importe quel autre workload Kubernetes. Le choix de BerriAI de bâtir sur ce CRD plutôt que de shipper leur propre primitive d'isolation, c'est un bet sur la direction du SIG. Le writeup de Marktechpost spécifie pas si le sandbox sous-jacent utilise gVisor, Firecracker, ou juste de l'isolation par namespaces — ça dépend de l'implémentation du CRD, pas de la couche plateforme. Les variables d'env sont injectées via une convention de préfixe `CONTAINER_ENV_` (donc `CONTAINER_ENV_GITHUB_TOKEN=ghp_...` devient `GITHUB_TOKEN=ghp_...` dans le sandbox), les sessions persistent dans Postgres, et les migrations de schema roulent comme init container au démarrage.
Mets ça contre les Routines d'Anthropic, annoncées plus tôt cette semaine : Routines roule sur le cloud d'Anthropic, tie aux events de repository et triggers HTTP, et n'a pas de pricing publié. LiteLLM Agent Platform est self-hosted sur ton cluster Kubernetes, MIT-licensé, et provider-agnostique via le router de 100+ providers du gateway LiteLLM. Même problème statement — où tu roules tes agents en production — philosophie opposée. Pour les équipes avec des contraintes de régulation ou de data-locality (healthcare, finance, résidence EU), self-hosted plus multi-provider est la seule forme viable. Pour les équipes sans ces contraintes, le « Anthropic opère ça » de Routines est la forme low-ops. Le split est plus large que ce que le marketing de chaque bord suggère : LiteLLM Agent Platform claim pas la parité avec Routines sur l'intégration first-party de tooling Claude, et Routines claim pas la parité avec LiteLLM sur la neutralité de provider.
Lundi matin : si tu choisis où rouler tes agents en production ce trimestre, la matrice c'est cloud-operated single-provider (Anthropic Routines, OpenAI Assistants, AWS Bedrock Agents) vs. self-hosted multi-provider (LiteLLM Agent Platform, build-your-own sur Modal ou E2B). LiteLLM Agent Platform est en alpha — mets pas des workloads load-bearing sur de l'alpha — mais les choix d'architecture (CRD Kubernetes SIG, état Postgres, convention d'injection d'env vars) te disent à quoi t'attendre quand ça hit beta. Si tu roules déjà un gateway LiteLLM pour le routing de providers, l'Agent Platform c'est un déploiement additif, pas une migration. Watch `kubernetes-sigs/agent-sandbox` pour la maturité upstream — c'est ça la question de lock-in, pas le dashboard de BerriAI.