A BerriAI, o time por trás do gateway LiteLLM, open-sourceou a LiteLLM Agent Platform em 8 de maio — uma camada de infraestrutura auto-hospedada para rodar agentes em produção em Kubernetes. O stack: um dashboard Next.js para CRUD de agentes e session chat, um worker process para tarefas async, PostgreSQL para estado persistente de sessões, e um cluster Kubernetes sandbox onde cada agente roda num pod isolado via o CRD `kubernetes-sigs/agent-sandbox`. Licença MIT, alpha public preview, repo em github.com/BerriAI/litellm-agent-platform. A plataforma depende de um gateway LiteLLM rodando para roteamento a 100+ provedores LLM.
O detalhe arquitetural relevante é a primitiva do Kubernetes. `kubernetes-sigs/agent-sandbox` é um CRD vindo dos Kubernetes SIGs que padroniza "ambiente isolado para execução de agente" como tipo de recurso Kubernetes de primeira classe. Se esse CRD ganhar adoção, os sandboxes de agente se tornam tão portáveis quanto qualquer outro workload Kubernetes. A escolha da BerriAI de construir sobre esse CRD em vez de enviar sua própria primitiva de isolamento é uma aposta na direção do SIG. O writeup da Marktechpost não especifica se o sandbox subjacente usa gVisor, Firecracker, ou só isolamento por namespaces — isso depende da implementação do CRD, não da camada de plataforma. As variáveis de ambiente são injetadas via uma convenção de prefixo `CONTAINER_ENV_` (assim `CONTAINER_ENV_GITHUB_TOKEN=ghp_...` vira `GITHUB_TOKEN=ghp_...` dentro do sandbox), as sessões persistem em Postgres, e as migrações de schema rodam como init container na inicialização.
Coloque isto contra os Routines da Anthropic, anunciados no início desta semana: Routines roda no cloud da Anthropic, se atrela a eventos de repositório e triggers HTTP, e não tem preço publicado. LiteLLM Agent Platform é auto-hospedada no seu cluster Kubernetes, MIT-licenciada, e provider-agnóstica via o roteador de 100+ provedores do gateway LiteLLM. Mesmo problema — onde você roda agentes em produção — filosofia oposta. Para times com restrições regulatórias ou de data-locality (healthcare, finanças, residência EU), auto-hospedado mais multi-provedor é a única forma viável. Para times sem essas restrições, o "Anthropic opera" dos Routines é a forma low-ops. O split é mais amplo do que o marketing de cada lado sugere: LiteLLM Agent Platform não reivindica paridade com Routines em integração first-party de tooling Claude, e Routines não reivindica paridade com LiteLLM em neutralidade de provedor.
Segunda-feira: se você está escolhendo onde rodar agentes em produção neste trimestre, a matriz é cloud-operado single-provedor (Anthropic Routines, OpenAI Assistants, AWS Bedrock Agents) vs. auto-hospedado multi-provedor (LiteLLM Agent Platform, build-your-own em Modal ou E2B). LiteLLM Agent Platform está em alpha — não coloque workloads load-bearing em alpha — mas as escolhas arquiteturais (CRD Kubernetes SIG, estado Postgres, convenção de injeção de env vars) te dizem o que esperar quando chegar a beta. Se você já roda um gateway LiteLLM para roteamento de provedores, a Agent Platform é um deploy aditivo, não uma migração. Fique de olho em `kubernetes-sigs/agent-sandbox` para maturidade upstream — essa é a pergunta de lock-in, não o dashboard da BerriAI.