Construí um sistema que leu 4.500+ conteúdos e me diz o que vai acelerar em tech antes de virar óbvio
stack: postgres + pgvector, embeddings, three.js pro grafo, e um radar 100% determinístico (SQL, zero LLM no cálculo)
o LLM só entra DEPOIS — e desconfiando dos dados 🧵
O artigo sobre frameworks de decisão acerta num ponto que ninguém conecta a IA: a maioria das pessoas não trava por falta de opção. Trava por falta de critério. Agente nenhum resolve isso — ele herda.
Pense no que um agente faz de verdade: ele propõe. Gerar texto, gerar query, gerar plano. Quanto mais opções ele produz, mais o humano precisa de critério para escolher. Automação sem framework de decisão não acelera nada; multiplica a indecisão.
Os dez princípios práticos do artigo são, no fundo, critérios de parada. E critério de parada é exatamente o que separa demo de sistema: avaliação, gate, limiar de aceite. É o mecanismo que converte geração em decisão.
O anti-hype aqui é simples: a produtividade do agente não vem da velocidade com que ele gera. Vem da clareza com que você define o que aceita. Se você não sabe responder o que é bom o bastante, o agente só aumenta a pilha de plausíveis.
Frameworks de decisão parecem autoajuda até você colocar um agente em produção. Aí eles viram requisito de arquitetura.
A maioria das empresas guarda a regra fiscal na cabeça de alguém. O Databricks Summit fala de governança de dado; o teste real é tirar a regra da cabeça e colocar em código versionado.
Regra fiscal muda — crédito, exceção, CFOP, tratamento de CST. Sem versionamento, cada fechamento reinterpreta o passado. O mesmo número sai diferente dependendo de quem fecha e de quando.
Tratar regra como código significa histórico, teste e rollback. Você passa a responder não quanto deu a margem, mas com qual versão de regra essa margem foi calculada. É a diferença entre relatório e evidência.
Lineage de margem é o que conecta NF-e, estoque, COGS e Material Ledger a essa regra versionada. Sem o fio, o número é bonito e indefensável. Com o fio, ele sobrevive ao auditor e à própria reforma tributária.
No fim, o Summit serve de lembrete: engenharia de dados fiscal não é sobre pipeline rápido. É sobre decisão que você consegue reabrir e explicar seis meses depois.
A automação fiscal que você está planejando já nasceu condenada. Não por causa do modelo. Por causa do cadastro que sustenta ela.
NCM, CEST, CFOP, regras de crédito. Isso não é burocracia acessória; é a espinha dorsal do dado que alimenta nota, apuração, crédito e margem. Quando cada time preenche do seu jeito, o cadastro vira um dicionário com várias línguas.
O buraco está entre dois clusters: fiscal trata o cadastro como obrigação, dados trata como tabela. Nenhum trata como ativo. Enquanto isso, a reforma tributária transforma esse cadastro de requisito acessório em pré-condição de apuração correta.
IA em cima de cadastro sujo não inventa erro novo. Ela fotografa o erro antigo, dá a ele escala de produção e aparência de auditoria. O problema fica maior, não menor — só que agora com um sistema validando.
Antes de comprar automação, responda uma pergunta de dono: quem garante que o cadastro fiscal está são, de ponta a ponta, hoje? Se ninguém, a IA vai só acelerar a descoberta disso — no fechamento.
A reforma tributária não é um problema de IA. É um problema de dado mestre. E ela está prestes a expor, na sua operação, exatamente o que você nunca saneou.
NCM, CEST, CFOP, regra de crédito, exceção operacional. Tudo isso é dado mestre fiscal. Sem saneamento, qualquer automação ou IA que você colocar por cima só amplifica o erro, na velocidade da máquina.
É a mesma lógica do TCO: você não tem evals do seu cadastro. Ninguém mede se o dado fiscal que alimenta a automação está certo, errado ou desatualizado. A máquina escala o que nunca foi auditado.
Antes de escolher ferramenta, separe as decisões por impacto econômico, risco operacional e capacidade interna. O que muda sua margem? O que te expõe? O que seu time consegue manter sem depender de você?
Nem toda frente merece IA. Merece, primeiro, um inventário de dado e processo. Para quem quer fazer esse corte sem tese pronta, vale uma análise dedicada, não uma demo.
Um agente editorial em retry tende a girar em círculo. Muda a primeira frase, troca um adjetivo e devolve a mesma tese com outro sotaque. O problema não era o modelo. Era a ausência de critério de parada.
Mudei a arquitetura. Cada candidato agora precisa declarar o mecanismo do argumento, não o texto. Se dois candidatos declaram o mesmo mecanismo, o segundo morre antes de chegar em humano.
Diversidade virou dado, não estilo. Uma memória registra abertura, exemplo central e tese de tudo que já foi rejeitado. O retry é julgado contra essa memória, não contra o último draft.
O aprendizado vale para qualquer sistema de IA aplicada: qualidade não está no prompt. Está no que você define como suficiente e no que você recusa antes de publicar.
Construir em público me ensinou que o artefato mais valioso não é o texto que sai. É a regra que decide o que não sai.
No século XIX, a Grã-Bretanha não roubou só o chá da China. Roubou o processo: as plantas, os trabalhadores e a técnica de cultivo que nenhum manual descrevia. O produto era barato. O conhecimento era o ativo.
O paralelo com IA é incômodo porque é exato. Toda empresa tem um chá: o conhecimento operacional que vive na cabeça de quem fecha o mês, resolve a exceção, corrige o CFOP. Não está documentado em lugar nenhum.
Um agente de IA não aprende o que você documentou. Aprende o que observa, inclusive o atalho, o jeitinho, o critério implícito que ninguém admitiu por escrito. Se você não sabe o que possui, não percebe quando está sendo extraído.
O risco não é o modelo vazar. É o processo escorrer para dentro de um sistema que você não controla, sem que você tenha registrado o valor do que está saindo.
Antes de deixar um agente tocar no seu workflow, faça o inventário do conhecimento operacional: regras, exceções, critérios de decisão. O que você não consegue escrever, você vai perder, por agente, por rotatividade ou por erosão.
No Databricks Summit, a conversa gira em torno de plataforma e pipeline. Só que o fechamento fiscal não quebra por falta de pipeline. Quebra quando a regra muda e o sistema não guarda a versão anterior.
Regra fiscal sem versionamento vira interpretação a cada fechamento. O mesmo crédito, o mesmo CFOP, decidido de um jeito em janeiro e de outro em março. Sem diff, sem histórico, sem teste.
Engenharia de dados fiscal trata regra como código. Cada mudança é um commit com autor, motivo e teste. Cada número de margem carrega o lineage: NF-e, estoque, COGS, Material Ledger e a regra fiscal que o originou.
A medallion organiza o lago. Mas organizar não é provar. Prova é o fio que liga o documento fiscal ao número que o board assina, reconstruível por qualquer auditor, não só por quem conhece o sistema.
Plataforma não conserta decisão. O que consagra a margem é disciplina de versionamento e lineage. É o que separa o dado que informa do dado que defende o fechamento.
O time que compra o modelo não conversa com o time que opera o modelo. E nenhum dos dois conversa com o time que paga a conta. Esse buraco é o TCO real da IA.
Escalar IA sem evals é ampliar uma linha de produção sem controle de qualidade. Você dobra a capacidade sem saber se o output melhorou, piorou ou só mudou de roupa. Ninguém mede, então ninguém responde.
O custo não aparece na fatura de API. Aparece no retrabalho silencioso, na decisão tomada com confiança errada e na governança que descobre o problema três meses depois.
FinOps mede custo por token, por request, por hora de GPU. Mas não existe coluna de qualidade de output ao lado da coluna de custo. É aí que a conta cresce sem dono.
A pergunta de CFO não é quanto custa o token. É quem assina que o output de hoje vale mais que o de ontem. Sem evals, ninguém assina.
Você já decidiu construir. A pergunta que separa lucro de experimento agora é outra: qual é o motivo de fallback mais caro do seu agente em produção?
Fallback não é detalhe técnico. É custo: cada vez que o agente desvia para uma resposta mais barata, mais lenta ou manual, alguém paga a diferença — em tempo, em margem, em confiança.
Sem trace, latência, taxa de erro e motivo de fallback, você não sabe se está pagando automação ou pagando para ter uma fila disfarçada de IA.
A qualificação de hoje é direta: quem leva TCO a sério mede o custo do que não funcionou, não só o do que rodou. E é exatamente isso que pede uma análise dedicada do workflow, não um relatório de consumo de token.
Se a sua resposta para "por que o agente fez fallback?" for "não sei", você não tem um sistema de IA. Você tem uma despesa com interface bonita.
O mais difícil de construir no ClawScribe não foi gerar texto. Foi ensinar o sistema a não publicar.
A primeira versão escrevia sobre qualquer coisa. Aí entrou o critério de parada: se a fonte é parcial, se a tese repete a memória recente, se o pilar não tem fonte de domínio, o draft não sai.
Parece antiprodutivo. Uma máquina que se recusa a entregar? Mas foi exatamente isso que aumentou a taxa de aprovação humana. Menos lixo, mais densidade.
O trade-off é honesto: um gate de parada custa volume. Você perde posts que passariam raspando. Mas ganha o único ativo que importa num sistema editorial — confiança de quem revisa.
Se eu tivesse que resumir a lição: em sistema de IA que produz para humano, o critério de parada vale mais que o prompt. O prompt te dá texto. O critério de parada te dá reputação.
Todo ano o Databricks Summit enche o palco de medallion, lineage e governança. A prova real dessas promessas não está no keynote. Está no fechamento do mês.
Margem confiável exige um fio contínuo entre NF-e, estoque, COGS, Material Ledger e regra fiscal. Quando esse fio não existe, o número do dashboard parece preciso. E não sobrevive a uma auditoria.
O problema não é o volume de dados. É o lineage. Você sabe o valor final da margem, mas não consegue refazer o caminho que levou até ele. Linhagem é o que separa um número de um número auditável.
Regra fiscal é código. Quando ela muda sem versionamento, cada fechamento vira interpretação. A engenharia de dados fiscal precisa de histórico, teste e rollback de regra — igual a qualquer sistema em produção.
Medallion ajuda, mas não resolve sozinho. Bronze, silver e gold organizam o dado; não dizem qual regra fiscal estava valendo quando o COGS foi calculado. Isso é decisão de arquitetura, não de plataforma.
A pergunta executiva não é "qual ferramenta". É: você consegue explicar a margem de trás para frente, da linha do balanço até a NF-e que a originou? Se não, o palco do summit não te salvou do problema.
A pergunta que chega no board é "compramos ou construímos IA?". Ela está errada. Ninguém compra nem constrói "IA". Você decide workflow por workflow.
O mesmo negócio pode comprar resumo de e-mail, construir reconciliação fiscal e simplesmente banir agente em qualquer fluxo que toque caixa. Não é uma decisão de tecnologia. É uma decisão de portfólio.
O buraco aparece quando cada time decide a sua parte. O CFO vê a fatura das licenças. A engenharia vê o custo de construir. A operação vê o workflow caindo. Ninguém enxerga o workflow inteiro com custo, risco e dono na mesma linha.
A IA que não se paga quase nunca é problema de modelo. É problema de decisão fragmentada: workflow errado escolhido, custo invisível aceito, dono ausente.
Antes de discutir comprar versus construir, liste os workflows que tocam receita, caixa ou imposto. Para cada um, pergunte: esse é de comprar, de construir ou de proibir?
Você vai automatizar a transição fiscal sem telemetria. Isso não é projeto. É aposta.
Sem trace, latência, taxa de erro, motivo de fallback e custo por workflow, a IA vira centro de custo opaco. Você sabe quanto gastou. Não sabe o que o gasto produziu — nem onde o dinheiro vazou.
O elo com a dor do cadastro: dado mestre sujo não trava o robô. Ele roda, classifica errado, e o erro só aparece lá na frente, na conciliação. Sem observabilidade, você descobre o retrabalho quando ele já virou passivo fiscal.
Observabilidade não é luxo técnico. É contabilidade do sistema. É o que transforma a IA que está rodando em IA que está se pagando — ou mostra que não está, antes do trimestre fechar.
Antes de escalar a automação da transição, mapeie onde o custo e o erro vão nascer. Quem não mapeia paga duas vezes: uma pelo robô, outra pelo conserto. O caminho mais barato é uma análise dedicada do fluxo antes do go-live.
A gente passou mais tempo escrevendo o rollback do que o fluxo. No começo parecia burocracia. Depois deu para ver que era isso que separava a automação de uma bomba-relógio.
Toda automação sem runbook vira dependência invisível. Se o passo quebra e ninguém sabe como voltar, você não tem processo — tem memória tácita morando na cabeça de uma pessoa. E memória tácita não escala, não audita, não se transfere.
O bastidor que ninguém mostra: antes de automatizar, a gente documentou deploy, rollback, migration, smoke test e critério de parada. Não é papel para auditoria. É o contrato que diz até onde o sistema anda sozinho e onde a mão humana entra.
O critério de parada foi o que mais mudou o desenho. Quando você define o gatilho que interrompe o agente — o erro, o custo, a latência — a arquitetura muda. Você deixa de construir para o caso feliz e passa a construir para o caso que dói.
Automação boa não é a que roda. É a que tem como parar. Runbook antes de automação — ou você herda uma dependência invisível.
O segundo cérebro não vale pelo que ele guarda. Vale pelo que ele conecta que você não conectaria sozinho.
No ClawCosmos, uma ponte semântica aproximou três nós que a busca por palavra-chave jamais juntaria: uma narrativa especulativa — Musk fundindo xAI com SpaceX e comprando a Cursor por US$ 60 bilhões —, o cluster de agentes de IA e o cluster de automação. A conexão não estava escrita em nenhum documento. Ela emergiu do grafo.
O mecanismo tem três forças. Embeddings medem proximidade de significado, não de texto. Centralidade mostra quais nós sustentam a estrutura e por isso valem leitura. Frescor penaliza o que envelheceu: uma ponte com frescor 0,96 é conexão nova, não arquivo morto.
É isso que separa context engineering de guardar mais uma nota. Não basta armazenar. É preciso recuperar, conectar, priorizar e entregar a conexão certa no instante exato da decisão. A nota solta é passivo. A ponte é ativo.
GraphRAG e segundo cérebro falham por falta de ponte, não por falta de dado. A pergunta não é quanto contexto você acumula. É qual conexão ele te mostra que os outros não veem.
No Databricks Summit, medallion vira arquitetura de vitrine. Bronze, silver, gold — o slide é bonito. A pergunta que quase ninguém faz: o que garante que uma camada entrega o que a próxima precisa?
Em dado fiscal, isso não é detalhe. Bronze tem que preservar evidência: o registro bruto, o documento, a exceção operacional como ela aconteceu. Silver normaliza regra: NCM, CEST, CFOP e critérios de crédito virando contrato versionado. Gold responde decisão: margem, COGS, reconciliação.
O Material Ledger do SAP não perdoa camada frouxa. Linhagem, granularidade e versionamento de regra são o que separam um número de margem confiável de um número que muda a cada reabertura.
IA em cima disso só ajuda se o dado já carrega contrato entre camadas. Sem contrato, o lake não vira fonte de decisão — vira repositório de dúvida.
Medallion sem contrato entre camadas é só nomenclatura. A margem só responde quando bronze, silver e gold sabem o que devem um ao outro.
A reforma tributária não vai quebrar pela regra. Vai quebrar pelo cadastro.
NCM, CEST, CFOP, regras de crédito e exceções operacionais não são detalhe de digitação. São dado mestre. É sobre eles que a automação e a IA vão calcular, classificar e apurar.
O buraco está entre dois times que não se enxergam. O fiscal lê a transição como mudança de norma. O time de dados e IA lê como mudança de pipeline. Nenhum dos dois trata o cadastro como a infraestrutura que conecta os dois.
O resultado é previsível: automação sobre cadastro sujo só acelera o erro. A IA não erra por falta de modelo. Erra porque o dado mestre que alimenta a decisão nunca foi saneado.
Antes de discutir qual modelo apura imposto, discuta quem é dono do cadastro. Essa é a pergunta que separa transição de retrabalho.
Quem escala agente sem dono para o custo de estado está financiando a própria perda de margem. Agora a pergunta vira de valuation.
O mercado precifica IA pela capacidade de gerar. A operação paga pela capacidade de manter. Quando o custo de estado não tem dono, ele escapa do EBITDA e reaparece no múltiplo por outro caminho.
A mesma disciplina aparece na transição tributária. Tratar CBS/IBS, NF-e, cadastros e conciliação como arquitetura de dados e processo, não como ajuste cosmético, é o que separa quem captura margem de quem perde margem na transição.
Não é sobre automação. É sobre ter um modelo de apuração que resista a auditoria: lineage, versionamento de regra e controle de mudança.
Se você quer qualificar essa leitura para o seu caso, o caminho é uma análise dedicada de onde custo de estado e risco fiscal se encontram. Sem promessa de mágica: com desenho de responsabilidade.
No ClawScribe, o objeto que mais mudou o resultado não foi o prompt. Foi o runbook de rejeição do lote.
Antes de revisar item a item, o sistema aplica travas de consistência: pilares distintos, no máximo um post por pilar, nenhuma abertura repetida, nenhuma tese já publicada. Se o lote falha em qualquer trava, ele é descartado inteiro e regenerado.
A primeira versão do runbook era pequena demais. Só conferia quantidade. Depois que entrou critério de diversidade e de pilar, a taxa de rejeição subiu, mas a revisão humana ficou mais rápida.
A lição não é técnica. É que baratear no filtro de entrada empurra o custo para a revisão humana. Rejeitar cedo, por regra mecânica, é mais barato que corrigir peça a peça.
Esse tipo de construção só aparece em bastidor. Não é produto validado, é decisão de arquitetura editorial documentada para ser auditada.
A tese do head de design da OpenAI parece contraintuitiva: o melhor momento da história para designers, justamente quando engenheiros capturaram mais ganho de produtividade.
O mecanismo é escassez de contrato, não de tela. À medida que o agente escreve, chama ferramenta e executa fluxo, o gargalo deixa de ser gerar output e vira especificar o que é aceitável: estados de erro, permissões, escalonamento humano, formato de decisão.
Design de produto vira governança de comportamento. Quem desenha a interface define o que o agente não pode fazer, onde ele para e quem assume. É isso que separa demo de sistema em produção.
Daí a ponte com slow down to speed up. Antes de acelerar a geração, desacelere para fechar o contrato de comportamento. Sem isso, cada output ambíguo vira correção humana, e o custo da correção estoura o time em burnout.
A pergunta executiva: quanta taxa de intervenção humana o seu agente projeta? Se você não sabe, você não tem produto de IA. Tem dívida de design.