Två nya byggblock ska göra AI-agenter mer uthålliga och enklare att drifta

Google Cloud satsar på två delar av samma problem: AI-agenter behöver en stabil och prisvärd körmiljö, och databaserna bakom dem måste kunna sättas upp, övervakas och felsökas utan lika mycket manuellt arbete.

I augusti presenterade företaget därför Database Operations Agents för databasdrift och Cloud Run instances för långlivade, ofta personliga, AI-agenter. Tillsammans breddar de Googles strategi för en så kallad Agentic Data Cloud från själva datahanteringen till infrastrukturen runt agenterna. 78

Database Operations Agents: från provisionering till felsökning

Den Gemini Cloud Assist-integrerade lösningen består av två agenter med olika roller:

• Database Onboarding Agent hanterar det som Google beskriver som Day 0: val av databas, provisionering, konfiguration och den första driftsättningen.
• Database Observability Agent fokuserar på Day 1 och Day 2: övervakning, felsökning och löpande underhåll. 8

Tanken är att ersätta delar av det återkommande arbetet med arkitekturplanering, skript, provisionering, schema- och indexkonfiguration, frågeoptimering och diagnostik med guidning på naturligt språk. Det kan minska den manuella belastningen för bland annat databasadministratörer, utvecklare, SRE- och DevOps-team. 8

Onboarding Agent kan guida användaren genom provisionering och grundläggande konfiguration av Googles hanterade databaser AlloyDB, Bigtable, Cloud SQL och Spanner. 8

Observability Agent sammanför i sin tur telemetri från Database Insights, Cloud Monitoring, Cloud Logging, Cloud Trace och relaterade källor. Målet är att hitta bakomliggande orsaker till problem som plötsliga latensökningar, långsamma eller överbelastade frågor, låskonflikter och otillräckliga resurser. 8

Inte bara analys – även föreslagna åtgärder

Funktionerna ska kunna nås via Gemini Cloud Assist, relevanta databassidor i Google Cloud Console, Database Centers vyer över databasflottan, kommandoraden, IDE:er och verktyg från tredje part. Database Insights och Database Center kan dessutom användas som MCP-verktyg via Googles Remote MCP-servrar. Då kan externa utvecklingsverktyg och AI-agenter hämta exempelvis mätvärden för system och frågor, information om databasflottan och upptäckta problem. 8

Observability Agent stannar inte vid att beskriva problemet. Den kan föreslå validerade ändringar, förklara varför de behövs och ange förväntad effekt. Efter användarens godkännande kan den även genomföra vissa åtgärder, som att aktivera anslutningspoolning i Cloud SQL eller lägga till ett index. Vissa funktioner för utredning och åtgärd var fortfarande i förhandsversion för utvalda kunder. 8

Cloud Run instances ger agenter en mer permanent körmiljö

Den 27 augusti presenterade Google Cloud Run instances i förhandsversion. Det är dedikerade, singulära körmiljöer i Cloud Run, avsedda för långlivade och tillståndsberoende arbetslaster – exempelvis en personlig AI-agent som ska vara tillgänglig över tid. 9

Till skillnad från vanliga Cloud Run-tjänster kör en Cloud Run instance exakt en kopia. Den autoskalar inte och skalas inte ned till noll. Instansen kan köras kontinuerligt i upp till sju dagar, har en automatisk omstartspolicy och kan stoppas när den inte används för att sedan återupptas. Varje instans får också en stabil HTTPS-adress som inte ändras vid uppdateringar eller omstarter. 9

Google positionerar modellen som ett alternativ till en virtuell maskin som måste vara igång hela tiden. Användaren slipper då bland annat underhåll av operativsystemet samt separat arbete med brandvägg och HTTPS-endpoint, men får ändå en mer permanent processmodell än i traditionella serverlösa tjänster som skalar till noll. 9

Priset som Google anger för kontinuerlig drift i 30 dagar med en delad vCPU och 1 GiB minne är 5,70 dollar. Tanken är att använda burst-budgetar för tillfälliga belastningstoppar i stället för att dimensionera och betala för en större virtuell maskin hela tiden. 9

En mer permanent instans kan också minska problemen med kallstarter. En tidig användare uppgav att kallstarter för dennes långkörande agent minskade med 88 procent, men det är ett kundexempel och ingen generell prestandagaranti. 9

Vad betyder det för agentarkitekturer?

Google försöker alltså täcka både körlagret och datalagret. Cloud Run instances är tänkta för agenter som behöver hantera asynkront arbete och interaktioner över flera turer, medan Database Operations Agents gör det enklare att administrera databaser med naturligt språk och MCP-kompatibla verktyg. 18

En viktig begränsning kvarstår: att en process är ”stateful” betyder inte automatiskt att agentens tillstånd överlever en omstart eller att pågående arbete sparas för alltid. För produktionsagenter behövs därför fortfarande beständig extern lagring, exempelvis sessionslagring i Cloud SQL. 5