BerriAI har frigivet koden til LiteLLM Agent Platform. En Kubernetes-baseret base med isolerede sandboxes pr. team og pr. kontekst samt vedvarende sessionshistorik. For alle, der sidder fast i PoC-land, føles det som et skub i den rigtige retning.
Pointen er drift, ikke lokale scripts. Sessioner overlever pod-genstarter og deploys, så konteksten ikke tabes. De konkrete arkitekturdetaljer nedenfor er gengivet, hvor MarkTechPost beskriver dem — vi har markeret dem tydeligt og linker til kilderne.
Hvad LiteLLM Agent Platform er
Ifølge MarkTechPost er LiteLLM Agent Platform en self‑hosted infrastruktur til flere AI‑agenter i produktion, med to kerneprimitives: isolerede runtime‑miljøer som sandboxes på Kubernetes og persistent session management, så historik og mellemregninger bevares ved pod‑genstart eller opgradering (MarkTechPost). Koden ligger offentligt hos BerriAI (GitHub‑repo).
MarkTechPost beskriver også et selvstændigt Next.js‑dashboard (webproces på port 3000) til live‑status, agent‑CRUD og chat i sessioner. Kodebasen nævnes som primært TypeScript (92,8 procent), suppleret af shell‑scripts, en Dockerfile og CSS. Arkitekturen deler ansvar i en web‑proces og en worker‑proces. Postgres er persistent backing store, og schema‑migration kører som init‑container ved opstart. Disse tal og valg er gengivet fra MarkTechPost, ikke fra et gennemlæst repo‑manifest.
Sandboxlaget og lokal udvikling
Agent‑sandboxes kører på Kubernetes via kubernetes‑sigs agent‑sandbox CRD, som giver et deklarativt API til livscyklus for isolerede agentmiljøer (CRD‑repo). Til lokal udvikling peges der på kind (Kubernetes in Docker), så et lille cluster kan køre på en laptop uden cloud‑konto (kind‑docs).
Et praktisk greb, som MarkTechPost fremhæver: .env‑variabler med præfikset CONTAINER_ENV_ injiceres i sandbox‑containere med præfikset fjernet. Eksempel: CONTAINER_ENV_GITHUB_TOKEN bliver til GITHUB_TOKEN i containeren. Lille ting, mindre friktion i hverdagen.
Hvorfor der er et driftshul at lukke
Et Python‑script på en bærbar er ikke en produktionsagent. Agenter bærer tilstand: samtalehistorik, værktøjskald, halvfærdige ræsonnementer. Ryger tilstanden, ryger konteksten. I produktion skal agenten også køre med rigtige secrets, scopes og værktøjer, uden at alt ligger i én delt container.
LiteLLM sigter mod at bygge bro med isolerede sandboxes og en vedvarende sessionsmodel, der kan tåle driftsbegivenheder. Vi har selv set sessioner forsvinde ved første mandags‑deploy, når pods ruller. Man glemmer det aldrig, når det rammer en kundedemo fem minutter før frokost.
Teknik i praksis
MarkTechPost beskriver en opdeling i web og worker: en Next.js‑web på port 3000 og en separat worker til asynkrone agentopgaver. Det holder UI responsivt og tunge job væk fra interaktivitet. Persistens i Postgres, med migrations via init‑container ved opstart, så skemaet er klart før appen starter. Vi hæfter os ved, at disse detaljer er fra MarkTechPost, ikke et audit af repoet.
Sandboxlaget styres via agent‑sandbox CRD fra kubernetes‑sigs. MarkTechPost nævner også et harness‑system under harnesses\/opencode til kodningsagenter med en vault‑proxy til credentials samt et separat litellm‑agent‑runtime, beskrevet som en coding‑agent runtime, der kan køre i per‑session VM‑miljøer provisioneret af en LiteLLM‑proxy. .env‑prefix‑mønsteret betyder, at secrets kan føres ind i containere uden nye builds.
Hvad platformen løser, og hvad den ikke gør
LiteLLM leverer to solide byggeklodser: isolation via sandboxes og kontinuitet via persistent sessions. Mindre læk mellem teams, og mere robusthed ved pod‑genstarter. Dashboardet samler det, så drift ikke er en bunke scripts.
Men det er ikke en hel driftsplatform. Der følger ikke CI\/CD for modeller og agenter, ingen indbyggede rollout‑strategier og ingen færdig pakke for cost‑styring, governance, audit eller fuld observability. De lag skal I selv lægge ovenpå — og det kan man godt, hvis man planlægger det fra start.
Sikkerhed, governance og compliance
Self‑hosting forpligter. Kør en credential‑proxy eller vault‑proxy mellem agenter og tredjeparts‑APIs. Skær RBAC mellem teams, så secrets ikke kan vandre. Få audit trails for sessioner og værktøjskald på plads, så I kan svare, hvad der skete torsdag kl. 14.07.
Dataminimering er vigtig. Persistent sessions hjælper brugeroplevelsen, men presser compliance uden styring. Sæt TTL for sessioner, krypter i ro og i transit, og beslut bevidst, hvad der gemmes. Kilderne oplyser ikke anbefalede TTL‑intervaller — det må testes i pilot.
Et kort integrationsspor vi ville køre
Vi førte for nylig en finanskunde gennem en hybrid opsætning med stateless frontlinje og stateful session‑store. Det der gav ro, var en stram migrationsplan og to SLO’er: p95 session‑latency og recovery‑tid efter pod‑genstart. Én konkret måling pr. domæne, mindre støj i vagten.
Arkitektur i ord: en web‑pod på port 3000, en worker‑pod, Postgres som managed service eller cluster‑lokalt, agent‑sandbox CRD i et separat namespace, stramme netpolicies og en vault‑proxy sidecar til secrets. Vær forberedt på, at en init‑container kan hænge på en lås — det skal håndteres.
Driftens små kanter
Init‑container migrations kan blokere opstart ved låse og lange kørsler. Test lange migrationer og hav fallback. Delvise migrationer gør rollback dyrt. Vi har set låse overleve genstarter, fordi gamle statements hang — øv procedurerne på forhånd.
Per‑session VM‑lignende runtime koster. Sæt quotas tidligt, lav cost‑estimat pr. session, og overvåg samtidige sandboxes. Demoer med to brugere skjuler smertepunkter, indtil 200 logger på samtidig. Kilderne giver ikke priseksempler, så regn selv før pilot.
Begrænsninger og åbne spørgsmål
MarkTechPost beskriver CRD‑baseret sandboxing, men ikke isolationsgarantierne på lavt niveau. Bruges gVisor, kata eller containerd‑sandboxing? Hvilke netpolicies følger med som standard, hvis nogen? Materialet siger det ikke. Det hul bør lukkes, før regulerede brancher går i drift.
Der er heller ikke tal for skaleringsgrænser: hvor mange samtidige sandboxes pr. cluster, eller hvor meget overhead vedvarende sessions lægger på latency. Det er centralt for SLO’er, men ikke dokumenteret. Samme for backup\/restore‑mønstre i Postgres og håndtering af korruption efter opgraderinger. Planlæg konservativt og test.
Markedet bevæger sig
Agent‑drift vokser som kategori. VentureBeat beskriver, at Fin (tidligere Intercom) lancerede Operator — en agent, der administrerer en anden agent — som signal om agent‑for‑agent styring i praksis (VentureBeat).
I den kontekst giver LiteLLM Agent Platform mening som byggeblok. Ikke altomfattende, men præcist rettet mod to problemer, der ofte vælter driften: isolation og state.
Pilot playbook på 30 dage
Et kort, prioriteret forløb vi selv ville køre:
