Um agente é problema de engenharia. Doze é problema de coordenação.

A Terça de Manhã Quando Três Agents Brigaram

Numa terça de janeiro de 2026, três agents da Apollo Space tentaram contatar o mesmo prospect dentro de uma janela de 90 minutos.

O agent SDR tinha agendado um email de follow-up para 9:15, parte de uma sequência de nurture que estava rodando há duas semanas. O agent de deal intelligence tinha detectado que a empresa do prospect acabava de anunciar uma nova rodada de funding e queria enviar uma nota de parabéns referenciando a notícia. O agent de competitor watch tinha flaggado que o fornecedor atual do prospect anunciou um aumento de preço, e queria disparar um email de reposicionamento.

Três agents. Três emails. Um prospect. Mesma manhã.

Qualquer um desses emails teria sido apropriado. Todos os três, enviados dentro de 90 minutos, teriam sido um desastre, o tipo de comunicação excessiva e spammy que transforma um prospect aquecido num remetente bloqueado.

Esse é o problema de orquestração. Não “como você constrói agents” mas “como você impede agents de se atropelarem.” E é o problema de que ninguém fala no ciclo de hype de agents, porque as demos sempre mostram um agent fazendo uma coisa, e a complexidade da coordenação multi-agent é invisível até você realmente rodar múltiplos agents em produção.

Construir um agent é um problema de engenharia. Orquestrar doze é um problema de design de sistemas, um problema de teoria dos jogos, e às vezes um problema de ciência política. A camada de orquestração é a peça mais difícil da Apollo Space de construir, a mais frágil de manter e a mais invisível para os usuários. Quando funciona, ninguém percebe. Quando falha, tudo desmorona.

Por Que Agents Entram em Conflito

Conflitos entre agents não são bugs. São propriedades emergentes de um sistema onde múltiplos atores autônomos operam em estado compartilhado com objetivos parcialmente sobrepostos.

Os doze agents da Apollo Space entram em conflito por três razões:

1. Contenção de Recursos

Múltiplos agents querem usar o mesmo recurso ao mesmo tempo. O conflito de recurso mais comum é atenção, múltiplos agents querem contatar a mesma pessoa ou postar no mesmo canal. Mas recursos também incluem computação (rodar análises caras), APIs externas (rate limits) e bandwidth de revisão humana (só tantas decisões podem ser escaladas para humanos antes de ficarem sobrecarregados).

O incidente de terça de manhã foi um conflito de recursos: três agents competindo pela atenção do mesmo prospect.

2. Contradição de Recomendação

Dois agents olham a mesma situação e chegam a conclusões opostas. O modelo do agent SDR diz para pressionar por reunião esta semana. O agent de deal intelligence diz que a agenda do prospect está lotada (baseado em sinais públicos de disponibilidade) e recomenda esperar até semana que vem. Ambos os agents estão raciocinando a partir de dados válidos. Apenas ponderam os fatores diferentemente.

Isso acontece mais frequentemente do que você esperaria. Em dezembro de 2025, registramos 23 contradições de recomendação entre todos os pares de agents. O par mais comum era SDR + deal intelligence (11 contradições), seguido por competitor watch + SDR (7 contradições). Os agents de QA e code review quase nunca entram em conflito porque seus domínios são claramente separados.

3. Interferência de Efeito Colateral

Uma ação de um agent muda o estado do qual outro agent depende. O agent de conteúdo publica um blog post que referencia um concorrente pelo nome. O agent de competitor watch, que monitora menções à nossa empresa em canais de concorrentes, agora precisa considerar que qualquer resposta do concorrente pode ser acionada pelo nosso conteúdo em vez de ser um sinal orgânico.

Interferência de efeito colateral é a forma mais sutil de conflito e a mais difícil de detectar. Não se manifesta como dois agents tentando fazer a mesma coisa, se manifesta como o ambiente de um agent sendo alterado pelas ações de outro agent de formas que afetam a qualidade da decisão.

A Camada de Orquestração

A camada de orquestração da Apollo Space fica entre os agents e o mundo exterior. Nenhum agent age diretamente, cada proposta de ação passa pelo orquestrador, que aplica quatro mecanismos: resolução de prioridade, detecção de conflito, protocolos de consenso e escalação humana.

Resolução de Prioridade

Cada proposta de ação tem um score de prioridade. O score é calculado a partir de três componentes:

Prioridade base: Cada agent tem um nível de prioridade estático que reflete a criticidade do seu domínio. O agent de observabilidade tem a maior prioridade base (saúde do sistema é sempre urgente). O agent de conteúdo tem a menor (conteúdo quase sempre pode esperar).

Agent	Prioridade Base
Observabilidade	95
QA	85
Monitor de Orçamento	80
Deal Intelligence	75
SDR	70
Competitor Watch	70
Code Review	65
Saúde Pós-Venda	65
Team Intelligence	60
Meeting Digest	55
Conteúdo	50
Agents Customizados	Variável

Modificador de urgência: Ações sensíveis ao tempo recebem boost. Um email que precisa sair antes de uma reunião em 2 horas recebe +20 de urgência. Um relatório semanal que pode esperar até amanhã recebe +0. Urgência é calculada baseada em tempo-até-deadline e taxa de decaimento (quão rapidamente o valor da ação diminui com atraso).

Modificador de impacto: Ações de alto impacto recebem boost. Uma ação afetando um deal de $200K recebe modificador de impacto maior que uma ação afetando um deal de $10K. Impacto é estimado a partir do valor de negócio esperado da ação, que o agent reporta como parte da sua proposta de ação.

O score composto de prioridade: prioridade_base + modificador_urgência + modificador_impacto. Quando duas ações conflitam, a de maior prioridade ganha.

Para o incidente de terça de manhã, os scores de prioridade ficaram:

• Alerta de competitor watch (email de posicionamento): 70 + 15 (sensível ao tempo, notícias de concorrente esfriam) + 18 (deal grande) = 103
• Deal intelligence (nota de parabéns): 75 + 10 (notícia de funding é atual mas não urgente) + 12 (manutenção de relacionamento) = 97
• Follow-up SDR (sequência de nurture): 70 + 5 (agendado, não urgente) + 8 (pipeline padrão) = 83

O email de competitor watch ganhou. O email de deal intelligence foi reagendado para quarta. O follow-up SDR foi empurrado para quinta. Um email por prospect por dia, o orquestrador aplica isso como restrição rígida.

Detecção de Conflito

Antes de qualquer ação executar, o orquestrador verifica conflitos com ações pendentes e recentemente executadas. O sistema de detecção de conflito mantém um grafo de estado que rastreia:

• Estados de entidade: Quais prospects foram contatados recentemente, quais canais receberam posts, quais PRs estão em revisão
• Ações pendentes: Todas as propostas de ação submetidas mas ainda não executadas
• Janelas de cooling: Tempo mínimo entre interações com a mesma entidade (ex: 24 horas entre emails para o mesmo prospect)

Detecção de conflito roda em tempo constante usando lookup baseado em hash em identificadores de entidade. Quando uma nova proposta de ação chega, o orquestrador verifica:

1. Existe uma ação pendente mirando a mesma entidade? (Contenção de recurso)
2. Existe uma ação recentemente completada que aciona um cooling? (Violação de cooling)
3. Existe uma ação pendente que contradiz esta proposta? (Contradição de recomendação)

Se qualquer verificação falha, o processo de resolução de conflito entra em ação.

O sistema de detecção de conflito pegou uma média de 31 conflitos por semana desde o deploy. A maioria (68%) são violações de cooling, agents tentando contatar a mesma pessoa com frequência demais. Cerca de 22% são contenções de recurso, múltiplos agents querendo o mesmo slot de tempo ou canal de comunicação. Os 10% restantes são contradições de recomendação.

Protocolos de Consenso

Para contradições de recomendação, casos onde dois agents discordam sobre o que fazer, o orquestrador roda um protocolo leve de consenso.

O protocolo depende das apostas:

Baixo risco (modificador de impacto < 10): O agent de maior prioridade ganha. Sem discussão, sem deliberação. Para decisões de baixo risco, velocidade é mais valiosa que consenso.

Médio risco (modificador de impacto 10-25): O orquestrador apresenta o raciocínio de ambos os agents a um desempate, tipicamente o agent Director responsável por aquele domínio (Growth Director para conflitos de vendas, Ops Director para conflitos de engenharia). O Director toma uma decisão baseada no raciocínio combinado dentro de um ciclo de decisão.

Alto risco (modificador de impacto > 25): Escalação humana. O raciocínio de ambos os agents, a recomendação do Director e o contexto relevante são empacotados numa escalação e roteados ao humano apropriado. O humano decide.

Na prática, cerca de 70% das contradições são baixo risco e auto-resolvidas por prioridade. Cerca de 25% são médio risco e resolvidas por um agent Director. Cerca de 5% são alto risco e escaladas para humanos. O objetivo é manter a taxa de escalação humana baixa o suficiente para que humanos não fiquem sobrecarregados mas alta o suficiente para que decisões genuinamente importantes recebam julgamento humano.

O protocolo de consenso adiciona latência, cerca de 2-4 segundos para resolução por Director, e minutos a horas para escalação humana. Para a maioria das ações de agents, essa latência é aceitável. Para agents em tempo real (observabilidade, QA), o protocolo tem um caminho rápido: se a ação está dentro do escopo autônomo do agent (conforme definido pela arquitetura de confiança), ela bypassa consenso inteiramente.

Escalação Humana

Escalação humana é a válvula de segurança. Quando o orquestrador não consegue resolver um conflito através de prioridade ou consenso, ou quando uma ação excede o escopo autônomo da arquitetura de confiança, ele escala para um humano.

Escalações são estruturadas, não livres. Um humano recebe:

1. A decisão: O que o agent quer fazer
2. O raciocínio: Por que o agent quer fazer (extraído do loop de decisão)
3. O conflito: Se relevante, o que o agent contraditório propôs e por quê
4. A recomendação: A resolução sugerida pelo orquestrador
5. O deadline: Quanto tempo até o valor da ação degradar (contexto de urgência)

O humano pode aprovar, modificar ou rejeitar. Sua decisão é registrada e alimentada de volta na memória episódica dos agents para que situações similares sejam tratadas melhor no futuro.

Miramos uma taxa de escalação humana de 3-5% de todas as ações de agents. Abaixo de 3%, provavelmente não estamos escalando coisas que deveriam ter olhos humanos. Acima de 5%, humanos estão gastando tempo demais revisando decisões de agents, o que derrota o propósito de ter agents.

Nossa taxa atual de escalação: 4,1%, que está bem na faixa alvo. De decisões escaladas, humanos concordam com a recomendação do orquestrador 73% das vezes. Os 27% onde humanos discordam são os dados mais valiosos que temos, revelam onde a lógica de orquestração tem gaps.

Padrões de Fallback

Agents falham. Modelos caem. APIs atingem rate limits. Recuperação de memória trava. O trabalho da camada de orquestração não é prevenir falha, é garantir degradação graciosa quando falha acontece.

A Apollo Space implementa três padrões de fallback:

1. Degradação de Capacidade

Quando um agent falha, o sistema perde uma capacidade mas continua operando. Se o agent de competitor watch cai, o agent SDR ainda envia emails, só não tem inteligência competitiva fresca. Se o agent de meeting digest falha, reuniões ainda acontecem, as pessoas só não recebem resumos automatizados.

Isso parece óbvio, mas acertar requer mapeamento cuidadoso de dependências. Alguns agents dependem um do outro. A qualidade de outreach do agent SDR é melhor quando tem inteligência competitiva. O scoring do agent de deal intelligence é mais preciso quando tem resumos de meeting digest. Essas são dependências soft, melhoram performance mas não são necessárias para operação.

Dependências hard são diferentes. Se o agent de observabilidade não consegue alcançar a API de métricas, não consegue fazer seu trabalho, não existe modo degradado. Para dependências hard, o fallback é alertar um humano que a capacidade está totalmente offline.

Mapeamos cada dependência entre agents como soft (degrade graciosamente) ou hard (falhe ruidosamente). O mapa de dependências parece assim:

Agent SDR soft-depende de: Deal Intelligence, Competitor Watch, Agent de Conteúdo Agent de QA hard-depende de: API do GitHub, Infraestrutura de Testes Competitor Watch soft-depende de: APIs de Web Scraping (pode cachear dados desatualizados por 48 horas) Observabilidade hard-depende de: API de Métricas, API de Logs

Quando uma dependência soft falha, o agent dependente continua com qualidade reduzida. Quando uma dependência hard falha, o agent dependente entra em estado suspenso e o orquestrador roteia suas responsabilidades para o handler de fallback.

2. Tolerância a Dados Desatualizados

Quando um agent não consegue dados frescos, por quanto tempo consegue operar com dados desatualizados? Isso varia por agent e por tipo de dado.

O agent de competitor watch consegue tolerar dados de preço desatualizados por cerca de 48 horas, preços não mudam por hora. Mas só tolera dados de vagas desatualizados por cerca de 7 dias antes do sinal se tornar não confiável.

O agent SDR consegue tolerar dados de CRM desatualizados por cerca de 4 horas. Além disso, há risco significativo de que o status do prospect tenha mudado (pode ter respondido numa thread separada, ou outro membro do time pode ter contatado).

Codificamos tolerância a dados desatualizados como configuração por-tipo-de-dado para cada agent. Quando a idade dos dados excede o threshold de tolerância, o agent não crasha, ele reduz seus scores de confiança para refletir a incerteza de dados desatualizados, e a arquitetura de confiança pode rotear mais decisões para revisão humana como resultado.

3. Enfileirar e Retry

Quando uma ação falha por problema transitório (timeout de API, rate limit, indisponibilidade temporária de serviço), o orquestrador enfileira a ação para retry com backoff exponencial. A política de retry é:

• Primeiro retry: 30 segundos
• Segundo retry: 2 minutos
• Terceiro retry: 10 minutos
• Após três retries: a ação é registrada como falha e o agent é notificado para replanejar

A fila de retry lida com cerca de 340 falhas transitórias por semana em todos os agents. A maioria (89%) tem sucesso no primeiro retry. Cerca de 7% tem sucesso no segundo. Os 4% restantes ou têm sucesso no terceiro ou falham permanentemente.

Falhas permanentes são escaladas ao agent que propôs a ação, que replaneja, seja escolhendo uma ação alternativa ou escalando para um humano. O orquestrador não toma decisões sobre o que fazer quando coisas falham. Ele roteia a informação de falha para a entidade que pode tomar essa decisão.

Os Bugs Mais Difíceis

Bugs de orquestração são os bugs mais difíceis que debugamos. São emergentes, intermitentes e frequentemente não reproduzíveis.

Três exemplos:

A Inversão de Prioridade: Em dezembro de 2025, o agent SDR parou de enviar emails de follow-up por uma semana. Sem erros. Sem alertas. A causa raiz: o agent de observabilidade vinha gerando uma rajada de notificações de health check de baixa prioridade que estavam enchendo a fila de ações do orquestrador. As ações do agent SDR estavam sendo enfileiradas atrás de centenas de notificações de observabilidade. O sistema de prioridade deveria ter resolvido isso, mas um bug no cálculo do modificador de urgência estava atribuindo zero urgência a follow-ups agendados (porque seu deadline era “quando o cooling expirar,” que o sistema interpretou como “sem deadline”). A correção foi duas linhas: ações agendadas agora recebem um score mínimo de urgência de 5.

O Conflito Fantasma: Em janeiro de 2026, o agent de meeting digest começou a falhar em postar resumos para cerca de 20% das reuniões. A causa: um falso positivo na detecção de conflito. O agent de conteúdo começou a publicar blog posts no mesmo canal do Slack onde meeting digests eram postados. O detector de conflito era amplo demais, tratava “qualquer post no #general” como conflito potencial com “qualquer outro post no #general” e estava aplicando janela de cooling. A correção foi estreitar o matching de entidade para distinguir entre tipos de post, não apenas destinos.

O Deadlock de Consenso: Em fevereiro de 2026, uma decisão de alto risco ficou na fila de consenso por 6 horas sem resolução. O agent SDR propôs enviar uma proposta de preços para um prospect grande. O agent de deal intelligence recomendou esperar porque o CFO do prospect estava de férias (detectado por auto-replies de out-of-office). O agent Growth Director não conseguiu resolver o empate porque ambos os argumentos eram válidos, a janela de preços estava fechando, mas enviar proposta quando o tomador de decisão estava ausente era desperdício. A confiança do Director era 51/49, que estava abaixo do nosso threshold de resolução de 60%. Deveria ter escalado para um humano, mas um bug na lógica de escalação estava verificando a confiança vencedora (51%) contra o threshold de escalação em vez da margem (2%). A correção foi direta, mas a detecção levou horas porque o sistema parecia estar “pensando”, sem erros, sem timeouts, apenas uma decisão pendente.

Esses bugs compartilham uma propriedade comum: não se manifestam como falhas tradicionais de software. O sistema está rodando. Os agents estão saudáveis. As métricas estão verdes. Mas a coordenação está quebrada de uma forma que só aparece como resultado de negócio, emails não enviados, resumos faltando, decisões atrasadas.

É por isso que observabilidade de orquestração é separada de observabilidade de agents. Você precisa monitorar a camada de coordenação em si: profundidade de filas, taxas de conflito, latência de consenso, taxas de escalação e, mais importante, a porcentagem de ações de agents que estão sendo atrasadas, modificadas ou bloqueadas pelo orquestrador. Se essa porcentagem desviar da baseline, algo está errado na camada de coordenação, mesmo se cada agent individual está saudável.

O Princípio de Design

Doze agents operando independentemente são caos. Doze agents operando sob um controlador centralizado são frágeis. O design certo está no meio: agents que são autônomos no seu domínio mas coordenados nas fronteiras.

Cada agent da Apollo Space é dono completo do seu domínio. O agent SDR decide quem contatar, o que dizer e quando dizer. O agent de QA decide o que testar, como testar e se deve flaggar um problema. Nenhum outro agent ou sistema diz a eles como fazer seu trabalho.

O orquestrador não gerencia agents. Gerencia interações entre agents. Não decide o que o agent SDR deveria escrever, decide se o agent SDR pode enviar aquele email agora, dado o que cada outro agent está fazendo. É um controlador de tráfego, não um gerente.

Esse princípio, domínios autônomos, fronteiras coordenadas, é o que torna o sistema escalável. Adicionar um décimo terceiro agent não requer reescrever a lógica de orquestração. Requer definir o domínio do novo agent, seu nível de prioridade, seus padrões de interação com agents existentes e seu comportamento de fallback. O framework de orquestração cuida do resto.

Adicionamos três agents desde os nove iniciais, e cada adição levou 2-3 dias de configuração de orquestração versus 2-3 semanas de desenvolvimento do agent. A camada de orquestração é difícil de construir mas fácil de estender, que é exatamente o trade-off que você quer num sistema que precisa crescer.

A camada de orquestração é invisível. Usuários nunca a veem. Veem doze agents trabalhando em harmonia, cada um fazendo seu trabalho no momento certo. Essa harmonia não é natural, é engenheirada, linha por linha, conflito por conflito, fallback por fallback. E é a engenharia mais difícil e mais importante que fazemos.