Super Squad AI

O problema

Coordenar uma IA é simples. Coordenar várias com segurança não é.

Coding agents conseguem executar tarefas individualmente. Quando vários agentes trabalham sobre um mesmo repositório ao mesmo tempo, surgem outros problemas: conflitos entre mudanças, alterações fora do escopo de cada tarefa, perda de contexto entre agentes, estados incompatíveis, custo acumulado, falhas sem recuperação e uma dificuldade real de auditoria sobre o que cada agente fez.

O desafio do Super Squad AI não é gerar código. É governar a execução de agentes sobre um repositório com regras determinísticas, fronteiras claras e verificação baseada em evidência, não em declaração.

A IA propõe. O sistema verifica.

Este é o princípio central do projeto.

Um agente pode afirmar que terminou. Isso não modifica o estado real da tarefa. A tarefa somente avança quando existe evidência autorizada produzida pelo sistema, não pelo agente.

WorkerReport é uma declaração. VERIFIED é um estado que exige prova.

Como funciona

Cada etapa é determinística. A IA ocupa os nós de execução. O controle do fluxo, das fronteiras e da verificação é do sistema.

Uma squad baseada em capabilities, não em agentes fixos

A arquitetura não define posições rígidas como worker_01, worker_02 ou security_worker. Os agentes registram capabilities. O scheduler seleciona os compatíveis com cada tarefa.

Novos especialistas podem entrar na squad sem redesenhar o core. A modularidade é real porque está no contrato de capabilities, não no código de orquestração.

Planejar antes de executar

O Leader não distribui tarefas diretamente. Ele interpreta o objetivo, cria um plano estruturado, decompõe em tarefas, define dependências entre elas e associa a cada uma as capabilities necessárias.

A execução começa somente depois que o plano existe. Isso evita que agentes iniciem trabalho paralelo sem contexto sobre o que os outros estão fazendo.

Cada agente trabalha isolado

Esta é a segunda grande história de arquitetura do projeto.

Múltiplos agentes não trabalham livremente sobre o mesmo working tree. Cada tarefa possui uma fronteira Git própria: um worktree isolado criado a partir da Run Branch.

A branch humana permanece fora do ciclo automático. Mudanças chegam a ela somente depois de passar pelos dois estágios de verificação.

Benefícios conceituais dessa abordagem: isolamento entre agentes concorrentes, rollback granular por tarefa, auditoria do que cada agente fez separadamente, integração controlada e menor risco de contaminação entre tarefas.

Funcionar isolado não significa funcionar integrado

A verificação acontece em dois momentos distintos por razão arquitetural.

Código correto isoladamente pode quebrar o sistema quando integrado. A segunda verificação existe justamente para capturar isso.

Dar a cada agente o contexto necessário, e somente ele

O sistema utiliza um ContextPack por tarefa e por agente. Existe um ContextCache determinístico para reduzir duplicação de contexto entre tarefas correlatas.

O objetivo não é memória de IA. É controle sobre o que cada agente enxerga: menos arquivos irrelevantes, maior isolamento, menor superfície de exposição.

Autonomia limitada por políticas

Os agentes operam dentro de fronteiras definidas pelo sistema. Cada worker tem acesso apenas ao conjunto de ferramentas e caminhos autorizados para aquela tarefa.

O sistema define conceitualmente:

• quais caminhos um agente pode ler e escrever
• quais ferramentas estão disponíveis por tarefa
• quais comandos podem ser executados
• como segredos são filtrados do contexto
• quais evidências são necessárias para avançar o estado

Os detalhes de implementação dessas políticas não são publicados. O princípio é: o agente opera dentro do espaço que o sistema define, não no espaço que o agente gostaria de ter.

Falha não significa perder a execução inteira

Falhas fazem parte do design, não são exceções não tratadas.

O sistema utiliza budgets de tentativa por tarefa, estratégias de retry, fail-fast quando o budget é esgotado, persistência do estado entre tentativas, recuperação de runs interrompidas e retenção dos worktrees de tarefas que falharam para análise posterior.

Worktrees de tarefas bem-sucedidas são limpos. Worktrees de tarefas com falha permanecem disponíveis para diagnóstico.

Testar também o sistema contra formas de enganá-lo

O Super Squad AI utiliza regressões adversariais como parte do processo de desenvolvimento.

O objetivo é garantir que APIs públicas, registros fabricados ou evidências inválidas não consigam promover artificialmente o estado de uma execução. Detalhes de implementação desses controles não são publicados.

Não é um wrapper de múltiplos modelos

Decisões de produto e engenharia

Decisão 1 — Relato do agente não é estado real

O problema era que um modelo pode afirmar sucesso sem prova verificável.

A decisão foi tratar WorkerReport como declaração e exigir evidência autorizada para qualquer avanço de estado. O trade-off é um lifecycle mais complexo em troca de maior confiança operacional sobre o que o sistema realmente executou.

---

Decisão 2 — Git como fronteira operacional

O problema era que vários agentes alterando o mesmo working tree tornavam rollback e auditoria difíceis de realizar com confiança.

A decisão foi worktrees isolados por tarefa com integração controlada. O trade-off é mais gerenciamento Git em troca de isolamento real entre agentes concorrentes.

---

Decisão 3 — Capabilities em vez de papéis fixos

O problema era que uma arquitetura com posições fixas de agentes não escala conceitualmente e exige redesenho do core para adicionar especialistas.

A decisão foi seleção por capabilities no scheduler. O trade-off é um scheduler mais sofisticado em troca de modularidade real.

---

Decisão 4 — Verificação antes e depois da integração

O problema era que código correto isoladamente pode quebrar o sistema quando integrado com outras tarefas concorrentes.

A decisão foi two-stage verification com estágios independentes. O trade-off é mais tempo e custo de execução em troca de maior confiabilidade do estado integrado.

Arquitetura

Estado atual

O Super Squad AI é um produto funcional em evolução ativa. O que existe hoje:

• execução controlada com Leader e Workers dinâmicos
• persistência de estado em SQLite
• Git isolation por tarefa com worktrees
• orquestração multiagente com planejamento estruturado
• verificação em dois estágios
• recuperação de runs interrompidas
• testes automatizados cobrindo os contratos principais

Não há usuários externos, empresas, receita ou métricas de produtividade confirmadas. Esses dados não existem e não são afirmados aqui.

O projeto também serviu como ambiente para experimentação com desenvolvimento assistido por múltiplos agentes, com revisão e validação humana ao longo do processo.

O que este projeto demonstra