Google Deep Research Max adiciona MCP e recursos visuais nativos: agentes de pesquisa estão se tornando pipelines de construção reutilizáveis
A atualização Deep Research do Google em 21 de abril é menos importante como um recurso de chatbot e mais como uma movimentação de sistemas de agentes. Gemini Deep Research e Deep Research Max agora podem combinar a web aberta com dados privados, gerar gráficos inline e executar trabalhos de pesquisa de segundo plano que alimentam o próximo modelo da cadeia.
O que o Google realmente enviou
O Google afirma que os novos agentes são construídos no Gemini 3.1 Pro e agora suportam fluxos de trabalho de pesquisa que combinam pesquisa na web, servidores MCP remotos, arquivos carregados, armazenamentos de arquivos conectados, contexto de URL, execução de código e pesquisa de arquivos. A empresa dividiu o produto em dois modos: Deep Research padrão para experiências interativas de menor latência e custo mais baixo, e Deep Research Max para execuções em segundo plano de maior abrangência que usam mais computação em tempo de teste.
O anúncio oficial é extraordinariamente explícito sobre o fluxo de trabalho alvo. O exemplo do Google não é uma consulta de chat do consumidor. É um cron job noturno que gera relatórios de due diligence antes que a equipe de analistas acorde. Este é um forte sinal de que os agentes de investigação estão a ser posicionados como infra-estruturas para o trabalho a jusante e não apenas como motores de resposta.
Por que isso é importante para os construtores
Existem três mudanças importantes aqui. Primeiro, o Google está transformando a pesquisa em um estágio de pipeline reutilizável. Uma equipe pode executar Deep Research para coletar e sintetizar evidências e, em seguida, usar a API Interactions para entregar esse estado a outro modelo Gemini por meio de previous_interaction_id para resumir, reformatar ou executar a próxima etapa. Em segundo lugar, o Google está reduzindo a lacuna entre o contexto público e privado, permitindo que o agente trabalhe na Web, além de fontes de dados personalizadas. Terceiro, gráficos e infográficos agora fazem parte da mesma execução, em vez de uma etapa de visualização separada.
Para os construtores, isso significa que a “pesquisa profunda” deixa de ser um recurso de UI premium e começa a parecer uma classe de trabalho de back-end. As equipes de produto podem anexá-lo a resumos de pesquisa, preparação de vendas, fluxos de trabalho de conformidade, análises de mercado e investigações técnicas. Se funcionar bem, reduz o tempo gasto na junção manual de pesquisas, notas, resultados de planilhas e resumos executivos.
A advertência importante: os documentos ainda estão se atualizando
Há um aviso útil escondido nas próprias superfícies do Google. A postagem do blog diz que a Deep Research agora oferece suporte a MCPs remotos arbitrários e ferramentas combinadas, mas a página de documentos públicos da API de interações ainda mostra advertências da era de visualização de 15 de abril e IDs de modelos mais antigos. Essa incompatibilidade não significa que o lançamento seja falso. Isso significa que a superfície do produto está se movendo mais rápido do que os documentos estáveis.
É exatamente aí que começam o desperdício de tokens e a confusão da equipe. Se você construir diretamente a partir da cópia do anúncio, corre o risco de superestimar o que é estável hoje. Se você ignorar o lançamento, perderá uma mudança real no fluxo de trabalho. A regra prática é tratar os agentes de pesquisa como qualquer outro tempo de execução de visualização: fixe o ID exato do agente ou modelo que você testou, registre qual combinação de ferramentas realmente funcionou e mantenha um caminho alternativo para quando a superfície beta mudar.
Esta é a mesma disciplina operacional que TRH impõe Realidade da cota do Google AI Studio e Design de tempo de execução do OpenAI Agents SDK. A compactação do fluxo de trabalho só será valiosa se o tempo de execução permanecer legível.
O ângulo TRH: pipelines de pesquisa também precisam de orçamentos
Token Robin Hood os leitores devem prestar atenção ao formato do faturamento, não apenas ao gráfico de referência. Deep Research Max é otimizado para profundidade, o que geralmente significa execuções mais longas, mais uso de ferramentas, mais acúmulo de contexto e artefatos de saída maiores. Isso pode valer a pena quando o relatório for reutilizável ou vinculado a receitas. É um desperdício quando o relatório morre em uma guia ou é regenerado do zero porque ninguém armazenou o resultado em um formato que o resto da pilha possa consumir.
O padrão certo é simples. Limite o trabalho. Defina quais fontes de dados são permitidas. Salve a saída em um formato reutilizável. Encadeie apenas a próxima etapa do modelo que realmente precisa acontecer. Se o relatório for lido apenas uma vez, Deep Research Max provavelmente é o padrão errado. Se se tornar a camada de briefing para um agente de codificação, fluxo de trabalho de vendas ou memorando operacional, o gasto poderá se justificar.
O que os construtores devem fazer a seguir
Comece com um fluxo de trabalho em segundo plano onde a qualidade da pesquisa é mais importante do que a latência instantânea: monitoramento competitivo, due diligence, rastreamento de políticas, análise forense de bugs ou preparação de parceiros. Compare Deep Research regular com Max em uma tarefa repetível. Meça o tempo total de execução, a utilidade da saída e com que frequência o resultado pode ser entregue a um segundo modelo sem reafirmar todo o problema. Em seguida, decida se a versão cara pertence à produção ou apenas atrás de um portão humano.
Se sua pilha já usa agentes, adicione mais uma regra: os resultados da pesquisa devem se tornar entradas, e não becos sem saída. Persista-os, crie versões deles e mantenha a transferência downstream explícita.