A Palantir chamou arquiteturas como a nossa de "denatured markdown files" na DevCon 5 de abril de 2026. Setenta e duas horas depois, absorvemos os nove vídeos, adotamos seis termos do vocabulário deles, rejeitamos três decisões arquiteturais com razão declarada, e implementamos três skills novas no sistema a partir do que a DevCon sugeriu.
Este artigo é o registro desse ciclo. Não é análise externa. É o processo de absorção declarado publicamente, com paths e commits.
O ponto do artigo é: o próprio ciclo de absorção é Ontologia Operacional em execução. O que a Palantir descreve em keynote, a FSTech exerce em produção. Your Ontology Is Your Alpha, inclusive quando a Palantir é quem diz.
Três Frases Que a Palantir Declarou (e a FSTech Já Operava)
Três citações literais, de três vídeos diferentes da DevCon:
- "The ontology is effectively the software that's powering your organization." (Landon, vídeo #10 Advanced Ontology)
- "You need AI to produce alpha, distinct value that builds around your tribal knowledge and your unique advantages." (Akshay Krishnaswamy, CTO, vídeo #02 Opening)
- "Agents building agents building agents." (vídeo #04 AI FDE)
Juntas formam a tese: ontologia é o software da organização, alpha exige tribal knowledge codificado, agents compõem recursivamente. Esse é o vocabulário do framework de Ontologia Operacional que publiquei poucos dias antes da DevCon. Não é reverência. É convergência documentada.
Seis Temas Recorrentes: Onde Convergimos, Onde Tínhamos Gap
A análise cross-videos identificou seis temas repetidos em três ou mais vídeos. Agrupados por status FSTech.
Onde já convergimos (paradigma idêntico, execução idêntica)
- Ontology como substrato compartilhado (aparece em 7 vídeos). Palantir redefine ontologia como shared mutable state para humanos e agentes. Operamos assim há meses: memory, Pin/Spec e logs JSONL são nosso shared substrate.
- Human-in-the-loop não-removível (5 vídeos). Nenhum vídeo da DevCon propõe autonomia total. A FSTech também não propõe. Mensagens externas aguardam aprovação explícita do operador, commits são review manual.
- Separation of concerns com contexto curado (3 vídeos, declarada best practice em #11). Anti-pattern explícito é passar "o arquivo inteiro" para sub-agent. Convergência em teoria (Pin/Spec), prática às vezes mais frouxa.
Onde havia gap real (paradigma idêntico, execução nossa atrasada)
- Eval-Driven Development (4 vídeos). Ordem canônica: logic function, eval suite, measure, debug, prod. Só o OntosAI rodava eval antes desta semana. Outros agentes operam em prod sem eval automático. Gap reconhecido, não fechado ainda.
- Feedback estruturado linkado (4 vídeos). Não é log. É objeto ontológico com execution_id, prompt version, modelo, input e correção. Gap fechado em 14/04: logs JSONL em
01_operacoes/logs/feedback/substituíram o antigomemory/feedback_*.mddesconectado. - Adversarial review automática no pipeline (3 vídeos). Não é verify reativo. É agente crítico automático rodando após toda saída. Gap fechado via skill
/annealment(seção abaixo).
Seis Termos Que Passamos a Usar (Com Orgulho Declarado)
Vocabulário externo validado entrou em propostas, posts e framework. Não mímica, confirmação de que a FSTech estava escrevendo a mesma coisa com palavras piores.
| Termo | Uso FSTech agora |
|---|---|
| Alpha vs Beta (vantagem proprietária vs commodity) | Frame master do SyaaS. Ontologia Ativa = alpha. Automação comoditizada = beta. |
| Annealment (recozimento iterativo) | Nome próprio do refinamento iterativo via critique adversarial. Virou skill /annealment. |
| Grounding mechanism | Ontologia como âncora que impede agentes de alucinar sobre o estado do sistema. |
| Encoded intelligence | Tribal knowledge codificado em artefatos versionados (pins, specs, logs). |
| Shared substrate | Memory, Pin/Spec e logs JSONL como camada comum humano-agente. |
| Compound value | Valor que cresce com uso. Justificativa da cobrança mensal pela Ontologia Ativa. |
Três Decisões da Palantir Que Rejeitamos (Com Razão)
Nem tudo foi absorvido. Três pontos rejeitados ativamente.
Dynamic agent generation (Hivemind #08). A Palantir gera agentes on-the-fly a partir do contexto do problema. A FSTech mantém roster fixo (Ares, Ontos, Finn, Chava). Razão: relacionamentos contínuos exigem identidade persistente. O Finn atende o Anderson há meses. Identidade rotativa quebraria o vínculo. Dynamic generation só faz sentido em one-shot problems.
Schema tipado obrigatório (vídeos #06 e #10). A Palantir aposta em ontology database tipada com SDK auto-gerado. A FSTech mantém markdown com YAML frontmatter informal. Razão: soberania e flexibilidade têm valor maior do que type safety nesta escala. Trade-off declarado, não limitação.
Hosted Foundry como default. A Palantir vende Foundry hosted. A FSTech vende ontologia soberana (filesystem do operador, zero lock-in). Razão arquitetural: tribal knowledge é patrimônio do operador, não do fornecedor. Lock-in hosted viola esse princípio.
A própria DevCon validou parcialmente a rejeição 3. O vídeo #07 anunciou embedded ontology rodando no laptop, sem conexão ao Foundry. A Palantir descendo para local-first valida o paradigma que a FSTech opera há meses.
Três Primitivas Implementadas em 72 Horas (Com Ponteiros)
O ponto que distingue absorção real de leitura passiva: gaps identificados viraram código executável no sistema. Entre 14 e 15 de abril, três skills foram escritas, testadas e registradas.
/annealment (origem vídeo #08 Hivemind, conceito de annealment iterativo). Skill de refinamento via cinco critiques adversariais paralelos (clareza, acurácia, tom, FSTech-fit, persuasão). Aplica-se a propostas, posts e análises antes de mostrar ao operador. Validada em dois casos reais esta semana: primeiro, a thread de anúncio desta absorção detectou duas issues críticas que revisão rápida perderia (citações falsamente atribuídas a Akshay e violação de posicionamento); segundo, este próprio artigo passou pela skill antes de você lê-lo.
/opcoes (origem vídeo #08 Hivemind, multi-option ideation). Skill que pega um dilema estratégico, dispara três subagents paralelos defendendo opções divergentes, monta matriz comparativa numerada e produz recomendação com condição de reversão explícita. Testada em caso comercial real. A recomendação final emergiu da síntese do orquestrador, não de nenhum subagent isolado, exatamente o padrão que a Palantir descreve em Hivemind.
/refatorar (origem vídeo #11 Army Software Factory). Pipeline 5-stage para migração de código não-trivial: decompose (regex, não LLM), warnings com human checkpoint, recon human-readable com segundo checkpoint, decode para pseudo-code JSON, encode com side-by-side comments. Dormente até caso real de migração aparecer, registrada como disponível.
Além das três skills, duas primitivas de infra foram implementadas na mesma janela: feedback estruturado linkado via JSONL (fechando gap recorrente em quatro vídeos) e await-on-condition com watcher cron unificado (fechando gap de polling espalhado, origem vídeo #05).
Cinco primitivas em 72 horas. Não por virtuosismo de velocidade, mas porque a Ontologia Operacional força write-back. Insight sem alteração do sistema é lixo computacional.
Resposta ao Ataque Denatured Markdown (Contra-Ataque Primeiro)
O único ataque frontal a arquiteturas como a FSTech em toda a DevCon merece resposta na mesma moeda.
Contra-ataque primeiro. O vídeo #07 da mesma DevCon anunciou embedded ontology local, rodando direto no laptop do dev, sem conexão ao Foundry. Ou seja, a Palantir está descendo para o paradigma que a FSTech opera há meses. Local-first não é ideia da FSTech nem da Palantir, mas a Palantir reconhecendo em conferência oficial é endosso involuntário.
Concessão honesta no que é real. Schema informal não escala para Fortune 500 com milhões de objetos interdependentes. Para essa escala, database tipada com SDK e derived properties é a resposta. Palantir está certa nesse ponto específico.
Ponto inválido no resto. Para operações com tribal knowledge real e bem curado (prestadores, núcleos familiares, times de produto, operadores soberanos de qualquer tamanho abaixo do F500), markdown com frontmatter e search hybrid é grafo semântico emergente. Mais de 500 docs indexados respondem em menos de 10ms. Limite prático: cerca de 10k docs, suficiente por anos para qualquer operador abaixo de enterprise.
Assimetria final. Quando a dor chegar, migração é trivial porque os dados já estão com o operador. Markdown para database tipada é um script de parsing. Foundry para outro stack é renegociação de contrato e exfiltração de dados hosted. A soberania resolve isso por construção, não por feature.
A Pergunta de Três Anos
A convergência estratégica entre Palantir e FSTech é ordens de grandeza maior que a divergência arquitetural. Em três anos, a pergunta comercial dominante não será "markdown ou database tipada".
Será: quem codificou tribal knowledge em artefatos operáveis, e quem ainda depende de pessoas carregando o sistema na cabeça?
Operações que não codificarem o alpha em camadas D+L+A (Dados, Lógica, Ação) vão competir com operações que codificaram. Ferramenta importa menos que disciplina. O método é Ontologia Operacional. A aposta aqui: metade dos operadores com ambição de escala vai ter algo parecido com OO rodando; a outra metade vai estar sendo comprada, extinta ou capturada por fornecedor hosted.
A FSTech aposta no primeiro grupo.
Próximo Passo (Se Você Constrói Agente)
Framework canônico: fstech.digital/framework (licença CC BY 4.0, 13 seções, cases reais em produção documentados).
Se você constrói agente hoje:
- Leia o framework antes de escolher stack (45 minutos).
- Rode Pin/Spec em um projeto real esta semana. Um projeto pequeno, com tribal knowledge real, operável por humano e agente sobre o mesmo arquivo.
- Se quebrar, me diz o que quebrou. O framework está aberto exatamente para isso.
A convergência entre Palantir e FSTech confirma o paradigma. O que muda é quem detém o alpha: fornecedor hosted, ou operador local e soberano.
