Gemini Deep Research e Interactions API sono, di fatto, la mossa con cui Google prova a trasformare la “ricerca assistita” da funzione consumer a componente sviluppabile: un agente in grado di pianificare, cercare sul web, colmare gap informativi e sintetizzare un report citato, richiamabile via API e pensato per task che durano minuti, non secondi. L’annuncio è datato 11 dicembre 2025 e mette sul tavolo due pezzi: l’agente Gemini Deep Research (in preview) e l’Interactions API come endpoint unificato per modelli e agenti.
Cos’è davvero Gemini Deep Research: non un modello, ma un workflow gestito
Google definisce Deep Research come un agente ottimizzato per attività di “context gathering” e sintesi a lunga esecuzione: il punto non è rispondere bene a una domanda singola, ma iterare in autonomia su più passaggi, con un ciclo che include pianificazione, query, lettura, identificazione di lacune e nuove ricerche fino a convergere su un report strutturato. In altre parole, è un’architettura “research loop” preconfezionata, esposta come servizio.
Sul piano tecnico, Google lega il “core di ragionamento” a Gemini 3 Pro, descritto come il modello più “factual” della casa e addestrato per ridurre le allucinazioni e massimizzare la qualità del report in compiti complessi. La parte interessante non è solo il modello, ma l’addestramento e il comportamento: si parla esplicitamente di reinforcement learning multi-step applicato alla ricerca, con l’obiettivo di migliorare accuratezza e profondità quando l’agente naviga “in profondità” nei siti per trovare dati specifici.
Interactions API: l’endpoint che “capisce” stato, tool call e background
Il motivo per cui Deep Research arriva “via Interactions API” non è cosmetico. Interactions API nasce come interfaccia nativa per gestire contesti complessi tipici delle app agentiche: messaggi, “thoughts”, chiamate a strumenti, risultati degli strumenti e stato della sessione, il tutto con la possibilità di spostare parte della gestione della history lato server e di eseguire loop lunghi in background. È anche, nelle parole di Google, un’unificazione: un solo endpoint REST (/interactions) che può parlare con un modello (parametro “model”) o con un agente (parametro “agent”).ì
Questa distinzione è cruciale: Deep Research, in questa fase, non passa da generateContent. È disponibile esclusivamente tramite Interactions API ed è in anteprima.
Benchmark e numeri: HLE, DeepSearchQA e BrowseComp come cartina di tornasole
Google accompagna l’annuncio con numeri su tre benchmark che, oggi, sono diventati “moneta” nelle comparazioni di agenti di ricerca. Nell’articolo ufficiale si parla di risultati SOTA su Humanity’s Last Exam (HLE) e su DeepSearchQA, oltre a un “best” interno su BrowseComp. I valori dichiarati sono 46,4% sull’intero set di HLE, 66,1% su DeepSearchQA e 59,2% su BrowseComp.
Qui c’è un messaggio implicito: Google sta posizionando Deep Research come agente affidabile e “completo” più che come “chat veloce”. E infatti DeepSearchQA è costruito proprio per misurare la completezza (comprehensiveness) su task a catena causale, dove ogni passo dipende dall’analisi precedente, e dove conta non solo la precisione nel trovare un fatto, ma anche il recall nel non lasciarsi dietro pezzi necessari. La suite include 900 task “causal chain” su 17 ambiti.
DeepSearchQA: perché Google open-source un benchmark (e cosa misura davvero)
DeepSearchQA viene presentato come risposta a un limite pratico: molti benchmark, dice Google, non catturano la complessità della ricerca multi-step reale. L’idea è valutare agenti che devono costruire una risposta esaustiva, non “indovinare” un singolo dato. C’è anche un punto metodologico interessante: DeepSearchQA viene usato come strumento diagnostico per quantificare il valore del “thinking time”, cioè quanto migliora la performance quando si concede all’agente più step di ricerca e ragionamento.
Nella stessa sezione compare un concetto tipico dei sistemi agentici: confrontare pass@1 e pass@8 per mostrare quanto la verifica su traiettorie parallele aiuti l’affidabilità (l’agente esplora più percorsi e poi consolida). È una logica più vicina al “metodo” che al singolo output.
Cosa puoi costruire: sintesi ibrida (web + documenti) e output governabili
Dal punto di vista “developer”, Google enfatizza quattro capacità che, sommate, descrivono un prodotto pensato per workflow aziendali:
Gemini Deep Research può combinare dati del web pubblico e documenti caricati (PDF, CSV, documenti), con gestione di contesti ampi e possibilità di mettere molto background direttamente nel prompt.
Il report è “steerable” via prompting: puoi imporre struttura, titoli, sottotitoli e persino richiedere tabelle e formattazioni. Nella documentazione viene esplicitato che il formato va definito nell’input, con esempi che chiedono sezioni e tabelle comparative.
Le citazioni sono un punto dichiarato: l’obiettivo è fornire sourcing granulare per permettere la verifica dell’origine delle affermazioni.
Sono menzionati anche output strutturati (schema JSON) nell’articolo di annuncio, ma la documentazione tecnica indica che, al momento, l’agente Deep Research non supporta output strutturati. Tradotto: la direzione è chiara, ma alcune feature sono ancora in assestamento e va letto bene cosa è “promesso” a livello di roadmap vs cosa è effettivamente disponibile oggi.
Il modello operativo: background obbligatorio, polling e stati della ricerca
Qui non c’è da edulcorare: Deep Research non è pensato per una chiamata sincrona. Nella doc è scritto che le attività possono richiedere diversi minuti e che bisogna usare esecuzione in background impostando background=true, poi fare polling fino allo stato completed (o gestire failed). Il pattern è: crei un’Interaction, ricevi subito un oggetto parziale con un id, poi interroghi l’API fino al completamento. (Google AI for Developers)
Esempio (Python) riportato nella documentazione, qui riscritto in modo fedele nei parametri chiave:
import time
from google import genai
client = genai.Client()
interaction = client.interactions.create(
input="Research the history of Google TPUs.",
agent="deep-research-pro-preview-12-2025",
background=True
)
while True:
interaction = client.interactions.get(interaction.id)
if interaction.status == "completed":
print(interaction.outputs[-1].text)
break
if interaction.status == "failed":
print(interaction.error)
break
time.sleep(10)
Il nome dell’agente indicato è deep-research-pro-preview-12-2025 e, sempre secondo Google, Interactions API “currently supports” proprio quell’agente in questa fase. (Google AI for Developers)
Strumenti disponibili: web di default, file_search opzionale (e sperimentale)
Per impostazione predefinita, Deep Research ha accesso al web pubblico con strumenti come google_search e url_context senza che tu debba dichiararli nel prompt o nella configurazione. Se vuoi aggiungere anche i tuoi dati, devi esplicitare tool e store per file_search, che viene indicato come ancora sperimentale. (Google AI for Developers)
Questo è il punto che, in produzione, cambia tutto: l’agente può fare “due diligence” o “market scan” incrociando web e materiali proprietari. Ma è anche il punto dove aumenta il rischio di leakage se la governance è approssimativa, perché stai mettendo in contatto due mondi che spesso, in azienda, si tengono separati per ragioni di compliance. La stessa documentazione cita rischi legati al contenuto web e raccomanda di verificare le citazioni, oltre a richiamare il tema dell’esfiltrazione quando si mescolano dati interni e navigazione web. (Google AI for Developers)
Streaming e “osservabilità” del processo: cosa puoi vedere e cosa no
La doc prevede streaming con stream=True insieme a background=True per ricevere aggiornamenti in tempo reale sul progresso. Però c’è una condizione: per vedere passaggi intermedi e aggiornamenti, vanno abilitati i “thought summaries” in agent_config; altrimenti lo stream può limitarsi ai risultati finali. La stessa sezione spiega anche come recuperare interaction_id e usare un event_id per riprendere lo stream dopo una disconnessione. (Google AI for Developers)
In pratica: Google sta mettendo basi per la “telemetria” applicativa degli agenti, che è un tema enorme quando sposti agentic loops in server-side background e devi capire perché un report ha preso una certa direzione.
Limiti e vincoli: quello che oggi non puoi fare (e devi sapere prima di prometterlo a un cliente)
Ci sono alcuni paletti espliciti che, se ignorati, ti fanno perdere tempo in fase di design:
L’agente Deep Research è in anteprima e passa solo da Interactions API; niente generate_content. (Google AI for Developers)
Il tempo massimo di ricerca è 60 minuti e “la maggior parte” dei task dovrebbe chiudersi entro 20 minuti: va considerato nella UX e nei timeout applicativi. (Google AI for Developers)
Non sono supportati input audio. (Google AI for Developers)
La doc segnala che, al momento, non puoi fornire strumenti di function calling personalizzati o server MCP remoti all’agente Deep Research; inoltre viene indicato che non supporta pianificazione approvata da persone e (sempre nella doc) output strutturati. Questo è un punto da tenere d’occhio perché l’annuncio “marketing” e la doc tecnica non sempre vanno allo stesso passo. (Google AI for Developers)
Interactions API è in beta pubblica, quindi schemi e feature possono cambiare. (Google AI for Developers)
Dove Google dice di volerlo portare: Search, NotebookLM, Finance e Vertex AI
Nel post di annuncio, Google scrive che Deep Research “soon” arriverà anche in prodotti come Google Search, NotebookLM e Google Finance, oltre a un upgrade nella Gemini App. È anche citato il lavoro per portarlo su Vertex AI per il mondo enterprise. Qui la lettura è semplice: la stessa capability viene “impacchettata” sia come funzione per utenti finali, sia come building block per sviluppatori e aziende. (blog.google)
Casi d’uso: due diligence e ricerca scientifica, con esempi citati
Google cita già utilizzi in ambiti ad alta precisione come servizi finanziari, biotech e market research. Un esempio è la due diligence: aggregare segnali di mercato, analisi competitor e rischi di compliance da web e fonti proprietarie per accelerare la fase iniziale del lavoro. Un altro è l’ambito biomedicale: viene citata Axiom Bio, che lavora su sistemi AI per prevedere la tossicità dei farmaci, e che avrebbe usato Deep Research per ottenere maggiore profondità e granularità nella ricerca preliminare su letteratura biomedica. (blog.google)
Cosa cambia per chi sviluppa: dal “prompt” alla “pipeline di ricerca”
Se finora molte app “AI” hanno usato il modello come generatore di testo, qui il paradigma diventa pipeline: un’interazione che dura, che ha stato, che usa strumenti e produce un artefatto (report) che spesso sarà consumato da altri sistemi (CRM, strumenti di BI, knowledge base, sistemi di ticketing). Ed è qui che Interactions API prova a togliere attrito: server-side state, background execution, schema più leggibile per storie agentiche e, per i modelli, supporto a tool MCP remoti (attenzione: questo vale per i modelli; l’agente Deep Research ha limitazioni specifiche citate in doc).
Immagine concettuale: un’interfaccia “research console” con una timeline di step (query, lettura, gap, nuova query), a sinistra i documenti interni (PDF/CSV) e a destra i risultati web, al centro un report con citazioni.
Alt consigliato: “Gemini Deep Research via Interactions API: agente che combina web pubblico e documenti aziendali per generare report citati e strutturati”.
Riferimenti testuali
Riferimento interno (testuale): “la documentazione Gemini API per Interactions API e Deep Research”.
Riferimento esterno (testuale): “il technical report di DeepSearchQA pubblicato da Google”.
Se mi dai l’OK, passo al workflow post-articolo (titoli SEO + permalink, tre meta description 135–145 caratteri con conteggio, riassunto 300 caratteri, post LinkedIn 500–600 caratteri).
