O que você vai entender
Um agente combina um modelo, ferramentas e um ciclo de decisão orientado a um objetivo.
MAS significa Multi-Agent Systems: sistemas com múltiplos agentes que interagem.
Mais agentes só fazem sentido quando a divisão de trabalho melhora o resultado de forma mensurável.
O que muda quando a IA deixa de apenas responder?
Imagine duas solicitações: “explique por que uma rede pode ficar lenta” e “investigue a lentidão desta rede usando os registros disponíveis”. A primeira pede uma resposta. A segunda exige reunir evidências, escolher verificações e decidir o próximo passo conforme os resultados aparecem. É nessa passagem da conversa para uma sequência de ações que entra a IA agêntica.
Em sistemas baseados em modelos de linguagem, um agente pode escolher ferramentas e ajustar o caminho de execução para alcançar um objetivo. Já um fluxo automatizado pode seguir etapas previamente definidas pelo desenvolvedor. As duas abordagens podem coexistir: parte do processo fica fixa, enquanto determinadas decisões são delegadas ao modelo.
“Autonomia” não significa consciência, intenção própria ou permissão irrestrita. É a liberdade operacional que o projeto concede: quais informações o agente pode consultar, quais ferramentas pode usar e quando precisa parar ou pedir uma decisão humana.
Fontes e leitura complementar
O ciclo de um agente: observar, decidir, agir e verificar
Considere um assistente que recebe um chamado técnico. Ele lê o pedido, consulta uma fonte autorizada, examina o retorno e decide se precisa de outra consulta. Quando encontra evidência suficiente, apresenta uma conclusão; se os dados não bastam, pode solicitar esclarecimentos. O retorno das ferramentas orienta a próxima etapa.
Nesse desenho, o modelo propõe a ação, mas a aplicação executa a ferramenta e deve conferir suas permissões. O contexto mantém informações relevantes sobre o trabalho, enquanto limites de tempo e de tentativas impedem uma investigação sem fim. A ilustração abaixo é uma simplificação desse ciclo, não uma descrição do raciocínio interno do modelo.
Fontes e leitura complementar
O que são Sistemas Multiagentes (MAS)?
MAS é a sigla em inglês para Multi-Agent Systems. O conceito é mais amplo que os modelos de linguagem: descreve sistemas nos quais vários agentes interagem. Eles podem cooperar, negociar ou competir, dependendo dos objetivos e das regras do ambiente. Neste artigo, o foco é a colaboração entre agentes baseados em IA.
Em uma equipe desse tipo, cada agente pode ter instruções, ferramentas e contexto próprios. Eles não precisam usar modelos diferentes. Um mesmo modelo pode assumir papéis distintos em execuções separadas; o que diferencia os agentes é a responsabilidade atribuída e a forma como trocam informações.
O trabalho sobre AutoGen apresenta uma abordagem de aplicações com conversas entre agentes configuráveis, que podem combinar modelos, ferramentas e participação humana. Isso ajuda a entender por que um MAS é uma arquitetura de interação, e não apenas uma lista de prompts executados sem coordenação.
Fontes e leitura complementar
Como os agentes organizam o trabalho?
Uma possibilidade é ter um coordenador que recebe o objetivo, distribui subtarefas e reúne as entregas. Outra é transferir a responsabilidade conforme o assunto: um agente de atendimento identifica uma questão técnica e passa o contexto para um especialista. Também é possível dividir pesquisas independentes e combinar os resultados depois.
No relato de seu sistema de pesquisa, a Anthropic descreve um agente principal que coordena subagentes trabalhando em partes do problema. O texto mostra a importância de delegar com objetivos claros e de projetar a comunicação entre os participantes. Isso não quer dizer que a mesma arquitetura seja ideal para qualquer aplicação.
A interface entre os agentes precisa ser tão clara quanto a interface entre serviços: o que cada um recebe, o que deve devolver e como sinaliza uma falha. Uma entrega útil distingue observações, hipóteses e limitações; um texto persuasivo sem evidências não resolve o problema de coordenação.
Fontes e leitura complementar
Exemplo prático: investigar um incidente de rede
Pense em um provedor que recebe relatos de falhas intermitentes em alguns serviços. A proposta a seguir é um cenário didático, não uma integração já disponível no DNSR Block. O objetivo seria organizar evidências para o técnico, com acesso inicial somente de leitura.
Um coordenador delimita o período do incidente e distribui três tarefas. Um agente organiza os relatos e horários; outro examina registros de resolução de nomes; o terceiro consulta métricas de conectividade. Cada um devolve achados vinculados às suas fontes, sem aplicar mudanças na rede.
Depois, o coordenador compara os resultados. Se duas evidências entrarem em conflito, registra a divergência e propõe uma verificação adicional. A conclusão pode ser simplesmente “não há dados suficientes para atribuir a falha ao DNS”. Essa resposta é mais útil do que inventar uma causa para encerrar o chamado.
O técnico revisa o relatório e decide se autoriza alguma intervenção. A distinção entre investigar e alterar precisa existir no sistema de permissões, e não apenas no texto das instruções. Assim, um erro na interpretação de um registro não se transforma automaticamente em uma mudança de configuração.
Mais agentes também trazem mais custo e mais coordenação
Distribuir tarefas pode ampliar a cobertura de uma pesquisa, mas cria trabalho adicional: explicar o objetivo, transmitir contexto e reconciliar respostas. Se todos dependem da mesma informação e repetem as mesmas consultas, o ganho esperado pode desaparecer.
O relato da Anthropic destaca o consumo adicional de recursos dos sistemas multiagentes e a necessidade de avaliar resultados. Os ganhos observados em uma aplicação de pesquisa não devem ser tratados como promessa de desempenho para suporte, programação ou operações de rede.
Também não basta pedir que um segundo agente revise o primeiro. Eles podem compartilhar o mesmo erro ou aceitar a mesma fonte incorreta. Para o exemplo de rede, uma validação mais forte seria comparar a hipótese com registros verificáveis e com casos cujo diagnóstico já é conhecido.
O estudo Why Do Multi-Agent LLM Systems Fail? organiza falhas observadas em categorias ligadas ao desenho do sistema, ao desalinhamento entre agentes e à verificação da tarefa. É um lembrete de que aumentar o número de participantes não elimina problemas de especificação ou validação.
Resultado: a tarefa foi resolvida com evidências suficientes?
Custo: quantas consultas e chamadas de modelo foram necessárias?
Tempo: quanto demorou até produzir uma conclusão útil?
Intervenção: quantas vezes um humano precisou corrigir o caminho?
Falhas: o sistema reconheceu informações insuficientes e respeitou os limites?
Fontes e leitura complementar
Como começar sem perder o controle
Para uma primeira experiência, nossa sugestão é escolher uma atividade pequena e de baixo impacto, como organizar evidências de chamados já encerrados. Use um conjunto de exemplos com resultados conhecidos e compare o trabalho assistido com o procedimento atual. Isso permite medir se a automação ajuda antes de conectá-la à operação.
No cenário proposto, os primeiros acessos seriam somente de leitura. Credenciais ficariam no servidor, com permissões específicas para cada ferramenta. Conteúdo encontrado em páginas, mensagens ou registros seria tratado como dado: uma instrução escondida em um documento não deveria ampliar o acesso do agente.
Quando houver necessidade de ações, convém separar proposta, autorização e execução, registrando o que aconteceu. Uma ferramenta que altera configuração deve validar seus parâmetros e ter um procedimento de recuperação definido. Esses controles fazem parte da aplicação que envolve os modelos.
IA agêntica abre espaço para delegar tarefas com várias etapas. Sistemas multiagentes acrescentam divisão de responsabilidades. O valor aparece quando essa divisão produz um resultado melhor, verificável e compatível com o custo — não simplesmente quando há mais agentes em execução.