Bastidores do OpenBot: Governando Agentes com Jev SystemOne e a Proteção Fail-Closed

Orquestrar mais de vinte agentes autônomos operando em paralelo na mesma máquina não é apenas um desafio de prompts ou modelos: é essencialmente um problema de governança de software, controle de custos e integridade operacional.

Quando dezenas de rotinas disparam ao longo do dia, o risco imediato é duplo. De um lado, o consumo descontrolado de tokens em verificações infrutíferas. Do outro, a tentação perigosa de conceder autonomia cega a modelos que, diante da menor anomalia, podem disparar deploys corrompidos ou sobrescrever dados críticos.

Nas últimas semanas estruturando o ecossistema do OpenBot, refinamos três pilares que transformaram a operação em uma linha de produção estável, enxuta e segura. Compartilho aqui as lições práticas dessa arquitetura.

1. O Filtro Rápido: Economia de Tokens com o Jev SystemOne

Em qualquer esteira com tarefas periódicas (como monitorar repositórios, conferir notícias ou atualizar bases internas), 90% das execuções encontram exatamente o mesmo estado da rodada anterior.

Se cada agente acionar um modelo de fronteira completo a cada 15 ou 30 minutos apenas para concluir que “nada mudou”, o orçamento de inferência vai embora antes do almoço.

Para resolver esse gargalo, adotamos o protocolo TypeSafe System One (Jev) na versão fixa jev-1.14.0. A lógica é análoga ao pensamento rápido (System 1) da psicologia cognitiva: antes de carregar o contexto completo de um modelo pesado, o agente roda um script local leve (systemone_call.py) com perguntas calibradas sobre o estado superficial.

python "systemone_call.py" `
  --agent "redacao-texto" `
  --state "Resumo do estado capturado nesta rodada..." `
  --questions-json '{"algo_novo":{"type":"noul","instructions":"Ha fato novo ou relevante que exija execucao hoje?"}}'

A Regra de Corte dos 300 Tokens

A chamada avalia uma métrica de novidade (algo_novo). Se o valor retornado for menor ou igual a 0.25, a rotina encerra imediatamente em silêncio.

• Consumo médio por gate: Menos de 300 tokens de contexto.
• Latência: Menos de dois segundos.
• Resultado: Redução de mais de 75% no consumo inútil de API em rotinas recorrentes, preservando a cota dos modelos pesados para tarefas analíticas reais.

2. A Proteção Fail-Closed em Ação

O segundo princípio cardeal é a blindagem contra erros silenciosos. Em sistemas distribuídos ou pipelines de agentes, a regra fundamental de segurança é: na dúvida, o sistema trava fechado (fail-closed).

Hoje mesmo tivemos um exemplo clássico na esteira editorial. Nosso wrapper auditado de pré-publicação realizou a verificação cruzada de integridade do rascunho antes de qualquer comando de envio. Durante o processo, identificou uma divergência no hash (sha256) dos arquivos e uma falta de sincronia com a árvore remota do repositório.

Em uma arquitetura sem travas rígidas, um agente poderia forçar um push, sobrescrever código ou gerar páginas quebradas em produção. Aqui, o pipeline abortou no mesmo instante com código de erro, registrou a anomalia em log protegido e escalou o evento para revisão humana.

As Regras de Ouro da Publicação

1. Nenhum deploy automático sem validação: Nenhum rascunho sai do ambiente local sem passar por verificação de integridade e conferência de fontes.
2. Aprovação humana mandatória: O Jev calibra confiança e valida requisitos técnicos, mas o comando de publicação externa exige explicitamente o aprovo humano.
3. Piso de confiança elevado para ações irreversíveis: Operações de escrita crítica exigem confiança mínima de 0.9 e flag --strict. Qualquer índice abaixo desse limiar bloqueia o processo.

3. Especialização de Infraestrutura: A Chegada da Valkyrie (WinNet-Core)

À medida que o ecossistema cresce, agentes generalistas começam a gargalar diante de problemas profundos de sistema operacional e conectividade. Sugestões superficiais como “reinicie o computador” ou “execute um scannow genérico” não têm espaço em um ambiente sério de produção.

Para cobrir essa lacuna, especificamos um agente Tier-3 dedicado a diagnósticos avançados de Windows e rede: a Valkyrie (WinNet-Core).

A diretriz da Valkyrie elimina o empirismo:

• Diagnóstico baseado em telemetria real: Consultas diretas via PowerShell moderno utilizando CIM e classes .NET nativas (Get-CimInstance, namespaces WMI).
• Análise forense de eventos: Monitoramento cirúrgico de Event IDs específicos no log do Windows para detectar quedas de serviço e conflitos de porta.
• Resolução de anomalias de rede complexas: Tratamento de MTU/MSS e PMTU Black Holes diretamente na pilha TCP/IP, garantindo estabilidade nas conexões de longa duração dos agentes.

O Que Fica de Lição

Agentes autônomos deixam de ser brinquedos experimentais no exato momento em que você impõe limites de engenharia clássica:

1. Economize tokens na triagem: Use gates ultraleves para saber se há trabalho real antes de acordar o modelo principal.
2. Adote fail-closed por padrão: Modelos falham e alucinam; suas travas de código determinístico devem ser intransponíveis.
3. Especialize para não improvisar: Agentes focados em papéis claros (redação, checagem, infraestrutura de SO) produzem resultados infinitamente mais previsíveis que prompts sobrecarregados.

O objetivo final não é criar sistemas que agem sozinhos a qualquer custo, mas construir assistentes que respeitam limites operacionais e ampliam a capacidade produtiva com previsibilidade cirúrgica.