Por que a Trustyu criou a FORGE: da memória de um founder a um sistema verificável

Empresas não começam com um framework. Começam com um problema que insiste em voltar.

Na Trustyu, esse problema aparecia sempre que uma boa decisão precisava ser reconstruída: por que escolhemos esta arquitetura, o que aprendemos com aquele incidente, qual promessa já havia sido testada, que risco continuava aberto e o que realmente significava “pronto”. Parte das respostas estava em documentos, parte em código e parte na memória de quem participou. A organização avançava, mas pagava repetidamente para reaprender o que já sabia.

A FORGE nasceu dessa fricção. Antes de ser um nome público, foi JARVIS: um modo de transformar experiência em instruções, decisões e verificações que pudessem sobreviver a uma conversa, a um modelo de IA e até às pessoas que estavam na sessão original.

Este artigo é uma retrospectiva autoral. Não pretende provar que toda empresa deve copiar a FORGE. Ele explica por que a Trustyu a construiu, quais mudanças de pensamento foram necessárias e quais perguntas qualquer founder pode aproveitar.

Resumo executivo

A FORGE não é um catálogo de prompts nem uma seleção fixa de modelos. É um sistema de trabalho para conectar intenção humana, execução assistida por IA, limites, verificação, evidência e aprendizagem.

A evolução aconteceu em seis movimentos:

1. memória virou contexto versionado;
2. instrução virou contrato;
3. papel virou capacidade e autoridade delimitada;
4. conferência virou verificação por propriedade;
5. entrega virou evidência ligada ao asset exato;
6. correção virou aprendizagem que altera o sistema.

O resultado mais importante não é fazer a IA parecer autônoma. É permitir que pessoas deleguem mais execução sem perder autoria, responsabilidade ou capacidade de corrigir o caminho.

O primeiro problema: a memória não escala

No início, velocidade costuma depender de proximidade. O founder conhece o produto, lembra das conversas, reconhece os atalhos perigosos e completa mentalmente aquilo que o pedido não explicou. Essa memória tácita resolve muita coisa — até se tornar gargalo.

Quando o time, os produtos e os agentes aumentam, o custo aparece de formas conhecidas:

• decisões semelhantes recebem respostas diferentes;
• uma exceção temporária passa a parecer regra;
• a mesma pesquisa é refeita sem aproveitar o corte anterior;
• “foi validado” circula sem dizer qual versão, ambiente ou critério;
• uma conversa importante termina sem produzir estado durável;
• o founder vira o único mecanismo de reconciliação.

Adicionar IA a esse cenário não remove o problema. Uma IA rápida pode reproduzir inconsistências com mais volume. O desafio deixa de ser apenas recordar informação e passa a ser preservar contexto decisório: intenção, fronteira, evidência, validade e consequência.

JARVIS: conhecimento precisava virar mecanismo

JARVIS começou como uma tentativa prática de tornar o trabalho repetível. Documentos ganharam hierarquia; decisões arquiteturais passaram a ter IDs; padrões se tornaram verificáveis; sessões foram separadas por escopo; handoffs precisaram declarar estado e residual.

O salto conceitual foi perceber que documentação útil não é um arquivo que descreve o trabalho depois. Ela participa do trabalho enquanto ele acontece.

Uma decisão registrada pode orientar a próxima implementação. Um contrato pode bloquear uma projeção incoerente. Um teste pode impedir que uma afirmação pública avance sem fonte. Um histórico pode mostrar não só o estado atual, mas como se chegou até ele.

Isso muda a pergunta de “onde está a informação?” para “que comportamento este conhecimento produz?”.

Da conversa para o estado versionado

Conversas são excelentes para explorar. São ruins como única fonte de verdade. Elas misturam hipóteses, decisões, correções e contexto transitório em uma sequência difícil de comparar.

A FORGE passou a exigir que o que precisa durar deixe a conversa e ganhe uma forma endereçável:

• uma decisão com contexto e consequências;
• um contrato com campos fechados e versão;
• um plano com critério de aceite;
• um artefato com hash e origem;
• uma evidência ligada à revisão que foi verificada;
• um residual explícito, em vez de uma promessa vaga de “depois”.

Pesquisas e implementações recentes de agentes gerenciados convergem na necessidade de separar histórico de sessão, política de orquestração e isolamento de execução. O corte de fontes da FORGE sustenta essas fronteiras como responsabilidades explícitas; não como propriedades mágicas de um modelo específico. [HARNESS31-C2]

De prompts para contratos

Um prompt pode orientar comportamento. Ele não é, sozinho, um contrato operacional.

Contratos respondem o que o texto persuasivo costuma esconder:

• qual é o input permitido;
• qual output será aceito;
• o que está fora do escopo;
• quem pode executar cada ação;
• que controle verifica qual propriedade;
• onde o resultado fica registrado;
• quem pode publicar, pagar, apagar ou enviar;
• como corrigir e retirar.

Essa distinção também protege o trabalho da volatilidade do mercado de modelos. Fable, Sol, Terra, Opus, Sonnet e os nomes que vierem depois podem ocupar posições diferentes conforme tarefa, risco, custo e disponibilidade. O papel “Security” não deve significar “sempre use o modelo X”. Ele deve declarar capacidades, ferramentas, limites e responsabilidade. O roster pode mudar sem reescrever a arquitetura inteira.

De papéis decorativos para autoridade delimitada

Dar nomes de cargos a agentes cria uma interface familiar, mas pode esconder uma ambiguidade séria. “Architect”, “Backend” e “Security” descrevem perspectivas; não concedem automaticamente acesso nem autoridade.

Na FORGE, um papel útil precisa responder:

1. que tipo de decisão ele prepara;
2. que ferramentas pode usar;
3. que dados pode acessar;
4. o que pode modificar;
5. que evidência deve produzir;
6. onde precisa parar e pedir decisão humana.

Por isso, a arquitetura é orquestrada por capacidades. Modelos são dependências selecionáveis, não a definição permanente do papel. Essa foi também a resposta à preocupação de manter uma interface que envelheceria toda vez que um fornecedor lançasse uma nova família de modelos.

De “passou” para evidência ligada ao asset

Uma organização aprende pouco quando o resultado de uma verificação é apenas uma cor verde.

Verificação útil informa:

• qual revisão foi examinada;
• qual propriedade o controle observa;
• qual ferramenta e política foram usadas;
• qual relatório foi produzido;
• quem aprovou;
• até quando a conclusão continua válida;
• o que o controle não prova.

É assim que a FORGE separa especificado, observado, aplicado e qualificado. Uma intenção documentada não vira operação por proximidade. Um teste em um commit não certifica outro. Um bom resultado em uma tarefa não autoriza generalização para todas as tarefas.

O sistema de seis movimentos

O que começou como memória organizada se consolidou em seis responsabilidades conectadas:

Intenção

Transforma desejo em outcome, escopo, restrições e definição de pronto.

Política

Define dados, ferramentas, ações, limites e gates que não podem depender apenas da boa vontade do executor.

Execução

Fornece ambiente, identidade, ferramentas e continuidade para realizar o trabalho.

Verificação

Usa controles adequados às propriedades que precisam ser provadas, sem transformar o executor em seu próprio auditor universal.

Evidência

Liga decisão, código, fonte, teste, versão e aprovador ao mesmo resultado.

Feedback

Faz uma correção produzir mudança durável: teste, decisão, padrão, limite ou aprendizado versionado.

Esses planos não exigem uma plataforma enorme. Exigem fronteiras que continuem visíveis quando o experimento cresce.

Por que FORGE

O nome FORGE marcou uma mudança de altitude. JARVIS permanece como origem histórica e codinome interno; FORGE passou a representar o framework: o lugar em que conhecimento humano e capacidade de IA são trabalhados até se tornarem um resultado verificável.

A metáfora importa porque forjar não é apertar um botão. Há matéria-prima, intenção, ferramentas, temperatura, repetição, inspeção e julgamento. Mais energia sem controle não cria uma peça melhor.

Da mesma forma, capacidade de IA não substitui direção. Ela amplia o que um sistema já consegue transformar em trabalho.

O que a FORGE ainda não autoriza dizer

Uma retrospectiva honesta precisa separar direção de prova.

A FORGE organiza controles, contratos e evidência. Isso não significa que todo mecanismo esteja aplicado em todos os produtos, que toda execução seja autônoma ou que um selo interno substitua uma avaliação independente. Estados públicos precisam continuar dizendo o que foi especificado, o que foi observado e qual residual permanece.

Também não existe “modelo oficial para sempre”. Um modelo pode ser melhor para uma tarefa hoje e deixar de ser amanhã. O que deve durar é o contrato que permite avaliá-lo e substituí-lo.

Um roteiro para founders

Antes de construir sua própria plataforma, vale responder:

1. Que decisões você está reconstruindo toda semana?
2. Que conhecimento existe apenas na cabeça de uma pessoa?
3. Que palavra — “pronto”, “seguro”, “validado” — está sendo usada sem critério comum?
4. Que ação externa uma IA jamais deveria executar sem um gate explícito?
5. Que evidência permitiria reproduzir ou corrigir o resultado?
6. Que falha recente alterou permanentemente o sistema?
7. O que precisa continuar verdadeiro quando o modelo mudar?

Comece pelo fluxo que mais custa reaprender. Registre a decisão. Transforme um critério em contrato. Ligue uma verificação ao asset exato. Feche um loop. O framework deve nascer do trabalho real, não de um organograma imaginário de agentes.

Conclusão

A Trustyu criou a FORGE porque memória, talento e velocidade não bastavam para sustentar uma organização que queria aprender com IA sem terceirizar responsabilidade.

Sua tese pode ser resumida assim:

Conhecimento humano define intenção e julgamento. A IA amplia execução. O sistema preserva limites, evidência e aprendizagem.

O valor não está em fazer uma máquina parecer humana. Está em tornar o trabalho conjunto mais claro, repetível e corrigível do que seria com qualquer uma das partes isoladamente.

Próxima leitura: O modelo não é o sistema, que detalha por que capacidade de modelo ainda precisa de um engineering harness.