Kubernetes får eget kontrollplan for AI-agenter

Agentdrift flytter ned i infrastrukturen

Solo.io beskriver en ny byggestein for AI-agenter på Kubernetes: Agent Substrate brukt under kagent. Målet er å kjøre sandkassede agenter med rask oppstart, bedre ressursutnyttelse og tydeligere sikkerhetsgrenser. Det høres teknisk ut, men treffer et ganske praktisk problem: Kubernetes er god på tjenester. Den er ikke laget for millioner av små agentprosesser som starter, sovner, gjenopptas og kjører kode på vegne av brukere.

Det er nettopp den typen arbeid virksomheter nå prøver å sette i produksjon. En agent skal lese saker, hente dokumenter, kalle interne API-er, skrive kode eller bygge en rapport. Den kan være inaktiv lenge, og så plutselig trenge et isolert arbeidsmiljø i noen sekunder eller minutter. Hvis hver agent må bli en fullverdig pod med vanlig oppstart, volumhåndtering og livssyklus gjennom Kubernetes API-et, blir kontrollplanet raskt en flaskehals.

Solo.io skriver at Agent Substrate legger et supplerende kontrollag ved siden av Kubernetes. I stedet for en agent per pod, kan systemet planlegge, suspendere og gjenoppta agent-aktører inne i forhåndsprovisjonerte worker pods. Agentene kan skaleres til null, snapshots kan lagres, og miljøer kan vekkes igjen raskt. Solo oppgir rundt 50 millisekunder gjenopptak for sin Bubblewrap-baserte løsning og rundt 200 millisekunder med Firecracker microVM-er.

For ledere er poenget enkelt: agentplattformen begynner å ligne et eget driftssjikt. Den skal håndtere isolasjon, state, egress, observability og policy før agentene får gjøre arbeid i virksomhetens systemer. Det er et sunnere utgangspunkt enn å slippe en modell løs med brede tokens og håpe at prompten holder orden.

Kubernetes er ikke automatisk nok

Kubernetes har blitt standarden for mye moderne drift, men agentarbeid har en annen rytme enn vanlige mikrotjenester. Agentene kan være mange, korte, ujevne og stateful på en irriterende måte. De trenger ofte filsystem, nettverk, verktøy og en klar grense for hva kode de produserer kan gjøre.

Solo.io peker på fire problemer. Først: agent-per-pod-modeller sløser ressurser når agenter sitter inaktive. Deretter: Kubernetes API-serveren er ikke laget for et enormt antall hyppige opprettelser, oppdateringer og slettinger i hot path. Tredje punkt er oppstartstid. Pods bruker ofte sekunder på å bli klare, mens agenter trenger miljøer som kan våkne på millisekunder. Til slutt kommer state. Kubernetes er ikke designet for millioner av volum som kontinuerlig kobles til og fra for små agentøkter.

Agent Substrate svarer ved å behandle agenten mer som en aktør enn som en vanlig applikasjonspod. Worker pools står klare. Agenten kan settes inn i en worker når den skal jobbe, suspenderes når den er inaktiv, og gjenopptas med state fra lagring. Det er ikke nødvendigvis løsningen alle skal kjøpe, men mønsteret er viktig. AI-agenter trenger et kontrollplan som passer deres arbeidsform.

Sikkerhet handler om egress og sandkasse

Solo.io beskriver også en sikkerhetsmodell der agenttrafikk låses ned og går via agentgateway, et prosjekt for kontroll, sikkerhet og styring av LLM-, MCP- og agentkommunikasjon. De nevner Bubblewrap, Landlock, seccomp og Firecracker som tekniske byggesteiner for isolasjon. Dette er ikke pynt. Når agenten kan skrive eller kjøre kode, er sandkassen selve risikogrensen.

Mange virksomheter undervurderer akkurat dette. De vurderer modellen, men ikke kjøremiljøet. De spør om agenten svarer riktig, men ikke hvor verktøyene kjøres, hvordan nettverksegres styres, hvem som kan lese arbeidsfilene, og hva som skjer hvis agenten blir lurt av data den leser. I en produksjonssetting er det feil rekkefølge.

For CISO bør kravlisten være konkret. Agentplattformen må kunne forklare hvordan den isolerer hver kjøring, hvordan den begrenser nettverk, hvordan secrets holdes unna generert kode, hvordan sesjoner logges, og hvordan hendelser kan rekonstrueres etterpå. Hvis en agent kan åpne pull requests, kjøre CLI-er eller hente kundedata, må den behandles som en privilegert arbeidsflyt.

Evaluering blir del av samme kontrollplan

Samme uke publiserte AWS en gjennomgang av Agent-EvalKit, et open source-verktøy for systematisk evaluering av AI-agenter. AWS peker på et nærliggende problem: å sjekke sluttresultatet er ikke nok. En agent kan gi et pent svar og likevel ha hoppet over verifisering, brukt feil verktøy eller hallusinert over tomme tool-resultater. Derfor må evaluering fange hele kjørebanen: hvilke verktøy ble kalt, hvilke data kom tilbake, og om svaret faktisk bygger på dataene.

Sett sammen peker Solo.io og AWS på samme utvikling. Agentdrift trenger både runtime-kontroll og evalueringsspor. Runtime-laget bestemmer hvor agenten får jobbe. Evalueringslaget vurderer hvordan den jobbet. Begge deler må inn før agentene får produksjonsrettigheter.

Dette er en viktig dreining for norske virksomheter som nå tester agentverktøy i utvikling, saksbehandling, kundeservice og analyse. Det holder ikke å kjøpe et smart grensesnitt. Man må også kjøpe eller bygge kontrollplanet rundt det.

Hva CIO bør ta med til arkitekturmøtet

Det første spørsmålet er hvor agentene faktisk kjører. I leverandørens sky, i egen VPC, på eksisterende Kubernetes, eller i et blandet oppsett? Det andre spørsmålet er hvordan agentenes state håndteres. Kan en økt gjenopptas, slettes, eksporteres og revideres? Det tredje er hvordan nettverk og credentials begrenses. Agenten bør ikke ha bredere tilgang enn oppgaven krever, og tilgangen må være knyttet til bruker, rolle og formål.

Det fjerde spørsmålet er måling. Hvilke tester viser at agenten bruker riktige verktøy, stopper når datagrunnlaget er svakt, og etterlater et spor som kan ettergås? Her er poenget fra AWS nyttig: sluttresponsen er bare én del av kvaliteten. En pålitelig agent må vurderes på prosessen.

Markedet beveger seg raskt fra agentdemoer til agentinfrastruktur. Det er bra. Demoer skaper entusiasme. Infrastruktur avgjør om agentene kan brukes uten å øke risikoen mer enn nytten forsvarer.

Kilder og medier

Primærkilde: Solo.io, «Agent substrate can power agents on Kubernetes with kagent», https://www.solo.io/blog/agent-substrate-powers-kubernetes-agents-with-kagent

Supplerende kilde: AWS Machine Learning Blog, «Evaluate AI agents systematically with Agent-EvalKit», https://aws.amazon.com/blogs/machine-learning/evaluate-ai-agents-systematically-with-agent-evalkit/

Kildekreditering: Solo.io for beskrivelse av Agent Substrate, kagent, worker pools, sandboxing og oppgitte gjenopptakstider. AWS for evalueringsvinkel rundt agentspor, tool calls og systematisk testing.

Thumbnail: OpenAI Image 2 / hogby.ai