Et nyt tutorialforløb, omtalt af MarkTechPost, beskriver Googles marts 2026-opdateringer til Gemini API. Ifølge gennemgangen kan udviklere kombinere indbyggede værktøjer som Google Search og Google Maps med egne funktioner i samme API-kald. For virksomheder, der vil bygge AI, som faktisk gør noget, er det en praktisk ændring i måden flows kan bygges på.
Vi skal lige have kildegrundlaget på plads. Historien bygger på et tutorial gengivet af MarkTechPost, ikke på en selvstændig Google-meddelelse, vi gennemgår direkte her. Det gør ikke oplysningerne uinteressante. Det betyder bare, at vi holder os stramt til det, tutorialen faktisk viser.
Det, der faktisk flytter noget
Ifølge MarkTechPost handler opdateringen ikke bare om, at flere værktøjer kan bruges samtidig. Tutorialen beskriver også det, de kalder context circulation, altså at tool calls og tool responses bliver bevaret på tværs af flere trin, så modellen kan arbejde videre med tidligere output. Navnet er lidt tungt, ja, men selve mekanikken er ret jordnær.
Der er også den detalje, som mange udenfor udvikling hurtigt springer over. Hvert værktøjssvar kan ifølge tutorialen få sit eget unikke ID, så parallelle funktionskald bliver matchet med de rigtige resultater. Det er ikke flashy. Til gengæld er det præcis sådan noget, der afgør, om et flow holder sammen, når mere end én datakilde er i spil.
MarkTechPost skriver, at tutorialen består af fem praktiske demoer, som bygger oven på hinanden fra den grundlæggende værktøjskombination til et fuldt multi-tool-forløb. Det siger egentlig en del om, hvor tyngden ligger. Ikke i modelnavnet. I arbejdsgangen rundt om modellen.
Et eksempel, der er mere nyttigt end smart
En af demoerne kombinerer Google Search med en custom getWeather-funktion i én request. Ifølge kilden bruger Gemini websøgning til at hente geografiske oplysninger i realtid og beder samtidig den brugerdefinerede funktion om vejrinformation. Bagefter returneres det simulerede vejrsvar med det matchende funktions-ID, og modellen samler begge datakilder til ét svar.
Det er en enkel demo, men arbejdsgangen er interessant. Modellen søger, kalder en funktion og bruger begge svar i sin formulering bagefter. Det er en anden disciplin end bare at skrive en god prompt og håbe på det bedste.
Og det er også dér mange virksomheder støder ind i virkeligheden. Problemet er sjældent kun at få et pænt svar. Problemet er at få flere kilder til at spille sammen uden rod i mellemtrinnene.
Når to funktioner kører samtidig
En anden demo i tutorialen bruger to custom functions, lookupInventory og getShippingEstimate. Prompten er ifølge MarkTechPost sat op, så Gemini udløser begge funktioner i samme tur. Hver funktion får sit eget unikke ID, og de simulerede svar bygges derefter op, så de passer til de rigtige kald, før hele historikken sendes tilbage til modellen.
Først derefter kommer slutsvaret, hvor begge resultater bliver samlet. Beskrivelsen er enkel, næsten tør. Men det er faktisk præcis den type styring, der ofte vælter i praksis, når flere systemer skal koordineres samtidig.
Vi har hos Snilld set det samme mønster i tool-flows generelt. Selve modellen klarer sig ofte fint. Det er rundt om modellen, det begynder at knirke lidt: forkert svar koblet til forkert kald, dobbeltkald, eller et output der ser overbevisende ud, selv om logikken under motorhjelmen er skæv. Derfor er ID-styring ikke en lille teknikalitet. Det er oprydning.
Maps som datakilde, ikke pynt
Tutorialen skifter ifølge kilden til gemini-2.5-flash i den del, der handler om grounding med Google Maps. Her viser forløbet lokationsbevidste svar, blandt andet med forespørgsler om nærliggende italienske restauranter, spørgsmål om et specifikt kryds og en dagsplan for San Francisco. MarkTechPost skriver også, at grounding-metadata kan bruges til at vise kildehenvisninger med URI og titel.
Det gør Maps-delen mere brugbar end mange af de sædvanlige lokalitetsdemoer. Når lokationssvar kan følges af kilder, bliver outputtet lettere at kontrollere. Ikke perfekt, ikke magisk. Bare lettere at arbejde med.
Og nej, vi skal heller ikke gøre den del større, end kilden kan bære. Tutorialen dokumenterer lokationsbevidste svar og kildevisning. Det er det sikre grundlag her.
Modelvalg og billing med lidt is i maven
MarkTechPost angiver, at tutorialen bruger gemini-3-flash-preview til kombinationen af værktøjer og gemini-2.5-flash til Google Maps-grounding. Det er en nyttig teknisk detalje, fordi den viser, hvordan eksemplerne faktisk er sat op.
Kilden skriver også, at alt i forløbet kan køre uden billing setup. Den oplysning skal læses som en tutorialoplysning, ikke som en bred garanti for alle Gemini-opsætninger eller fremtidige brugsmønstre. Det er et af de steder, hvor det er sundt at holde begejstringen en smule nede.
Hvor værdien ligger for virksomheder
For Snillds læsere ligger nyheden ikke i endnu et modelnavn. Den ligger i, at webdata, lokationsdata og egne funktioner kan indgå i samme arbejdsgang, mens konteksten bliver bevaret fra trin til trin. Det åbner for små agentforløb, hvor AI kan kobles til interne systemer, lagerdata, booking eller supportværktøjer uden at hvert trin skal håndsys forfra.
Det her er ikke specielt glamourøst. Men det er tit den usexede del, der afgør, om en løsning sparer tid eller bare flytter besværet et andet sted hen. Vi har selv siddet med tool calling-forløb, hvor modellen gjorde sit arbejde, mens resten af kæden var det, der skabte fejlene. Ikke altid dramatisk. Bare nok til, at man ikke havde lyst til at sætte det tæt på drift.
Så det interessante ved tutorialen er efter vores mening ikke ord som agentic chains. Det er, at Google her viser nogle meget konkrete greb til at holde styr på flere værktøjer i samme arbejdsgang. Forskellen mærker man først rigtigt, når modellen skal jonglere tre datakilder og stadig give et svar, man faktisk tør sende videre.
