BerriAI, the team behind the LiteLLM gateway, open-sourced the LiteLLM Agent Platform on May 8 โ€” a self-hosted infrastructure layer for running production agents on Kubernetes. The stack: a Next.js dashboard for agent CRUD and session chat, a worker process for async tasks, PostgreSQL for persistent session state, and a Kubernetes sandbox cluster where each agent runs in an isolated pod via the `kubernetes-sigs/agent-sandbox` CRD. MIT-licensed, alpha public preview, repo at github.com/BerriAI/litellm-agent-platform. The platform depends on a running LiteLLM gateway for routing to 100+ LLM providers.

The relevant architectural detail is the Kubernetes primitive. `kubernetes-sigs/agent-sandbox` is a CRD coming out of the Kubernetes SIGs that standardizes "isolated environment for agent execution" as a first-class Kubernetes resource type. If that CRD gains adoption, agent sandboxes become as portable as any other Kubernetes workload. BerriAI's choice to build on that CRD rather than ship their own isolation primitive is a bet on the SIG's direction. The Marktechpost writeup doesn't specify whether the underlying sandbox uses gVisor, Firecracker, or just namespace isolation โ€” that depends on the CRD implementation, not the platform layer. Env vars are injected via a `CONTAINER_ENV_` prefix convention (so `CONTAINER_ENV_GITHUB_TOKEN=ghp_...` becomes `GITHUB_TOKEN=ghp_...` inside the sandbox), sessions persist in Postgres, and schema migrations run as an init container on startup.

Map this against Anthropic's Routines, announced earlier this week: Routines runs on Anthropic's cloud, ties to repository events and HTTP triggers, and has no published pricing. LiteLLM Agent Platform is self-hosted on your Kubernetes cluster, MIT-licensed, and provider-agnostic via the LiteLLM gateway's 100+ provider router. Same problem statement โ€” where do you run production agents โ€” opposite philosophy. For teams with regulatory or data-locality constraints (healthcare, finance, EU residency) self-hosted-plus-multi-provider is the only viable shape. For teams without those constraints, Routines' "Anthropic operates it" is the lower-ops shape. The split is wider than the marketing on either side suggests: LiteLLM Agent Platform doesn't claim parity with Routines on first-party Claude tooling integration, and Routines doesn't claim parity with LiteLLM on provider neutrality.

Monday: if you're choosing where to run agents in production this quarter, the matrix is cloud-operated single-provider (Anthropic Routines, OpenAI Assistants, AWS Bedrock Agents) vs. self-hosted multi-provider (LiteLLM Agent Platform, build-your-own on Modal or E2B). LiteLLM Agent Platform is alpha โ€” don't put load-bearing workloads on alpha โ€” but the architectural choices (Kubernetes SIG CRD, Postgres state, env-var injection convention) tell you what to expect when it hits beta. If you already run a LiteLLM gateway for provider routing, the Agent Platform is an additive deploy, not a migration. Watch `kubernetes-sigs/agent-sandbox` for upstream maturity โ€” that's the lock-in question, not BerriAI's own dashboard.