Existe uma fase inevitável em quase todo projeto de inteligência artificial: alguém descobre agentes, se empolga e quer transformar tudo em multiagente.
Um agente para vender.
Um agente para pesquisar.
Um agente para revisar.
Um agente para responder.
Um agente para validar.
Um agente para decidir.
Um agente para orquestrar todos os outros agentes.
No papel, parece sofisticado. Na prática, pode virar um Frankenstein: um monte de componentes autônomos, cada um tomando pequenas decisões, com pouca rastreabilidade, lógica espalhada, baixa governança e uma dificuldade enorme para explicar por que o sistema chegou naquele resultado.
Foi por isso que o anúncio do Microsoft Agent Framework, em outubro de 2025, chamou minha atenção. A Microsoft apresentou o framework em public preview como um SDK e runtime open source para simplificar a orquestração de sistemas multiagentes, convergindo o AutoGen, que nasceu em pesquisa, com as bases enterprise do Semantic Kernel. Ao mesmo tempo, o Azure AI Foundry ganhou novas capacidades para ajudar desenvolvedores a construir, observar e governar sistemas multiagentes.
Esse ponto é importante: a conversa não é mais apenas “como criar um agente”. A conversa agora é “como criar um sistema de agentes que não vire caos”.
O problema dos multiagentes
Agentes são poderosos porque conseguem raciocinar, usar ferramentas, consultar contexto e executar etapas. Mas quando você coloca vários agentes juntos, a complexidade sobe rápido.
Um agente já pode falhar de várias formas. Ele pode interpretar mal uma instrução, chamar a ferramenta errada, usar contexto incompleto, responder com excesso de confiança ou tomar um caminho que parecia bom, mas não era.
Agora imagine cinco agentes interagindo.
Quem coordena?
Quem decide a ordem?
Quem valida a resposta?
Quem mantém estado?
Quem registra o que aconteceu?
Quem trata erro?
Quem interrompe o fluxo?
Quem chama o humano quando precisa?
Quem garante que um agente não passe informação sensível para outro?
Sem arquitetura, multiagente vira improviso distribuído.
E improviso distribuído é pior do que improviso centralizado.
Por que o Microsoft Agent Framework importa
O Microsoft Agent Framework importa porque tenta organizar uma dor real: o ferramental para agentes estava ficando fragmentado.
De um lado, o AutoGen trouxe uma abordagem forte para padrões de agente único e multiagente. De outro, o Semantic Kernel trouxe uma base mais enterprise, com preocupações de estado, filtros, telemetria, conectores e uso em ambientes corporativos. A Microsoft posicionou o Agent Framework como uma convergência desses dois mundos, criando uma base mais unificada para construir sistemas agentic com mais controle.
Para mim, o valor está menos no nome do framework e mais na direção arquitetural: parar de tratar agentes como scripts soltos e começar a tratá-los como componentes de software dentro de um runtime mais governável.
A Microsoft destacou que o framework permite experimentar localmente e depois implantar no Azure AI Foundry com observabilidade, durabilidade e compliance embutidos; integrar APIs via OpenAPI; conectar ferramentas usando MCP; colaborar entre runtimes com Agent2Agent; e usar padrões multiagentes como Magentic One e workflows.
Isso mostra uma ambição clara: criar uma camada onde agentes, ferramentas, workflows e governança possam conviver de forma menos artesanal.
A pergunta certa: preciso mesmo de multiagente?
Antes de falar de arquitetura, precisamos falar de bom senso.
Nem todo problema precisa de agente. E, principalmente, nem todo problema precisa de multiagente.
Essa é uma das maiores armadilhas da IA aplicada. Quando uma tecnologia fica popular, todo problema começa a parecer oportunidade de usá-la. Mas arquitetura boa não começa pela ferramenta. Começa pelo problema.
Se eu consigo resolver uma tarefa com uma função determinística, eu prefiro uma função.
Se eu consigo resolver com um workflow simples, prefiro um workflow simples.
Se eu consigo resolver com um bom RAG, prefiro um bom RAG.
Se o processo exige raciocínio aberto, uso de ferramentas e decisão contextual, aí um agente começa a fazer sentido.
Se existem várias especialidades, tarefas independentes, revisão cruzada ou fluxo longo, aí multiagente pode fazer sentido.
O erro é começar com multiagente porque parece moderno.
Multiagente deve ser consequência da complexidade real do problema, não da vontade de parecer avançado.
O que é um sistema multiagente bem desenhado?
Um sistema multiagente bem desenhado não é uma reunião caótica de agentes conversando entre si.
Ele tem papéis claros.
Tem fluxo.
Tem estado.
Tem limites.
Tem ferramentas.
Tem observabilidade.
Tem critério de parada.
Tem tratamento de erro.
Tem revisão humana quando necessário.
Tem governança.
Na minha visão, um sistema multiagente precisa responder a cinco perguntas.
1. Quem faz o quê?
Cada agente precisa ter uma responsabilidade específica.
2. Quem coordena?
Alguém ou algum workflow precisa controlar a ordem e a troca de informações.
3. O que cada agente pode acessar?
Nem todo agente deve acessar todos os dados e ferramentas.
4. Como o sistema sabe que terminou?
Sem critério de conclusão, agentes podem entrar em loops ou gerar trabalho inútil.
5. Como eu audito o processo?
Sem tracing, logs e telemetria, você não consegue explicar o resultado.
Se essas respostas não estão claras, ainda não existe arquitetura. Existe uma demo.
Agentes versus workflows
Um ponto interessante do movimento da Microsoft é a ênfase em workflows multiagentes no Azure AI Foundry. No anúncio de outubro, a Microsoft falou em uma camada estruturada e stateful para orquestrar processos de negócio multi-step, coordenar agentes em tarefas longas, compartilhar contexto, lidar com erro, retry e recovery.
Isso é muito importante.
Porque muita gente tenta resolver com “conversa entre agentes” aquilo que deveria ser resolvido com workflow.
Um workflow define etapas.
Um agente interpreta e decide dentro de um escopo.
Um sistema bom sabe combinar os dois.
Por exemplo, imagine um fluxo de análise de fornecedor:
- coletar dados públicos;
- consultar base interna;
- analisar risco;
- revisar compliance;
- gerar parecer;
- enviar para aprovação humana.
Isso não precisa ser um bate-papo livre entre agentes. Pode ser um workflow com etapas claras, onde agentes especialistas executam partes específicas.
Essa diferença muda tudo. Quanto mais crítico o processo, mais explícita deve ser a orquestração.
Um exemplo prático: análise de fornecedor
Vamos transformar isso em um caso concreto.
Imagine uma empresa que quer usar IA para apoiar análise de fornecedores. O objetivo não é deixar a IA aprovar fornecedores sozinha. O objetivo é acelerar a triagem, organizar evidências e preparar uma recomendação para revisão humana.
Um desenho multiagente poderia ter:
Agente de pesquisa externa
Busca informações públicas sobre o fornecedor, notícias, presença digital e possíveis sinais de risco.
Agente de dados internos
Consulta documentos, histórico de relacionamento, contratos e registros internos disponíveis.
Agente de compliance
Avalia sinais de risco, políticas internas e pontos que exigem atenção.
Agente redator
Transforma os achados em um parecer claro para o time responsável.
Workflow orquestrador
Define a ordem das etapas, guarda estado, trata erros e envia para aprovação humana.
Repare: cada agente tem uma função. O workflow coordena. A decisão final continua humana.
Isso é muito diferente de criar um “superagente de fornecedores” e pedir para ele resolver tudo.
Como eu documentaria os papéis
Antes de escrever código, eu faria uma especificação simples:
System: Supplier Review Assistant
Goal:
Support supplier risk analysis by collecting evidence, organizing findings and preparing a human-reviewable report.
Agents:
1. External Research Agent
- Searches public information.
- Cannot make final risk decisions.
- Must cite sources.
2. Internal Context Agent
- Retrieves approved internal records.
- Cannot access confidential data outside its permission scope.
3. Compliance Review Agent
- Identifies risk indicators.
- Must classify uncertainty.
- Must escalate sensitive findings.
4. Report Agent
- Produces a structured summary.
- Cannot add facts not present in previous steps.
Workflow:
Research → Internal Context → Compliance Review → Report → Human Approval
Stop condition:
A final report is generated and sent for human review.
Human approval required:
Always, before any supplier decision.Isso não é burocracia. É arquitetura.
Quando o sistema começa com esse tipo de clareza, a implementação fica menos perigosa.
O que entra no agente e o que entra no workflow?
Essa é uma pergunta central.
Eu colocaria no agente aquilo que exige interpretação, linguagem natural, raciocínio contextual e uso de ferramentas dentro de um papel específico.
Eu colocaria no workflow aquilo que exige ordem, regra explícita, controle de estado, retry, aprovação, roteamento e auditoria.
Exemplo:
Classificar se uma notícia parece relevante para risco reputacional pode ser tarefa de agente.
Garantir que o relatório só avance depois da análise de compliance é tarefa de workflow.
Gerar um resumo executivo pode ser tarefa de agente.
Enviar para aprovação humana é tarefa de workflow.
Decidir qual ferramenta usar em uma pesquisa aberta pode ser tarefa de agente.
Bloquear envio automático em caso de risco alto é tarefa de workflow.
Essa separação evita que o agente vire dono do processo inteiro.
Agente é bom para raciocinar em ambientes ambíguos. Workflow é bom para impor controle.
Em produção, você precisa dos dois.
Onde MCP, OpenAPI e A2A entram
No anúncio do Microsoft Agent Framework, a Microsoft destacou três integrações importantes: OpenAPI, MCP e Agent2Agent.
Cada uma resolve uma parte da arquitetura.
OpenAPI ajuda quando você quer conectar agentes a APIs existentes de forma padronizada.
MCP ajuda quando você quer expor ferramentas para agentes de uma maneira mais dinâmica e orientada ao ecossistema agentic.
A2A entra na ideia de colaboração entre agentes e runtimes diferentes.
A leitura prática é: a Microsoft está tentando evitar que cada time construa agentes isolados que só funcionam dentro de um único runtime fechado.
Isso é relevante porque, no mundo real, empresas terão agentes de vários lugares. Alguns no Microsoft Foundry. Outros conectados a Microsoft 365 Copilot. Outros em frameworks externos. Outros em aplicações próprias.
Interoperabilidade começa a virar tema central.
Mas interoperabilidade sem governança também é risco.
O perigo da interoperabilidade sem fronteira
Quando agentes começam a conversar com outros agentes, chamar ferramentas externas e operar em múltiplos runtimes, a pergunta de segurança fica mais difícil.
Quais dados saem do ambiente?
Qual agente recebeu qual informação?
Qual ferramenta foi chamada?
Qual runtime executou a ação?
Existe retenção de dados por terceiros?
Existe limite geográfico ou regulatório?
Existe log suficiente?
Esse ponto é tão relevante que a própria documentação do Agent Framework alerta que, ao criar aplicações que operam com servidores ou agentes de terceiros, é responsabilidade da organização revisar os dados compartilhados e entender práticas de retenção, localização de dados e possíveis implicações de compliance.
Esse aviso precisa ser levado a sério.
Multiagente não é só uma questão de produtividade. É uma questão de fronteira de dados.
Observabilidade: a camada que separa arquitetura de fé
Um sistema multiagente sem observabilidade é um sistema baseado em fé.
Você espera que o agente certo tenha chamado a ferramenta certa, com o contexto certo, no momento certo, e gerado a resposta certa. Mas se algo dá errado, você não consegue explicar.
No anúncio de outubro, a Microsoft também destacou melhorias em observabilidade multiagente com contribuições ao OpenTelemetry, ajudando a padronizar tracing e telemetria para sistemas agentic. A proposta é dar mais visibilidade a workflows, chamadas de ferramentas e colaboração entre agentes, inclusive em frameworks como Microsoft Agent Framework, LangChain, LangGraph e OpenAI Agents SDK.
Para mim, essa é uma das partes mais importantes.
Porque conforme o número de agentes cresce, a explicabilidade do fluxo diminui. E quando a explicabilidade diminui, a confiança cai.
Observabilidade é o mecanismo que permite responder:
Qual agente iniciou o processo?
Quais etapas foram executadas?
Quais ferramentas foram chamadas?
Quanto tempo cada etapa levou?
Onde ocorreu erro?
Qual foi o input e output de cada agente?
O processo entrou em loop?
Houve intervenção humana?
Qual versão da instrução estava em uso?
Sem isso, multiagente não deveria ir para produção.
Como eu estruturaria logs em um sistema multiagente
Eu criaria um padrão de log com, no mínimo:
execution_id
workflow_name
agent_name
agent_role
step_name
input_summary
tool_called
tool_result_status
model_used
latency_ms
risk_level
requires_human_review
output_summary
error_message
timestampNão precisa registrar dados sensíveis desnecessários. Na verdade, deve-se evitar isso. Mas precisa registrar metadados suficientes para auditoria.
O segredo é equilibrar observabilidade e privacidade.
Log demais pode virar risco.
Log de menos vira cegueira operacional.
Responsible AI em multiagentes
Outro ponto importante do anúncio de outubro foi a camada de Responsible AI. A Microsoft mencionou recursos em public preview como task adherence, prompt shields com spotlighting e PII detection, voltados a ajudar agentes a ficarem alinhados à tarefa, proteger contra prompt injection e identificar dados sensíveis.
Isso é especialmente importante em multiagentes.
Em um sistema com um único agente, já existe risco de desvio de tarefa. Em um sistema com vários agentes, o desvio pode se propagar. Um agente interpreta errado, passa adiante uma informação ruim, outro agente usa aquilo como base, outro gera uma recomendação e o sistema inteiro parece coerente, mas está errado.
Esse é o perigo: erros em cadeia.
Por isso, eu não trataria Responsible AI como checklist final. Trataria como parte do desenho desde o começo.
Um padrão simples de governança
Para cada agente, eu definiria:
Missão
O que esse agente faz.
Limite
O que ele não pode fazer.
Fontes permitidas
Quais dados ele pode consultar.
Ferramentas permitidas
Quais ações ele pode executar.
Critério de escalonamento
Quando deve chamar humano.
Nível de risco
Baixo, médio ou alto.
Tipo de saída
Resumo, classificação, recomendação, relatório, ação.
Observabilidade obrigatória
O que deve ser registrado.
Isso parece simples, mas evita muitos problemas.
Um agente sem limite é um risco.
Um agente sem fonte é especulação.
Um agente sem log é caixa-preta.
Um agente sem critério de escalonamento é arrogância automatizada.
Exemplo de matriz de agentes
Para um workflow de onboarding de cliente, eu desenharia assim:
Agent: Intake Agent
Role: Understand initial request and collect missing information.
Risk: Low
Tools: form_reader, customer_profile_lookup
Human review: No
Agent: Document Analysis Agent
Role: Analyze submitted documents and extract relevant fields.
Risk: Medium
Tools: document_search, extraction_service
Human review: Required if confidence is low
Agent: Compliance Agent
Role: Check policy alignment and flag risk indicators.
Risk: High
Tools: policy_search, risk_rules
Human review: Always required for high-risk findings
Agent: Summary Agent
Role: Generate final onboarding summary.
Risk: Medium
Tools: none
Human review: Required before final approvalEsse tipo de matriz transforma multiagente em arquitetura governável.
O erro mais comum: criar agente especialista demais
Existe outro erro que vejo bastante: criar agentes especialistas demais, cedo demais.
Um agente para cada microtarefa. Um agente para cada departamento. Um agente para cada pergunta. Isso parece organizado, mas pode aumentar complexidade sem necessidade.
Antes de separar em múltiplos agentes, eu faria uma pergunta:
A separação reduz risco, melhora qualidade ou aumenta governança?
Se a resposta for sim, faz sentido.
Se a resposta for “porque parece mais moderno”, não faz.
Às vezes, um único agente com boas ferramentas resolve.
Às vezes, um workflow com funções tradicionais resolve.
Às vezes, três agentes são suficientes.
Raramente você precisa começar com dez.
Arquitetura boa não é a mais complexa. É a que resolve o problema com o menor nível de complexidade sustentável.
Local primeiro, cloud depois
Um ponto interessante do Agent Framework é a possibilidade de experimentar localmente e depois implantar no Azure AI Foundry com camadas de observabilidade, durabilidade e compliance.
Isso conversa muito com o fluxo real de desenvolvimento.
Eu gosto da ideia de testar localmente porque reduz fricção. O desenvolvedor consegue iterar rápido, validar papéis, ajustar instruções, simular ferramentas e experimentar padrões de orquestração.
Mas isso não pode virar desculpa para levar qualquer coisa para produção.
O caminho maduro é:
Protótipo local.
Teste controlado.
Definição de papéis.
Definição de ferramentas.
Observabilidade.
Avaliação.
Deploy em ambiente controlado.
Monitoramento.
Expansão gradual.
Pular essas etapas é como colocar um estagiário com acesso root porque ele respondeu bem em uma conversa.
Multiagente e varejo: um exemplo aplicado
Como eu trabalho muito com tecnologia aplicada a negócio, gosto de pensar em cenários concretos.
Imagine uma operação de varejo com múltiplas lojas e canais digitais. Um sistema multiagente poderia ajudar a analisar campanhas, produtos e operação.
Agente de dados comerciais
Consulta vendas, estoque e margem.
Agente de marketing
Analisa campanhas, calendário, criativos e canais.
Agente de atendimento
Resume dúvidas e reclamações recorrentes.
Agente de recomendação
Sugere ações comerciais com base nos dados.
Workflow de aprovação
Envia sugestões para gestores antes de qualquer execução.
Esse tipo de arquitetura pode gerar valor real, mas só se houver governança.
O agente de marketing não deve acessar todos os dados financeiros.
O agente de recomendação não deve alterar campanha sozinho.
O agente de dados não deve expor informação sensível.
O workflow precisa registrar a decisão humana.
Sem isso, o sistema vira uma mistura perigosa de automação e improviso.
A pergunta sobre autonomia
Quando falamos de agentes, sempre aparece uma pergunta: quanto de autonomia devemos dar?
Minha resposta é: autonomia deve ser proporcional à reversibilidade da ação.
Se a ação é apenas sugerir, a autonomia pode ser maior.
Se a ação é consultar dado público, risco menor.
Se a ação é consultar dado interno sensível, risco médio ou alto.
Se a ação executa mudança em sistema, risco alto.
Se a ação tem impacto financeiro, jurídico ou reputacional, precisa de aprovação humana.
Essa regra simples ajuda muito.
O problema não é agente autônomo. O problema é autonomia sem fronteira.
Como testar um sistema multiagente
Testar multiagente exige mais do que testar resposta final.
Eu testaria:
Se cada agente cumpre seu papel.
Se um agente invade responsabilidade do outro.
Se o workflow segue ordem correta.
Se o sistema para quando deve parar.
Se erro em uma etapa é tratado.
Se informações sensíveis são protegidas.
Se chamada de ferramenta é registrada.
Se o sistema pede aprovação humana nos casos corretos.
Se a resposta final mostra incerteza quando necessário.
E criaria casos de teste com:
Pergunta ambígua.
Dado faltante.
Dado conflitante.
Tentativa de prompt injection.
Solicitação fora de escopo.
Erro de ferramenta.
Timeout.
Ação sensível.
Baixa confiança.
Sem testes desse tipo, o sistema pode parecer bom até encontrar o primeiro usuário real.
O que eu faria antes de produção
Antes de colocar um sistema multiagente em produção, eu exigiria:
Mapa de agentes.
Mapa de ferramentas.
Fluxo de workflow.
Política de acesso.
Critérios de escalonamento humano.
Logs mínimos.
Teste de prompt injection.
Teste de falha de ferramenta.
Avaliação de qualidade.
Revisão de segurança.
Dono do processo.
Plano de rollback.
Isso é o mínimo para começar a falar sério.
Multiagente não pode ser tratado como brinquedo de laboratório quando toca processo de negócio.
Minha leitura sobre outubro de 2025
Outubro de 2025 marcou uma mudança importante porque a Microsoft começou a organizar a história de agentes em uma camada mais madura de desenvolvimento.
O Microsoft Agent Framework em public preview não é apenas mais um SDK. Ele representa a tentativa de unificar aprendizados de AutoGen e Semantic Kernel em uma base mais consistente para criar sistemas agentic. Junto com isso, o Azure AI Foundry reforçou workflows, observabilidade multiagente, integração com OpenTelemetry, Responsible AI e padrões de interoperabilidade como OpenAPI, MCP e A2A.
A leitura que faço é simples: a Microsoft entendeu que o próximo gargalo da IA corporativa não será apenas o modelo. Será a capacidade de orquestrar agentes com segurança, controle e rastreabilidade.
E esse é exatamente o ponto onde muitas empresas vão errar.
Conclusão
O Microsoft Agent Framework chega em um momento em que o mercado está encantado com agentes, mas ainda aprendendo a lidar com a complexidade dos sistemas multiagentes.
Criar um agente é relativamente simples. Criar vários agentes trabalhando juntos, com estado, ferramentas, observabilidade, governança e responsabilidade, é outra história.
Por isso, a pergunta certa não é “quantos agentes eu consigo criar?”. A pergunta certa é: “qual arquitetura eu preciso para que esses agentes resolvam um problema real sem virar risco?”
Multiagente pode ser poderoso.
Mas poder sem desenho vira caos.
E caos com IA parece inteligente até causar problema.
Minha recomendação é começar pequeno, separar responsabilidades, usar workflow onde houver processo, limitar ferramentas, observar tudo, exigir revisão humana nos pontos críticos e tratar cada agente como componente de software.
Porque, no fim, agente não é mágica. Agente é arquitetura com modelo dentro.
E arquitetura boa continua sendo a diferença entre uma demo impressionante e uma solução que aguenta produção.
Referências técnicas usadas como base: anúncio oficial da Microsoft sobre o Microsoft Agent Framework em public preview, novas capacidades do Azure AI Foundry para multiagentes, workflows, observabilidade com OpenTelemetry, Responsible AI e integração com OpenAPI, MCP e A2A
Seja o primeiro a comentar