Google Deep Research Max voegt MCP en native visuals toe: onderzoeksagenten worden herbruikbare bouwpijplijnen
De Deep Research-update van Google van 21 april is minder belangrijk als chatbotfunctie en meer als een verplaatsing van agentsystemen. Gemini Deep Research en Deep Research Max kunnen nu het open web combineren met privégegevens, inline grafieken genereren en uitvoeren als achtergrondonderzoekstaken die het volgende model in de keten voeden.
Wat Google daadwerkelijk heeft verzonden
Google zegt dat de nieuwe agenten zijn gebouwd op Gemini 3.1 Pro en nu onderzoeksworkflows ondersteunen die zoeken op internet, externe MCP-servers, geüploade bestanden, verbonden bestandsopslag, URL-context, code-uitvoering en zoeken naar bestanden combineren. Het bedrijf heeft het product in twee modi opgesplitst: standaard Deep Research voor interactieve ervaringen met lagere latentie en lagere kosten, en Deep Research Max voor uitgebreidere achtergrondruns die meer testtijdcomputergebruik gebruiken.
De officiële aankondiging is ongebruikelijk expliciet over de doelworkflow. Het voorbeeld van Google is geen chatquery voor consumenten. Het is een nachtelijke cronjob die due diligence-rapporten genereert voordat een analistenteam wakker wordt. Dat is een krachtig signaal dat onderzoeksagenten worden gepositioneerd als infrastructuur voor downstream-werk, en niet alleen als antwoordmotoren.
Waarom dit belangrijk is voor bouwers
Er zijn hier drie belangrijke verschuivingen. Ten eerste verandert Google onderzoek in een herbruikbare pijplijnfase. Een team kan Deep Research uitvoeren om bewijsmateriaal te verzamelen en te synthetiseren en vervolgens de Interactions API gebruiken om die toestand via een ander Gemini-model aan een ander Gemini-model over te dragen previous_interaction_id voor het samenvatten, opnieuw formatteren of uitvoeren van de volgende stap. Ten tweede verkleint Google de kloof tussen de publieke en private context door de agent op internet en op maat gemaakte gegevensbronnen te laten werken. Ten derde maken grafieken en infographics nu deel uit van dezelfde run in plaats van een afzonderlijke visualisatiestap.
Voor bouwers betekent dit dat ‘diep onderzoek’ niet langer een premium UI-functie is, maar op een backend-jobclass begint te lijken. Productteams kunnen het toevoegen aan onderzoeksinstructies, verkoopvoorbereiding, compliance-workflows, marktscans en technisch onderzoek. Als het goed werkt, vermindert het de tijd die besteed wordt aan het handmatig samenvoegen van zoekopdrachten, notities, spreadsheetuitvoer en samenvattingen.
Het belangrijke voorbehoud: de documenten zijn nog steeds bezig met een inhaalslag
Er is een nuttige waarschuwing verborgen op de eigen oppervlakken van Google. De blogpost zegt dat Deep Research nu willekeurige externe MCP's en gecombineerde tools ondersteunt, maar de openbare Interactions API-documentatiepagina toont nog steeds kanttekeningen uit het preview-tijdperk van 15 april en oudere model-ID's. Die mismatch betekent niet dat de lancering nep is. Het betekent dat het productoppervlak sneller beweegt dan de stabiele documenten.
Dat is precies waar tokenverspilling en teamverwarring beginnen. Als je rechtstreeks vanuit de aankondigingskopie bouwt, loop je het risico dat je overschat wat vandaag stabiel is. Als je de lancering negeert, mis je een echte workflowverschuiving. De praktische regel is om onderzoeksagenten te behandelen zoals elke andere preview-runtime: zet de exacte agent of model-ID vast die u hebt getest, registreer welke toolmix daadwerkelijk heeft gewerkt en bewaar een terugvalpad voor wanneer het bèta-oppervlak verandert.
Dit is dezelfde operationele discipline die TRH naar voren brengt Google AI Studio-quotumrealiteit En Runtime-ontwerp van OpenAI Agents SDK. Workflowcompressie is alleen waardevol als de runtime leesbaar blijft.
De TRH-invalshoek: onderzoekspijplijnen hebben ook budgetten nodig
Token Robin Hood lezers moeten letten op de factureringsvorm, niet alleen op het benchmarkdiagram. Deep Research Max is geoptimaliseerd voor diepgang, wat doorgaans langere runs, meer toolgebruik, meer contextaccumulatie en grotere outputartefacten betekent. Dat kan de moeite waard zijn als het rapport herbruikbaar is of aan inkomsten is gekoppeld. Het is verspilling als het rapport op een tabblad verdwijnt of helemaal opnieuw wordt gegenereerd, omdat niemand het resultaat heeft opgeslagen in een vorm die de rest van de stapel kan gebruiken.
Het juiste patroon is eenvoudig. De baan gebonden. Definieer welke gegevensbronnen zijn toegestaan. Sla de uitvoer op in een herbruikbaar formaat. Keten alleen de volgende modelstap aan die daadwerkelijk moet gebeuren. Als het rapport slechts één keer wordt geskimd, is Deep Research Max waarschijnlijk de verkeerde standaard. Als het de briefinglaag wordt voor een codeeragent, verkoopworkflow of operationele memo, kunnen de uitgaven zichzelf rechtvaardigen.
Wat bouwers vervolgens moeten doen
Begin met één achtergrondworkflow waarbij de kwaliteit van het onderzoek belangrijker is dan de onmiddellijke latentie: concurrentiemonitoring, due diligence, het volgen van beleid, forensisch onderzoek naar bugs of voorbereiding van partners. Vergelijk regulier Deep Research met Max voor één herhaalbare taak. Meet de totale looptijd, het uitvoergebruik en hoe vaak het resultaat aan een tweede model kan worden doorgegeven zonder het hele probleem opnieuw te beschrijven. Bepaal vervolgens of de dure versie in productie hoort of alleen achter een menselijke poort.
Als je stapel al agenten gebruikt, voeg dan nog een regel toe: onderzoeksresultaten moeten inputs worden, en geen doodlopende wegen. Houd ze vol, versieer ze en houd de stroomafwaartse overdracht expliciet.