Google åpner agent-tjenesten bak Gemini for kundene – foreløpig kun i preview uten dato
Google lanserte Agent Compute Engine 22. oktober 2026 på AGNTCon + MCPCon – en compute-tjeneste bygget spesielt for AI-agenter, som allerede driver Gemini, men som kundene må vente «i de kommende månedene» på å få prøve. Bak annonseringen ligger en teknisk innsikt: agentiske arbeidsmønster bryter de tradisjonelle primitivene skyen er bygget på. Artikkelen forklarer mekanismene – per-agent microVM-er, copy-on-write minnedeling og checkpoint/restore i agentens «tenkefase» – og skiller skarpt mellom det som er dokumentert arkitektur og det som er Googles egne, uavhengig uverifiserte ytelsestall.
Nyheten: en computedienst for agentflåter
Under konferansen AGNTCon + MCPCon 22. oktober 2026 lanserte Google Cloud Agent Compute Engine, beskrevet i selskapets eget blogginnlegg som en «purpose-built compute service» som allerede driver Gemini som agent for arbeidsoppgaver, og som skal være tilgjengelig i preview «i de kommende månedene» med «hardware-isolated runtime sandbox security» (Google Cloud-bloggen, kilde 54387a98).
Det er verdt å understreke hva slags nyhet dette er: En tjeneste som internt allerede bærer Geminis agentdrift åpnes altså for eksterne kunder, men uten dato, pris eller regioner. Lesere som vurderer tjenesten for egen drift bør derfor behandle dette som et annonseringsvindu, ikke et tilgjengelighetsnytt.
Samtidig med compute-tjenesten kunngjorde Google utvidede governance-kontroller for agenter, inkludert token tracking, model routing og støtte for tredjeparts identitetsleverandører som Ping Identity og SailPoint, med rekkevidde ut til Cloud Run, GKE og managed endpoints (The Decoder, kilde 2d829ed6). Google skriver også at selskapet utvider Gemini for business' agent governance-funksjoner «til å støtte agenter der de opererer» (kilde 54387a98).
Problemet: den agentiske loopen bryter VM-primitivene
Det interessante ved lanseringen er ikke lanseringen i seg selv, men begrunnelsen. I en teknisk «deep dive» skrevet av Googles distinguished engineers Ramanathan Venkatapathy og Rohit Jnagal forklarer selskapet hvorfor agentiske arbeidsmønster ikke passer inn i de eksisterende alternativene (Google Cloud-bloggen, kilde 558235af).
Det første alternativet, den klassiske virtuelle maskinen, er teknisk trygg, men for treg for bruksmønsteret. «Hver VM starter og konfigurerer en full maskin, så det å starte, suspendere og gjenoppta en tar sekunder til minutter», skriver de to ingenirene. En agent som utfører mange korte verktøykall med modell tenkning imellom – det Google kaller en loop med høy «churn» – vil da bruke mer tid på maskinvare-håndtering enn på selve arbeidet.
Det andre alternativet, containere, har rask start, men deler vertskjernen med andre containere. For kodeagenter og utviklerassistenter som kjører vilkårlig kode, shell-kommandoer og nettleserhandlinger, er den isolasjonen ikke tilstrekkelig der full isolasjon kreves. Hverken coding-agenter eller developer assistants kan dermed trygt bruke containermiljøer i slike scenario, ifølge deep dive-bloggen.
Arkitekturen: hjerne og hender, adskilt
Googles løsning bygger på et skille som gjenspeiler hvordan agent-rammeverk faktisk fungerer. «Begge team deler hver agent i to deler. Harnessen, eller 'hjernen', kaller modellen og bestemmer hva som skal gjøres neste. Sandboksen, eller 'hendene', kjører koden, shell-kommandoene og nettleseren som modellen ber om», skriver Venkatapathy og Jnagal (kilde 558235af).
Agent Compute Engine gir hver agent sin egen maskinvare-isolerte microVM – altså en lettvekts virtuell maskin med egen kjernerom-isolasjon, ikke en container – men med oppstartshastighet på container-nivå. Googles formulering er at tjenesten gir «hver AI-agent sin egen maskinvare-isolerte microVM med container-hastighet og null credentialer holdt inne i sandboksen» (kilde 558235af). Det siste punktet er sikkerhetsmessig sentralt: selv om en agent kompromitteres fra innsiden, skal den ikke ha tilgang til credentialer i sitt eget miljø. Googles deep dive indikerer også at dette bygger videre på selskapets Titanium-silisium/IPU-fundament, selv om detaljene i den leverte dokumentasjonen er begrensede.
To mekanismer gjør det hele rimelig i stor skala. Den første er minnedeling: ifølge lanseringsbloggen bruker Agent Compute Engine «copy-on-write memory sharing til å kjøre flere agenter på ett enkelt operativsystem-mal» – altså deler mange microVM-er det samme grunnminnet, og skriver bare sine egne endringer til separat minne (kilde 54387a98). Det andre er checkpointing: «Når en agent er ferdig med et verktøykall og går inn i 'tenkefasen' av den agentiske loopen, signaliserer microVM-en at den er inaktiv, og hosten flytter den fra en aktiv til en inaktiv tilstand», heter det i samme kilde. I praksis betyr det at mens modellen tenker, fryses agentens maskin ned via rask checkpoint og kan gjenopprettes øyeblikkelig når den skal handle igjen.
Det er et elegant grep: Den mest karakteristiske egenskapen ved agentiske arbeidsmønster – lange pauser med tenking mellom korte utbrudd av handling – brukes som signal for når maskinvare kan frigjøres.
Skala og governance: Agent Substrate og kontrollene rundt
Under panseret ligger ifølge The Decoder «Agent Substrate», en Kubernetes-runtime som Google har åpnet kildekoden til. De ytelsestallene som siteres, er tydeligvis Googles egne: Selskapet sier at løsningen kan romme «ti ganger så mange agenter på en enkelt server», og at suspend og resume tok «under 500 millisekunder» i en test med 200 000 agenter, ifølge The Decoders dekning av Googles påstander (kilde 2d829ed6). Ingen av disse tallene er uavhengig verifisert.
På styringssiden utvider Google som nevnt token-sporing, model routing og støtte for identitetsleverandører som Ping Identity og SailPoint, med virkning for Cloud Run, GKE og managed endpoints (kilde 2d829ed6). Kombinasjonen er meningsfull: Hvis agentflåter skal operere med egne maskiner og uten credentialer i sandboksen, trenger organisasjonene på utsiden verktøy for å se hva agentene faktisk forbruker (tokens), hvor de rutes (hvilke modeller), og hvem som står bak identiteten deres.
Hva vi ikke vet
Det finnes betydelige hull. For det første: Ytelsestallene – 10x-tetthet og sub-500 ms suspend/resume – er utelukkende Googles egne, gjengitt gjennom The Decoder som siterer «Source: Google». Det finnes ingen uavhengig benchmarking i det dokumentasjonsgrunnlaget som foreligger, og de to Google-bloggene kan ikke regnes som uavhengig bekreftelse av hverandre; begge er selskapets egen stemme.
For det andre: At Agent Substrate omtales som åpen kildekode, er basert på The Decoders formulering. Det foreligger ingen førstehånds Google-dokumentasjon av selve utgivelsen i det leverte materialet – ingen opplysninger om repository, lisens eller hvilken kode som faktisk er tilgjengelig. For organisasjoner som vurderer å bygge på runtime-en, er dette en konkret og oppfølgbar mangel.
For det tredje: Preview-vinduet er udefinert. «I de kommende månedene» uten datoer, prising eller regioner betyr at enhver planlegging nå bygger på annonsering, ikke på tilgjengelig produkt.
Hva som gjenstår, er et klart arkitekturforslag: skill agentens hjerne fra hendene, gi hendene egne maskinvare-isolerte microVM-er, utnyttenkefasen som checkpoint-pause, og hold credentialene borte fra sandboksen. Om dette holder seg like overbevisende i praksis, får vi først vite når preview-vinduet åpner og noen utenfor Google har målt tallene selv.