Construí uma plataforma de IA completa. Então descobri que estava na altitude errada.

E
Enio Rocha
6 min de leitura GitHub →

TL;DR: Construi uma plataforma de IA com 45 agentes, 9 fases de pre-commit, e 4 camadas de validacao — para zero usuarios. Quando auditei com honestidade, encontrei um repositorio esquecido com 3 scripts Python que ja resolvia o problema real. Essa e a historia do gap entre a altitude da plataforma e a altitude do problema.

Os numeros que me acordaram #

Em abril de 2026, pedi ao ChatGPT para auditar o ecossistema EGOS com base no meu historico de commits. Os numeros foram desconfortaveis:

MetricaValorSignificado
Agentes registrados4524 ativos, 21 orfaos ou duplicados
Fases de pre-commit9Gitleaks, typecheck, doc-drift, evidence-gate, vocab guard...
Camadas de validacao de docs4SSOT drift, doc proliferation, file intelligence, evidence gate
Tabelas Supabase com RLS8+Entity graph, wiki pages, timeline, gem discoveries...
Clientes pagantes0Zero. Nenhum. Nada.
Usuarios reais0Eu mesmo era o unico usuario.

A escala de complexidade que o ChatGPT usou foi essa:

NivelDescricaoExemplo
0Checklist + promptGPT com template fixo
1Copiloto com contextoAgente que le seus docs antes de responder
2Fluxo com aprovacao humanaPipeline: transcricao, revisao, entrega
3OrquestracaoEvent bus, agents coordenados, retry logic
4Multiagente45 agentes, governanca nativa, self-healing

O EGOS estava operando no nivel 4. O primeiro problema real que precisava resolver estava no nivel 2. A razao entre complexidade construida e complexidade necessaria era de 10:1.

Por que isso acontece #

Karpathy tem um principio simples: abstracao so depois da terceira repeticao. Antes disso, voce esta inventando complexidade que o problema nao pediu.

Quando voce e um builder que gosta de sistemas, o sistema em si vira o trabalho. O pre-commit hook vira o objetivo. O schema de entidades com 8 tipos vira a feature. E a governanca — que deveria ser um meio — vira o produto.

Dos 1189 commits nos ultimos 60 dias, 44% eram documentacao e governanca. O sistema de governanca virou o trabalho em si.

O antidoto: medir sempre a razao complexidade construida / complexidade encontrada. Mirar em 1:1.

O que eu encontrei no policia repo #

Enquanto auditava o kernel, encontrei um repositorio que eu mesmo tinha esquecido: /home/enio/policia. Sem governanca sofisticada, sem 45 agentes — apenas tres scripts Python funcionando sobre casos reais de delegacia em Minas Gerais.

# O pipeline completo que ja funcionava:
Media (MP4/OGG)
  → transcribe.py (Groq Whisper, auto-segmenta >25MB)
  → oitiva_to_docx.py (sinopse/OVM)
  → cs_to_docx.py (template oficial com brasao)
  → DOCX pronto para entrega

# Testar:
make transcribe CASE=caso_elcio
make cs MD=comunicacao.md TEMPLATE=templates/cs.docx OUT=saida.docx

Os fatos:

  • 2 casos reais processados (caso Elcio + homicidio DP 18526073)
  • 7+ testemunhas transcritas via Groq Whisper large-v3
  • Comunicacoes de servico geradas no template oficial (brasao, headers institucionais)
  • 15 testes pytest passando
  • 4 workflows: OVM master, cartorio, investigacao, relatorio final
  • Suporte a OGG, MP4, M4A, MP3, WAV

Nenhum agent. Nenhum event bus. Nenhuma migracao Supabase. E resolvia o problema real.

O que mudou no EGOS #

A plataforma nao vai encolher. O kernel continua la — Neo4j com 83 milhoes de nos, Guard Brasil com 16 padroes de PII em 4ms, sistema de knowledge base com wiki compilada. O que muda e a ordem em que as coisas chegam ao usuario.

Antes: construir primeiro, validar depois (ou nunca).

Agora: validar primeiro, construir o que o campo pede.

A pessoa que vai validar se chama Lidia. E policial civil em MG, parceira do Enio, e a primeira pessoa real que vai usar o sistema fora do ambiente de desenvolvimento. Nao e dev. Nao conhece TypeScript. Mas conhece os processos da delegacia melhor do que qualquer diagrama de arquitetura.

A meta dos proximos 30 dias:

  • Lidia entende 80% do sistema
  • 1 processo real da delegacia e melhorado com IA
  • Feedback do campo guia o que construir a seguir

O que realmente funciona hoje #

Sem exagero, sem numeros inflados. Isso aqui e o que esta live e rodando:

SistemaStatusProva
Guard Brasil APILive, 4ms p95curl https://guard.egos.ia.br/health
Policia pipeline15 testes, 2 casos reaiscd /home/enio/policia && pytest
Gem Hunter14 fontes, cron semanalgemhunter.egos.ia.br
Timeline publishing2 artigos, auto-draft via LLMVoce esta lendo agora
Knowledge baseWiki + entity graph schemasSupabase egos_wiki_pages

O Guard Brasil, especificamente, faz isso:

curl -X POST https://guard.egos.ia.br/v1/inspect \
  -H "Content-Type: application/json" \
  -d '{"text": "CPF do cliente: 123.456.789-09, email joao@x.com"}'

# Resposta (~4ms):
{
  "patterns": [
    {"type": "CPF", "value": "123.456.789-09", "valid": true},
    {"type": "EMAIL", "value": "joao@x.com"}
  ],
  "lgpd_risk": "HIGH",
  "latency_ms": 4
}

16 padroes brasileiros. Validacao de digito verificador real para CPF e CNPJ. Open-source no GitHub e npm (@egosbr/guard-brasil).

O codigo que publicou este artigo #

Este artigo foi publicado usando o pipeline que construimos nesta mesma sessao. O article-writer.ts gera drafts via LLM (qwen-plus), roda Guard Brasil PII check, e insere em timeline_drafts. O publish.sh move para timeline_articles e sincroniza com a knowledge base:

# Gerar draft a partir de um commit:
bash scripts/publish.sh "tema do artigo" ae7b9ad

# Aprovar e publicar (draft → article + KB sync):
bash scripts/publish.sh --approve <draft-id>

# O cron faz isso automaticamente as 03:00 UTC:
# scripts/timeline-cron-daily.sh
# → escaneia commits 24h → gera drafts → envia pra revisao

Cada artigo publicado automaticamente vira uma pagina na knowledge base (egos_wiki_pages) com cross-references para outros artigos. Tudo interligado.

Perguntas frequentes #

O que e o EGOS exatamente?
Um kernel de orquestracao para agentes de IA com governanca nativa. Nao e um produto unico — e a infraestrutura que potencializa multiplos produtos (Guard Brasil, Gem Hunter, policia pipeline). Codigo aberto em github.com/enioxt/egos.
O Guard Brasil substitui o AWS Macie ou Microsoft Presidio?
Nao substitui — complementa. O diferencial e ter 16 padroes brasileiros nativos (CPF, CNPJ, MASP, REDS, SUS, Titulo de Eleitor) com validacao de digito verificador real. Macie e Presidio nao conhecem MASP ou REDS. O Guard e open-source (MIT), self-hostable, e roda em 4ms.
Por que nao usar um framework existente como LangChain ou CrewAI?
Os 45 agentes do EGOS nasceram antes desses frameworks amadurecerem. A governanca nativa (.guarani/, pre-commit, SSOT drift) e especifica para compliance BR. Dito isso — o principio da complexidade diz que frameworks prontos deveriam ser usados sempre que possiveis. Estamos reduzindo, nao expandindo.
Como a Lidia vai usar o sistema?
Atraves do policia repo, nao do kernel EGOS. O pipeline e: audio (MP4/OGG) → transcricao Groq → sinopse → documento oficial DOCX. Ela nao precisa saber o que e TypeScript. Precisa saber que make transcribe CASE=caso_nome transcreve e formata.
Posso contribuir?
Sim. O repositorio e open-source em github.com/enioxt/egos. PRs sao bem-vindas, especialmente em Guard Brasil (novos padroes PII) e no policia pipeline (novos formatos de documento).

Enio Rocha — dev, formado em Direito (UNIPAM 2019), builder do EGOS.
Guard Brasil: guard.egos.ia.br · GitHub: github.com/enioxt/egos · X: @anoineim

No EGOS, isso também se conecta com #

Código aberto. Tudo que você viu aqui está disponível em github.com/enioxt/egos. Se você está construindo algo parecido ou quer aplicar no seu contexto, fala comigo no X: @eniorocha_. Construindo em público.