Existe uma tensão silenciosa em muitos times de engenharia hoje: o backend corporativo roda em Java, mas toda a magia de IA vive num script Python que “ninguém sabe bem como funciona”. O Google acabou de lançar a versão 1.0 do Agent Development Kit (ADK) para Java, e a proposta é exatamente eliminar esse atrito.

Mas antes de tratar isso como mais um release de SDK, vale entender o que mudou de verdade na arquitetura.

Plugins globais: fim do callback hell em sistemas multi-agente

Quem já tentou instrumentar um sistema com múltiplos agentes e subagentes sabe a dor: cada nó precisa do seu próprio callback de logging, cada camada repete a mesma lógica de observabilidade. O ADK 1.0 resolve isso com uma arquitetura de plugins centralizada ancorada na classe App.

O App funciona como um container de nível superior que intercepta e modifica comportamentos de modelos, agentes e ferramentas em todo o sistema — sem duplicar lógica. Na prática:

• LoggingPlugin → log estruturado de erros, chamadas de ferramentas e requests de modelos

• GlobalInstructionPlugin → regras de segurança e identidade aplicadas a todos os agentes dinamicamente

• BasePlugin → extensível para políticas arquiteturais próprias do time

Para quem opera sistemas em produção com SLAs, isso é a diferença entre depurar logs fragmentados e ter uma plataforma de observabilidade com dados uniformes.

O problema que a maioria ignora: seu contexto vai morrer no meio da sessão

Sistemas conversacionais de longa duração têm um inimigo silencioso: o limite de tokens. Quando o histórico de uma sessão enche a janela de contexto, você paga mais, a latência sobe e o modelo começa a “esquecer” coisas.

O ADK 1.0 introduz compactação de eventos configurável via eventsCompactionConfig. Em vez de truncar a conversa abruptamente, o sistema mantém uma janela deslizante de eventos recentes e resume os mais antigos com o LlmEventSummarizer.

Para domínios altamente específicos, você pode implementar BaseEventSummarizer e EventCompactor do zero, útil quando o sumarizador padrão não entende a semântica do seu negócio. Parâmetros configuráveis incluem intervalo de compactação, tamanho de overlap, limites de tokens e tempo de retenção.

---

Execução de código sem deixar brechas de segurança

Duas abstrações novas endereçam o pesadelo de segurança de rodar código gerado por IA:

ContainerCodeExecutor — executa localmente em Docker, integrável com pipelines CI/CD existentes.

VertexAiCodeExecutor — executa nativamente na nuvem dentro do Vertex AI.

Para automação de interface, a abstração ComputerUseTool permite controlar um navegador real via Playwright, útil para cenários de RPA inteligente.

Persistência que não exige reescrever sua infra

Um dos pontos mais pragmáticos do release: múltiplas opções de sessão configuráveis diretamente no loop do executor, sem impor um banco específico.

CenárioServiçoDev/teste localInMemorySessionServiceProdução gerenciadaVertexAiSessionServiceEscala horizontalFirestoreSessionService

Memória conversacional de longo prazo segue o mesmo padrão: conecte um LoadMemoryTool ao agente e ele consulta automaticamente o FirestoreMemoryService ou InMemoryMemoryService. Para artefatos grandes (PDFs, imagens), o GcsArtifactService oferece versionamento via Google Cloud Storage.

Human-in-the-loop sem gambiarras de estado

Fluxos de aprovação humana sempre foram dolorosos de implementar. O ADK 1.0 formaliza esse padrão com ToolConfirmation: quando uma ferramenta chama requestConfirmation via ToolContext, a execução pausa automaticamente até que o humano aprove.

Após a aprovação, o framework retoma o fluxo, limpa eventos intermediários e injeta a chamada confirmada de volta no contexto, sem loop infinito, sem estado inconsistente.

Exemplo concreto: um assistente de relatórios equipado com ferramenta de busca pode ser configurado para sempre pedir confirmação antes de disparar um agente de coleta de dados.

Protocolo A2A: seus agentes Java conversando com agentes Python (e qualquer outra linguagem)

O suporte nativo ao protocolo Agent2Agent (A2A) é provavelmente o item mais estratégico do release. Ele permite que agentes Java colaborem com agentes remotos em frameworks e linguagens diferentes.

O fluxo: resolva um AgentCard (identidade + capacidades de um agente remoto), encapsule num RemoteA2AAgent e insira na hierarquia local. O agente remoto se comporta exatamente como uma entidade local, transmitindo eventos nativamente de volta pro executor.

Na direção inversa, você expõe seus agentes internos encapsulando-os num AgentExecutor, que cria um endpoint REST JSON-RPC acessível por qualquer serviço.

O que isso significa na prática para times de engenharia

O lançamento do ADK Java 1.0 não é sobre features isoladas, é sobre uma mudança de postura: IA em produção precisa dos mesmos padrões de engenharia que qualquer outro sistema crítico. Observabilidade centralizada, gerenciamento de estado, isolamento de execução e interoperabilidade são requisitos, não opcionais.

Para times Java que vinham postergando a integração de agentes por falta de um caminho nativo e maduro, esse release remove a principal desculpa.