IntelBuzz · Buzz Giro · Arquitetura · v1 · 16/08/2026 · núcleo único de estado, especialistas de julgamento na borda
Complementa o desenho do agente e o placar da onda 0. Aqui está onde a gente corta em agentes separados, onde não corta, e o contrato entre eles.
A Buzz já opera em arquitetura multiagente hoje, sem ter chamado assim: 159 crons ativos e 66 serviços rodando na VPS. Monitor de 30 minutos, watcher do Canal Aberto, cadência da fase Lead, BZ Proativo, guardião, cobrança de retirada de pauta.
E o resultado dessa arquitetura é exatamente o diagnóstico que originou o Giro: a máquina não é lenta, ela para. Não faltaram agentes. Faltou dono do card inteiro. Cada um vigia sua fatia e solta a mão: o watcher do Canal Aberto larga no 3º dia, o Card Rápido larga quando o card sai da fase Lead. O lead cai no vão entre os agentes.
É dono do estado e é indivisível. Mantém o relógio de cada card, decide o estado, levanta flag, monta balde e fila de decisão. É o único que escreve no CRM e o único que fala com a equipe.
Hoje: execution/giro_estado.py classifica 3.980 cards em 9 estados, validado contra o Bitrix. Dono operacional: RevOps.
Pergunta que responde: "o que esse cliente quer?" Lê notas, comentários e conversa, e devolve valor, bairro, tipo e quartos.
Por que é agente separado: é interpretação de texto ambíguo, precisa de LLM, erra de um jeito próprio (inventa dado que não está lá) e melhora com prompt, não com regra. Não tem nada a ver com contar prazo.
Por que vale a pena: 1.521 cards abertos estão sem perfil e por isso são invisíveis pro motor de sugestão do BZ Proativo. Perfil é combustível, não enfeite.
Pergunta que responde: "esse registro é confiável?" Procura prova de fachada (registro sem evento correspondente no Bitrix), valor implausível, campo preenchido na mão, padrão de cadastro sem trabalho.
Por que é agente separado: porque ele audita o núcleo, e auditor que roda dentro do auditado não audita nada. Precisa de fonte e execução independentes para ter valor.
Por que vale a pena: já achou coisa na onda 0 sem existir formalmente: card de R$ 4,25 bilhões, 6 cards com valor implausível, 111 cards órfãos com gente desligada. É o insumo direto do laudo do RevOps.
Pergunta que responde: "o cliente ainda está vivo?" Se o corretor não toca no prazo, manda a primeira mensagem ao cliente e devolve o contexto pro corretor.
Por que é agente separado: por risco, não por elegância. Ele é o único que fala com o cliente. Isolamento de falha aqui é obrigatório: ele precisa poder ser desligado sozinho, sem parar o resto.
Estado: desenhado e desligado. Só liga por decisão do COO, com o resultado das ondas 1 a 3 na mesa.
| Contrato | Perfilador | Auditor | Resgate |
|---|---|---|---|
| Entrada | notas, comentários e histórico do card | card + eventos + atividades do Bitrix | card + histórico + carteira compatível |
| Saída | perfil estruturado + confiança + trecho que gerou a conclusão | veredito (confiável, suspeito, sem evidência) + motivo | rascunho de mensagem, nunca envio direto |
| Escreve no CRM? | não, o núcleo grava | não, o núcleo grava | não, o núcleo despacha |
| Como erra | inventa dado que não está no texto | acusa quem não fez nada errado | fala o que não devia com o cliente |
| Custo do erro | baixo: perfil errado gera sugestão ruim | alto: mancha reputação de corretor | altíssimo: chega no cliente e não volta |
| Trava | só grava com confiança alta; abaixo disso vira pergunta pro corretor no Card Rápido | nunca vira cobrança automática; sai só no laudo do RevOps, com card citado | teto de 1 mensagem por cliente, horário comercial, corretor em cópia, kill switch |
| Dono | RevOps | RevOps | COO, decisão a cada onda |
| Quando desligar | confiança média abaixo do piso por 2 semanas | rejeição de veredito acima de 5% | qualquer reclamação de cliente |
Chamada síncrona, sem fila de mensagens entre agentes. Especialista é função, não é colega de trabalho do núcleo: recebe, responde, morre. Sem estado próprio, sem memória entre chamadas, sem conversar com outro especialista.
núcleo → perfilador: {card_id, textos[], pergunta: "perfil"}
perfilador → núcleo: {valor, bairro, tipo, quartos, confianca: 0.0-1.0, evidencia: "trecho"}
núcleo decide:
confianca >= 0.8 → grava no card e segue
confianca < 0.8 → não grava, vira pergunta pro corretor no Card Rápido
sem resposta → segue sem perfil, marca flag e não trava o giroA última linha é a mais importante: o núcleo nunca fica bloqueado esperando especialista. Especialista fora do ar degrada a qualidade, não para a operação. É o oposto do que acontece quando se fatia o ciclo do card, onde um agente parado trava a esteira inteira.
Isso não é teoria, é a operação de vocês: existe um vigia só para monitorar as esteiras de cron, porque elas quebram. Em 16/08/2026, achei o Placar da Empresa parado há 7 horas por uma máscara de ACL zerada.
Cada agente novo custa: um cron, um log, um dono, uma entrada no vigia e um caminho a mais para o corretor receber mensagem.
O caminho de mensagem é o pior deles. Com N agentes falando, o teto de 3 mensagens por dia vira uma negociação entre eles: quem cede a vez? Hoje isso é resolvido por fila única. Em multiagente puro, precisaria de um coordenador, que é um agente novo, que também quebra.
Custo de coordenação cresce mais rápido que o benefício. Numa consultoria isso é elegante porque eles entregam e vão embora. Aqui alguém convive com o resultado toda segunda de manhã.
1. Ele precisa saber o histórico do card pra decidir? Se sim, é o núcleo. Não crie.
2. Ele erra de um jeito diferente dos outros? Se erra igual, é a mesma competência e não justifica separação. Se erra diferente, precisa de trava própria e aí faz sentido.
3. Ele pode cair sem parar a operação? Se a queda dele trava o giro, ele não é especialista, é dependência crítica disfarçada. Traga pro núcleo ou torne opcional de verdade.