Empresa de IA com 33 Agentes Autonomos em Produção

Sistema de orquestracao de 33 agentes de IA autonomos que executa centenas de tasks por semana sem supervisão humana, com cérebro distribuído de 2,5 milhoes de fatos e motor de dispatch com rollup pai/filho.

Não é um experimento. E a infraestrutura operacional da PEI Digital rodando desde 2025, processando trabalho real para produtos reais.

Contexto e Problema Real

Em 2025, eu operava como único responsavel técnico e estrategico de múltiplos produtos. Cada produto precisava de análise, copy, SEO, rastreamento, QA é ajuste continuo. Fazer tudo sequencialmente significava entregar semanas depois da janela de relevancia. Contratar humanos custava mais do que o MRR disponivel. A restricao era binaria: ou eu automatizava a operação inteira ou um dos produtos seria sacrificado. Não havia meio-termo financeiramente sustentavel.

Meu Papel

Eu projetei a arquitetura do sistema inteiro. Defini os contratos entre agentes, o modelo de task rollup pai/filho, o esquema de routing entre modelos de IA, o motor de dispatch com backlog e reconciliacao automática. Escrevi o código do motor, os prompts dos agentes especializados, é os gates de qualidade. Opero o sistema sozinho. Cada decisão de arquitetura foi minha.

As Decisões que Importaram

Decisão 1: SQLite com WAL mode em vez de fila externa para estado das tasks.

A alternativa natural seria RabbitMQ ou PostgreSQL gerenciado. Recusei os dois. RabbitMQ adiciona overhead operacional que um time de 1 pessoa não absorve. PostgreSQL gerenciado tem custo fixo incompativel com a fase atual. SQLite com WAL mode aguenta 2.000 writes por segundo, mais de 10x acima do throughput do motor. Roda no mesmo processo, backup é um arquivo copiavel, custo operacional zero. Calculei 18 meses antes de precisar migrar. Acertei: mais de 6 meses sem nenhum gargalo de escrita.

Decisão 2: dois modelos de IA em pipeline, nunca um so.

A tentacao era usar Claude para tudo. O custo ficaria inviavel no volume de agents que opero. A solução foi routing automático por categoria de task: DeepSeek V4 Pro para execução massiva (análise de volume, geração em lote, code review pesado, classificação), Claude para decisão crítica, auditoria de código, arquitetura é qualquer coisa que toca o cliente. O routing acontece sem intervencao minha: a task entra no backlog com categoria, o motor decide o modelo. Privacidade também entrou na equacao: DeepSeek não recebe dado de cliente identificavel, credencial ou financeiro da empresa. Tudo isso vai obrigatoriamente para Claude.

Decisão 3: par fixo DEV+QA em vez de agente único executor.

Cada task de implementação despacha dois agentes: um executor é um revisor independente. O revisor não ve o código antes de avaliar. Essa estrutura custa mais tokens por task, mas eliminou o falso PASS que eu chamo de “agente carimbador”: o executor aprova o próprio trabalho em exit 0 ou tsc --noEmit sem rodar o efeito real em runtime. Vi agentes declararem “entrega concluida” sem nenhuma evidencia de efeito mensuravel. O par fixo resolve isso porque o revisor tem incentivo contrario ao executor.

O que Deu Errado

O maior incidente do sistema foi o módulo de embedding local. Integrei o fastembed (wrapper do ONNX Runtime) para busca semântica no cérebro distribuído. A arena de memória do ONNX Runtime cresce em potencia de 2 e nunca devolve memória ao sistema operacional por padrao. Com o processo rodando inline no servidor da pipeline, a memória vazou 737 MB por minuto até o servidor atingir 12GB de RAM e morrer, derrubando o registry de todos os agents em execução. Levei 3 horas para isolar o root cause. A cura foi um monkey-patch que forca desabilitacao da arena antes da importação do fastembed, mas a versão inicial do patch tinha um bug: so aplicava quando sess_options estava ausente, é o fastembed sempre passa o dele. O resultado foi um patch que logava “patched” e não fazia nada. Esse bug me custou mais um incidente. Hoje o sistema opera com kill-switch que desativa embedding local se necessário, degradando gracefully para busca textual pura.

Resultado e Evidencia

Motor em produção com ciclo continuo de dispatch. Cérebro distribuído com 2,5 milhoes de fatos indexados. 33 agentes especializados com supervisão restrita a decisões estrategicas é aprovacao de deploy. O portfolio de produtos opera sem contratacao humana no time de execução.

Stack

• Python com FastAPI para o motor de pipeline
• SQLite WAL para estado de tasks e brain distribuído
• Claude (Anthropic) para decisão crítica é audit
• DeepSeek V4 Pro para execução de volume
• 11 ferramentas mecanicas na pipeline (SQL, grep, Playwright, curl, cache, memory recall)