NODTeam: quem revisa o trabalho quando vários agentes atuam juntos?

Quando vários agentes de IA trabalham ao mesmo tempo, a pergunta deixa de ser apenas “quem consegue escrever mais rápido?”. Eu preciso saber quem recebeu cada tarefa, qual contexto usou, que resultado entregou e quem aprovou a próxima ação. Sem isso, duas pessoas podem revisar versões diferentes e um rascunho pode parecer pronto só porque um agente encerrou sua parte.

O NODTeam é o projeto de um QG para tornar essas passagens visíveis. O frontend já mostra uma visão de squads, cards e atividade recente; o repositório também contém uma API. Ainda assim, ele está em desenvolvimento. A captura da interface foi feita com o backend offline e com dados fixos do próprio frontend. Ela comprova o desenho visual do QG, não que dezenas de agentes estejam executando tarefas reais.

Interface demonstrativa do NODTeam em desenvolvimento com squads e indicadores fictícios; backend não conectado na captura.

O que o QG mostra hoje

A tela de Cards separa um resumo no topo, os squads no centro e um painel de monitoramento à direita. Os cards dos squads exibem foco, quantidade ilustrativa de agentes e estado. A navegação inclui áreas para agentes, squads, conteúdos, auditoria e configurações. Há controles para modos de visualização chamados Jogo, Planta e Cards.

Esse desenho ajuda a enxergar uma operação possível. Por exemplo, um squad pode cuidar de pesquisa, outro de conteúdo e um terceiro de atendimento. Uma atividade que exige decisão humana apareceria numa fila de revisão. Mas a existência dessas áreas na tela não comprova que o encaminhamento, a execução e a aprovação já funcionem de ponta a ponta.

Como eu aplicaria isso a uma série de artigos

Neste próprio blog, um agente poderia localizar a documentação de um app, outro preparar um texto e outro conferir se a captura da interface usa dados fictícios. O revisor reuniria essas partes, resolveria divergências e verificaria o artigo final antes de publicar. Esse é um exemplo de fluxo desejado, não um relato de que o NODTeam já publicou esta série automaticamente.

Há diferenças que o sistema precisaria preservar: uma tarefa concluída não significa artigo aprovado; um print do frontend não prova que uma integração funciona; uma aprovação de texto não equivale a autorização para publicar em todas as plataformas. O QG foi desenhado justamente para tornar essas etapas e responsabilidades legíveis.

Os números da tela são uma demonstração

A captura do NODTeam exibe, entre outros elementos, cartões de agentes, squads, tarefas concluídas, custo estimado e atividade recente. Esses KPIs e atividades vêm de constantes de demonstração no frontend. O número “14 agentes”, por exemplo, não é uma medição de agentes ativos. O backend não estava conectado durante a captura.

Por isso, eu não usaria aquela imagem para anunciar produtividade, custo real ou operação pronta. O que posso mostrar é a proposta de interface: squads com focos distintos, uma visão de tarefas e um lugar reservado à revisão humana. Para chamar esse fluxo de validado, ainda é preciso testar as ações reais, a persistência dos estados, o registro das evidências e o bloqueio de ações antes da aprovação.

A ideia por trás do NODTeam continua útil mesmo enquanto o projeto amadurece: velocidade sem contexto cria retrabalho. Uma equipe de agentes precisa de responsabilidade, histórico e uma pessoa capaz de dizer “está pronto” com base em prova, não apenas em um status verde.

O que a imagem do QG permite observar

Na captura, o modo Cards está selecionado. Há atalhos para os modos Jogo e Planta, uma navegação lateral para agentes, squads, conteúdos, concorrentes, criativos, auditoria e configurações, quatro indicadores no topo e cartões de squads no centro. O painel à direita reúne uma atividade recente demonstrativa. Essa composição é útil porque coloca equipe, tarefas e alertas no mesmo campo visual.

Mas os números precisam ser lidos corretamente. “14 agentes ativos”, “47 tarefas concluídas” e “R$ 23,50” de custo estimado foram preenchidos por constantes do frontend para demonstração. Os nomes e horários na atividade recente também são exemplos. Nenhum deles é evidência de execução ou gasto real. A própria captura foi feita com o backend desconectado. O que ela documenta é a proposta da interface, não produtividade medida.

Os cartões ajudam a visualizar focos diferentes: conteúdo, pesquisa, atendimento, monitoramento e documentos. Status como “Em execução”, “Ocioso” ou “Pausado” precisam vir de eventos reais para orientar uma decisão operacional. Enquanto isso não for testado, eu trataria esses rótulos como parte do protótipo visual.

Exemplo: produzir um artigo sem perder responsabilidade

Suponha que o objetivo seja publicar um guia sobre um aplicativo. A tarefa inicial teria título, público, fonte canônica, versão do produto e prazo. Um agente de pesquisa poderia apontar a documentação e registrar o que foi confirmado. Outro criaria um rascunho. Um terceiro verificaria prints, dados fictícios, links e afirmações técnicas. O revisor humano receberia um pacote único com texto, fontes, imagem e dúvidas ainda abertas.

Há três travas que eu exigiria antes de chamar o fluxo de pronto. Primeiro, cada saída precisa indicar qual tarefa e qual fonte a originou, para evitar que uma versão antiga volte por engano. Segundo, o estado “concluído” de um agente deve significar apenas que ele entregou sua parte; a revisão editorial continua pendente. Terceiro, publicar é uma ação própria, dependente de aprovação explícita e de uma verificação no destino. Um card verde não substitui nenhuma dessas etapas.

No QG imaginado, eu conseguiria voltar de um artigo publicado à tarefa, aos agentes envolvidos, às correções humanas e ao recibo da publicação. Esse é o critério de utilidade do produto. A interface atual mostra onde essas informações poderiam aparecer; a persistência e a execução dessa trilha ainda precisam ser demonstradas em teste.

Checklist para validar o projeto antes de operar

• Tarefas mantêm objetivo, responsável, fonte e versão depois de recarregar a página?
• Cada agente registra saída e evidência sem substituir o trabalho de outro?
• Uma mudança de estado é auditável com autor, horário e motivo?
• A fila de revisão bloqueia ações críticas até uma aprovação humana real?
• Custos e atividades vêm de eventos observados, não de cartões demonstrativos?
• Uma publicação gera recibo verificável no canal de destino?

Dúvidas comuns

Os 14 agentes mostrados estão trabalhando? Não há essa comprovação. O número da captura é dado fixo de demonstração.

Um squad substitui o revisor? Não. O squad pode dividir tarefas, mas a decisão editorial e a autorização da próxima ação precisam de uma pessoa responsável.

O que falta para chamar o QG de operacional? Validar execução real, persistência, evidências, auditoria e bloqueio de ações antes da aprovação. Uma interface convincente é apenas o começo.

Este guia faz parte da série 13 projetos que criei com Claude Code e Codex.