Criando um sistema multiagente com o Google Cloud

Há algum tempo, participei de um laboratório para criação de agentes de IA utilizando o Google Cloud. Nosso objetivo principal foi entender, na prática, como funciona um sistema multiagente, no qual diferentes agentes assumem papéis específicos dentro do mesmo fluxo: orquestrador, research, judge e writer.

O interessante desse tipo de experimento foi entender como é possível ter diferentes agentes colaborando entre si para gerar uma resposta final. Embora um único LLM consiga responder a perguntas com base em uma grande quantidade de dados, a complexidade do mundo real geralmente exige funções especializadas.

Divisão de tarefas entre agentes A2A

Nesse contexto, a divisão de responsabilidades entre agentes acaba sendo mais efetiva do que criar um único agente gigante tentando resolver tudo sozinho.

A ideia aqui é: em vez de um agente concentrar todas as tarefas, diferentes agentes atuam como especialistas em partes específicas do processo.

Os principais agentes utilizados neste laboratório foram:

Agente de pesquisa: usa o google_search para encontrar informações atualizadas.
Agente de avaliação: critica a pesquisa em relação à qualidade, relevância e integridade das informações.
Agente Content Builder: transforma a pesquisa em um curso ou conteúdo estruturado.
Agente de orquestração: gerencia o fluxo de trabalho e a comunicação entre esses especialistas.

Agent-to-Agent — A2A

Um pouco mais sobre o sistema multiagente.

O protocolo A2A, ou Agent-to-Agent, é um padrão de comunicação proposto pelo Google que permite que agentes de inteligência artificial conversem entre si e troquem informações dentro de um fluxo de trabalho.

Esse tipo de arquitetura é importante quando há múltiplas etapas em um processo. Nesse modelo, cada agente assume um papel especializado, como pesquisar, validar, decidir, revisar ou escrever.

Como exemplo, podemos imaginar uma arquitetura Agent-to-Agent aplicada a processos complexos e especializados.

Imagine o fluxo de uma seguradora utilizando esse tipo de arquitetura. Ela poderia ser aplicada a processos como cotação, atendimento ou análise de sinistro, por exemplo:

Cliente / Corretor / Analista

         |

         v

Agente Orquestrador

         |

         |————————-

         |           |            |

         v           v            v

Agente de       Agente de     Agente de

Apólice         Documentos    Risco/Fraude

         |           |            |

         ———– v ———–

               Agente Judge

                    |

                    v

               Agente Writer

                    |

                    v

     Resposta ao cliente ou analista

Nesse tipo de fluxo, os processos são divididos entre diferentes agentes, que se comunicam entre si para gerar um output final.

O orquestrador entende que se trata de uma abertura de sinistro.
O agente de atendimento coleta os dados obrigatórios.
O agente de apólice verifica se o seguro está ativo.
O agente de documentos analisa as imagens e identifica documentos faltantes.
O agente de risco verifica possíveis inconsistências.
O agente judge classifica o caso como:

  • simples;
  • incompleto;
  • suspeito;
  • precisa de análise humana.

O agente writer gera uma resposta clara para o analista ou para o cliente.

É importante deixar claro que não é recomendado utilizar esses agentes para decisões finais sem supervisão. Em contextos sensíveis, é sempre necessário que humanos validem as decisões e utilizem senso crítico para avaliar cada situação.

Quando não usar agentes

Nem todo problema precisa de uma arquitetura multiagente. Em alguns casos, esse tipo de solução pode aumentar a complexidade sem gerar ganho real.

Alguns exemplos de quando evitar o uso de agentes:

  • quando a tarefa requer supervisão humana contínua;
  • em contextos de alta sensibilidade a erros;
  • em decisões baseadas em valores humanos ou julgamentos éticos;
  • quando há falta de dados estruturados ou contexto adequado;
  • quando o tempo de execução é muito crítico;
  • em tarefas muito criativas ou inovadoras, nas quais a definição do caminho ainda depende bastante de intuição humana.

Voltando à construção do laboratório de que participei, o fluxo foi mais simples. Ainda assim, ele ajudou a entender a arquitetura desse tipo de sistema e como as tarefas podem ser distribuídas entre agentes especializados.

Exemplo do agente- Content-Builder

from google.adk.agents import Agent




MODEL = "gemini-2.5-pro"


# TODO: Define the Content Builder Agent
# This agent should take approved research and format it into a course module.


content_builder = Agent(
    name="content_builder",
    model=MODEL,
    description="Transforms research findings into a structured course.",
    instruction="""
    You are an expert course creator.
    Take the approved 'research_findings' and transform them into a well-structured, engaging course module.


    **Formatting Rules:**
    1. Start with a main title using a single `#` (H1).
    2. Use `##` (H2) for main section headings.
    3. Use bullet points and clear paragraphs.
    4. Maintain a professional but engaging tone.


    Ensure the content directly addresses the user's original request.
    """,
)
root_agent = content_builder

Abaixo, uma visão do output desse experimento:

Laboratório feito com o GDG Cloud SP


Leave a comment

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top