Ontologia Operacional FSTech

1. Contexto e Problema

Agentes baseados em LLM enfrentam três problemas estruturais quando saem do protótipo e entram em produção real.

Falta de auditabilidade. Não há registro estruturado do que o agente decidiu e por quê. Logs de execução mostram o quê, raramente o porquê. Quando o agente age errado, reconstruir a cadeia causal é forense, não engenharia.

Perda de estado entre execuções. Cada chamada começa do zero sem contexto das anteriores. A tentativa comum é persistir via bancos vetoriais ou embeddings, o que transfere o problema: o agente agora lembra de forma difusa, sem garantia de quais fatos sobreviveram.

Validação circular. O modelo valida a si mesmo. Pergunta ao LLM se a resposta está correta, e ele confirma. Sem camada externa de controle, a validação é ruído treinado para soar confiante.

O Framework de Ontologia Operacional FSTech resolve os três com uma estrutura documental mínima executada em ciclo. Sem infraestrutura adicional, sem memória persistente no modelo, sem dependência de stack específica.

2. Tese Central

Um agente de IA é production-ready quando opera dentro de um envelope de controle explícito, com estado auditável entre execuções, e quando a memória vive no documento, não no modelo.

O framework é agnóstico de modelo (roda com Claude, GPT, Gemini, modelos locais) e de infraestrutura (não requer banco vetorial, orquestrador específico ou pipeline customizado). A única dependência é um filesystem e disciplina documental.

Um corolário direto segue dessa premissa: porque a memória vive no filesystem e não no modelo, o agente é portável entre provedores sem perda de estado. Trocar de modelo amanhã não apaga o que ele aprendeu ontem.

3. Fundação: A Tríade D+L+A

A Ontologia Operacional se sustenta numa decomposição de primeiros princípios: todo sistema de gestão real tem três componentes atômicos, não mais.

DADOS (D). As entidades do negócio. Leads, clientes, projetos, contratos, faturas. Tudo que existe no mundo real e precisa ser representado no sistema. Extração e estruturação do conhecimento disperso em sistemas legados, documentos e memórias dos operadores.

LÓGICA (L). As regras de relação. Scoring, classificação, priorização, condições de ativação. A inteligência do negócio mapeada de forma que o sistema possa inferir. São as leis que governam o comportamento.

AÇÃO (A). O write-back acionável. Automações, notificações, atualizações de estado, mensagens enviadas. O estágio onde o insight se transforma em execução real no ambiente operacional.

A estrutura clássica é linear: D para L para A. A observação da prática mostra que o loop é contínuo: ações geram dados novos, que alimentam lógica refinada, que produz ações melhores. Projetar um sistema linear é projetar um sistema que morre no primeiro ciclo.

Implicação operacional. Ao projetar qualquer automação, a pergunta canônica não é "o que acontece quando executarmos" mas "o que acontece depois da ação". Se a resposta é nada, o sistema é linear, e linear significa frágil.

Metáfora para clientes. O negócio tem substantivos (clientes, pedidos, contratos), verbos (cobrar, notificar, consultar) e gramática (regras de priorização, scoring, escalação). Um sistema operacional existe quando todas as frases do negócio estão escritas e o sistema sabe executá-las. Dados são substantivos. Lógica é gramática. Ação são verbos.

4. Componentes Executáveis

O framework implementa D+L+A como três artefatos documentais mínimos. Cada artefato é um arquivo de texto, versionado, legível por humano e por modelo.

4.1 Pin (Invariante) — D + L

Arquivo imutável que descreve o que o projeto é. Propriedades verdadeiras independente do estado atual: regras, identidade, limites, restrições.

O Pin funciona como invariante de sistema. Complexidade cognitiva escala de forma quadrática com o tamanho do projeto, mas invariantes mudam raramente. Quando há dúvida sobre o projeto, o agente consulta o Pin, porque ele opera no espaço de menor complexidade. Fundamentação matemática vem de Lamport, provas por invariante em sistemas concorrentes.

O que vai no Pin:

• Identidade e escopo do projeto
• Regras imutáveis (restrições, políticas, limites)
• Entidades do domínio com definições não ambíguas
• Rotas de decisão com condições de entrada e saída
• Automações (crons, triggers, webhooks) formalizadas

O que não vai no Pin:

• Estado de execução, isso é Spec
• Histórico de decisões, isso é Handoff
• Preferências do operador humano, isso é outro documento

4.2 Spec (Comportamento) — L + A

Arquivo vivo que descreve o que fazer. Checklist sequencial de tarefas. A complexidade escala de forma exponencial com o número de tarefas e dependências, por isso a Spec é mais volátil que o Pin.

A Spec é o espaço comportamental. Cada tarefa concluída é marcada e gera aprendizado. Tarefa marcada como concluída é imutável, nunca desmarca. Se o resultado tem defeito, cria nova tarefa corretiva referenciando a original. Mesmo princípio do Git: commits são imutáveis, correções são novos commits.

Princípio da auto-contenção. Toda tarefa numa Spec precisa sobreviver ao handoff. Quem escreve a tarefa raramente é quem a executa, pode ser outro agente, outra sessão, outro dia. Uma tarefa que depende de contexto implícito para ser entendida morre no momento em que o contexto morre. Por isso, cada entrada da Spec carrega uma camada de metadados suficiente para que qualquer executor posterior saiba o que fazer, por que aquilo existe, de onde veio a demanda e qual o caminho mínimo de implementação. A FSTech padroniza esses metadados em uma convenção interna, refinada continuamente pela prática. A ausência desse padrão é o anti-pattern canônico da Spec: "fazer X" sem contexto adjacente é fratura silenciosa que só aparece no próximo ciclo, quando o executor seguinte não sabe mais o que aquilo significava.

4.3 Handoff (Memória) — A para D

Registro estruturado que alimenta o próximo ciclo. Não é log de execução (o quê), é registro de estado (onde estamos, por que paramos, o que precisa continuar).

Handoff contém:

• Foco da sessão encerrada
• Decisões tomadas com justificativa
• Tarefas executadas com resultado
• Tarefas não executadas com razão
• Continuação: briefing de reengajamento para o próximo ciclo

O handoff é a memória. O modelo não precisa de persistência de estado próprio, porque o handoff da sessão N alimenta o boot da sessão N+1. Cada novo ciclo começa com contexto completo em minutos, sem banco vetorial, sem embeddings, sem memória stateful.

Uma distinção fina importa: isto não é "zero persistência". O filesystem persiste, a ontologia persiste, o handoff persiste. O que é zero é estado mantido dentro do modelo. A memória vive no documento, não no peso da rede neural.

5. Ciclo de Execução

O framework opera em quatro fases. Cada fase é explícita, cada fase gera artefato.

Boot

Carregar Pin e Spec do projeto no início da sessão. Em sistemas com múltiplos agentes, o boot também carrega memória compartilhada (índice global) e a última entrada do handoff.

Executar

Resolver tarefas na mesma sessão. Quantas a sessão comportar com qualidade. O limite não é número de tarefas, é degradação perceptível de contexto.

Execução paralela (Wave). Quando a Spec tem três ou mais tarefas independentes, o agente principal dispara sub-agentes em paralelo com contexto isolado. O principal preserva contexto para orquestração e raciocínio. Dependências são respeitadas: tarefa B que depende de A espera A concluir.

Contexto isolado por tarefa pesada. Para tarefas que envolvem leitura extensiva (análise de codebase, pesquisa, auditoria), delegar a sub-agente mesmo que sejam sequenciais. O sub-agente opera em contexto fresco, sem acumular resíduo. Isso evita degradação de qualidade por acúmulo de contexto irrelevante.

Write-back (Commit Atômico)

A cada tarefa concluída:

• Verificar antes de marcar concluída, confirmar que a tarefa está realmente feita, com rigor proporcional ao risco
• Commitar uma tarefa, um commit. Mensagem referencia a tarefa. Rastreabilidade total via git bisect
• Marcar concluída na Spec
• Anotar aprendizado para a próxima tarefa, se houver

Verificação pré-done (Gate programático). Antes de marcar qualquer tarefa como concluída, o agente executa uma verificação proporcional ao risco da ação. Tarefas de baixo impacto (documentação, configuração local, registro) passam por uma releitura de coerência. Tarefas de impacto médio (features, integrações, refatorações) exigem teste funcional com comportamento observado. Tarefas de alto impacto, qualquer coisa que toque segurança, infraestrutura compartilhada ou dados de clientes, exigem o grau mais rigoroso de verificação: teste adversarial, revisão manual, e disciplina explícita contra as classes de vulnerabilidade conhecidas. O rigor não é uniforme porque o custo do erro não é uniforme.

Anti-pattern canônico. Verificação não é "rodei e não deu erro". É "tentei quebrar e não consegui". Para qualquer tarefa de alto impacto, o teste deve incluir tentativas adversariais explícitas, não basta observar que o caminho feliz funciona.

Handoff

Encerrar a sessão quando:

• A qualidade da geração começa a degradar perceptivelmente (respostas imprecisas, repetições, perda de foco)
• Há mudança de projeto ou domínio
• O agente entra em território onde o contexto acumulado virou ruído, não sinal

Procedimento: sempre nova sessão, nunca compactação. Compactação é compressão lossy. Ela perde nuance, perde causalidade e paga um custo de contexto logo na abertura da sessão seguinte. Uma sessão nova com boot via Pin e Spec começa leve, recupera o estado completo a partir do que está documentado no filesystem e preserva a fidelidade dos fatos. Compactação é o patch que existe para quem não tem write-back estruturado. Com write-back, compactação é o caminho errado.

Por que Handoff não é apenas outra compactação. Uma objeção natural neste ponto é que o Handoff também é escrito pelo modelo, então ele também seria compressão lossy. A objeção é legítima e a resposta importa. Handoff e compactação são dois atos distintos, não dois nomes para o mesmo ato. Compactação é uma heurística automática aplicada ao histórico inteiro de uma sessão, sem objetivo explícito além de reduzir tokens. O modelo não sabe o que vai importar amanhã, então faz uma aposta conservadora e perde causalidade no processo. Handoff é escrito com intenção explícita de continuidade. O modelo sabe que está produzindo um artefato para reengajamento futuro, e por isso preserva seletivamente o que a próxima sessão precisará: decisões tomadas e suas justificativas, tarefas executadas e seus resultados, bloqueios encontrados, briefing de continuação. A assimetria não está no ato de escrever, está no propósito. Um é reação, o outro é protocolo. A perda de fidelidade existe nos dois, mas é qualitativamente diferente: compactação perde o que não parece importante no momento da compressão, Handoff preserva o que foi decidido que importa para o próximo ciclo.

6. Mapeamento D+L+A nos Componentes

A validação externa (Gate pré-done) é o que elimina a circularidade. O agente não valida a si mesmo nas questões verificáveis externamente. Schema, permissões, estado de dependências, tudo é checado por código, não por opinião do modelo. A parte que é validação semântica (coerência com contrato, suficiência de dados) continua no modelo, mas com risco isolado: se falhar, gera bloqueio documentado, não tentativa cega.

7. Write-Back Obrigatório

If you think you know something but don't write it down, you only think you know it. — Leslie Lamport

Write-back não é apenas registro. É o próprio ato de pensar. Formular em texto revela lacunas, forçando precisão que o pensamento interno não exige. Quem sabe mas não escreve está no nível do conforto cognitivo, não do conhecimento validado.

Toda percepção, insight ou decisão gera write-back:

• Atualização de documento
• Criação de registro
• Alteração de estado
• Notificação acionável

Métrica: ciclo insight para write-back menor que um dia.

Teste: se é difícil de escrever, a ideia ainda não está madura. A dificuldade de formulação revela imprecisão de pensamento, não do texto.

Insight sem alteração do sistema real é lixo computacional.

8. Case Real: FSTech em Produção

O framework não é especulação. A FSTech opera sua frota interna de agentes neste framework há seis meses em produção, cinco canais ativos, múltiplos clientes.

Frota operando sob o framework:

• Ares agente orquestrador no terminal do operador, executa auditoria, refatoração, desenvolvimento, análise estratégica
• Ontos hub central da frota, roda em servidor dedicado, intermedia comunicação e orquestra agentes de campo
• Finn agente financeiro pessoal em produção para três clientes distintos, rodando em containers isolados, cada cliente com seu Pin
• Chava assistente pessoal rodando no notebook de uma cliente, integração com WhatsApp, calendário e contatos
• Ares WhatsApp mesmo agente orquestrador em canal de WhatsApp, comunicação direta com leads e clientes

Todos compartilham a estrutura do framework. Cada um tem seu Pin (regras imutáveis do domínio), seu diretório de Specs (tarefas em execução), e seu histórico de handoffs. A mesma disciplina documental que governa a frota também governa os agentes entregues a clientes, por desenho.

Prova técnica de portabilidade. Ao longo dos seis meses de operação, a frota migrou entre modelos sem perder estado acumulado. Ares rodou com Claude em diferentes versões, Ontos opera parcialmente sobre modelos locais (Gemma), Finn mescla provedores comerciais conforme o custo por cliente. Em nenhuma dessas transições o conhecimento acumulado foi perdido, porque o conhecimento nunca esteve no modelo. Estava no Pin, no Spec e no Handoff, exatamente onde a disciplina mandava que estivesse.

Case externo validado. A Ontologia Operacional foi adotada organicamente por uma empresa cliente (VJ Turrini) após um mês de contato. A adoção não foi venda, foi osmose. A operadora começou a consultar o agente via WhatsApp para tarefas reais, confiança se formou, automação seguiu depois. Este é o caminho natural: consulta, confiança, automação. Não o inverso.

9. Posicionamento

O framework não compete com frameworks de orquestração de chamadas (LangChain, CrewAI, AutoGen). Complementa. Esses frameworks resolvem como o agente chama ferramentas. O Framework de Ontologia Operacional FSTech resolve como o agente mantém estado auditável entre chamadas e execuções.

Comparativo com referências internacionais:

• Palantir Foundry opera sob Closed World Assumption com ontologia centralizada. O Framework FSTech segue o mesmo princípio (se não está documentado, não existe para o sistema) mas substitui o stack proprietário por filesystem versionado. Mesmo paradigma, infraestrutura radicalmente mais simples.
• Microsoft Fabric IQ Ontology oferece contexto operacional para agentes via produto gerenciado. O Framework FSTech oferece o mesmo sem fornecedor único, sem lock-in, sem SaaS obrigatório.
• Skan Agentic Ontology of Work formaliza ontologia como linguagem comum entre agentes. O Framework FSTech vai além ao formalizar o ciclo de execução, não apenas o vocabulário.

9.1 Soberania de Memória

Há um debate recente no setor sobre quem controla a memória dos agentes de IA. A preocupação é legítima. Quando a memória vive dentro do modelo, dentro do provider, dentro de um harness proprietário, quem usa o agente não controla seu próprio estado. Trocar de provider significa começar do zero. Atualizar o modelo significa torcer para que o conhecimento acumulado ainda funcione. A memória vira ativo do fornecedor, não do operador. A resposta comum a esse problema tem sido defender harnesses abertos e runtimes independentes como camada de soberania.

O Framework de Ontologia Operacional FSTech resolve esse problema por construção, não por adesão a um padrão externo. Como a memória vive em artefatos de filesystem versionados (Pin, Spec, Handoff) e não no peso do modelo nem no cache do provider, a frota é portável por desenho. Um agente que rodou com Claude ontem pode rodar com Gemini amanhã, com GPT na semana seguinte, com um modelo local depois, e o estado acumulado continua válido. O Pin é o mesmo documento. O Handoff é o mesmo arquivo. O contexto sobrevive à troca de modelo porque o contexto nunca esteve no modelo em primeiro lugar.

Isso não é uma feature adicionada para atrair quem teme lock-in. É consequência direta do princípio inicial de que a memória vive no documento. O framework não foi desenhado para resolver soberania e acabou ficando portável, foi desenhado para ter estado auditável e ganhou portabilidade como corolário. Quando o debate do setor chegou, o framework já operava do lado correto dele por seis meses.

10. Validação N5

Todo componente do framework passa pelo N5, metodologia proprietária de validação analítica desenvolvida pela FSTech. O N5 aplica cinco critérios hierárquicos sobre qualquer solução ou sistema antes de considerá-lo production-ready. A hierarquia interna prioriza evidência empírica sobre elegância teórica.

O Framework de Ontologia Operacional FSTech foi validado pelos cinco critérios do N5 antes de ser publicado. O critério Empirical, tipicamente o mais difícil, é satisfeito pelos seis meses de operação da frota interna e pelo caso externo adotado organicamente. Detalhes completos da metodologia N5, incluindo os cinco critérios, a hierarquia de resolução e o algoritmo de aplicação, estão disponíveis sob acordo de parceria com a FSTech.

11. Limites e Quando Não Usar

Um framework honesto declara onde não se aplica. O Framework de Ontologia Operacional FSTech não é adequado para:

• Agentes conversacionais puros sem efeito colateral em sistemas reais. Um chatbot de FAQ não precisa de Pin, Spec ou Handoff. A disciplina documental adiciona custo sem benefício.
• Protótipos exploratórios onde o objetivo é descobrir se o problema existe. Formalizar cedo demais cristaliza hipóteses erradas.
• Sistemas stateless verdadeiros onde cada execução é independente e não precisa de memória. Function as a service, transformações puras, pipelines de dados determinísticos.
• Equipes sem disciplina de write-back. O framework falha silenciosamente quando operadores ignoram o registro. Não é autoexecutável, exige cultura.

Se o sistema que você constrói cabe em alguma dessas categorias, o framework é overhead. Use algo mais leve.

11.1 Lacuna Empírica Declarada

Um framework publicado honestamente também declara onde a própria evidência é insuficiente. Este é esse parágrafo.

A prova apresentada nas seções anteriores (seis meses de operação, cinco agentes, caso VJ Turrini adotado organicamente) é evidência operacional, não métrica quantitativa. Não há neste documento: taxa de falha de boot, tempo médio de recuperação por handoff, número de ciclos executados por sessão, percentual de decisões preservadas entre transições de modelo, ou comparação controlada contra baseline sem write-back. A ausência é real. Um revisor técnico rigoroso vai apontar esta lacuna e a aponta corretamente.

Há duas respostas possíveis. A primeira é reconhecer que a disciplina de write-back que o próprio framework prescreve torna essas métricas produzíveis. Cada ciclo executado deixa rastro: Pin versionado, Spec com tarefas marcadas, Handoff escrito, git log. O material bruto existe, apenas não foi compilado em relatório público até esta versão.

A segunda é reconhecer o limite da afirmação que se faz sem essas métricas. Até que sejam publicadas, a tese empírica deste framework é: "operamos isso em produção há seis meses sem perda de estado entre transições de modelo". Isso é verdade e verificável por terceiros que quiserem conversar diretamente. Mas não é o mesmo que dizer "nossa taxa de falha de boot é X, comparada a Y do baseline sem write-back". Essa afirmação mais forte precisa ser publicada separadamente, com dados, e será.

Roadmap empírico (compromisso público):

• Métricas de ciclo publicadas em versão futura do framework (ciclos/semana, tempo médio de boot, tempo médio de handoff)
• Comparação controlada contra baseline de agente sem write-back, usando um projeto padrão replicável
• Estudo de preservação de estado em transição entre três provedores diferentes, com verificação cega

Enquanto essas publicações não existem, leia este framework como descrição de mecanismo e convite à verificação, não como artigo científico com métricas arbitradas. A prática veio antes da publicação, a publicação veio antes das métricas formais, e as métricas formais virão antes da próxima versão.

12. Este Documento é um Snapshot

Uma observação final sobre a natureza deste texto. O framework aqui descrito não é um estado final. É o recorte de abril de 2026 de um sistema que continua em movimento, exatamente através do ciclo que descreve. Cada componente (Pin, Spec, Handoff) é refinado pelo próprio write-back que ele governa. Cada afirmação deste documento foi produzida dentro do framework e, portanto, é passível de ser revisada pelo próximo ciclo.

Isso tem uma implicação importante. Adotar o framework não é adotar uma especificação estática. É entrar em um loop de refinamento onde a estrutura se adapta ao domínio enquanto mantém a disciplina documental. A diferença entre um protocolo morto e um sistema vivo é que o primeiro para quando a especificação é publicada, e o segundo trata a publicação como mais um evento de write-back, não como linha de chegada.

Em termos da tríade, o framework é Dados (estrutura documental), Lógica (ciclo de execução) e Ação (write-back obrigatório), aplicado recursivamente a si mesmo. Publicar esta versão é o write-back da operação que a produziu. A próxima versão já está sendo escrita no próximo handoff.

13. Próximos Passos

Este documento é a versão pública do framework que a FSTech opera internamente. A versão interna inclui:

• Templates executáveis de Pin e Spec por tipo de projeto
• Toolchain de boot e handoff history-based
• Protocolos adjacentes (isolamento de canal, notificação escalonada, firewall de qualificação)
• Metodologia N5 completa aplicada a cada artefato
• Integrações específicas com ferramentas de operação

A versão pública é suficiente para adoção em projetos reais. Organizações que quiserem acelerar adoção, aplicar o framework a domínios específicos ou obter a metodologia N5 aplicada podem contatar a FSTech diretamente.