Na semana passada publicamos o framework. Esta semana provamos que funciona no menor modelo que tínhamos disponível.
Quando publicamos o Operational Ontology Framework, uma das críticas mais honestas que fizemos a nós mesmos foi a seção 11.1 do documento: "Lacuna Empírica Declarada". Seis meses de operação, cinco agentes em produção, zero perda de estado entre transições de provider. Mas a evidência era operacional e anedótica. Faltava algo mais concreto.
Esta semana fechamos parte dessa lacuna. Pegamos o framework, implementamos o ciclo completo num Gemma 2B (o menor modelo que temos) rodando localmente via Ollama, e colocamos pra operar como agente comercial da FSTech via WhatsApp.
Custo de API: zero. Custo de infraestrutura: um notebook Dell com 16GB de RAM que já existia.
O Que Significa "Ciclo Completo"
O framework define 5 artefatos e um ciclo. Na teoria, qualquer agente que implemente os 5 artefatos e execute o ciclo está operando segundo o framework. Na prática, a pergunta era: um modelo de 2B parâmetros consegue fazer isso?
A resposta curta: sim, se a inteligência estiver no lugar certo.
Os 5 artefatos implementados:
- Pin — regras imutáveis do agente, carregadas no boot. Definem quem ele é, o que pode fazer, limites de acesso.
- Spec — estado atual dos projetos. Tarefas pendentes, bloqueadas, concluídas. Lido e escrito pelo agente em tempo real.
- Log — registro estruturado de toda interação. JSONL com timestamp, ator, tipo, conteúdo, latência. Auditável via git.
- Skill — funções determinísticas que executam sem passar pelo modelo. Consulta de pipeline, detalhe de lead, atividade recente. Latência: 0ms.
- Handoff — resumo estruturado gerado quando a sessão encerra. A próxima sessão carrega o handoff e sabe o que aconteceu antes.
O ciclo: Boot (carrega Pin + Spec + Pipeline + Handoff anterior) → Execute (Skill ou modelo) → Write-back (detecta eventos comerciais, registra no log) → Handoff (preserva contexto para a próxima sessão).
O Truque: Código Orquestra, Modelo Conversa
Um modelo de 2B parâmetros não consegue gerenciar artefatos. Não produz JSON confiável. Não faz raciocínio multi-step. Se você pedir pra ele atualizar um arquivo markdown com o status de um lead, ele vai inventar dados que não existem.
O que um modelo de 2B consegue: responder perguntas sobre dados que ele recebeu no contexto. Manter tom consistente. Ser conciso.
A arquitetura que funciona separa responsabilidades:
| Responsabilidade | Quem faz | Por quê |
|---|---|---|
| Ler/escrever artefatos | JavaScript | Determinístico, sem alucinação |
| Detectar comandos (/pipeline, /lead) | JavaScript (regex) | Instantâneo, 0ms |
| Buscar dados de um lead | JavaScript | Lê do JSONL/pipeline real |
| Detectar evento comercial | JavaScript (padrões) | "Francielli respondeu" → log automático |
| Gerar handoff | JavaScript | Extração de tópicos por keyword, não por modelo |
| Responder ao humano | Modelo (Gemma 2B) | Humaniza dados reais que recebeu no contexto |
O modelo não é a fonte dos dados. Ele é o formatador. Os dados vêm do código. O código lê os artefatos, busca os registros, injeta no prompt. O modelo recebe "Francielli: proposta R$10K, 3 fases, aguardando aprovação" e responde com linguagem natural usando esses dados. Não precisa inventar porque já tem tudo.
O Problema da Alucinação (E Como Resolvemos)
Na primeira versão, o modelo recebia o contexto genérico do pipeline e respondia perguntas sobre leads específicos. Resultado: inventava valores, status e datas que não existiam.
A correção foi o que chamamos de pre-inject. Quando o código detecta que a mensagem menciona um lead (por nome ou empresa), ele busca os dados reais desse lead nos logs comerciais e injeta diretamente no prompt, antes do modelo processar.
Antes: "Qual o status da Francielli?" → modelo inventa "Proposta Aceita, R$25.000"
Depois: "Qual o status da Francielli?" + [dados: call 09/04, proposta R$10K, 3 fases, aguardando] → modelo responde com dados reais
A diferença não é sutil. É a diferença entre um agente que parece inteligente e um que é confiável.
Números Reais
| Operação | Latência | Precisão |
|---|---|---|
| Comandos (/pipeline, /lead, /log) | 0ms | 100% (JavaScript direto) |
| Saudação simples | ~20 segundos | OK |
| Query sobre lead (com pre-inject) | ~50 segundos | Dados reais, zero alucinação |
| Write-back automático | 0ms (+ tempo do modelo) | Lead e ação corretos |
20 a 50 segundos não é rápido. É o limite de um Gemma 2B num notebook com 16GB de RAM. Mas é funcional, é gratuito, e os dados estão corretos. Para um agente comercial que consulto pelo celular algumas vezes por dia, a troca vale.
O Que Isso Prova
Três coisas:
- O framework é independente do modelo. O mesmo ciclo (Pin, Spec, Log, Skill, Writeback, Handoff) que opera com Claude Opus 4.6 no terminal funciona com um Gemma 2B de 3.4GB via WhatsApp. Os artefatos são markdown e JSONL. O ciclo é código. O modelo é intercambiável.
- A inteligência não precisa estar no modelo. Skills como funções determinísticas, write-back por detecção de padrões, handoff por extração de keywords. O modelo faz o que faz bem (conversar) e o código faz o resto.
- Soberania de memória funciona na prática. O estado do agente vive em arquivos no filesystem. Se amanhã eu trocar o Gemma por um Llama, por um Haiku, ou por qualquer outro modelo, o agente não perde o que aprendeu. Porque nunca esteve no modelo.
Como Começar
O framework está publicado, licença CC BY 4.0. O código de referência tem 44 testes e adapters para Anthropic, OpenAI e Ollama.
Se você opera qualquer processo recorrente (comercial, financeiro, atendimento), pode implementar o ciclo com o modelo que já tem disponível. Não precisa de GPU enterprise. Não precisa de API cara. Precisa de 3 arquivos markdown e disciplina de write-back.
