🔀 Multi-Agentes e Orquestração

A justificativa técnica para dividir um problema complexo entre múltiplos agentes especializados em vez de um agente generalista.

Entender quando multi-agente compensa (versus quando complica desnecessariamente) é a decisão mais importante de arquitetura que você vai tomar.

Especialização de domínio · Execução paralela de tarefas independentes · Resiliência por redundância · Separação de responsabilidades

Um orquestrador central recebe o objetivo, planeja, e delega subtarefas para sub-agentes especializados. Toda comunicação passa pelo orquestrador.

É o padrão mais comum e mais fácil de auditar — governança clara, logs centralizados, controle de custo em um ponto.

Orquestrador como single source of truth · Bottleneck no orquestrador · Single point of failure · Fan-out controlado

Agentes se comunicam diretamente entre si via protocolo padronizado, sem um orquestrador central obrigatório. Cada agente pode iniciar comunicação com outro.

Elimina o bottleneck hierárquico e aumenta resiliência — se um agente cai, os outros continuam operando. Base do protocolo A2A.

Discovery de agentes · Protocolo de comunicação padronizado · Complexidade de coordenação distribuída · Difícil de auditar

Agente A processa → entrega para Agente B → que processa → entrega para Agente C. Fluxo linear onde cada etapa transforma o dado anterior.

Ideal para transformações sequenciais previsíveis. Fácil de debugar (você sabe exatamente onde a falha ocorreu). Adotado por ETL agentic e processamento de documentos.

Transformação sequencial · Dado imutável entre etapas · Falha em cascata · Checkpoint entre etapas · Ideal para processamento de documentos

Múltiplos agentes executam simultaneamente sobre partes diferentes do problema. Os resultados são combinados (fan-in) pelo coordenador ao final.

Reduz latência dramaticamente. Analisar 10 documentos em 1 min (paralelo) vs. 10 min (sequencial). Crítico para sistemas de alta performance.

Fan-out pattern · Fan-in e combinação de resultados · asyncio.gather() · Custo 10x maior · Timeout de resultado parcial

Framework de decisão para escolher entre hierárquica, P2P, pipeline e paralela com base em critérios mensuráveis do seu problema.

Escolher errado custa caro. Hierárquica onde deveria ser paralela = latência desnecessária. Paralela onde deveria ser pipeline = custo desnecessário.

Critérios: latência · custo · governança · tolerância a falhas · complexidade de coordenação · tamanho da equipe que vai manter

Sistema responsável por coordenar agentes — não apenas chamar funções, mas gerenciar estado, tratar falhas, manter o objetivo em foco ao longo de toda a execução.

Confundir orquestrador com "agente que chama outros agentes" leva a sistemas frágeis. O orquestrador é um componente de infraestrutura, não de lógica de negócio.

Estado persistente · Tratamento de falhas · Manutenção de objetivo · Controle de custo · Logs centralizados · Diferença de agente para orquestrador

Como banco de dados é infraestrutura (você não pensa nele enquanto funciona, entra em pânico quando falha), o orquestrador é infraestrutura para sistemas multi-agente.

Infraestrutura exige investimento em confiabilidade, monitoramento e recovery que código de aplicação não exige. Essa mentalidade muda como você o projeta.

Alta disponibilidade · Recovery automático · Monitoramento proativo · SLA de latência · Capacidade de escala · Custo de operação

Lista completa das responsabilidades: planeja decomposição de tarefas, roteia para agentes corretos, monitora estado, detecta falhas, replanneja, controla custo, mantém logs.

Cada responsabilidade que você não implementa é um ponto de falha silencioso que vai aparecer em produção no pior momento possível.

Planejamento · Roteamento dinâmico · Monitoramento de estado · Detecção de desvio · Replanejamento · Budget control · Audit trail

As decisões arquiteturais fundamentais ao projetar um orquestrador: monolítico vs. distribuído, síncrono vs. assíncrono, stateful vs. stateless.

Cada decisão tem trade-offs diretos em custo de operação, complexidade de debug e capacidade de escala. Escolher sem critério é apostar.

Monolítico: simples de operar, não escala horizontalmente · Distribuído: escala, mas complexo · Stateful: recovery fácil · Stateless: escala fácil

O ponto em que um orquestrador ganha features suficientes (logs + permissões + custo + coordenação + UI) para se tornar um produto enterprise standalone.

Entender esse threshold ajuda a decidir: construir internamente ou comprar um produto de orquestração (LangGraph Cloud, CrewAI Enterprise, etc.).

Features que cruzam o threshold: RBAC · audit trail · cost dashboard · multi-tenant · SLA garantido · suporte empresarial

Panorama dos produtos de orquestração em 2026: LangGraph, CrewAI Enterprise, Azure AI Studio, OpenAI Enterprise Controls — todos têm camada de orquestração.

Saber o que existe evita reinventar a roda. Mas poucos produtos expõem o orquestrador como produto transparente — saber a diferença economiza meses de trabalho.

LangGraph: stateful workflows · CrewAI Enterprise: RBAC + audit · Azure AI Studio: integração Microsoft · OpenAI Controls: budget + permissions

BMad (Breakdown-Manage-Delegate) é um método de raciocínio para decompor objetivos complexos em tarefas executáveis por agentes, com dependências e prioridades explícitas.

Sem um método de decomposição, agentes recebem tarefas vagas e falham ou produzem resultados inconsistentes. BMad torna a decomposição repetível e auditável.

Decomposição sistemática · Dependências entre tarefas · Critérios de sucesso por tarefa · Rastreabilidade do objetivo ao resultado

Recebe o objetivo → identifica subproblemas → cria lista de tarefas com dependências → prioriza por criticidade. Saída: TaskList com grafo de dependências.

Uma decomposição ruim propaga erro por todas as fases seguintes. Tarefas mal definidas garantem resultados mal definidos.

Granularidade de tarefa · Grafo de dependências (DAG) · Critério MECE (Mutually Exclusive, Collectively Exhaustive) · Prioridade por impacto

Organiza as tarefas em árvore de execução, define quais são paralelas (independentes) vs. sequenciais (dependentes), estima custo de tokens de cada uma.

A organização define latência e custo total. Executar paralelamente o que poderia ser paralelo reduz tempo de 10x para 1x. Sequenciar o que precisa ser sequencial evita dados inconsistentes.

Árvore vs. grafo de execução · Identificação de caminhos críticos · Estimativa de custo por tarefa · Budget total da execução

Atribui cada tarefa ao agente mais adequado (por habilidade, custo, disponibilidade), passa o contexto necessário e define o critério de sucesso por tarefa.

Delegar a tarefa errada para o agente errado é o desperdício mais caro: você paga pelo processamento E pelo resultado inútil.

Matching agente-tarefa · Context injection mínimo · Critério de aceitação por tarefa · Timeout por agente · Callback de resultado

Implementação prática: classe TaskTree, Task com campo dependencies, executor que respeita a ordem do grafo, monitor de progresso com callbacks.

Ver o código transforma o método de teoria para implementação real. Você vai reconhecer o padrão em LangGraph, CrewAI e outras ferramentas.

TaskTree como DAG · Topological sort para execução · Status tracking: pending → running → done/failed · Progress callbacks

"Analisar concorrência e gerar relatório" → Breakdown em 8 tarefas → Manage com 3 paralelas + 5 sequenciais → Delegate para pesquisador, analista e redator.

Exemplos concretos fixam o método. Você vai ver exatamente como as 3 fases se conectam em um caso que qualquer empresa poderia usar amanhã.

Decomposição real de problema de negócio · Identificação de paralelismo · Seleção de agentes por especialidade · Custo estimado vs. custo de humano

A lógica por trás de usar agentes com escopo restrito: menor contexto necessário, menor custo de tokens, menor chance de hallucination, mais fácil de avaliar qualidade.

Um agente generalista que faz tudo é caro e impreciso. Especialização é a diferença entre custo de $50 e $5 para o mesmo resultado.

Context window mínimo · Prompt especializado por domínio · Avaliação de qualidade por critérios específicos · Modelo menor = custo menor

Agente que recebe objetivo complexo e produz plano estruturado (lista de tarefas com dependências, agentes necessários, critérios de sucesso). Usa modelo maior e mais caro.

Um plano ruim contamina toda a execução. Investir num modelo melhor no planejamento economiza 10x nos tokens de execução desperdiçados.

Output estruturado (JSON) · Identificação de agentes necessários · Estimativa de custo · Critérios de sucesso verificáveis

Recebe tarefa específica e bem definida, executa usando suas ferramentas (APIs, banco de dados, código), retorna resultado estruturado. Pode usar modelo menor e mais barato.

É o agente que mais executa e mais consome tokens. Otimizar o executor (modelo, prompt, ferramentas) é onde você controla o maior custo do sistema.

Input schema estrito · Tool selection · Output schema com flag de confiança · Max_iterations para evitar loop infinito · Custo por execução

Recebe resultado do executor, avalia qualidade contra critérios definidos pelo planejador, aprova (passa adiante) ou rejeita com feedback estruturado para o executor tentar novamente.

Sem revisor, você entrega resultados de qualidade variável ao usuário final. O revisor é o controle de qualidade automático do sistema.

Rubrica de avaliação · Feedback estruturado · Aprovação com score · Max_revision_cycles · Escalada para humano quando necessário

Registra todas as ações de todos os agentes, verifica compliance com políticas, gera audit trail imutável, alerta quando detecta anomalias ou violações.

Em ambiente enterprise, sem audit trail você não consegue explicar o que aconteceu, não passa auditoria e não cumpre regulamentações como SOC2, LGPD, HIPAA.

Append-only log · Hash de integridade · Alertas em tempo real · Relatório de compliance · Retenção de dados por regulamentação

Definição formal de interfaces entre agentes: input schema (o que aceita), output schema (o que retorna), SLA de tempo, custo máximo permitido, comportamento em falha.

Contratos explícitos permitem trocar um agente por outro sem quebrar o sistema. Sem contratos, você tem acoplamento rígido disfarçado de flexibilidade.

Interface-first design · Pydantic schemas · SLA como contrato de tempo · Budget por agente · Compatibilidade de versão de schema

O desafio central de sistemas multi-agente: quando múltiplos agentes precisam ler e escrever no mesmo estado compartilhado, surgem race conditions, inconsistências e dados corrompidos.

Estado corrompido em produção é o bug mais difícil de debugar e o mais perigoso. Entender o problema antes de escolher a solução evita dias de dor.

Race condition · Dirty read · Lost update · Stale data · CAP theorem aplicado a agentes

Usar Redis como blackboard (quadro negro) compartilhado onde todos os agentes leem e escrevem. Locks distribuídos (Redlock) evitam conflitos de escrita simultânea.

Redis é a solução padrão de mercado para estado distribuído de alta performance. Redlock resolve conflitos sem complexidade de bancos distribuídos.

Redis como shared memory · Redlock para mutual exclusion · TTL para dados temporários · Pub/Sub para notificações · Pipeline para operações atômicas

Cada agente mantém seu próprio estado isolado. Ao finalizar, entrega resultado para o coordenador que combina todos os estados parciais no estado final.

Mais simples, menos conflitos, mais fácil de debugar. Para tarefas onde agentes não precisam compartilhar estado durante execução, é a escolha óbvia.

Immutable local state · Resultado como output imutável · Merge function no coordenador · Sem lock necessário · Mais simples de testar

Quando dois agentes atualizam o mesmo campo simultaneamente, você precisa de uma estratégia: last-write-wins (simples, perde dados), merge (combina, complexo), ou manual (humano decide).

A estratégia de resolução de conflito define a integridade dos dados do seu sistema. Escolher last-write-wins pode fazer você perder resultados de horas de processamento.

Last-write-wins (LWW) · Three-way merge · Operational transform · Conflict-free Replicated Data Types (CRDTs) · Human-in-the-loop para conflitos críticos

Em vez de sobrescrever estado, adicionar cada mudança a um log imutável. Você pode ver toda a história do estado, fazer rollback para qualquer ponto e auditar mudanças.

Quando o sistema produz resultado inesperado às 3h da manhã, um log de estado versionado é a diferença entre debug em 10 minutos e debug em 10 horas.

Event sourcing · Append-only log · State reconstruction · Temporal queries · Snapshot + log para performance

Problemas reais de produção: estado cresce indefinidamente sem TTL, backups falham silenciosamente, recovery após falha perde horas de trabalho de agentes.

Estado mal gerenciado em produção é lento (cresceu demais), caro (armazenamento) ou inconsistente (falha de recovery). Esses problemas aparecem meses depois do lançamento.

TTL strategy · Compaction de log antigo · Backup incremental · Recovery point objective (RPO) · Recovery time objective (RTO)

Transferência formal de controle E contexto de um agente para outro, com garantia de que o estado está consistente antes da transferência e confirmação de recebimento.

Handoff informal (agente A termina, agente B começa) é a principal fonte de perda de contexto e dados em sistemas multi-agente. Formalizar garante continuidade.

Handoff packet (dados transferidos) · Confirmação de recebimento · Estado consistente antes da transferência · Log de handoff · Rollback se destino não confirma

Quatro estratégias de roteamento: por conteúdo (tipo de tarefa), por carga (agente menos ocupado), por habilidade (agente mais adequado para o domínio), por custo (agente mais barato).

Roteamento incorreto é eficiência desperdiçada. Enviar análise jurídica para agente de código, ou tarefa simples para o modelo mais caro, são erros evitáveis com bom roteamento.

Content-based routing · Load balancing · Skill-based routing · Cost-aware routing · Combinação de critérios com pesos

Um LLM leve (classificador) analisa o input e decide qual agente deve receber a tarefa. Alternativa: regras determinísticas baseadas em palavras-chave ou tipo de dado.

Roteamento com LLM é flexível mas adiciona latência e custo. Regras determinísticas são rápidas mas rígidas. Saber quando usar cada abordagem é uma habilidade de arquitetura.

Classifier prompt · Few-shot examples para classificação · Confidence threshold · Fallback para humano quando confiança baixa · Latência de roteamento

O que acontece quando o agente destino falha após receber o handoff? Protocolo de rollback: o controle retorna ao agente origem ou é transferido para um terceiro agente de fallback.

Sem rollback definido, uma falha de handoff deixa a tarefa em estado indefinido — nem no agente origem, nem no destino. Isso trava o sistema silenciosamente.

Two-phase commit para handoff · Timeout de confirmação · Rollback automático · Log de handoff pendente · Cleanup de estado parcial

Técnicas para passar contexto relevante de um agente para outro sem incluir tudo (o que explodiria a context window e o custo): sumarização, extração de entidades, compressão semântica.

Passar contexto demais é caro. Passar de menos leva a erros. Dominar essa técnica é o que separa sistemas multi-agente eficientes dos caros.

Context summarization · Entity extraction · Relevance filtering · Hierarchical context (full + summary) · Context versioning

Quatro padrões: sequential (A→B→C), conditional (se X→B, se Y→C), parallel (A→B e C simultaneamente), dynamic (A decide em runtime para qual agente ir).

Cada padrão resolve uma classe de problema diferente. Conhecer todos permite escolher o mais simples que resolve seu caso — simplicidade é confiabilidade.

Sequential: previsível e auditável · Conditional: flexível com risco de lógica complexa · Parallel: rápido mas custoso · Dynamic: máxima flexibilidade com complexidade máxima

Executar múltiplos agentes simultaneamente quando as tarefas são independentes entre si. 10 documentos em paralelo = 1 min. 10 documentos em série = 10 min.

Latência define experiência de usuário e competitividade. Sistemas que executam tarefas independentes em série são 10x mais lentos do que precisam ser.

Independência de tarefas (pré-condição) · Speedup de Amdahl's Law · Identificação do caminho crítico · Quando paralelismo compensa o overhead

Um input é distribuído para múltiplos agentes que executam simultaneamente, cada um com sua subtarefa. O orquestrador aguarda todos completarem.

Fan-out é o padrão que transforma análise sequencial em análise simultânea. É a base de qualquer sistema que precisa escalar para grandes volumes.

Particionamento de input · Distribuição uniforme de carga · Controle de concorrência máxima · Rate limiting da API · Semáforo para limitar paralelismo

Múltiplos resultados de agentes paralelos são combinados em um resultado único. Estratégias: merge (concatena), vote (maioria), summarize (sumariza), aggregate (calcula).

A qualidade do fan-in determina a qualidade do resultado final. Combinar resultados de forma ingênua produz resultados inconsistentes apesar de análise paralela de qualidade.

Merge strategy: concatenação, votação, sumarização · Conflito de resultados · Peso por confiança do agente · Resultado parcial quando um agente falha

Implementação Python: asyncio.gather() para executar múltiplos agentes coroutines em paralelo, TaskGroup para melhor controle, tratamento de exceções em contexto assíncrono.

asyncio é o padrão Python para paralelismo de I/O (que é exatamente o que chamadas LLM são). Sem asyncio, você está deixando performance na mesa.

asyncio.gather() com return_exceptions · asyncio.TaskGroup (Python 3.11+) · Semáforo para limitar concorrência · Exception handling assíncrono

O que acontece quando um de 10 agentes paralelos demora 5x mais? asyncio.wait_for() para timeout, cancelamento de tarefas lentas, retorno de resultado parcial sem o agente que atrasou.

Sem timeout, um agente lento bloqueia todo o sistema. Com timeout agressivo demais, você perde resultados válidos. Calibrar timeout é uma habilidade de engenharia de sistemas.

asyncio.wait_for() · asyncio.wait(return_when=FIRST_EXCEPTION) · Partial result strategy · P95 latency como base para timeout · Retry após timeout

A matemática do paralelismo: 10 agentes em paralelo custam aproximadamente 10x mais em tokens, mas entregam em 1/10 do tempo. Como otimizar: batching, modelo menor para subtarefas simples.

Paralelismo sem controle de custo é como contratar 10 consultores sênior quando 8 juniors e 2 sêniors fazem o mesmo trabalho por menos. A arquitetura define o custo operacional.

Cost per parallel task · Batching para reduzir overhead · Modelo tier (cheap para análise simples, caro para síntese) · Budget máximo por execução paralela

Classificação das falhas específicas de agentes: LLM retorna formato inválido, tool call falha, loop infinito de reasoning, context window overflow, custo estoura o budget, agente "trava".

Cada tipo de falha exige uma resposta diferente. Tratar loop infinito igual a formato inválido produz sistemas que "mascaram" erros em vez de resolvê-los.

Formato inválido → retry com instrução · Loop → max_iterations · Context overflow → summarize · Budget → checkpoint + escalada · Tool failure → fallback tool

Para falhas transitórias (timeout de API, rate limit, erro 500), espera exponencialmente antes de tentar de novo: 1s, 2s, 4s, 8s... com jitter para evitar thundering herd.

Rate limits são a causa mais comum de falha em sistemas com muitos agentes paralelos. Retry sem backoff agrava o rate limit. Com backoff, você resolve automaticamente.

Exponential backoff: 2^n segundos · Jitter aleatório · max_retries (3-5) · Erro retryable vs. não-retryable · tenacity library Python

Quando o agente A falha além de max_retries: tentar agente B com abordagem diferente (outro modelo, outro prompt, outra ferramenta), ou retornar resultado parcial com flag de incerteza.

Sistemas sem fallback viram sistemas que falham completamente. Com fallback, você degrada graciosamente — entrega resultado inferior mas entrega. Isso é a diferença entre 99.9% e 95% de uptime.

Fallback chain: A → B → C → resultado parcial · Modelo de fallback (mais caro, mais capaz) · Partial result com confidence score · Graceful degradation

Padrão que "abre o circuito" quando um serviço falha N vezes em sequência, parando temporariamente de chamá-lo. Testa periodicamente se recuperou, fecha o circuito quando OK.

Sem circuit breaker, você continua tentando chamar um serviço morto, desperdiçando tokens e aumentando latência. Com ele, você detecta falha sistêmica e para de desperdiçar recursos.

Estados: Closed → Open → Half-Open · Threshold de falhas para abrir · Timeout para tentar fechar · pybreaker library · Monitoramento de estado do circuito

Definir critérios para escalar ao humano: custo acima do limite, ação irreversível (deletar dados, fazer pagamento), confiança baixa no resultado, falha após todos os fallbacks.

Sistemas que nunca escalam para humano eventualmente cometem erros irreversíveis. Sistemas que escalam muito nunca ganham autonomia real. Calibrar o threshold é arte e ciência.

Escalation triggers: custo · irreversibilidade · confiança · deadline · Aprovação humana como checkpoint · Timeout de aprovação · Notificação por canal (Slack, email)

Como retomar execução após falha sem repetir tudo: checkpointing de estado após cada etapa significativa, replay a partir do último checkpoint estável, skip de etapas já concluídas.

Se um sistema de 50 etapas falha na etapa 48 e recomeça do zero, você perde $40 em tokens toda vez que falha. Checkpointing transforma falha de catástrofe em inconveniência.

Checkpoint após cada etapa · Idempotência das etapas · Replay from checkpoint · Skip de etapas completed · Garbage collection de checkpoints antigos

Replanejamento é quando o sistema detecta que o plano atual não está funcionando e cria um novo plano. Diferente de retry (tenta o mesmo de novo com a esperança de resultado diferente).

Sem replanejamento, agentes ficam presos em loops tentando o mesmo plano falho indefinidamente. Replanning é o que transforma um agente frágil em um sistema adaptativo.

Retry: mesmo plano, tenta de novo · Replanning: novo plano, nova estratégia · Trigger: N falhas do mesmo plano · Custo: novo LLM call para planejar

Métricas que indicam que o plano não está progredindo: N iterações sem mudança de estado, custo acima do threshold, critério de sucesso não aproximando, mesmo erro repetindo.

Detecção precoce de desvio economiza tokens. Um agente que demora 100 iterações para detectar que está perdido desperdiçou 90 iterações de tokens.

Progress metric: distância do objetivo · Stagnation: N iterações sem progresso · Cost threshold: budget consumido · Error pattern: mesmo erro N vezes

Quando acionar replanning: automático por métricas (mais comum), ou manual por humano (para casos críticos). Custo: replanning exige um novo LLM call para criar o plano. Risco: replanning em loop.

Replanning automático sem limite vira loop infinito de planejamento. Com limite bem calibrado, você tem sistema adaptativo sem risco de loop.

Trigger automático por métricas · Trigger manual por flag humano · Custo: modelo caro para replanning · max_replanning_cycles · Log de todos os planos tentados

Três estratégias: replanning total (novo plano do zero, descarta o atual), replanning parcial (ajusta só a parte problemática, mantém o que funcionou), escalada de modelo (usa modelo mais capaz).

Replanning total descarta trabalho que funcionou. Parcial é mais eficiente mas mais complexo de implementar. Escolher a estratégia errada desperdiça tokens ou não resolve o problema.

Full replanning: mais simples, perde contexto · Partial: preserva progresso, mais complexo · Model escalation: claude-opus-4 no lugar de haiku quando haiku falhou

Máximo de N replanejamentos (tipicamente 3) antes de escalar para humano. Sem esse limite, o sistema pode entrar em loop de replanejamento consumindo tokens indefinidamente.

Sistemas sem limite de replanning já causaram contas de $10.000+ em APIs de LLM em incidentes reais. O limite é o último mecanismo de proteção contra custo descontrolado.

max_replanning: 2-3 ciclos · Escalada automática ao humano após limite · Log de todos os planos tentados para debug · Alert quando se aproxima do limite

Dois casos: agente de pesquisa que não encontra informação após 3 buscas → replanning muda a query strategy. Agente de código que falha no teste 5x → replanning muda abordagem de implementação.

Exemplos concretos mostram quando replanning funciona e quando a falha é fundamental (o objetivo é impossível). Essa distinção evita replanning infinito de objetivos inatingíveis.

Diagnóstico da falha antes de replanning · Mudança real de estratégia (não variação mínima) · Aprendizado: o novo plano usa contexto das falhas anteriores

MCP conecta agente a ferramentas (banco, API, arquivo). A2A resolve o problema diferente: como dois agentes em sistemas distintos se comunicam de forma padronizada e descobrível.

Sem A2A, cada integração agente-agente é custom. Com A2A, você implementa uma vez e qualquer agente compatível pode se comunicar com o seu.

MCP: agente ↔ ferramenta · A2A: agente ↔ agente · Problema: integração N×M sem padrão · Solução: protocolo de descoberta e comunicação padronizado

Cada agente expõe uma interface padronizada: Agent Card (quem sou), Skill List (o que faço), Task Protocol (como recebo e processo tarefas). Qualquer agente pode descobrir e chamar outro.

É a arquitetura que permite "marketplace de agentes" — você pode comprar um agente especializado de um fornecedor e ele funciona no seu sistema sem integração custom.

Agent Card: JSON com identidade e capacidades · Skill registry: lista de skills com input/output schema · Task protocol: como enviar, receber e cancelar tarefas

Arquivo JSON que descreve o agente: nome, versão, capacidades, skills disponíveis com schemas, protocolo de comunicação suportado, autenticação necessária, limites (rate limit, custo).

O Agent Card é o que permite descoberta automática. Um orquestrador pode ler o Card e saber exatamente como usar o agente sem documentação adicional.

JSON schema · Skills com input/output type · Autenticação (API key, OAuth) · Rate limits declarados · Versioning do protocolo · URL de endpoint

Como enviar uma tarefa (task.send com payload), como receber atualizações de progresso (task.subscribe via streaming), como cancelar uma tarefa em andamento (task.cancel com cleanup).

O task protocol define como sistemas interagem. Implementar corretamente garante que seu agente é um cidadão de primeira classe no ecossistema A2A.

task.send: idempotent com task_id · task.subscribe: SSE ou WebSocket para streaming · task.cancel: cleanup garantido · task.status: polling alternativo

Exemplo completo: Agente A lê Agent Card de Agente B, verifica compatibilidade, envia task, monitora progresso via streaming, recebe resultado e trata erros.

Ver o código completo do fluxo A2A desmistifica o protocolo e mostra que a implementação é mais simples do que parece para casos básicos.

httpx para requests async · SSE client para streaming · Pydantic para validação de Agent Card · Error handling: task failed vs. network error

Tabela comparativa: chamada direta (simples, acoplado), MCP (agente ↔ ferramenta, padrão Anthropic), A2A (agente ↔ agente, interoperabilidade). Quando usar cada um e por quê.

Usar A2A onde deveria usar chamada direta é over-engineering. Usar chamada direta onde deveria usar A2A é acoplamento que vai custar caro quando o outro agente mudar.

Chamada direta: mesmo sistema, custo zero · MCP: ferramentas externas, padrão estabelecido · A2A: agentes externos, interoperabilidade máxima · Futuro: A2A como HTTP dos agentes