Em julho escrevi aqui que o prompt virou contrato: a relação com os modelos deixou de ser conversa improvisada e passou a ser engenharia de camadas de contexto. Neste ensaio quero contar a história de um produto que levou essa ideia até a última consequência. O Hermes Agent, da Nous Research, foi lançado em fevereiro de 2026 e chegou a agosto com 231,5 mil stars no GitHub, presença em mais de 20 plataformas de mensagem e um fato que resume a tese inteira: hoje o maior contribuidor do código do Hermes Agent é o próprio Hermes Agent.

A fonte principal é a entrevista de 46 minutos que Karan Malhotra, cofundador da Nous Research, deu a Peter Yang no podcast Behind the Craft, publicada em 2 de agosto. Cruzei o relato dele com o repositório oficial, a documentação do produto e as coberturas de funding da Fortune e do Dealroom. Organizei o argumento em seis pontos: a origem quase acidental da empresa, o precursor que ficou engavetado, o produto que saiu do gelo, a tese técnica que o diferencia, o loop de self-improvement que virou fato mensurável e o modelo de negócio que sustenta a bandeira open source. No fim, as lições que enxergo para empresas brasileiras.

01. Dois amigos num Discord

A Nous Research nasceu em 2023 de uma sequência de improvisos bem executados. Karan Malhotra fazia consultoria de “chat com PDF” usando GPT-3 com tool use rudimentar para ler documentos de empresas. Nas horas vagas, era voluntário no projeto Open Assistant e ajudava a quantizar modelos para a comunidade. Por essa via chegou ao coletivo LAION, que rodava RLHF comunitário e dispunha de 8 nós de A100, um luxo raro para pesquisadores independentes naquele momento.

Quando saiu o paper do Alpaca, Karan replicou a receita com duas trocas: substituiu as seed tasks e usou GPT-4 no lugar do GPT-3.5 para gerar os dados de treino. Descobriu pelo Twitter que um amigo, conhecido pelo pseudônimo Teknium, fazia exatamente o mesmo experimento. A proposta que fundou a empresa coube numa mensagem: tenho 8 nós de A100, quer treinar algo junto?

O primeiro treino conjunto, sobre o modelo Vicuna, saiu razoável e atraiu interesse de gente como Jeffrey Quesnelle, que viria a ser o CTO. A repetição do mesmo run sobre o LLaMA base mudou de patamar: Karan relata centenas de milhares de downloads em poucos dias. A Nous, nesse momento, era literalmente dois amigos num Discord. Houve empresa acusando o duo de treinar em cima de benchmarks para inflar resultados, e a defesa de Karan é o retrato do período: eles nem sabiam direito o que eram benchmarks. Teknium programava havia menos de um ano e Karan era formado em religião. Testes independentes acabaram confirmando que os fine-tunes da dupla estavam entre os melhores abertos de meados de 2023.

Dali em diante a linha de modelos Hermes virou a marca registrada da casa, conduzida por Teknium e pelo time de post-training, com mais de 50 milhões de downloads acumulados segundo Karan. O grupo de voluntários virou laboratório full-time por proposta de Dillon Rolnick, hoje CEO, e formou uma coorte de cerca de 40 pesquisadores. Do corpo de pesquisa saíram peças que o mercado inteiro usa: o YaRN, método de extensão de janela de contexto de 16K para 128K tokens assinado por Quesnelle e Bowen Peng, citado por Meta, DeepSeek e Kimi, e o DisTrO, otimizador distribuído que permitiu treinar modelos de até 40 bilhões de parâmetros sem colocação física das GPUs.

02. O precursor engavetado e o motivo real

O Hermes Agent tem um predecessor espiritual chamado Forge, demonstrado num demo day nos escritórios do GitHub anos antes do lançamento. O Forge foi posto no gelo por uma razão honesta que o mercado raramente admite: os modelos ainda não estavam à altura do harness. Guardar um produto bom esperando o substrato amadurecer é uma decisão de disciplina que poucos times têm estômago para tomar.

O degelo veio de uma observação estratégica. Teknium percebeu que Codex e Claude Code funcionavam, na prática, como ambientes de reinforcement learning para os laboratórios que os operam: os traces de uso dos usuários alimentam o treino dos próximos modelos dentro de um harness fechado. A conclusão dele foi que precisava existir uma versão aberta desse mecanismo, apoiada no Atropos, o microserviço de ambientes de RL da própria Nous. Há também uma linhagem menos óbvia: o WorldSim, experimento em que o modelo opera um CLI fictício criando aplicações fictícias, ensinou o time a tirar o modelo do modo assistente genérico, e Karan conecta esses aprendizados diretamente ao design do agente.

O agente saiu gratuito e open source, sob licença MIT. Karan resume a sequência sem épica: o produto se mostrou extremamente capaz, ganhou a comunidade, e a empresa decidiu investir tudo nele.

03. O agente que cresce com você

Os números de agosto de 2026 dão a dimensão do que aconteceu em seis meses. O repositório marca 231,5 mil stars, 46 mil forks e 23.203 commits. O projeto cruzou 140 mil stars em menos de três meses de vida, e um post oficial da NVIDIA o descreveu como o agente mais usado do mundo segundo o OpenRouter. A descrição do episódio o posiciona como número 1 entre agentes pessoais e apps de IA de uso geral nesse mesmo ranking.

A superfície do produto explica parte da tração. O Hermes roda como CLI, TUI, aplicativo desktop, dashboard web e servidor ACP para IDEs, e conversa com o usuário por mais de 20 plataformas de mensagem via gateway: Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Teams, email e SMS entre elas. Traz 6 backends de terminal (do Docker local ao Modal), mais de 60 ferramentas nativas, agendamento cron, subagentes paralelos, suporte a MCP e skills no padrão aberto agentskills.io. Funciona em Linux, macOS, Windows, WSL2 e até Android via Termux.

A decisão de arquitetura mais importante, porém, é ser agnóstico de modelo. O Hermes opera com qualquer provedor: OpenRouter, OpenAI, Anthropic, Google, xAI, DeepSeek ou modelos locais. O slogan oficial, “the agent that grows with you”, aponta para onde a Nous acredita que mora o valor: o agente cria skills a partir da experiência, melhora essas skills durante o uso, persiste memória, busca nas próprias conversas passadas e refina o modelo interno de quem é o usuário entre sessões. O produto aposta que essa camada acumulada, e ela apenas, é o que o usuário não vai querer abandonar.

04. Tudo no harness é gestão de contexto

A tese técnica do Hermes cabe numa frase de Karan: tudo no harness é gestão de contexto. Ele afirma na entrevista que in-context learning é mais poderoso que qualquer alternativa, incluindo fine-tuning. Memórias e skills, nessa leitura, são armazenamento de contexto que precisa entrar na janela do modelo no momento certo, e o trabalho do harness é decidir o que entra, quando entra e o que fica de fora.

Isso resolve um problema que qualquer um que opera agentes conhece: skills demais incham o contexto e degradam o desempenho. A resposta do Hermes é um curador automático, o Hermes Curator, que roda via cron dentro do próprio agente, limpando skills e memórias onde há desperdício e consolidando onde há ganho de eficiência. O usuário pode reprogramar os critérios do curador. É manutenção de conhecimento tratada como rotina operacional, e é exatamente o tipo de mecanismo que separa um agente que melhora de um agente que acumula entulho.

Há uma camada comportamental na mesma tese. A Nous declara que os prompts do sistema carregam zero política arbitrária alheia ao trabalho do usuário, e Karan formula a filosofia em termos de lealdade: o agente deve ficar mais leal ao usuário com o tempo, porque lealdade gera capacidade. A frase mais citada do episódio ataca a bajulação dos assistentes atuais: quando o modelo diz “you’re absolutely right” daquele jeito, você está sendo alvo de reward hacking, virou combustível da função de recompensa dele. Karan chega a afirmar que o Claude tem desempenho melhor dentro do Hermes Agent do que dentro do Claude Code, e resume a provocação numa imagem forte: tiramos a lealdade principal do Claude da Anthropic e demos a você. Registro as duas afirmações como claims do entrevistado, sem benchmark independente anexado, mas elas explicitam o produto que a Nous acha que está construindo: um harness que muda o comportamento do modelo que roda dentro dele.

05. O maior contribuidor de si mesmo

Peter Yang encerra a entrevista testando o claim que dá título ao capítulo final: seria verdade que o maior contribuidor do Hermes Agent é o próprio Hermes Agent? Karan confirma duas vezes, chamando o fato de absolutamente cem por cento verdadeiro: o agente é o contribuidor mais ativo do próprio repositório. O time usa o Hermes para desenvolver o Hermes, com humanos e agentes dividindo o mesmo Kanban, intercambiáveis na orquestração. Karan descreve cenários em que dez atendentes de call center são instruídos por um Hermes dentro do board, e relata proatividade emergente em agentes de usuários: o agente que avisa que a passagem da semana que vem não foi comprada e informa que já resolveu, sem cron agendado, apenas com o nível de permissão adequado.

A demonstração mais visceral do episódio, porém, vem de um videogame. Karan pediu ao Hermes para extrair o ancestral shrine do Sonic Adventure 1, riggar e animar os assets, portar tudo para o Sonic Adventure 2 sobrescrevendo o jardim dos Chao, reescrever spawns, adicionar um NPC guardião com random walk e animações, água com colisão, ciclo de dia e noite e skybox. O trabalho foi feito com Claude rodando dentro do Hermes. A comunidade de modding de Chao Garden, que é grande e veterana, classificou o resultado como melhor que 99 por cento dos modders em uma tarefa de dificuldade de topo, e reagiu com choque ao saber que era IA, porque modelo nenhum conhece aquela codebase obscura. A explicação de Karan fecha o argumento do ensaio: o Hermes estudou a documentação e os mods existentes, e salvou em memória e skills o entendimento que construiu da codebase. O conhecimento foi fabricado pelo harness e guardado na camada de contexto, fora dos pesos do modelo.

06. A bandeira e o caixa

A Nous se define como laboratório de pesquisa de IA open source, e Karan não relativiza a bandeira: eles querem que o open source vença, tratam inteligência como bem público antes de qualquer outra coisa, e leem o debate de segurança entre labs fechados e abertos como um jogo de captura regulatória e de capital. O North Star de Teknium é literal: GPT-4 em casa, o mesmo nível de inteligência disponível para todo mundo, em campo nivelado. Quando Peter pergunta se a missão é levar o agente a todos, Karan corrige para cima: todos com inteligência equivalente via agentes, e cada um com o agente personalizado à própria vida. Ao mesmo tempo, o discurso reconhece limites: a Nous declara não violar os paradigmas de segurança de Anthropic e OpenAI, admite que qualquer modelo aquém de uma superinteligência é jailbreakable e afirma que não está no negócio de apoiar maus atores.

A bandeira tem caixa para sustentá-la. A empresa levantou uma Série A de 50 milhões de dólares em abril de 2025, liderada pela Paradigm, com valuation de token na casa de 1 bilhão, e uma Série B acima de 75 milhões em julho de 2026, liderada pela Robot Ventures com participação da Union Square Ventures, a um valuation de 1,5 bilhão de dólares. A monetização declarada segue o manual do open core sem tocar no produto gratuito: o Nous Portal agrega e roteia modelos, o Tool Gateway vende conveniência (geração de imagem, áudio, web search e VPS embutidos, sem dez cadastros e dez API keys), o pricing é agressivo em modelos não subsidiados, e o cliente enterprise compra customização, suporte, roteamento e versões treinadas por RL nos próprios traces.

O argumento estratégico de fundo merece atenção de qualquer empresa que hoje depende de um único fornecedor de agente. Karan observa que quem usa Claude Code só usa modelos da Anthropic, salvo modificação, e que o custo de trocar de modelo é alto por construção. E acrescenta a variável que quase ninguém coloca na conta: ninguém sabe quanto tempo os subsídios atuais vão durar, e virá o momento em que os melhores modelos custarão o mesmo em qualquer lugar. O Hermes está montado hoje, agnóstico e aberto, em preparação para esse cenário.

O que fica para as empresas

A história do Hermes condensa quatro lições que venho testando na prática com times no Brasil. Primeira: a camada de contexto é o ativo, o modelo é insumo. O takeaway público do próprio Peter Yang formula isso com precisão: o “pessoal” do agente pessoal está na memória das conversas e nas skills construídas com ele, e o modelo é intercambiável. Empresas deveriam versionar, auditar e proteger suas memórias e skills com o mesmo rigor que aplicam a código, porque é essa camada que carrega o conhecimento operacional.

Segunda: curadoria de contexto é rotina, e dá para automatizar. O Hermes Curator existe porque contexto cresce como mato. Qualquer operação séria de agentes precisa de um processo equivalente, agendado, com critérios explícitos e revisáveis, para podar skills redundantes e consolidar memória.

Terceira: harness importa tanto quanto modelo. Se um agente aberto consegue, com o mesmo Claude, entregar um mod de dificuldade extrema numa codebase que o modelo desconhece, a diferença foi fabricada pela orquestração: leitura de documentação, memória persistente, skills acumuladas. Antes de pagar pelo próximo modelo de fronteira, vale perguntar quanto desempenho está sendo deixado na mesa por um harness pobre.

Quarta: lock-in de agente é risco de balanço, ainda que invisível hoje. Subsídio de token é decisão de marketing dos laboratórios, e decisões de marketing mudam. Manter a camada de contexto portável, em padrões abertos, é o hedge barato contra esse dia.

Fico com uma pergunta que o episódio deixa no ar e que vale para qualquer organização montando sua operação de IA agora: quando os preços convergirem e os modelos virarem commodity, o que exatamente da sua operação de IA vai ser seu?

Fontes: entrevista de Karan Malhotra a Peter Yang (Behind the Craft, 02/08/2026), repositório e documentação oficiais do Hermes Agent (dados de 16/08/2026), NVIDIA blog, Fortune e Dealroom.

Vinte e dois mil quinhentos e oitenta. É essa a quantidade de modelos GPT-2 (2019) que cabe dentro do Kimi K3 (2026). Em sete anos, aumentamos a escala por um fator de 22.580. Mas será que foi apenas... escala?

Neste diário de trabalho, vou mostrar como chegamos até aqui e quanto — ou quão pouco — realmente mudou desde então. Acompanharemos os principais avanços arquiteturais que levaram ao Kimi K3.

Nota editorial: os rótulos incorporados às imagens foram preservados no idioma original; títulos, prosa, listas, comentários de código e legendas estão em português brasileiro.

GPT-2

O GPT-2 usa uma arquitetura somente decodificadora:

tok_emb = self.transformer.wte(idx) # embeddings de tokens com forma (b, t, n_embd)
pos_emb = self.transformer.wpe(pos) # embeddings de posição com forma (t, n_embd)
x = self.transformer.drop(tok_emb + pos_emb)
for block in self.transformer.h:
 x = block(x)
x = self.transformer.ln_f(x)
logits = self.lm_head(x)
return logits

A entrada recebe embeddings de tokens e de posição:

class Block(nn.Module):
 def __init__(self, config):
 super().__init__()
 self.ln_1 = LayerNorm(config.n_embd, bias=config.bias)
 self.attn = CausalSelfAttention(config)
 self.ln_2 = LayerNorm(config.n_embd, bias=config.bias)
 self.mlp = MLP(config)

 def forward(self, x):
 x = x + self.attn(self.ln_1(x))
 x = x + self.mlp(self.ln_2(x))
 return x

O processo de atenção:

B, T, C = x.size() # tamanho do lote, comprimento da sequência e dimensão do embedding (n_embd)

# calcula consultas, chaves e valores para todas as cabeças e move a dimensão de cabeças para a frente
 q, k, v = self.c_attn(x).split(self.n_embd, dim=2)
 k = k.view(B, T, self.n_head, C // self.n_head).transpose(1, 2) # (B, nh, T, hs)
 q = q.view(B, T, self.n_head, C // self.n_head).transpose(1, 2) # (B, nh, T, hs)
 v = v.view(B, T, self.n_head, C // self.n_head).transpose(1, 2) # (B, nh, T, hs)

# implementação manual da atenção
 att = (q @ k.transpose(-2, -1)) * (1.0 / math.sqrt(k.size(-1)))
 att = att.masked_fill(self.bias[:,:,:T,:T] == 0, float(’-inf’))
 att = F.softmax(att, dim=-1)
 att = self.attn_dropout(att)
 y = att @ v # (B, nh, T, T) x (B, nh, T, hs) -> (B, nh, T, hs)
 y = y.transpose(1, 2).contiguous().view(B, T, C) # reagrupa lado a lado as saídas de todas as cabeças

# projeção de saída
 y = self.resid_dropout(self.c_proj(y))
 return y

Depois de produzir a matriz final de estados ocultos, a cabeça do modelo de linguagem a converte em logits sobre o vocabulário. Durante a decodificação autorregressiva, apenas os logits da última posição são necessários para escolher o próximo token.

Essa é uma ineficiência da geração somente decodificadora: o modelo calcula representações para todas as posições da entrada, embora cada etapa de decodificação consuma apenas os logits da posição final. Sem cache, grande parte desse trabalho seria repetida para o token seguinte.

O cache de KV nasce de uma observação simples: depois que o token gerado é anexado à entrada, o modelo teria de recalcular as projeções de todos os tokens anteriores. Armazenar seus vetores de chave e valor evita esse trabalho redundante.

Esse armazenamento é o cache de KV. Ele retém vetores dos N−1 tokens anteriores e pode crescer a ponto de se tornar um gargalo de largura de banda de memória.

No total, com cerca de 50 mil tokens possíveis, 12 blocos, 12 cabeças e uma dimensão de embedding de 768, nosso modelo de referência tem aproximadamente 124 milhões de parâmetros.

vocab_size: int = 50304 # vocab_size do GPT-2 (50257), preenchido até o múltiplo de 64 mais próximo para maior eficiência
n_layer: int = 12
n_head: int = 12
n_embd: int = 768

Com 2,8 trilhões de parâmetros, um único Kimi K3 contém aproximadamente tantos parâmetros quanto 22.580 modelos GPT-2.

Atenção linear

A atenção softmax aplica sua não linearidade depois do produto q·k, acoplando cada consulta a todas as chaves. A atenção linear, por sua vez, aplica separadamente a q e k um mapa de características, como ELU+1. Assim, o produto pode ser reassociado e o conjunto crescente de vetores K e V pode ser condensado em um estado fixo D×D.

A formulação O(N²) do artigo me confundiu. Não é verdade que “o custo por passo de tempo dos Transformers cresce com o quadrado do comprimento atual da sequência”. É justamente isso que o FlashAttention resolve... até eu perceber que o trabalho citado foi publicado em 2020.

Na época, o treinamento normalmente materializava a matriz de atenção N×N inteira, o FlashAttention ainda não existia e implementações autorregressivas de referência frequentemente recalculavam todo o histórico de tokens sem usar um cache de KV.

def forward(self, x, mask=None, past_kv=None):
# x tem forma b,t,d
 b,t,d=x.shape
 d_head=d//self.num_heads
 h=self.num_heads
 qkv=self.qkv_proj(x)

 q=qkv[:, :, :d].view(b,t,h,d_head).transpose(1,2)
 k=qkv[:, :, d:2*d].view(b,t,h,d_head).transpose(1,2)
 v=qkv[:, :, 2*d:].view(b,t,h,d_head).transpose(1,2)

# no prefill, q,k,v têm forma b,h,t,d
# na decodificação, a forma é b,h,1,d
# a concatenação ocorre na dimensão t, dim(2)

 if past_kv is not None:
 k_past=past_kv[0]
 v_past=past_kv[1]
 k=torch.cat((k_past, k), dim=2)
 v=torch.cat((v_past, v), dim=2)

 scores=(q@k.transpose(-1,-2))/math.sqrt(d_head)
 if past_kv is None: # estamos no prefill e precisamos aplicar a máscara
 causal_mask=torch.ones(t,t,dtype=bool, device=q.device)
 causal_mask=torch.triu(causal_mask, diagonal=1)
 scores=scores.masked_fill(causal_mask, float(’-inf’))

 if mask is not None:
 scores=scores.masked_fill(~mask, float(’-inf’))

# calcula a atenção (bhtt x bhtd)
 attn=scores.softmax(-1) # bhtt
 o=attn@v # bhtd
 o=o.transpose(1,2).contiguous().view(b,t,d) # b,t,d

# usa x para obter qkv
 o_proj=self.o_proj(o)
 past_kv=(k, v)
 return o_proj, past_kv

O mesmo processo fica mais claro visualmente. Cada etapa de decodificação realiza duas leituras ND e duas gravações 1D na HBM, enquanto o cache de KV cresce linearmente, em O(N), com o comprimento da sequência.

Observe o excesso de leituras e gravações, que o artigo substitui por:

def forward(self, x, mask=None, cache=None):
# x tem forma b,t,d
 b,t,d=x.shape
 d_head=d//self.num_heads
 h=self.num_heads
 qkv=self.qkv_proj(x)

 q=qkv[:, :, :d].view(b,t,h,d_head).transpose(1,2)
 k=qkv[:, :, d:2*d].view(b,t,h,d_head).transpose(1,2)
 v=qkv[:, :, 2*d:].view(b,t,h,d_head).transpose(1,2)
 
 k=F.elu(k)+1 
 k=k.transpose(-1,-2) 
 q=F.elu(q)+1
 
 S,z=cache if cache is not None else (0.0, 0.0)
 S=S+k@v
 z=z+k
 
 o=q@S # bhtd
 denom=q@z
 o_scaled=o/denom
 o_scaled=o_scaled.transpose(1,2).contiguous().view(b,t,d)
 o_proj=self.o_proj(o_scaled)
 cache=(S,z)
 
 return o_proj, cache

Há uma contrapartida.

Aqui, substituímos a exponenciação do softmax por ELU+1, aplicada separadamente a q e k antes de eles interagirem. As duas abordagens normalizam os escores resultantes, mas o mapa de características da atenção linear é uma aproximação menos expressiva do kernel softmax. Essa aproximação pode reduzir a fidelidade, embora a perda prática de acurácia dependa da arquitetura e da carga de trabalho.

Ainda dividimos pela soma de qk, embora isso tenha sido omitido do diagrama para simplificar. Em alto nível, a atenção é composta por três etapas:

1. Tornar não negativos os escores de qk. A atenção linear usa ELU+1, enquanto o softmax usa exponenciação.

2. Dividir pela soma.

3. Calcular a média ponderada dos valores.

Isso preserva o contrato básico da atenção, mas usa um mapa de características menos expressivo para tornar não negativos os escores de QK.

DeltaNet (programadores de pesos rápidos)

Um cache finito precisa sobrescrever ou combinar informações já armazenadas. O estado do token i−1 não recebe um espaço próprio; ele é somado à mesma matriz D×D. Por isso, novas consultas já não conseguem recuperar uma representação perfeitamente isolada de cada token anterior.

Essa soma também é a origem do ganho de eficiência. Atualizar o cache por adição, em vez de concatenação, impede que ele cresça em O(N), mas a mesma operação faz as informações interferirem entre si. A DeltaNet tenta recuperar essa capacidade de acesso.

Como resume com precisão o artigo de Schlag, Fast Weight Programmers: “quando o comprimento da sequência ultrapassa a capacidade de armazenamento, o modelo pode entrar em um regime de sobrecapacidade. Para operar adequadamente nesse regime, ele deve aprender a interagir dinamicamente com o conteúdo da memória e decidir, de forma seletiva, quais associações chave–valor manter e quais excluir. A instrução puramente aditiva pode ser inadequada para essa finalidade [...]. Somar indefinidamente novas associações a uma memória de tamanho finito, como na Eq. 17, inevitavelmente atingirá um limite”.

O regime que torna a atenção linear atraente — quando N é muito maior que D — também expõe sua principal limitação. Quando o estado ultrapassa sua capacidade efetiva, as associações começam a interferir, pois a atualização é aditiva e nada sai do cache.

def forward(self, x, mask=None, cache=None):
# x tem forma b,t,d
 b,t,d=x.shape
 d_head=d//self.num_heads
 h=self.num_heads
 qkv=self.qkv_proj(x)

 q=qkv[:, :, :d].view(b,t,h,d_head).transpose(1,2)
 k=qkv[:, :, d:2*d].view(b,t,h,d_head).transpose(1,2)
 v=qkv[:, :, 2*d:].view(b,t,h,d_head).transpose(1,2)

 q = F.normalize(F.silu(q), dim=-1) 
 k = F.normalize(F.silu(k), dim=-1) 
 beta = torch.sigmoid(self.w_beta(x)).view(b, 1, t, 1) 
# novo: intensidade de gravação por token

 S = cache if cache is not None else 0.0 

 v_old = k @ S # lê a memória nesta chave
 u = beta * (v - v_old) # o delta: apenas o que é realmente novo
 S = S + k.transpose(-1, -2) @ u # a mesma gravação por produto externo usada antes

 o = q @ S # leitura sem denominador
 o = o.transpose(1, 2).contiguous().view(b, t, d)
 return self.o_proj(o), S

Um exemplo visual ajuda a acompanhar o processo.

Considere uma única associação gravada como S = k.T @ v. Se a lermos de volta com a mesma chave, obtemos k @ (k.T @ v), isto é, (k @ k.T) v: a norma de k ao quadrado multiplicada por v. A leitura, portanto, devolve v escalado pela norma quadrática da chave. Se normalizarmos k para ter norma unitária — ou simplesmente dividirmos o resultado pela norma — recuperamos v exatamente.

Q também funciona como um ponteiro aprendido. Wq e Wk leem o mesmo fluxo residual, e a consulta associada a um fato aponta para a direção da chave na qual esse fato foi gravado. Primeiro, a atualização pergunta qual informação a chave atual recupera do cache. Em seguida, subtrai essa informação existente do valor que queremos armazenar, multiplica a diferença pela chave e soma o resultado de volta. A informação antiga é removida e a nova é gravada em seu lugar.

DeltaNet: paralelizando transformadores lineares com a regra delta

Esta é a seção mais difícil do texto. Levei cerca de sete horas para chegar a uma compreensão funcional, por isso construirei a explicação a partir da implementação. Em resumo, a DeltaNet implementa uma recorrência linear de primeira ordem com matrizes de transição de Householder generalizadas. Isso permite passagens diretas paralelas por chunks, adequadas ao hardware, durante um treinamento de tempo linear. As entradas e saídas são divididas em chunks de tamanho C, e a saída de cada chunk é calculada com base no estado final do chunk anterior e nos blocos de consulta, chave e valor do chunk atual.

O problema prático está no prefill. Uma implementação direta da regra delta sobre uma sequência de T tokens seria assim:

S = torch.zeros(b, h, dh, dh) if cache is None else cache
outs = []
for i in range(t):
 k_i = k[:, :, i:i+1] 
 v_i = v[:, :, i:i+1]
 b_i = beta[:, :, i:i+1]
 v_old = k_i @ S 
 u_i = b_i * (v_i - v_old)
 S = S + k_i.transpose(-1, -2) @ u_i # gravação
 outs.append(q[:, :, i:i+1] @ S) 
o = torch.cat(outs, dim=2)

Ao contrário da atenção padrão, essa formulação exige uma correção em cada vetor de chave, por isso o caminho até uma multiplicação matricial paralela não é imediatamente óbvio. Mesmo sem a regra delta, um prefill direto de atenção linear continua sequencial:

S = torch.zeros(b, h, dh, dh) if cache is None else cache
outs = []
for i in range(t):
 q = q[:, :, i:i+1] 
 k = k[:, :, i:i+1] 
 v = v[:, :, i:i+1]

 S=S_old+k@v
 o=q@S # bhtd
 o=self.norm(o)
 o=o.transpose(1, 2).contiguous().view(b, t, d)

 out=self.o_proj(o)
 cache=S
 outs.append(out)

o = torch.cat(outs, dim=2)

Uma formulação em chunks oferece uma alternativa mais eficiente. A mecânica fica mais fácil de entender com um exemplo:

Definir C=N recupera a atenção O(N²) padrão, enquanto C=1 produz a atenção linear convencional. Valores intermediários equilibram trabalho adicional dentro de cada chunk com melhor utilização do hardware. Na prática, C costuma ser 64 ou 128 porque as instruções dos tensor cores operam eficientemente nessa granularidade; UMMA é um exemplo.

Os blocos intermediários são incorporados a S como parte da atualização de estado:

S = torch.zeros(b, h, dh, dh) if cache is None else cache
outs = []
for i in range(t//C):
 q_c = q[:, :, i*C:(i+1)*C] 
 k_c = k[:, :, i*C:(i+1)*C] 
 v_c = v[:, :, i*C:(i+1)*C]

 o_prev=q_c@S # tudo o que veio antes deste bloco
 
 attn=(q_c@k_c.transpose(-1,-2)).tril() # atenção mascarada
 o_curr=attn@v_c
 
 o=o_prev+o_curr
 
 S_new=k_c.transpose(-1,-2)@v_c # atenção recorrente
 S=S+S_new
 outs.append(o)

o = torch.cat(outs, dim=2)

Dentro de um bloco, calculamos q(kᵀv): primeiro os escores, na ordem usual da atenção, com mascaramento. Entre blocos, seguimos (kᵀv)q: primeiro o estado, na ordem recorrente. A atenção cresce em O(N²), mas este método não. Dentro de um bloco, aplico atenção real — QKᵀ mascarado, multiplicado por V —; entre blocos, incorporo tudo ao estado e leio de volta com uma única multiplicação matricial. O custo se divide em duas partes. Há uma parcela fixa, 2Ld², correspondente ao trabalho de estado e independente de C, e uma parcela crescente, 2LCd, correspondente às matrizes de escores na diagonal. A atenção completa é o caso em que C=L; então, o segundo termo se torna 2L²d, quadrático. Portanto, quanto menor C, menor o número de FLOPs.

C=1 é a opção mais barata em número puro de FLOPs, mas não necessariamente em tempo de execução. Uma GPU pode concluir mais operações aritméticas em menos tempo quando o trabalho se adapta bem ao hardware de multiplicação matricial.

O próximo passo é estender essa mesma abordagem à DeltaNet.

O problema subjacente é simples: o método de divisão em chunks usado na atenção puramente aditiva não se aplica diretamente às atualizações delta:

v_old = k_i @ S 
u_i = b_i * (v_i - v_old)

Precisamos de cada estado intermediário, na ordem correta, para calcular a informação que deve ser subtraída. Não é possível paralelizar do mesmo modo sem alguma reparametrização matemática. Por isso, os autores reescrevem as atualizações delta de:

u=v_new-v_old
S_t= S_(t-1)+K.T@u
o=q@S_T

Aqui, um laço sequencial calcula um delta por iteração. A forma reparametrizada é:

S_t = S_{t-1}(I − β_t k_t k_tᵀ) + β_t v_t k_tᵀ
o_t = S_t q_t

Essa formulação permite que o código em chunks calcule os C deltas de uma só vez:

def chunk_delta_rule_forward(Q, K, V, beta, C):
# L: comprimento da sequência; d: dimensão da cabeça
 L, d = Q.shape
# divisão em chunks
 Q, K, V = map(lambda x: x.reshape(-1,C,d), [Q, K, V])
 beta = beta.reshape(-1, C)
 K_beta = K * beta.unsqueeze(-1)
 V_beta = V * beta.unsqueeze(-1)
 
# calcula a Eq. 10 com substituição direta vetorizada para obter a inversa com eficiência
 T = -(K_beta @ K.t()).tril(-1)
 for i in range(1, C):
 T[i, :i] = T[i, :i] + (T[i, :, None] * T[:, :i]).sum(-2)
 
 T += torch.eye(C)
 W = T @ K_beta
 U = T @ V_beta

# paralelismo por chunks, Eqs. 8–9
 S = torch.zeros(d, d)
 O = torch.empty_like(V)
 
 for i in range(L//C):
 q_i, k_i, w_i = Q[i], K[i], W[i]
 u_i = U[i] - w_i @ S # todas as correções de um chunk
 o_inter = q_i @ S
 A_i = (q_i @ k_i.t()).tril() # qk.t
 o_intra = A_i @ u_i # atenção @ v, usando u por conter as correções
 S += k_i.t() @ u_i # atualiza o estado por adição
 O[i] = o_intra + o_inter # atualiza a saída com os termos local e recorrente
 return O.reshape(L, d)

Chegamos, assim, ao primeiro ponto de comparação: Transformers com MHA versus Transformers com DeltaNet.

Gated DeltaNet

Agora temos um método para fazer alterações precisas no cache. A cada novo fato — isto é, a cada novo vetor de chave —, podemos consultar exatamente a informação antiga armazenada naquele ponto e substituí-la pelo novo conteúdo ao qual queremos dar atenção.

Esse mecanismo, porém, só consegue esquecer uma associação quando há uma substituição específica para ela. Ele não consegue limpar várias associações de forma eficiente durante uma mudança de contexto, nem fazer a memória decair de modo geral para liberar capacidade.

Se estivéssemos usando atenção linear puramente aditiva:

Adicionar a capacidade de esquecer seria simples. Bastaria um parâmetro para controlar o estado a ser retido:

S_old=cache
S_new=k@v
# cache=S_old+S_new
cache=alpha * S_old + S_new

Essa é a contribuição do Mamba-2. Aplicamos decaimento ao cache anterior e, depois, somamos o novo cache com força total, impedindo que o estado cresça sem limite.

Aplicar, em cada passo de tempo, o mesmo decaimento dinâmico a todas as associações chave–valor é uma abordagem funcional — e é o que o Mamba faz. Mas ela não considera que associações diferentes têm importâncias diferentes.

Em outras palavras, se o modelo precisa esquecer uma associação específica, todas as associações são esquecidas por igual. A regra delta, por outro lado, consegue atualizar um único fato, mas não oferece uma forma de fazer o restante decair.

A regra Gated Delta combina, portanto, a atualização com gate do Mamba com a regra delta. Ela acrescenta um parâmetro, alpha, que reproduz a regra delta pura quando vale um e limpa a memória quando vale zero. O desafio é implementar isso com o mesmo método de chunks paralelos.

A implementação usa a mesma reparametrização da DeltaNet descrita na seção anterior. A matemática é praticamente idêntica, com um acréscimo: um escalar dependente dos dados, entre zero e um, que controla o decaimento do estado anterior. Assim, o modelo combina aprendizado eficaz de associações chave–valor com gerenciamento adaptativo da memória.

As alterações correspondentes no código aparecem abaixo:

O termo γʳ/γⁱ representa o decaimento acumulado. Um token gravado no passo x e lido em x+t foi multiplicado por αₓαₓ₊₁αₓ₊₂…αₓ₊ₜ. É o análogo multiplicativo de um cálculo de soma prefixada.

A arquitetura resultante tem esta aparência:

KDA / Kimi Linear

A essa altura, pesquisadores começaram a experimentar modelos híbridos que combinam várias formas de atenção em uma única arquitetura, como Gated DeltaNet e Mamba.

O Kimi Linear chamou atenção por uma afirmação central: em comparações controladas, superou a atenção completa. Os autores o apresentaram como uma substituição arquitetural direta, com melhor qualidade e throughput de decodificação até seis vezes maior.

O Kimi Linear avança sobre a Gated DeltaNet ao introduzir gating de granularidade fina. Em vez de um único escalar de decaimento, aprende um valor de decaimento separado para cada canal.

A regra de atualização da KDA permanece semelhante, mas o código passa a se parecer mais com isto:

Aqui, alpha.reshape(nb, C, d) representa a contribuição mais importante do artigo: controle de granularidade fina sobre o decaimento da memória.

Colocada ao lado do Transformer com DeltaNet, a arquitetura Kimi Linear apresenta três mudanças principais:

1. Usa um sistema híbrido que intercala camadas de Multi-head Latent Attention (MLA).

2. Substitui a MLP por uma camada Mixture-of-Experts (MoE).

3. Amplia a capacidade da DeltaNet por meio da projeção alpha.

As seções seguintes explicam MLA e MoE com mais detalhes. Por ora, o ponto central é que não se trata de escalar às cegas. A capacidade adicional tem um propósito matemático específico: a escala por canal oferece ao modelo controle mais preciso sobre o decaimento da memória.

As leis de escala continuam relevantes, mas a capacidade precisa ser adicionada no lugar certo e em uma forma que o sistema consiga usar. Cada arquitetura dessa progressão acrescenta capacidade para resolver uma limitação concreta do sistema anterior.

Kimi K3

Em última análise, a espinha dorsal de linguagem do Kimi K3 se parece com o modelo Kimi Linear acima. Ela contém 23 macrociclos de quatro camadas. Em cada macrociclo, três camadas usam Kimi Delta Attention e a quarta usa Multi-head Latent Attention. A primeira camada emprega uma rede feed-forward densa; todas as demais usam uma Mixture-of-Experts latente.

À primeira vista, as mudanças em relação ao Kimi Linear parecem modestas:

1. Um aumento substancial de escala

2. AttnRes em blocos a cada 12 camadas

3. LoRA de consulta na MLA e gating de saída

4. MoE em espaço latente

5. Ativações SiTU

6. MLA com gating

A KDA fornece memória recorrente de estado constante, enquanto camadas periódicas de MLA preservam a recuperação softmax completa sobre o contexto. A visualização simplificada a seguir serve como referência para as mudanças discutidas abaixo.

Começaremos pelas mudanças mais diretas: MLA com gating, MoE em espaço latente e ativações SiTU.

A MLA com gating determina quanto de cada característica recuperada passa da MLA para o fluxo residual. Isso é feito por multiplicação elemento a elemento com um gate projetado a partir da entrada.

Em uma MoE convencional, um roteador aprendido usa similaridade por produto escalar para enviar cada token a um subconjunto de redes especialistas. O Kimi K3 tem 898 especialistas no total. Dois são compartilhados e processam todos os tokens; entre os outros 896, o roteador seleciona 16 para cada token.

O Kimi K3 também altera a ativação dos especialistas. Em vez de aplicar SiLU à projeção ascendente, multiplicá-la elemento a elemento pelo gate e, em seguida, aplicar a projeção descendente, o modelo usa SiTU:

d = x.shape[-1] // 2
gate = x[..., :d].to(torch.float32)
up = x[..., d:].to(torch.float32)
situ_a = self.beta * torch.tanh(gate / self.beta) * torch.sigmoid(gate)
if self.linear_beta is not None:
 up = self.linear_beta * torch.tanh(up / self.linear_beta)
return (situ_a * up).to(x.dtype)

O modelo também reduz a dimensionalidade das entradas destinadas aos especialistas compartilhados e volta a expandir a soma final:

Isso ilustra um desafio recorrente na inferência de modelos. Sem um kernel fundido, a nova ativação é quase três vezes mais lenta que o caminho original. Uma otimização compensatória é que os especialistas operam em um espaço latente comprimido, o que torna sua passagem direta muito mais rápida e quase reduz os FLOPs pela metade.

As mudanças restantes são LoRA de consulta na MLA, gating de saída e Attention Residuals em blocos a cada 12 camadas. A AttnRes acrescenta aproximadamente 2% de latência à inferência, mas oferece dois benefícios importantes:

1. Recuperação seletiva de representações anteriores, o que reduz a diluição residual e o crescimento dos estados ocultos

2. Uma vantagem computacional de 1,25x

AttnRes e MLA atacam a mesma limitação subjacente por caminhos diferentes. As camadas de KDA trabalham com um estado de tamanho constante e, inevitavelmente, precisam descartar informação. A MLA recupera conteúdo do contexto de tokens, enquanto a AttnRes recupera representações anteriores ao longo da profundidade da rede.

AttnRes

Agradeço a @chloey3k pela ajuda nesta seção. Em cada passagem direta, a entrada percorre uma pilha de camadas. Aqui, cada camada contém um bloco de atenção — KDA ou MLA — e um bloco MLP ou MoE. Normalmente, a entrada de cada camada é a soma do embedding original com a saída de todas as camadas anteriores, todas com o mesmo peso.

Aqui, h_i é a entrada da camada i, h_1 é o embedding do token atual — o último token da sequência até aquele momento — e f_i(h_i) é a saída da camada i, isto é, um bloco de atenção ou MLP.

O problema é a falta de acesso seletivo. Tipos diferentes de camada recebem o mesmo estado agregado, embora possam se beneficiar de ponderações distintas. Como a recorrência é puramente aditiva, camadas posteriores também precisam aprender saídas cada vez maiores para influenciar o residual acumulado, o que pode desestabilizar o treinamento. Em vez de tratar todas as camadas por igual, a AttnRes multiplica cada termo dessa soma por um peso especializado, permitindo que o modelo valorize as camadas mais úteis em cada contexto.

Cada peso alpha_i é calculado por um produto escalar entre consulta e chave. A consulta é aprendida para cada camada, enquanto chaves e valores vêm de estados anteriores do fluxo residual. Os escores são normalizados para somar um e, depois, usados para formar uma combinação ponderada desses estados.

Assim, o modelo não precisa se condicionar apenas ao predecessor imediato. A AttnRes oferece a cada camada acesso seletivo às saídas de camadas anteriores, permitindo que sua consulta aprendida recupere as representações mais úteis para o cálculo atual.

O pseudocódigo abaixo aplica a mesma ideia na granularidade de blocos. Um bloco é a soma elemento a elemento das saídas de atenção e MLP acumuladas ao longo de 12 camadas do decodificador, armazenada como uma única representação de profundidade para a mistura posterior da AttnRes.

Aplicar atenção residual em todas as camadas acrescentaria custo demais ao treinamento e à inferência. Usá-la apenas em limites fixos de bloco captura a maior parte do benefício com menor custo. No Kimi K3, cada limite ocorre depois de 12 camadas do decodificador. Ao longo de 23 macrociclos de quatro camadas, isso produz oito blocos AttnRes e melhora a velocidade de inferência.

Esta é, possivelmente, a parte mais importante da função block_attn_res:

V = torch.stack(blocks + [partial_block]) # [N+1, B, T, D]
K = norm(V)
logits = torch.einsum(’d, n b t d -> n b t’, proj.weight.squeeze(), K)
h = torch.einsum(’n b t, n b t d -> b t d’, logits.softmax(0), V)
return h

Isso conclui a progressão do GPT-2 ao Kimi K3.

A mudança central não está apenas na escala. Cada etapa arquitetural altera o que o modelo armazena, como atualiza esse estado ou como recupera informações que um estado de tamanho fixo não consegue preservar.

O Kimi K3 combina memória recorrente de estado constante, recuperação softmax periódica, capacidade esparsa de especialistas e acesso residual seletivo ao longo da profundidade. O resultado é um sistema que investe capacidade adicional onde ela cumpre uma função específica.

Em essência, uma memória associativa de capacidade fixa — com dimensões fixas — precisa de uma política de descarte, pois uma operação linear puramente aditiva acaba gerando interferência ao atingir o limite. Por isso, torna-se necessária alguma forma de seleção aprendida, como gating, roteamento ou decaimento; e a atenção é o mecanismo de leitura seletiva mais eficaz.

Artigo original traduzido: publicação de @waterloo_intern no X

Em julho de 2026, a documentação oficial da mesma OpenAI traz a instrução inversa, com todas as letras: “Avoid chain-of-thought prompts”. Como os modelos atuais raciocinam internamente, pedir que pensem passo a passo é desnecessário. A Anthropic foi na mesma direção e hoje pede que o usuário apague instruções que mandam o modelo verificar o próprio trabalho: elas causam verificação em excesso e desperdiçam tokens sem ganho de qualidade. O conselho que em 2022 somava dezenas de pontos de acurácia virou, na documentação de 2026, um defeito a remover.

Na semana passada fiz um levantamento das documentações oficiais da OpenAI e da Anthropic para atualizar meu manual interno. Este ensaio cruza esse levantamento com o que a literatura científica registrou no mesmo período: são quase 40 papers, a maioria no arXiv, cada número citado aqui (final do texto tem a lista completa). A tese central cabe numa frase: o prompt continua no centro do trabalho, com outra natureza.

O prompt deixou de ser a aula que ensina o modelo a pensar e virou o contrato que especifica comportamento, fronteiras e grau de autonomia.

Organizei o argumento, com auxilio do meu copiloto Hermes em dez pontos (inclusive fez esse levantamento de artigos e os categorizou, facilitando minha leitura). Os três primeiros reconstroem a era do prompt-aula com os números originais. Os pontos 04 a 06 documentam a virada: o raciocínio entrando para dentro do modelo, a instrução virando cláusula e a técnica virando parâmetro. Os pontos 07 a 09 mostram para onde a engenharia foi, o que os logs de uso real revelam sobre as pessoas e o que o mercado de trabalho fez com o cargo. O ponto 10 fecha com o que continua valendo e com as lições práticas para a sua empresa.

01. A era do prompt-aula: quando a frase valia 61 pontos

O ponto de partida é 2020, quando o paper do GPT-3 (Brown et al., arXiv 2005.14165) demonstrou que um modelo de 175 bilhões de parâmetros aprendia tarefas novas “sem qualquer atualização de gradiente ou fine-tuning”, apenas com demonstrações escritas no próprio texto de entrada. Nascia o few-shot prompting: ensinar pelo exemplo, dentro da janela de contexto.

Dois anos depois, o chain-of-thought completou o método. Wei et al. (arXiv 2201.11903) mostraram que oito exemplos com o raciocínio escrito por extenso levavam o PaLM 540B ao estado da arte no GSM8K, benchmark de problemas matemáticos: 56,9% de acerto nas tabelas do paper, superando os 55% de um GPT-3 ajustado com verificador externo. A versão mais famosa veio de Kojima et al. (arXiv 2205.11916): sem exemplo nenhum, a frase “Let’s think step by step” levou o text-davinci-002 de 17,7% para 78,7% no MultiArith e de 10,4% para 40,7% no GSM8K. Uma frase, 61 pontos percentuais de diferença. Logo depois, a self-consistency (Wang et al., arXiv 2203.11171) somou mais 17,9 pontos no GSM8K amostrando vários caminhos de raciocínio e votando na resposta majoritária.

Vale nomear o que esses números significavam na prática. O procedimento de raciocínio morava no prompt, escrito por um humano. Quem escrevia melhor a aula extraía mais do mesmo modelo, e a diferença entre uma aula boa e uma ruim era da ordem de dezenas de pontos. Foi esse diferencial que criou a disciplina, os cursos, os manuais internos e, por um breve período, o cargo de prompt engineer com salário de seis dígitos.

02. O folclore instrumentado: emoção, gorjeta e Jornada nas Estrelas

Entre 2023 e 2024, a literatura registrou uma fase curiosa: técnicas que nasciam da intuição social humana e funcionavam sem que ninguém soubesse explicar o mecanismo.

O EmotionPrompt (Li et al., arXiv 2307.11760) mediu o efeito de anexar apelos emocionais ao fim do prompt, como “isto é muito importante para a minha carreira”: 8% de melhora relativa em tarefas de instrução e 115% no BIG-Bench, com validação humana em 106 participantes. A polidez também virou variável experimental: Yin et al. (arXiv 2402.14531) mostraram que prompts rudes degradavam o desempenho (o Llama-2-70B caiu de 55,11 para 28,44 no MMLU entre o nível mais polido e o mais rude) e que o nível ótimo de cortesia variava por idioma. Um paper da MBZUAI catalogou 26 princípios de prompting, entre eles o de prometer gorjeta ao modelo. E as personas, técnica queridinha dos manuais (”você é um especialista em...”), foram testadas em escala por Zheng et al. (arXiv 2311.10054): 162 personas, 9 modelos, 2.410 questões factuais, e a conclusão de que adicionar persona no system prompt tem efeito “em grande parte aleatório” sobre a acurácia, com a seleção automática da melhor persona rendendo o mesmo que sorteio.

O episódio que melhor resume a fase veio da otimização automática. A máquina já superava o artesão desde 2022, quando o APE (arXiv 2211.01910) encontrou uma variação de “Let’s think step by step” que rendia mais que a original (82,0 contra 78,7 no MultiArith). Em 2023, pesquisadores do Google DeepMind usaram o próprio modelo para buscar prompts melhores (OPRO, arXiv 2309.03409) e a busca encontrou “Take a deep breath and work on this problem step-by-step”: 80,2% no GSM8K com PaLM 2-L, contra 71,8% da frase humana consagrada. Já a dupla da VMware (Battle e Gollapudi, arXiv 2402.10949) rodou otimização automática em modelos abertos e reportou que o prompt de melhor pontuação para o Llama2-70B na sua bateria era uma cena de Jornada nas Estrelas, com a resposta começando por “Captain’s Log, Stardate”: um framing que nenhum humano escreveria de propósito. As duas conclusões do paper anteciparam o fim da era: os resultados de cada truque “não generalizam universalmente entre modelos”, e o método mais eficaz é deixar o otimizador automático escrever o prompt. A IEEE Spectrum leu o recado e publicou, ainda em março de 2024, o obituário provocativo: “AI prompt engineering is dead”.

03. A fragilidade era o fundamento do ofício

Por que truques tão arbitrários mexiam tanto no resultado? Porque os modelos daquela geração eram estruturalmente sensíveis à superfície do texto, e a ciência mediu essa sensibilidade com precisão desconfortável.

Sclar et al. (arXiv 2310.11324) mostraram que mudanças triviais de formatação (espaços, separadores, dois-pontos) produziam diferenças de até 76 pontos de acurácia no mesmo modelo com o mesmo conteúdo, e que a sensibilidade persistia em modelos maiores e instruídos. Cao et al. (arXiv 2406.10248) mediram o pior caso entre paráfrases semanticamente equivalentes do mesmo pedido: 45,48 pontos de distância entre a melhor e a pior formulação no Llama-2-70B-chat, com o pior caso chegando a 9,38% de acerto. O formato do dado importava tanto quanto o texto: He et al. (arXiv 2411.10541) registraram variações de até 40% no GPT-3.5 em tarefas de código conforme o prompt vinha em texto puro, Markdown, JSON ou YAML, com o formato ótimo de um modelo valendo pouco para o vizinho. Até a posição da informação dentro da janela pesava: o clássico Lost in the Middle (arXiv 2307.03172) mostrou desempenho alto quando a informação relevante estava no início ou no fim do contexto e degradação significativa quando estava no meio.

Enquanto isso, o estudo de HCI mais citado da época (Why Johnny Can’t Prompt, CHI 2023) observava não especialistas tentando escrever prompts e concluía que eles exploravam “de forma oportunista, sem sistematização”, travados por expectativas herdadas da instrução entre humanos. A fotografia completa da era é essa: um artefato instável, operado por intuição social, onde o domínio da superfície do texto valia dezenas de pontos. A habilidade era real. O que ninguém sabia era quanto tempo ela duraria.

04. 2024: o raciocínio entra para dentro do modelo

A virada tem data e paper. Em setembro de 2024 a OpenAI lançou o o1, primeiro modelo de fronteira treinado para gerar cadeias longas de raciocínio por conta própria, e dois meses depois a Microsoft publicou o estudo que mede o que isso fez com as técnicas clássicas (From Medprompt to o1, arXiv 2411.03590). O resultado central: sem técnica nenhuma, o o1-preview marcou 96,0% no MedQA, acima dos 90,2% do GPT-4 Turbo equipado com Medprompt, o pipeline de prompting médico mais sofisticado da geração anterior. E o achado mais importante vinha em seguida: “few-shot prompting hinders o1’s performance”, exemplos no prompt pioraram o desempenho do modelo de raciocínio, sugerindo que o in-context learning deixou de ser um mecanismo eficaz de direcionamento para essa família. A técnica fundadora de 2020 virou interferência.

O mesmo período trouxe a meta-análise que dimensionou o chain-of-thought: Sprague et al. (arXiv 2409.12183) revisaram mais de 100 papers e concluíram que os ganhos se concentram em matemática e raciocínio simbólico, com efeito pequeno no resto; no MMLU, responder direto empatava com o passo a passo, salvo quando a questão continha um sinal de igual. Em 2025, o grupo de Wharton confirmou a tendência nos modelos novos (arXiv 2506.07142): para modelos de raciocínio, pedir o passo a passo rende ganho marginal de acurácia com aumento substancial de tempo e tokens, porque eles já raciocinam por padrão.

O pêndulo chegou a passar do ponto. A literatura de overthinking mediu o novo defeito: diante de “2+3=?”, um modelo de raciocínio típico gerou 13 soluções alternativas e 901 tokens, quando mais de 92% das vezes a primeira solução já estava correta (arXiv 2412.21187). Em 2026, um estudo de test-time compute mostrou que, no AIME, a utilidade marginal de pensar fica negativa depois de um certo ponto: respostas corretas começam a virar erradas quando o modelo insiste (arXiv 2604.10739). Guarde esse detalhe: se pensar demais custa caro e pode piorar o resultado, quanto pensar vira uma decisão de engenharia. Ela reaparece no ponto 06 como parâmetro de API.

05. O prompt vira contrato

Se o modelo já sabe raciocinar, o que sobra para o prompt? Sobra a parte que nenhum treinamento resolve: dizer o que fazer, para quem, dentro de quais fronteiras e com quanta autonomia. O prompt de 2026 se parece menos com uma aula e mais com um contrato, e essa mudança tem infraestrutura formal por trás.

O primeiro passo foi dado em 2024 pelo paper da hierarquia de instruções da OpenAI (Wallace et al., arXiv 2404.13208): treinar o modelo para tratar instruções como camadas de privilégio (sistema acima de desenvolvedor, desenvolvedor acima de usuário, usuário acima de texto vindo de ferramentas) e para ignorar seletivamente instruções de menor privilégio que conflitem com as de cima. A documentação atual da OpenAI formaliza a analogia jurídica do lado do desenvolvedor: as mensagens de developer “fornecem as regras e a lógica de negócio do sistema, como a definição de uma função”, e as mensagens de usuário funcionam “como os argumentos dessa função”. Quem já escreveu software reconhece o que isso significa: assinatura, tipos, pré-condições. Um contrato de interface.

E contratos cobram caro por ambiguidade. O guia de prompting do GPT-5 avisa que o modelo segue instruções “com precisão cirúrgica” e que, justamente por isso, prompts com instruções contraditórias ou vagas “podem ser mais danosos ao GPT-5 do que a outros modelos”, porque o modelo gasta tokens de raciocínio procurando uma forma de conciliar as contradições em vez de escolher uma delas. O caso documentado no próprio guia é o da Cursor: uma seção de prompt chamada maximizecontext_understanding, com a ordem “Be THOROUGH when gathering information”, ajudava os modelos anteriores e passou a causar uso excessivo de ferramentas no GPT-5. A correção foi remover o prefixo maximize e suavizar a linguagem; com o prompt mais calmo, o time viu o modelo tomar “decisões melhores sobre quando confiar no conhecimento interno versus buscar ferramentas externas”. No mesmo guia, um dado que parece burocrático e diz muito: só de migrar para a Responses API, passando o estado de raciocínio de uma chamada para a seguinte, o score no Tau-Bench Retail subiu de 73,9% para 78,2%. O contrato de 2026 inclui até a memória do processo entre chamadas.

A Anthropic escreveu o mesmo capítulo com outras palavras. As boas práticas atuais mandam desmontar a gritaria acumulada nos prompts da era anterior: onde se escrevia “CRITICAL: You MUST use this tool when...”, a recomendação agora é o tom normal de “Use this tool when...”, porque a ênfase agressiva calibrada para modelos desobedientes faz os obedientes dispararem demais. A página do Claude Opus 5 pede a remoção das instruções de verificação (”include a final verification step”, “use a subagent to verify”): o modelo verifica o próprio trabalho sem ser mandado, e a instrução herdada causa verificação em excesso, gastando tokens sem ganho de qualidade. A do Claude Fable 5 generaliza: skills e prompts escritos para modelos anteriores “são frequentemente prescritivos demais” e podem degradar a qualidade do modelo novo. Três páginas de documentação, um mesmo movimento: apagar texto virou otimização.

Um contrato, porém, só funciona se as partes respeitam a precedência, e aqui a pesquisa de 2026 impõe honestidade: um benchmark de hierarquias com múltiplos níveis (arXiv 2604.09443) mostrou modelos de fronteira acima de 99% quando há só duas camadas de privilégio, e o melhor deles em 42,7% quando as camadas se multiplicam como nos stacks reais de agentes. O prompt-contrato é o paradigma vigente, com cláusulas que ainda vazam.

06. A técnica vira parâmetro: o que era frase virou botão

A segunda metade da virada aconteceu fora do texto. Um a um, os controles que o prompt engineering exercia por frases foram absorvidos pela API como parâmetros nomeados.

O mecanismo ficou visível num paper simples e elegante (s1, arXiv 2501.19393): forçar o fim do raciocínio ou prolongá-lo anexando “Wait” transforma o tamanho do pensamento num dial contínuo, e só de girar esse dial o desempenho no AIME24 subiu de 50% para 57%, sem mudar uma palavra do prompt. Os vendors produtizaram o dial. Na OpenAI, reasoning_effort controla o esforço de raciocínio e verbosity controla, em separado, o tamanho da resposta final; o GPT-5.2 chegou com esforço padrão em none, raciocínio como opção e a recomendação de ajustar só depois de rodar evals. Na Anthropic, effort vai de low a max, e a documentação faz questão de avisar que ele controla o volume de pensamento, e que para encurtar a resposta visível o caminho continua sendo pedir no prompt; o adaptive thinking, em que o modelo decide sozinho quando e quanto pensar, é o único modo de operação do Claude Fable 5. “Pense passo a passo”, a frase de 61 pontos, virou um argumento tipado na chamada de função.

Para o dia a dia das empresas, a consequência prática apareceu nos casos que a própria OpenAI documenta: a SafetyKit saltou de 50% para 88% de acurácia nas suas tarefas mais difíceis de classificação de imagem “sem qualquer modificação no pipeline”, apenas trocando GPT-4o por o1; a Blue J mediu melhora de 4x no desempenho de ponta a ponta na pesquisa tributária; um cliente da Braintrust viu o F1 de um juiz automático ir de 0,12 para 0,74. Todos esses ganhos vieram de trocar o motor e deixar o contrato em paz, com o prompt intacto. A pergunta de otimização mudou de “que palavras uso?” para “que modelo, com quanto esforço, a que custo?”: uma decisão de arquitetura e orçamento, tomada em parâmetros.

07. De prompt engineering a context engineering

Com o raciocínio internalizado e o controle fino parametrizado, o que sobrou de engenharia migrou para uma camada acima: decidir o que entra na janela de contexto do modelo. A Anthropic deu nome ao movimento num ensaio de engenharia de setembro de 2025: construir com modelos “está se tornando menos sobre encontrar as palavras e frases certas para os prompts e mais sobre responder à pergunta mais ampla de qual configuração de contexto tem mais chance de gerar o comportamento desejado”. O texto introduz a imagem que organiza a disciplina: o modelo tem um “orçamento de atenção” finito, e o trabalho do engenheiro é encontrar “o menor conjunto possível de tokens de alto sinal que maximize a probabilidade do resultado desejado”. Do lado acadêmico, um survey de julho de 2025 sistematizou mais de 1.400 papers sob o guarda-chuva de context engineering (Mei et al., arXiv 2507.13334), formalizando a disciplina que transcende o design do prompt: retrieval, memória, ferramentas, gestão da janela.

Dois resultados mostram por que essa camada virou o gargalo. Primeiro, a robustez à sujeira: em modelos clássicos, inserir contexto irrelevante derrubou o desempenho em 55,89% na média de 13 modelos, enquanto o o1-preview caiu 2,68% (arXiv 2504.02111); o modelo novo aguenta quase tudo, menos um contexto mal curado em escala. Segundo, a origem da sensibilidade: um estudo de 2026 (arXiv 2602.04297) mostrou que boa parte da fragilidade que restou nos modelos modernos é atribuível a prompt subespecificado; com a especificação completa do comportamento, a variância entre formulações desaba. Dito de outro jeito: a brittleness de 2023 era do modelo; a de 2026 é do contrato mal escrito.

A infraestrutura acompanhou. As Agent Skills da Anthropic empacotam instruções em pastas versionáveis que o agente descobre e carrega sob demanda, por divulgação progressiva: o prompt virou artefato de software, componível e compartilhável, o que conversa direto com o que escrevi em O fim do código como ativo e com o sistema de registros que mantém meus agentes. A pesquisa acompanha: o método ACE (arXiv 2510.04618) trata o contexto como um playbook que evolui com o uso, com ganho de 10,6% em benchmarks de agentes. E até a escrita do que sobra está sendo automatizada: o DSPy tratava prompt como alvo de compilador já em 2023 (arXiv 2310.03714), o TextGrad levou a otimização por feedback textual à Nature em 2025, e o GEPA (arXiv 2507.19457) mostrou evolução reflexiva de prompts superando reinforcement learning com até 35 vezes menos rollouts. Quando a máquina escreve o prompt melhor que o humano, o valor humano se desloca para especificar o que “melhor” significa: a métrica, o contexto, o contrato.

08. As pessoas mudaram menos que os modelos

Tudo acima descreve a fronteira da engenharia. Os logs de uso real contam uma história paralela e mais honesta sobre o resto de nós.

Os grandes corpora de conversas reais (WildChat, com 1 milhão de diálogos, e LMSYS-Chat-1M) viraram matéria-prima para estudos longitudinais, e o resultado mais consistente é a inércia individual. Um estudo de 2026 com 12 mil usuários acompanhados por meses (arXiv 2605.29018) resume: “os hábitos dos usuários são pegajosos e resistentes à mudança”; a complexidade média das mensagens na população cresceu na casa de 1,5x, mas o efeito é de composição, puxado por usuários novos, e quem usa intensamente já era diferente desde a primeira mensagem. Outro trabalho sobre 211 mil consultas do WildChat (arXiv 2508.01213) detectou a única migração clara: os pedidos foram ficando menos “comando seco” e mais carregados de contexto, com cada usuário convergindo para um template pessoal estável depois de umas 20 interações, e com muito menos marcadores de polidez do que conversas entre humanos. Das 58 técnicas que The Prompt Report catalogou em 2024, o usuário comum segue conhecendo pouquíssimas; o aprendizado real foi dar contexto e repetir o que funciona.

A escala desse “resto de nós” é o que dá peso ao achado. O estudo do NBER sobre uso do ChatGPT (setembro de 2025) estimou cerca de 10% da população adulta mundial usando o produto, com o uso pessoal crescendo de 53% para mais de 70% das conversas e três categorias (orientação prática, busca de informação e escrita) somando quase 80% do volume. O Anthropic Economic Index, sobre milhões de conversas do Claude (arXiv 2503.04761), mapeou 36% das ocupações usando IA em pelo menos um quarto das suas tarefas, com 57% do uso em padrão de colaboração e 43% em delegação. E o folclore, aquele do ponto 02, envelheceu mal: um estudo de outubro de 2025 (arXiv 2510.04950) achou o efeito invertido no GPT-4o, com prompts rudes superando os educados (84,8% contra 80,8%), enquanto o grupo de Wharton (arXiv 2503.04818) mediu efeitos de polidez e formatação reais, porém imprevisíveis por pergunta. A lição operacional para quem usa IA todo dia: pare de colecionar truque de frase; eles mudam de sinal a cada geração de modelo. Especifique o que quer e dê o contexto.

09. O mercado precificou: de cargo a tarefa

O mercado de trabalho registrou a transição com a frieza de sempre. Nos dados da Indeed, as buscas por prompt engineering saíram de 2 por milhão em janeiro de 2023, atingiram o pico de 144 por milhão em abril de 2023 e estabilizaram na faixa de 20 a 30 por milhão. Em abril de 2025, o Wall Street Journal decretou no título: o emprego mais quente de 2023 já estava obsoleto. A pesquisa Work Trend Index da Microsoft, com 31 mil trabalhadores em 31 países, colocou prompt engineer na penúltima posição entre os novos papéis que as empresas consideravam contratar. A síntese mais citada veio de um executivo de recrutamento: o prompt engineering “virou de emprego em tarefa muito, muito rápido”. Dados de 2026 de uma base de vagas do setor (com a ressalva de ser levantamento próprio, sem revisão por pares) apontam queda de cerca de 30% nos títulos exclusivos entre 2024 e 2026, com o triplo de vagas de outros títulos exigindo a habilidade.

Note que a leitura correta é a menos dramática: a habilidade sobreviveu ao cargo. Saber especificar comportamento de modelo virou competência transversal, embutida em engenharia, produto, marketing, jurídico. O movimento é o mesmo que descrevi para o código em O fim do código como ativo: quando uma prática se comoditiza, o valor migra para a camada de cima. No caso do prompt, para o contexto proprietário e para a qualidade da especificação.

10. O que continua valendo, e o que levar para a sua empresa

Depois de tanta demolição, o inventário do que ficou de pé é curto e sólido. Clareza e direção continuam sendo a regra de ouro dos dois vendors: a OpenAI recomenda prompts simples e diretos (”Keep prompts simple and direct”), zero exemplos como ponto de partida (”Try zero shot first, then few shot if needed”) e delimitadores para separar as partes da entrada; a Anthropic mantém o teste do colega (se um colega sem contexto se confunde com o seu prompt, o Claude também se confunde) e acrescenta uma instrução nova e reveladora: explicar o motivo por trás da instrução, porque o modelo “é inteligente o suficiente para generalizar a partir da explicação”. Para contexto longo, o conselho continua mecânico e mensurável: documentos no topo, pergunta no fim, com ganho de até 30% de qualidade nos testes da Anthropic. E a recomendação mais recente da casa inverte de vez a gramática de 2022: “prefira instruções gerais a passos prescritivos”; um simples “pense com cuidado” costuma render raciocínio melhor do que o plano passo a passo escrito à mão. A aula ficou por conta do modelo. A direção, por nossa conta.

Fecho com quatro lições para empresas, em ordem de incômodo.

Primeira: prompts de 2023 rodando em modelos de 2026 pioram o resultado, e a sua empresa provavelmente tem vários. O caso Cursor, a instrução de verificação do Opus 5 e o aviso do Fable 5 sobre skills prescritivas demais contam a mesma história: o acúmulo de instruções defensivas calibradas para modelos antigos virou passivo. A OpenAI recomenda, na migração para o GPT-5.5, começar de uma baseline limpa em vez de carregar cada instrução do stack anterior. Auditar e apagar virou trabalho de otimização com ROI imediato.

Segunda: o controle fino saiu do texto e foi para a API, e isso transfere a decisão de quem escreve para quem arquiteta. Escolher modelo, reasoning_effort, verbosity e orçamento de pensamento por tarefa é o novo prompt engineering, com efeito direto na fatura. Quem trata esses parâmetros como default está pagando por raciocínio que não precisa ou economizando onde não devia.

Terceira: trate prompt como código de produção, porque os vendors já tratam. Versionamento, revisão, testes de regressão, rollback e evals; a OpenAI está encerrando o produto de prompts reutilizáveis da API (v1/prompts, com desligamento marcado para 30/11/2026) e orientando mover o conteúdo dos prompts para o código da aplicação. Prompt sem eval é opinião com acesso a produção.

Quarta: a vantagem durável mora no contexto, o insumo que só a sua operação gera. Modelos todo concorrente aluga pela mesma API; o orçamento de atenção cada empresa preenche com o que tem: dados proprietários organizados, ferramentas bem descritas, memória institucional, skills que codificam como o seu negócio decide. É o mesmo argumento do ativo invisível, uma camada acima: quem não construiu a base de contexto vai descobrir que ela também não se compra pronta.

A pergunta que deixo para o seu planejamento: quanto do manual de prompts que a sua empresa escreveu em 2023 continua colado nos seus sistemas em 2026, e quanto ele está custando, em tokens e em resultados, sem que ninguém tenha medido?

Referências principais.

Documentação oficial:

• OpenAI (Reasoning best practices; GPT-5 Prompting Guide; Text generation; Deprecations; Model guidance GPT-5.5)

• Anthropic (Prompting best practices; Prompting Claude Opus 5; Prompting Claude Fable 5; Effort; Adaptive thinking; Effective context engineering for AI agents; Agent Skills).

Papers citados:

• Brown et al. 2020 (arXiv 2005.14165);

• Wei et al. 2022 (2201.11903);

• Kojima et al. 2022 (2205.11916);

• Wang et al. 2022 (2203.11171);

• Zamfirescu-Pereira et al., CHI 2023 (DOI 10.1145/3544548.3581388);

• Sclar et al. 2023 (2310.11324);

• Li et al. 2023 (2307.11760);

• Yin et al. 2024 (2402.14531);

• Bsharat et al. 2023 (2312.16171);

• Liu et al. 2023 (2307.03172);

• Zhou et al. 2022 (2211.01910);

• Yang et al. 2023 (2309.03409);

• Battle e Gollapudi 2024 (2402.10949);

• Schulhoff et al. 2024 (2406.06608);

• Zheng et al. 2024 (2311.10054);

• Cao et al. 2024 (2406.10248);

• He et al. 2024 (2411.10541);

• Nori et al. 2024 (2411.03590);

• Sprague et al. 2024 (2409.12183);

• Chen et al. 2024 (2412.21187);

• Wallace et al. 2024 (2404.13208);

• Muennighoff et al. 2025 (2501.19393);

• Meincke et al. 2025 (2503.04818 e 2506.07142);

• Mei et al. 2025 (2507.13334);

• Khattab et al. 2023 (2310.03714);

• Yuksekgonul et al. 2024 (2406.07496; Nature 639, 2025);

• Agrawal et al. 2025 (2507.19457);

• Zhang et al. 2025 (2510.04618);

• Chatziveroglou et al. 2025 (2504.02111);

• Pecher et al. 2026 (2602.04297);

• Hicke e Tomlinson 2026 (2605.29018);

• Zhu et al. 2025 (2508.01213);

• Handa et al. 2025 (2503.04761);

• Chatterji et al. 2025 (NBER WP 34255);

• Dobariya e Kumar 2025 (2510.04950);

• Zhang et al. 2026 (2604.09443);

• Zhou et al. 2026 (2604.10739).

Infos gerais de mercado:

• IEEE Spectrum (mar/2024),

• Wall Street Journal (abr/2025),

• Fortune (mai/2025),

• Microsoft Work Trend Index.

Três semanas atrás, escrevi aqui que o julgamento acumulado nos arquivos de uma organização é o ativo que nenhum concorrente compra por API (O ativo invisível). Era o argumento econômico. Nesta semana, o AIA Labs da Bridgewater, em parceria com a Thinking Machines Lab, publicou o case que dá a esse argumento a demonstração técnica: o maior hedge fund do mundo mostrando, com números, por que tratar modelos open-weight como segunda divisão da IA é um erro de leitura.

Organizei a leitura em quatro movimentos: o teto do prompt, a virada do fine-tuning, o tratamento dos dados e a arquitetura que emerge quando os três se encontram.

O teto do prompt

A equipe testou variantes de Gemini, Claude e GPT em seis tarefas reais de filtragem de documentos que investidores fazem todos os dias: decidir se um artigo de notícia importa para quem aloca capital, se um documento de banco central sinaliza a direção dos juros, se um relatório ajuda a responder uma pergunta específica, onde começa o boilerplate de um documento ou de um e-mail.

Com prompts simples, os modelos ficaram perto de 50% de acurácia média. Quase uma moeda.

Com prompts escritos pelos especialistas, subiram para a casa dos 70, e o melhor modelo testado chegou a 78,2%. Melhor, mas ainda abaixo dos 80% que os investidores definiram como mínimo para confiar no sistema dentro do fluxo de trabalho. Métodos automáticos de otimização de prompt foram testados na sequência e devolveram ganho zero. Trocar de geração também ajudou pouco: o GPT 5.4 custa 43% a mais que o 5.2 e entrega acurácia quase igual nessas tarefas.

A virada

Aí vem a parte interessante. Em vez de insistir em prompt engineering, eles fine-tunaram um modelo open-weights, o Qwen3-235B, usando o Tinker, a infraestrutura de treino da Thinking Machines.

O resultado: 84,7% de acurácia média, 29,8% menos erros que o melhor frontier model testado e custo de inferência 13,8 vezes menor por tarefa.

O recipe importa. O baseline com GRPO já levou o modelo base de 44,8% para 73,5% de acurácia. Três refinamentos empurraram o resto do caminho: batching intercalado entre as tarefas, uma função de perda com clipping assimétrico (CISPO) e on-policy distillation em que o melhor checkpoint validado é promovido a professor do próprio treino.

Esse é o ponto central do case. A pergunta que a Bridgewater respondeu foi “qual modelo consegue aprender o julgamento específico dos nossos investidores”. E essa pergunta é bem diferente de “qual modelo sabe mais sobre finanças”.

O que um prompt captura

Julgamento específico raramente cabe inteiro em um prompt. Um prompt captura aquilo que o especialista consegue verbalizar. Boa parte do valor, porém, está no que ele aprendeu por repetição, contexto, erro, comparação, leitura de sinais fracos e anos de gosto acumulado. Esse tipo de conhecimento transfere mal por instrução e transfere bem por exemplo.

O próprio paper traz a ilustração perfeita: os investidores consideram as seis tarefas triviais e travam na hora de articular o processo de decisão. A regra que separa uma manchete geopolítica irrelevante de uma manchete geopolítica que move mercado existe na cabeça deles, funciona todos os dias e resiste à verbalização.

O detector de dados ruins

A parte mais inteligente do case, para mim, foi o tratamento dos dados. A primeira base de treino veio de fornecedores, rotulada por gente de fora do domínio, e os modelos treinados nela continuavam ruins. Examinando os traces de raciocínio, a equipe percebeu que muitos labels estavam simplesmente errados.

Como revisão por especialista é cara, eles montaram um esquema de verificação elegante: treinaram um modelo na base ruidosa e depois rodaram esse mesmo modelo sobre os próprios dados de treino. Quando o modelo discordava do label, o exemplo ia para os investidores especialistas revisarem. Se um modelo tropeça num exemplo que estava no próprio treino, ou o exemplo é genuinamente difícil, ou o label estava errado.

A confusão do modelo virou detector de dados ruins.

A tese

A lição vai bem além de “fine-tuning funciona”.

Modelos de fronteira são excelentes generalistas. O dia a dia de uma empresa, porém, é feito de decisões repetidas, critérios internos, exceções, histórico, contexto e julgamento acumulado. E quando a tarefa é específica, o dado é próprio e a métrica é clara, modelos menores e especializados podem vencer em três dimensões ao mesmo tempo: acurácia, custo e controle.

Há um espelho aqui do movimento que descrevi em O fim do código como ativo: quando todo concorrente acessa os mesmos modelos de fronteira por API, o acesso deixa de diferenciar, e o prêmio migra para o insumo que só a sua operação produz.

A evidência além da Bridgewater

E a Bridgewater tem companhia. O LoRA Land, da Predibase, avaliou 310 modelos fine-tunados com LoRA em 31 tarefas e reportou os especializados superando o GPT-4 em média nas tarefas testadas. Um benchmark da Distil Labs com 12 modelos pequenos mostra o Qwen3-4B fine-tunado igualando ou excedendo o GPT-OSS-120B, um modelo trinta vezes maior, em 7 de 8 benchmarks. E um case recente de suporte ao cliente mostra um modelo de 0,8B de parâmetros, treinado em uma hora por poucos dólares, superando GPT-5.4 e Claude Opus 4.6 em classificação de tickets, por 6,3 e 8,4 pontos respectivamente.

Comparar um modelo aberto pequeno com um frontier model no abstrato é medir com a régua errada. A comparação que interessa coloca um frontier model genérico contra um modelo menor treinado exatamente no seu problema, nos seus dados e na sua régua de qualidade.

Caramelo, o mesmo raciocínio na escala de uma pessoa

Foi essa lógica que me levou a criar o Caramelo, meu experimento pessoal open-source. Ele nasceu para testar uma pergunta estreita: até que ponto um modelo pequeno, barato e aberto consegue aprender uma camada específica de identidade, estilo e, no futuro, raciocínio a partir de um corpus próprio. Competir com frontier models em inteligência geral ficou fora da tese desde o primeiro dia.

O corpus, no meu caso, foram os meus próprios textos: um adapter LoRA treinado sobre um modelo aberto da família Gemma com os artigos que publiquei nesta newsletter ao longo de cinco anos, por menos de um dólar de GPU, rodando hoje numa VPS sem GPU e servido como API aberta. Essa primeira camada captura voz. A próxima fronteira é treinar padrões de raciocínio com exemplos verificáveis.

Esse último ponto merece cuidado: copiar chain-of-thought de um modelo forte, sem critério, apenas cristaliza dado ruim no modelo pequeno. A vantagem aparece quando existem tarefa estreita, avaliação objetiva, bons exemplos e um ciclo sério de revisão. O case da Bridgewater é exatamente a demonstração desse ciclo funcionando em produção.

A arquitetura híbrida

Por isso, o futuro que eu enxergo é uma arquitetura híbrida.

Modelos de fronteira trabalham como professores, revisores, geradores de dados sintéticos, avaliadores e orquestradores. Modelos abertos e especializados carregam o diferencial específico de uma pessoa, equipe ou instituição, com custo viável e controle maior. A Thinking Machines chama essa visão de differentiated intelligence. Eu chamo de levar a sério o que a organização já sabe.

O alpha estava no arquivo

Toda empresa grande tem décadas de decisões, documentos, pareceres, e-mails, análises, tickets, propostas, contratos, reuniões e revisões feitas por especialistas. Na maioria dos casos, isso está espalhado em pastas, CRMs, ERPs, drives e caixas de entrada. Ali mora um ativo que nenhum modelo de fronteira tem por padrão: o julgamento proprietário daquela organização.

A Bridgewater mostrou isso em finanças. O mesmo raciocínio vale para jurídico, vendas, atendimento, compliance, research, produto, engenharia, educação e praticamente qualquer área onde exista julgamento humano repetido ao longo do tempo. E vale ainda mais para quem desenha as aplicações para aprender com o próprio uso, transformando a operação diária em produtora contínua de exemplos rotulados.

O alpha estava no arquivo o tempo todo. A diferença é que agora ele pode virar modelo.

A pergunta que deixo para o seu planejamento: quais decisões os seus melhores especialistas repetem toda semana, e onde estão os exemplos que ensinariam um modelo a repeti-las com a sua régua de qualidade?

Em março escrevi aqui que a memória dos seus agentes está quebrada. O argumento era que jogar o histórico inteiro no contexto funciona no protótipo e desmorona em produção, e que a saída passava por separar camadas de memória com papéis distintos. Era arquitetura no papel.

Nos meses seguintes eu coloquei essa arquitetura para rodar na minha própria operação. Hoje cinco agentes trabalham para mim em máquinas diferentes: um numa instância EC2, um numa KVM, um no meu Mac, um agente de coding e um consolidador que roda diariamente. Todos escrevem e leem de um mesmo substrato. A rodada de consolidação de ontem processou 64 registros brutos vindos desses agentes e promoveu 15 arquivos ao acervo curado; a de anteontem, num dia atípico, processou cerca de 230. O sistema está vivo, tem cicatrizes, e é exatamente por isso que vale especificar.

Este ensaio é essa especificação. A tese central cabe numa frase: pare de procurar uma memória única de IA e construa um sistema de registros com fronteiras claras. A qualidade vem menos do modelo e mais de saber o que pode ser promovido, quem cura, qual é a fonte de verdade e como cada automação prova o que afirma.

Organizei a especificação em dez seções: o princípio, as quatro camadas de registro, os crons de captura que alimentam tudo, os consumidores desse contexto e as proteções de confiabilidade. A intenção é que você consiga implementar o equivalente com o agente que já usa, seja ele um assistente de código, um orquestrador próprio ou um framework de mercado.

01. O princípio: fronteiras antes de modelo

O erro mais comum que vejo em projetos de memória de agente é misturar quatro coisas que pedem tratamentos opostos: a sessão bruta, a memória semântica do agente, o conhecimento compartilhado entre agentes e o relatório executivo para humanos. Quando tudo vira “memória”, o log polui o raciocínio, a opinião de um agente contamina os demais e ninguém sabe mais o que é verdade consolidada.

O desenho que uso separa as camadas num fluxo de refino:

Cada camada tem dono, formato, ciclo de vida e critério de escrita próprios. Evidência bruta é imutável e barata; memória de sessão é volumosa e pesquisável; conhecimento curado é escasso e caro, porque passou por um funil com critério. A regra que sustenta o resto do artigo: descer de camada é automático, subir de camada exige promoção explícita. Nada “vira verdade” por acidente.

02. Session memories: o ledger do que aconteceu

A primeira camada é o ledger da sessão: conversa, ações, comandos relevantes, decisões, mudanças de contexto e resultados, gravados em append-only. Esse registro serve para auditoria e para recuperar detalhe exato (”o que foi dito na terça sobre o contrato X?”). Ele responde o que aconteceu; a verdade atual sobre um assunto mora em outra camada.

A implementação mínima é um armazenamento pesquisável por sessão, data, agente e tópico, com eventos neste formato:

{
  "session_id": "uuid",
  "agent_id": "daisy",
  "timestamp": "ISO-8601",
  "kind": "message|tool_result|decision|observation",
  "text": "...",
  "source": "webchat"
}

Dois cuidados aprendidos em produção. Primeiro, o ledger jamais entra inteiro no contexto de cada turno; ele existe para busca sob demanda, senão você recria o modelo ingênuo que critiquei em março. Segundo, vale manter um staging de momentos relevantes por sessão: um lugar onde o agente marca uma decisão como candidata antes de promovê-la a memória durável. Esse degrau intermediário evita tanto a perda do momento quanto a promoção precipitada.

03. Mem0: a memória semântica privada de cada agente

A segunda camada, no meu caso implementada com Mem0, guarda outra coisa: um índice semântico de fatos duráveis que ajudam aquele agente a trabalhar melhor daqui a dias ou semanas. Entra aqui apenas o que passa em três filtros ao mesmo tempo: muda estado, direção ou comportamento; segue válido (ninguém reverteu); e continuará relevante depois que a sessão acabar.

Exemplos que passam no filtro: uma decisão de arquitetura, uma preferência operacional minha, o contrato de um projeto, uma lição técnica reutilizável, o estado relevante de uma integração. Exemplos que ficam de fora: polling, saída crua de comando, “verifiquei e estava tudo verde”, conversa casual, progresso temporário. A diferença entre as duas listas é o que separa memória de ruído.

Cada memória carrega metadados mínimos:

{
  "agent_id": "daisy",
  "user_id": "daisy",
  "type": "decision|learning|correction|conclusion",
  "topic": "culkin-redshift",
  "durable": true,
  "reversible": false,
  "source": "session:<id>",
  "promoted_to_shared_knowledge": false
}

Um detalhe de desenho que considero inegociável: cada agente tem o seu índice privado, com a sua credencial, escrevendo sob a sua identidade. A experiência bruta de um agente é hipótese, e hipótese de um não pode virar verdade automática para todos. Já vivi o incidente que justifica a regra: um agente reportou um suposto bug de duplicação num fornecedor, e a investigação mostrou que o instrumento de medição dele é que estava errado. Se aquela “descoberta” tivesse se propagado como fato compartilhado, três agentes estariam operando sobre um erro.

04. gui-brain: o conhecimento curado que todos compartilham

A terceira camada é a que dá nome ao meu sistema: o gui-brain, um repositório Git de Markdown com frontmatter que funciona como fonte canônica sobre mim, meus projetos, decisões, preferências, pessoas e conceitos recorrentes. A distinção decisiva em relação à camada anterior: o Mem0 responde “o que este agente aprendeu?”; o repositório curado responde “qual é a verdade consolidada que todos os agentes devem usar?”.

A mecânica que faz isso funcionar é a separação entre inbox e acervo. Agente nenhum escreve direto na área curada. Cada um despeja observações numa caixa de entrada própria, por data:

gui-brain/
  _inbox/openclaw/2026-07-21/   <- área RAW, escrita livre por agente
  _inbox/hermes/...
  identity/                     <- curado, gate humano
  projects/  decisions/
  people/    knowledge/  work/

O fluxo de promoção: o agente detecta decisão, aprendizado ou mudança material; faz pull defensivo; cria a nota na inbox com proveniência, confiança, links e data; e commita. Uma vez por dia, um curador (no meu caso, um agente consolidador com playbook versionado) lê tudo que apareceu nas inboxes, deduplica observações que múltiplos agentes registraram, funde o que é a mesma coisa preservando as duas origens, e move o que tem sinal para a pasta curada apropriada. O que foi processado vai para um arquivo morto por agente, e nada é deletado.

Cada nota carrega um frontmatter que força o agente a se comprometer com o que está afirmando:

---
type: decision
title: "Contrato de dados do projeto X"
source_agent: openclaw
source_origin: "PR #123 + validação em produção"
created: 2026-07-21
confidence: high    # eu vi isso acontecer?
signal: high        # isso importa?
status: raw
links: [projects/active/projeto-x.md]
---

Dois campos merecem comentário. confidence e signal são ortogonais: um mede se a observação é sólida, o outro mede se ela importa. A matriz entre os dois decide o destino; sinal alto com confiança baixa, por exemplo, vira proposta para eu validar em vez de ser promovida direto. E o acervo separa updated (qualquer edição) de last_observed (a última vez que a realidade confirmou aquela informação), o que permite detectar conhecimento parado: arquivo formalmente recente cuja informação ninguém reconfirma há noventa dias é candidato a revisão.

Duas regras fecham a camada. Identidade (traços de personalidade, valores, forma de decidir) tem gate humano: o consolidador sintetiza propostas e elas ficam com review_decision: pending até eu aprovar ou rejeitar; agente nenhum escreve ali sozinho. E o consolidador também tece: injeta links bidirecionais entre arquivos relacionados e mede a razão de links novos por arquivo novo. Quando essa razão cai abaixo de um limiar, o grafo está virando um catálogo de arquivos órfãos, e isso dispara alerta. Inbox é proposta e evidência; área curada é verdade compartilhada. Essa fronteira é o coração do desenho.

05. Registros operacionais: a camada que evita contaminação

Existe uma quarta camada, auxiliar, que serve justamente para as outras não serem contaminadas por operação: um diário bruto por dia (memory/YYYY-MM-DD.md), um arquivo de obrigações futuras com prazo, verificação e rollback (FOLLOWUPS.md), os arquivos de estado dos crons (deduplicação, SHA já revisado, última notificação) e um MEMORY.md enxuto com pendências de alta visibilidade e ponteiros.

O propósito dessa camada é ser fila e estado, com ciclo de vida curto. Sem ela, o conhecimento estratégico vira lista de tarefas e a memória semântica vira log operacional, que são os dois modos clássicos de degradação.

06. Captura de decisões em PRs: review com estado e as CTO notes

Até aqui, camadas. Agora, os crons que as alimentam. O primeiro é o de captura de decisões em pull requests, que na minha operação culmina num produto executivo diário que chamo de CTO notes.

Começa pelo cron de review. Ele roda a cada 30 minutos e tem estado, o que o distingue de “pedir para uma IA opinar”:

GitHub/GitLab
  → descobre PR/MR aberto ou head alterado
  → deduplica por repo + número + SHA
  → busca body, diff, commits, checks e comentários
  → revisa contra rubrica versionada
  → publica review no SHA exato
  → grava estado e evidência
  → notifica somente quando houver mudança relevante

A rubrica é versionada e a regra de aprovação é dura: qualquer finding bloqueia. A parte que mais importa para quem for implementar é o papel do SHA. Uma review vale apenas para o head revisado; commit novo invalida o parecer anterior; e o estado do cron é chaveado por repo, número e head SHA. Sem isso, o sistema afirma coisas sobre um código que já mudou.

Sobre esse review roda o cron diário de CTO notes, à meia-noite: percorre os repositórios, coleta PRs, commits, diffs e discussões do intervalo do dia, salva a evidência bruta, sintetiza as decisões com fallback entre modelos e faz upsert idempotente da seção do dia num documento executivo. O sintetizador precisa distinguir código, discussão, decisão explícita, risco e ruído de merge; transformar todo comentário em “decisão” automaticamente produziria um documento executivo cheio de decisões que ninguém tomou. Na outra ponta, o consolidador diário lê esse documento, espelha o verbatim no acervo e destila apenas as decisões de alto sinal para a pasta de decisões curadas, com link de volta para a evidência.

07. Meeting intelligence: da fala ao objeto acionável

O segundo cron de captura trata reuniões, quatro vezes ao dia. O desenho parte de uma recusa: a saída que interessa é um conjunto de objetos acionáveis, e resumo bonito é subproduto.

gravação / notas de reunião
  → transcrição ou documento
  → extração estruturada de decisões, riscos, compromissos e owners
  → evidência bruta versionada
  → ações: issue, follow-up, estratégia ou CTO notes

Cada objeto extraído sai neste formato:

{
  "decision": "...",
  "owner": "...",
  "deadline": "...",
  "evidence": "meeting_id + trecho",
  "destination": "issue|followup|strategy|cto_notes"
}

A regra inviolável é o campo evidence: toda ação criada carrega o link para a reunião e o trecho de origem. É isso que impede a alucinação de decisão, o modo de falha mais caro desse tipo de automação. Uma “decisão” sem trecho de origem simplesmente não nasce.

08. Estratégia é consolidada, e nunca inferida de atividade

Sobre as notas executivas vive um segundo produto: o documento de estratégia (tese, prioridades, trade-offs, posicionamento) e um terceiro sobre pessoas e organização. Aqui vale uma correção que fiz ao meu próprio desenho. Cheguei a considerar um cron diário de estratégia e recuei: estratégia muda em ritmo semanal, na melhor das hipóteses.

O desenho que recomendo é um job semanal de consolidação estratégica que lê as CTO notes, as decisões curadas, as extrações de reunião e as métricas, e reescreve um documento vivo. Na minha operação, esse documento é alimentado por meeting intelligence e por input manual meu, e o consolidador o reescreve a cada ciclo em vez de empilhar apêndices. A restrição que protege a camada: o job nunca inventa estratégia a partir de atividade técnica. Volume de commits é sinal de movimento; direção é decisão humana registrada. Confundir os dois produz documentos que parecem estratégicos e apenas descrevem inércia.

09. Recuperação de contexto: a fonte certa para a pergunta certa

Todo o investimento em escrita se paga na leitura. No início de uma sessão, meus agentes seguem uma ordem de carregamento que começa leve e aprofunda sob demanda: primeiro identidade e o índice do conhecimento curado; depois o contexto do projeto em questão; depois busca semântica na memória privada; o ledger de sessão apenas se for preciso reconstituir detalhe; e as notas executivas quando a tarefa tem implicação de gestão.

A tabela mental que governa a leitura: verdade sobre pessoa, projeto ou decisão mora no acervo curado; experiência recente do próprio agente mora no Mem0; detalhe exato de conversa mora no ledger; estado operacional mora nos follow-ups e arquivos de estado; visão executiva mora nas CTO notes e na estratégia. Quando um agente responde errado, a causa mais frequente na minha experiência é consulta à camada errada, e o sintoma clássico é usar log de sessão para responder pergunta de estado atual.

Há um sinal de saúde que monitoro com atenção: o journal diário do consolidador registra quais arquivos curados foram efetivamente usados como fonte no dia. Se esse campo fica vazio por uma semana, o sistema está escrevendo sem ler. Chamo isso de write-only drift, e considero o sintoma número um de fracasso em gestão de conhecimento, humana ou de agente.

10. Confiabilidade: o que mantém o sistema honesto

As cadências que uso hoje: writer de memória a cada 2 horas; sincronização do repositório a cada 6; curadoria consolidada uma vez ao dia; review de PR/MR a cada 30 minutos; meeting intelligence quatro vezes ao dia; CTO notes diário; auditoria de qualidade de memória diária; backup em Git diário. Os números importam menos que a existência de cadência explícita por camada; ajuste ao seu volume.

As proteções, essas sim, considero não negociáveis. Idempotência por ID de origem, SHA ou hash de conteúdo, para que rodar duas vezes produza o mesmo resultado. Proveniência obrigatória em toda síntese. Evidência bruta separada da conclusão. Timestamps com timezone explícito. Health check por cron, com alerta para falha repetida; um cron parado em silêncio é indistinguível de “nenhuma novidade”, e essa ambiguidade já me custou 19 dias lendo uma fonte congelada achando que a fonte estava quieta. Fallback de modelo com a proveniência do modelo real registrada, porque provider pode responder com outro modelo por baixo do rótulo; e nenhum caminho de fallback em que a automação responde sem fonte. Git em tudo que é curado, pela auditabilidade e pelo rollback. E permissões mínimas por fonte: o agente que lê calendário raramente precisa escrever no repositório de conhecimento.

Cicatriz recente que ilustra a categoria: dois crons meus de monitoramento ficaram um dia inteiro fora do ar porque fixavam um único provedor de LLM, e a conta desse provedor ficou sem saldo. A correção virou regra escrita no acervo: automação operacional herda a cadeia central de failover, e fixar modelo exige justificativa explícita. É o sistema de registros documentando a própria operação, que é exatamente o comportamento que você quer ver emergir.

O que levar para o seu dia a dia

Quatro lições transferíveis.

• Primeira: defina as fronteiras antes de escolher ferramenta. Um arquivo de texto com fronteiras claras supera um vector database usado como balde único; a decisão cara é o que pode ser promovido, quem cura e qual é a fonte de verdade por tipo de pergunta.

• Segunda: exija proveniência de toda síntese. Decisão sem link para a origem é opinião com verniz de registro, e automação que afirma precisa provar, seja pelo SHA revisado, seja pelo trecho da reunião.

• Terceira: coloque um humano no gate das camadas sensíveis. No meu sistema, identidade e estratégia só mudam com veredito meu; o resto flui sozinho, e é essa assimetria que permite automatizar sem perder o controle.

• Quarta: trate o substrato curado como ativo. Escrevi em junho sobre dados proprietários como vantagem competitiva no nível das empresas; o acervo curado que seus agentes leem é a versão operacional disso, e ele se valoriza com o tempo pelas mesmas razões: acumulação, path dependence e a impossibilidade de comprar o atraso depois.

Quem quiser ver o mecanismo de melhoria contínua por trás disso, escrevi sobre ele em aplicações que aprendem com uso real.

Se for começar amanhã, comece pequeno: um repositório Git, uma inbox por agente, um frontmatter mínimo com proveniência e confiança, e um cron diário de curadoria com regras escritas. O resto do sistema cresce por demanda, camada a camada, e cada camada nova nasce quando a anterior começa a ser mal utilizada para um papel que exige outra.

Fecho com a pergunta que uso para auditar o meu próprio sistema. Quando o seu agente afirmar amanhã que uma decisão foi tomada, você vai conseguir apontar onde ela está escrita, quem a promoveu e qual evidência a sustenta?

O primeiro é um lançamento de modelo. O segundo é a maior revisão de um protocolo de agentes desde que ele existe. O terceiro é uma reportagem de mercado sobre empresas cortando gasto com IA. Separados, são três notas soltas. Juntos, marcam o fim de uma prática que dominou os últimos dois anos: jogar o modelo mais caro em cima de todo problema, o que a comunidade apelidou de tokenmaxxing.

Organizei o argumento em sete pontos, na ordem em que eles se constroem.

01. O que era tokenmaxxing

Tokenmaxxing é a prática de resolver qualquer tarefa com o modelo mais capaz disponível, sem perguntar se a tarefa exige aquela capacidade. Classificar um e-mail, extrair um campo de um PDF, resumir uma reunião e provar um teorema iam todos para o mesmo modelo de topo, faturados na mesma tarifa premium. Durante 2024 e 2025 isso fez sentido operacional: a diferença de qualidade entre o topo e o meio da tabela era grande o suficiente para justificar pagar caro por margem de segurança, e o orçamento de IA era tratado como investimento estratégico fora de questionamento.

A reportagem da CNBC de 26 de junho coloca número nessa cultura: usar modelo de fronteira para tudo responde por cerca de 95% do uso enterprise atual. Era a norma. O que mudou é que a norma ficou cara demais para sobreviver ao primeiro ciclo de orçamento sério.

02. O mercado puxou o freio

A mesma reportagem documenta o outro lado da curva. A Uber colocou um teto base de USD 1.500 por mês por funcionário depois de queimar o orçamento anual de IA em quatro meses. A Lindy AI migrou 100% do tráfego que rodava em Claude para DeepSeek e viu o custo despencar. O padrão que se repete entre as empresas citadas tem três peças:

1. teto de gasto mensal por funcionário,

2. roteamento de cada tarefa para o modelo mais barato que resolve, e

3. exigência de ROI comprovado antes de aprovar budget novo.

O pano de fundo financeiro confirma a pressão. Anthropic e OpenAI entraram com pedido de IPO confidencial em junho, com run-rates reportados de cerca de USD 47 bilhões e USD 25 bilhões respectivamente (números reportados, sem auditoria pública, e o NYT sugere que a OpenAI pode adiar o IPO para 2027). Os dois maiores fornecedores de fronteira se preparam para o mercado público no exato momento em que os clientes começam a racionalizar gasto. Roteamento de modelo deixa de ser otimização de engenheiro e passa a virar linha de governança financeira reportada a board.

03. A fronteira ficou barata: Claude Sonnet 5

No mesmo 30 de junho, a Anthropic lançou o Claude Sonnet 5. Modelo multimodal, janela de 1.000.000 de tokens de input e até 64 mil de output, a USD 3,00 por milhão de tokens de input e USD 15,00 por milhão de output, identificador de API claude-sonnet-5. Sonnet 5 fica abaixo do topo da própria Anthropic, com Opus 4.8 e Fable 5 acima em avaliação agregada. O ponto é exatamente esse. Sonnet 5 entrega raciocínio, código e matemática no quarto e terceiro lugares dos agregados de benchmark a uma fração do preço do tier Opus, com contexto suficiente para ingerir uma base de código inteira em um único request.

Vale separar o que é evidência do que é alegação, porque a diferença importa para a decisão. A data, o preço, o contexto e o identificador de API são fatos do system card. O score independente vem da Artificial Analysis, que coloca o modelo em 1618 de Elo no GDPval-AA, terceiro lugar, evidência forte porque é terceiro avaliando. Já os números de USAMO 79,5%, ChartMuseum 87% e CharXiv 88% são self-reported pela Anthropic e devem ser tratados como "alegação de fornecedor" até verificação independente. Latência e throughput citados vieram de página da Anthropic e pedem validação no endpoint oficial. A decisão de adotar Sonnet 5 como tier médio se sustenta nos fatos que forem possível auditar, sem depender dos números "com asterisco".

04. A infraestrutura de agente ficou barata: MCP stateless

O segundo fato técnico é o que torna o roteamento viável em escala. O Model Context Protocol publicou o Release Candidate da spec 2026-07-28, descrito pelo próprio projeto como a maior revisão desde o lançamento, com a versão final marcada para 28 de julho e uma janela de validação de dez semanas em que os SDKs Tier 1 ficam obrigados a suportar. A mudança de fundo é o core ficar stateless: removem o handshake de inicialização (SEP-2575) e o header de sessão Mcp-Session-Id (SEP-2567), e a versão do protocolo, as capabilities e a info do cliente passam a viajar em metadados em cada request, com um método novo de descoberta sob demanda.

A consequência operacional é direta. Um servidor MCP remoto que antes exigia sticky session, store de sessão compartilhado e inspeção profunda no gateway agora roda atrás de um load balancer round-robin comum, com clientes cacheando a lista de ferramentas até o tempo de vida expirar. O estado passa a ser explícito: uma ferramenta emite um identificador (um basket_id, um browser_id) e o modelo devolve esse identificador como argumento na próxima chamada, o que deixa o estado visível ao modelo em vez de escondido no transporte. Como há breaking changes, quem mantém servidor MCP próprio ganha em começar a leitura do changelog agora, antes de 28 de julho. Operar agente em produção fica mais barato e mais simples na mesma semana em que o modelo capaz ficou barato.

05. Model routing vira disciplina de gestão

Juntando as três peças, o roteamento de modelo assume o centro da operação de quem roda IA. A forma madura é uma política de tiers explícita: tarefa simples vai para um modelo open-weight barato (DeepSeek, Kimi K2.7 Code, GLM-5.2 são os candidatos que aparecem no radar e que eu uso), tarefa média vai para Sonnet 5, e só o raciocínio mais duro chega ao Opus. Cada request desce a escada até o degrau mais barato que ainda resolve, e o que torna isso defensável perante o board é instrumentar custo por fluxo, métrica que a maioria das operações ainda não tem.

O degrau do meio é o que muda mais de figura com o Sonnet 5. Para a maioria das tarefas de agente, código assistido e análise de documento, o tier médio passa a resolver com qualidade alta sem o custo do topo. O topo deixa de ser o default e volta a ser o que sempre deveria ter sido: a exceção cara, reservada para o problema que de fato a exige.

06. O que é hype nisso

Um bom radar precisa identificar separadamente o ruído e o sinal . Os números de benchmark self-reported do Sonnet 5 circulam como se fossem definitivos, e não são até alguém de fora confirmar. O número confiável hoje é o GDPval-AA da Artificial Analysis, terceiro independente. A narrativa de torcida Anthropic contra OpenAI também rende manchete e explica pouco: a própria TechCrunch argumenta que os dois enfrentam o mesmo gargalo regulatório, então a rivalidade fica como entretenimento e o sinal está no gargalo compartilhado. E a onda de busca agêntica do Google (Antigravity, Gemini 3.5 Flash, Search Agents) é tendência real de agentes embutidos em consumo, com um detalhe que o calendário desmonta por se tratar de um anúncio original de maio (mas que efetivamente ainda nao chegou na ponta).

A regra que uso para mim, e que recomendo, é simples de enunciar e difícil de seguir: número com asterisco é alegação até virar evidência, e a fonte primária vale mais que o agregador que a repackageia.

07. O que levar para a sua empresa

Quatro conclusões, em ordem de incômodo.

Primeira: frontier-para-tudo acabou como default. Se a sua operação roda toda tarefa no modelo mais caro, ela está pagando tier premium por trabalho que o tier médio resolve, e o primeiro ciclo de orçamento sério vai expor isso como a Uber expôs o próprio.

Segunda: roteamento é disciplina de gestão, com política de tiers e custo por fluxo medido. Desenhar essa política e instrumentar o custo é o que transforma a área de IA de centro de custo crescente em dona de uma arquitetura que entrega o mesmo resultado por uma fração do gasto. Esse é o argumento que sustenta IA na empresa perante quem assina o cheque.

Terceira: a infraestrutura barata chegou junto com o modelo barato. MCP stateless remove o motivo técnico mais comum para agente em produção sair caro. Quem mantém servidor próprio tem uma data, 28 de julho, e um changelog para ler antes dela.

Quarta, e a que compõe com tudo que já escrevi aqui: quando todo concorrente tem acesso aos mesmos modelos de fronteira pela mesma API, o modelo para de ser vantagem. O que sobra como fosso é o que não se compra por API, o ativo de dados proprietário coletado ao longo de anos que descrevi em O ativo invisível, agora somado à arquitetura de custo que decide qual modelo toca qual tarefa. O modelo de fronteira é a camada fina e comoditizada em cima. A vantagem real é a estrutura que sustenta embaixo.

A pergunta que fica para o seu planejamento é direta: se o modelo mais inteligente do mercado custasse o mesmo que o mais barato amanhã, o que na sua operação ainda seria difícil de copiar? A resposta a essa pergunta é a única coisa em que vale a pena investir antes do próximo lançamento tornar o resto commodity.

Fontes primárias consultadas: blog oficial do Model Context Protocol (RC 2026-07-28), system card do Claude Sonnet 5 cruzado em agregador de stats, blog do Google. Jornalismo com fontes nomeadas: CNBC (corte de gasto enterprise) e TechCrunch (gargalo regulatório). Números de benchmark marcados como self-reported são alegação da Anthropic até verificação independente; o número auditado citado é o GDPval-AA da Artificial Analysis. Run-rates de Anthropic e OpenAI são reportados, sem auditoria pública. Sinais de X foram tratados apenas como detector de fumaça, sem citação social como evidência. Este ensaio nasceu de uma rodada do AI Intelligence Radar, sistema de curadoria que mantenho em operação própria.

O estudo é “Data Assets and Industry Competition: Evidence from 10-K Filings”, de Adam Saunders (University of British Columbia) e Prasanna Tambe (NYU Stern), disponível no SSRN. Os dois fizeram algo que parece óbvio depois que alguém faz: usaram mineração de texto para ler todos os relatórios anuais que as empresas de capital aberto americanas são obrigadas a entregar à SEC (os formulários 10-K) entre 1996 e 2012, e mediram quanto cada empresa fala sobre capturar, armazenar, gerenciar e analisar dados.

O período analisado pode parecer datado, e é justamente essa distância que torna o estudo valioso. Eles mediram a formação da vantagem competitiva por dados antes do hype de big data, antes de deep learning, antes de LLMs. O mecanismo que documentaram é estrutural e independe de moda. E, como vou argumentar no final, é exatamente o mecanismo que está se repetindo agora com IA.

Organizei o argumento do paper em dez pontos, na ordem em que eles se constroem. Vamos a eles.

01. O problema: dados são um ativo invisível

Bases de dados, capacidade analítica e práticas data-driven são ativos intangíveis. Geram valor, custam caro para construir, levam anos para maturar, e não aparecem em nenhuma linha do balanço patrimonial. O contador registra o servidor, mas os quinze anos de histórico de transações que rodam nele ficam de fora.

Isso criava um problema de medição que travava o campo inteiro. As fontes tradicionais de dados sobre investimento em TI cobriam poucas centenas de empresas, períodos curtos, ou simplesmente deixaram de existir. Sem medida, sem evidência; sem evidência, a conversa sobre “dados como ativo” ficava no terreno da opinião: o pitch de consultoria de um lado, o ceticismo do CFO do outro.

A consequência prática: ninguém conseguia responder com rigor a perguntas básicas. Empresas que investem em dados valem mais? Lucram mais? Quanto tempo demora? A vantagem é replicável ou cumulativa?

02. Como mediram: do dicionário ao painel final

A solução dos autores tem duas pernas. A primeira é a fonte: o 10-K. Diferente de press release e de deck de investidor, o 10-K é regulado pelo Securities Act e pela Sarbanes-Oxley: cada afirmação é juridicamente vinculante, auditada, e mentir nele é crime com pena para os executivos que assinam. Quando uma empresa escreve no 10-K que implementou um data warehouse, o departamento jurídico dela deixou.

A segunda perna é o dicionário. Para evitar viés de quem escolhe as palavras, eles partiram de uma fonte externa e pública, o relatório Big Data do McKinsey Global Institute (2011), e extraíram toda combinação de palavra com “data”. Saíram 1.035 combinações, que foram validadas manualmente em amostras reais de 10-Ks: sobreviveram 410 keywords, agregadas em 155 termos-raiz (customer data, data mining, data warehouse, clinical data, data privacy...).

Aplicado o dicionário aos relatórios e cruzando com dados financeiros da Compustat, o funil ficou assim: 194.935 firma-anos no ponto de partida; 116.173 com 10-K válido (o painel usado para análise de difusão); e 33.120 observações na amostra final de valor e lucro, depois de exigir financeiros completos, excluir financeiras (cujo balanço não se compara) e excluir produtoras de TI, que citam dados para vender, não para usar. A medida final, PCTDATA, ranqueia as empresas de cada ano em decis de intensidade de keywords.

É a maior base já construída sobre o tema: cerca de 1.950 empresas por ano, dezessete anos. Ler fontes públicas em escala com software, aliás, ficou radicalmente mais acessível desde então: o radar de inteligência de mercado que publiquei em código aberto faz o equivalente com LLMs, sem depender de dicionário de keywords.

03. A difusão: começa na TI e se espalha pela economia inteira

Com o painel montado, a primeira pergunta é descritiva: quem fala de dados, e desde quando?

Em 1996, 78% das produtoras de TI já mencionavam ao menos uma keyword de dados em seus 10-Ks, contra 41% do resto da economia. Em 2012, as produtoras chegaram a 90%, mas a história real está nas usuárias: 75%, quase o dobro do ponto de partida. O crescimento atravessou todos os setores, inclusive os menos óbvios: agricultura foi de 20% para 62%, utilities de 26% para 78%.

O detalhe mais interessante está na dispersão dentro de cada setor. Entre as produtoras de TI, a variação de intensidade entre empresas vem caindo desde 1996: a prática amadureceu, padronizou, virou commodity. Entre as usuárias, a dispersão vem subindo. Líderes e retardatários estão se afastando. É a assinatura estatística de uma prática que deixou de ser curiosidade técnica e virou arma competitiva.

04. O vocabulário muda e conta a história da década

Olhar quais termos crescem é quase uma arqueologia da gestão de dados. Nos anos 90, o termo dominante era “data processing”, dados como tarefa operacional. Ele encolhe ao longo da amostra (11,5% para 8,0% dos relatórios), enquanto “database” quase dobra (13,9% para 24,8%) e “data center” sobe de 1,3% para 9,7%.

A explosão, porém, é de outra família. O termo que mais cresceu em todo o período foi “data privacy”: de exatos 2 relatórios (entre cerca de 3.000) em 1996 para 6,3% da amostra em 2012. Em 2012, data security, data privacy, sensitive data, data protection e personal data estavam todos entre os 20 termos mais citados: nenhum deles aparecia de forma relevante em 1996.

O centro de gravidade do discurso corporativo migrou de processar (anos 90) para coletar (anos 2000) e depois proteger (pós-2007). Guarde essa sequência: ela reaparece no ponto 07, precificada pelo mercado. E lembre que isso é anos antes de GDPR e LGPD existirem: as empresas líderes sinalizavam preocupação com privacidade uma década antes do regulador chegar. E a disputa por esse insumo só se intensificou: em 78% dos bots de IA querem uma coisa: seus dados mostrei quem está coletando o quê na internet de hoje.

05. O mercado paga prêmio, e o prêmio não tem teto

Aqui o estudo sai do descritivo e entra no que interessa. A métrica é o Tobin’s q: valor de mercado dividido pelo custo de reposição dos ativos tangíveis. Se q é maior que 1, o mercado enxerga na empresa valor além de máquinas, prédios e estoques, ou seja, precifica intangíveis.

Resultado, controlando por P&D, publicidade, alavancagem, tamanho, lucratividade, setor e ano (2001–2012, excluindo a bolha ponto-com): a relação entre intensidade de dados e valor é uma escada. Nos decis de baixo, nada. Do sétimo decil em diante, o prêmio aparece e cresce: +11,7%, +12,8%, +23,9%, até +35,3% de Tobin’s q para as empresas no decil mais intensivo, comparadas à base.

Dois detalhes elevam a barra. Primeiro, a relação é monotônica e não desacelera no topo: não existe “intensidade demais”. Segundo, o resultado sobrevive ao controle mais fino possível: comparando cada empresa apenas com concorrentes da mesma indústria de seis dígitos NAICS, no mesmo ano, o prêmio do topo segue em +28,4%. O prêmio é diferença entre vizinhos diretos de mercado, com qualquer efeito de “setor de tecnologia vale mais” já descontado pelos controles.

06. O lucro vem, mas demora anos (e discurso genérico custa caro)

Se o mercado paga na frente, o lucro confirma depois. A intensidade de dados de hoje não tem correlação significativa com o lucro de hoje. Tem com o lucro de daqui a dois, três, cinco anos, e o efeito cresce a cada ano de defasagem, chegando a +3,2 pontos percentuais de ROA acima da média da indústria no horizonte de cinco anos (top 10% vs. bottom 10%).

A leitura é a mesma que Brynjolfsson e colegas fizeram para a TI em geral: o ativo só vira resultado quando os complementos organizacionais (processos, habilidades, cultura de decisão, o lado humano que explorei em Construindo Times de IA) ficam prontos. Isso leva anos. Avaliar uma iniciativa de dados pelo resultado do primeiro ano é medir com a régua errada.

O contraste que dá força ao resultado: os autores rodaram o mesmo modelo com menções genéricas a “information technology” e “information systems”. O coeficiente é negativo: empresas que falam de TI em geral, sem prática específica de dados, lucram menos que as concorrentes nos anos seguintes. O mercado e a contabilidade convergem no mesmo veredito: o mercado recompensa a prática específica e cobra caro do discurso genérico.

07. As três eras do valor: coleta, segurança, padronização

Com análise fatorial (sem categorias pré-definidas), as 155 keywords se agrupam sozinhas em exatamente três temas: coleta (clinical data, trial data, collecting data...), segurança (data security, data protection, personal data...) e padronização (standardizing data, extract data, map data...).

O mercado premiou cada um em seu tempo. Entre 2001 e 2006, o prêmio estava na coleta: coeficiente de +0,218 sobre Tobin’s q, forte e significativo. De 2007 a 2012, o prêmio da coleta zera e migra para a segurança (+0,200). A padronização, sozinha, nunca foi premiada em nenhum período.

A interpretação dos autores é a que a microeconomia sugere: enquanto coletar dados diferenciava, o mercado pagava por coleta. Quando todo mundo passou a coletar, virou aposta de mesa: o prêmio foi para a fronteira seguinte. É um padrão de migração de valor que qualquer executivo de tecnologia reconhece, agora com coeficiente e erro-padrão.

08. Não dá para pular etapas: a evidência de path dependence

E a padronização, que nunca aparece premiada sozinha? Aqui está, para mim, o resultado mais importante do paper.

Os autores separaram as empresas em dois grupos: as que em algum momento anterior registraram alta atividade de coleta (top 25%) e as que nunca registraram. No período 2007–2012, investir em segurança vale +0,321 de Tobin’s q para quem tem a base de coleta, quase o triplo do efeito (não significativo) para quem não tem. E a padronização só gera prêmio estatisticamente detectável para quem coletou antes (+0,142).

Em outras palavras: segurança e padronização funcionam como multiplicadores de uma base que precisa existir antes. Os dados rejeitam explicitamente a história reconfortante de que retardatários conseguem “alcançar” comprando as camadas de cima depois: investimento tardio sem fundação rende pouco, e a diferença entre os dois grupos é maior em 2007–2012 do que em 2001–2006. A vantagem não só persiste; ela compõe.

A boa notícia para quem está atrás: construir a fundação não exige reescrever tudo. A arquitetura em camadas que documentei aqui consolida dezenas de fontes heterogêneas preservando os sistemas legados, e é o caminho pragmático para o degrau de baixo.

09. Antes de acreditar: os testes contra as explicações rivais

Todo resultado correlacional convive com duas objeções, e o paper enfrenta as duas de frente.

Objeção um: causalidade invertida, a ideia de que empresas boas é que falam de dados. O teste: acompanhar o valor de mercado em volta da primeira aparição de uma keyword de dados no 10-K de cada empresa. Um ano antes: nada (+4,0%, não significativo). Às vésperas: nada. De nove a dez meses depois: +18,8%, altamente significativo. Se a keyword fosse só um marcador de empresa boa, o prêmio existiria antes da primeira menção. Não existe.

Objeção dois: cheap talk, “é discurso para inflar a ação”. O teste: medir algo que narrativa nenhuma melhora, o giro de estoque. Resultado: melhora de cerca de 10% no ano seguinte à primeira keyword, e nada antes. A eficiência operacional real acompanha o discurso, exatamente o que se espera se o discurso reflete prática.

E a robustez: trocando o dicionário McKinsey por um léxico do NIST, ou usando só a palavra “data”, ou reincluindo financeiras e produtoras de TI, o padrão se mantém. Os autores são honestos sobre os limites: a medida captura a materialidade declarada dos dados, sem dizer quanto a empresa investe, e controles finos não substituem um experimento randomizado. Mas o conjunto de testes elimina as explicações alternativas óbvias.

10. O que levar para a sua empresa

Quatro conclusões, em ordem de incômodo.

Primeira: dados são um ativo de verdade, com prêmio de mercado mensurável, mesmo invisível no balanço. Se a sua empresa só gerencia o que aparece no demonstrativo, ela está gerenciando o conjunto errado.

Segunda: o retorno é estruturalmente defasado. O mercado precifica na frente; o lucro confirma dois a cinco anos depois. Quem cobra payback de iniciativa de dados no orçamento do ano seguinte está medindo com a régua errada e matando o ativo antes de ele maturar.

Terceira: a sequência importa mais que o montante. Coleta primeiro; segurança e padronização multiplicam sobre essa base, e rendem pouco sem ela.

Quarta: a vantagem é cumulativa. Bases de dados levam anos para construir, e os retardatários do estudo não conseguiram comprar o atraso. Em 2012, isso significava dispersão crescente de desempenho dentro das indústrias. O nome disso em estratégia é fosso.

O paralelo com 2026

Releia os dez pontos trocando “dados” por “IA” e o paper fica desconfortavelmente atual.

A escada que o estudo documentou (coletar, depois proteger, depois padronizar, cada camada multiplicando a anterior) ganhou um degrau novo: treinar e ativar modelos sobre dados proprietários. E o padrão de migração de valor do ponto 07 está se repetindo na nossa frente. Em 2024–2025, “ter IA” diferenciava; está virando aposta de mesa na mesma velocidade em que coletar dados virou nos anos 2000, o mesmo movimento de comoditização que descrevi em O fim do código como ativo, agora uma camada acima. Quando todo concorrente tiver acesso aos mesmos modelos de fronteira (e já tem), o prêmio migra para o único insumo que não se compra por API: o ativo de dados proprietário, coletado, protegido e padronizado ao longo de anos. E o degrau seguinte já está visível: aplicações desenhadas para aprender com o próprio uso, que transformam a operação diária em coletora contínua desse ativo.

O que o paper acrescenta à conversa de 2026 é a estrutura temporal da tese: o prêmio chega antes do lucro, o lucro demora cinco anos, e quem pula a fundação não recupera depois. Empresas que hoje tentam “comprar IA” sem nunca terem construído a base de dados são as empresas de padronização-sem-coleta do estudo: investimento de cima sem o degrau de baixo.

A pergunta que fica para o seu planejamento é a mesma de 1996: que dados só a sua operação gera, e o que você está fazendo, hoje, para que eles existam, organizados, protegidos e utilizáveis, em 2031?

Referência: Saunders, A. & Tambe, P. (2015). Data Assets and Industry Competition: Evidence from 10-K Filings. Draft de setembro/2015, SSRN 2537089. Coeficientes citados: tabelas 3–16 do draft. Significância: os valores citados como significativos têm p<0,05 ou p<0,01.

Há algumas semanas eu publiquei o Por onde eu começo?, contando da academia-ia, a trilha gratuita de 30 dias pra quem sempre se prometeu entender IA e nunca passou do módulo três de curso nenhum. No meio daquele texto, quase como nota de rodapé, eu deixei um aviso:

“Se você é engenheiro de ML procurando matemática de transformer, esse curso não é pra você.”

Eu escrevi aquela frase pra fechar uma porta. Hoje eu volto pra abrir a outra. Porque a pergunta do jantar de família tem uma irmã menos famosa, que chega por canais diferentes e com outro sotaque. Esse texto é pra ela.

A outra cena

Ela não aparece no jantar de família. Aparece no Slack do trabalho, no grupo de devs, na conversa que sobra depois da daily. E quase sempre vem numa versão de:

“Cara, eu uso essas APIs todo dia. Já fiz fine-tuning seguindo tutorial, já subi RAG em produção. Mas se você me perguntar por que o Adam converge onde o SGD patina, eu não sei. Eu copio. A IA faz pra mim… Por onde eu me aprofundo?”

Quem pergunta isso não é iniciante. É dev, é engenheiro de dados, é cientista de dados formado em bootcamp, é o Pleno que virou “a pessoa de IA” da empresa por ter chegado primeiro. Essa pessoa constrói coisas que funcionam. E é exatamente por isso que a sensação incomoda tanto: o chão funciona, mas soa oco quando você bate.

Os sintomas são sempre os mesmos. Você chama model.fit() e não sabe dizer o que acontece entre a primeira época e a segunda. Você ajusta learning_rate por superstição, não por diagnóstico. Você abre um paper, atravessa o abstract com confiança e afunda na equação dois. Você sabe que normalizar os dados melhora o treino, mas não por quê, então quando não melhora você não tem pra onde ir. E a cada tutorial novo a sensação se repete: você terminou, funcionou, e você sabe um pouquinho menos do que parece.

Isso tem nome, e você provavelmente já se ouviu dizendo: tutorial hell. O inferno não é a falta de material. É o excesso de material que te ensina a fazer sem nunca te cobrar entender.

O que existe lá fora, de novo, não resolve

Quando essa pergunta começou a chegar, eu fiz o mesmo exercício do texto anterior: sentei pra recomendar um caminho e percebi que não tinha um inteiro pra recomendar.

Os cursos de “ML na prática” ensinam receita de framework. Você sai sabendo qual função chamar e em que ordem, que é exatamente o conhecimento que evapora a cada major release. A matemática, quando aparece, vem num slide de 40 segundos com a promessa de que “você não precisa entender isso agora”. Spoiler: o agora chega.

Os livros bons existem e são ótimos. Mas livro de matemática é passivo. Você lê a derivação do gradiente, acena com a cabeça, vira a página, e três dias depois não reconstrói nem a primeira linha. Entender de verdade exige fazer, errar, plotar, comparar com a implementação de referência. Papel não roda código.

Os papers assumem a base que você está tentando construir. Ler paper sem álgebra linear e probabilidade sólidas é decifrar um idioma com dicionário rasgado. Dá pra fingir por um tempo, todo mundo finge por um tempo, mas fingir cansa.

E tem o filtro que quase ninguém nomeia: quase nada disso existe em português. O material de profundidade real está em inglês, o que cria um pedágio duplo. A pessoa paga pra entender o conceito difícil e paga de novo pra entender a língua em que o conceito difícil foi escrito. Tem muita gente boa ficando na superfície não por falta de capacidade, mas por excesso de pedágio.

A conclusão foi a mesma da outra vez, com o sinal trocado: ninguém precisa de mais um tutorial de “construa seu chatbot em 15 minutos”. Precisa de um caminho. Só que dessa vez um caminho longo, com equação, com código e com exercício que não aceita cola.

O que eu construí

Chama math-statistics-for-ai. É um repositório público no GitHub: github.com/guifav/math-statistics-for-ai.

São 54 notebooks Jupyter executáveis, somando 2.596 células, sendo 1.672 de texto e 924 de código. Tudo em português. Licença MIT, que é o jeito jurídico de dizer “isso é seu também”.

Cada notebook é uma aula completa: cabeçalho com pré-requisitos mapeados, tempo estimado, fio narrativo explícito, teoria intercalada com código que roda, exercícios marcados como TAREFA DO ALUNO e soluções executáveis em células com tag solution, separadas de propósito pra você suar antes de espiar. No final, seção de erros comuns e conexões com o que vem depois. Tem até validador automático rodando em CI, que checa sintaxe, referências internas e metadados de cada notebook a cada push, porque material de estudo com célula quebrada é desrespeito com quem estuda.

A filosofia é uma só: nenhum conceito entra sem os três estados. A equação, o código e o caso de uso. Se você só viu a equação, você não aprendeu. Se você só rodou o código, também não.

O caminho

São sete módulos, do zero matemático até o modelo rodando em produção. Não precisa percorrer linearmente, cada notebook declara seus pré-requisitos, mas a ordem existe por um motivo.

Módulo 00, Matemática, 8 notebooks. A fundação que todo mundo pula e depois paga juros. Começa em pré-cálculo, funções, exponenciais e logaritmos, exatamente as que viram funções de ativação. Passa por álgebra linear em duas camadas: vetores, produto interno, normas e similaridade, que é literalmente a matemática por trás de embeddings e busca vetorial; depois matrizes, transformações, autovalores, PCA e SVD. Segue pra cálculo: derivadas, gradientes, Jacobiano, Hessiano, até você implementar backpropagation entendendo cada passo; depois integrais, séries, Monte Carlo e a razão de a área sob a curva ROC se chamar área. Fecha com probabilidade em dois níveis, de Bayes e distribuições até MLE, inferência bayesiana e GMM, e com otimização: convexidade, SGD, Momentum, RMSprop, Adam e por que regularização funciona em vez de apenas “usar L2”. Pra calibrar expectativa: só o notebook de derivadas estima 10 a 12 horas de estudo. E vale cada uma, porque é ali que loss.backward() deixa de ser mágica.

Módulo 01, Estatística, 5 notebooks. O que separa quem treina modelo de quem confia em modelo. Descritiva e visualização, inferência com intervalos de confiança, testes de hipótese, ANOVA, bootstrap e o problema dos múltiplos testes, que é onde a maioria dos dashboards mente. Estatística bayesiana de verdade, priors, posteriors, e a revelação de que MAP e regularização são a mesma ideia com roupas diferentes. Regressão como estatístico vê, com diagnóstico de resíduos e multicolinearidade. E design de experimentos: poder estatístico, A/B testing, causalidade, DAGs e validação temporal. Se você já lançou uma feature baseada num teste A/B mal desenhado, esse módulo vai doer de um jeito produtivo.

Módulo 02, Data Science, 4 notebooks. O menos glamouroso e o que mais paga aluguel. NumPy e Pandas a sério, EDA com framework em vez de improviso, missing values, outliers e leakage, que é o bug silencioso que infla métrica e destrói credibilidade. SQL com joins e window functions, APIs com paginação e retry, e acesso a dados de gente grande: PostgreSQL, ORM, Parquet, feature stores e segurança.

Módulo 03, Machine Learning, 7 notebooks. Os clássicos, sem pressa. Classificação completa com as métricas que importam e quando cada uma mente, regressão com regularização, árvores e ensembles, bagging, Random Forest e boosting com seus trade-offs, SVM e o kernel trick, clustering com K-Means, DBSCAN e GMM, redução de dimensionalidade com PCA, t-SNE e UMAP e como não se enganar com elas. E um tutorial from-scratch que percorre o fluxo inteiro, dos dados crus à avaliação. Pular os clássicos pra ir direto pra LLM é construir o décimo andar primeiro.

Módulo 04, Deep Learning, 6 notebooks. Fundamentos de redes neurais, arquiteturas, e treinamento na vida real, o que fazer quando o loss não desce, que é o dia a dia que nenhum tutorial mostra. Transfer learning, e dois notebooks que quase nunca aparecem em curso: aceleração de hardware e otimização de Python. É a parte em que entender a máquina vira dinheiro, seu ou da empresa.

Módulo 05, Domínios Aplicados, 20 notebooks em 4 submódulos. Visão computacional: CNNs por dentro, convolução, pooling e receptive field, classificação com augmentation e interpretabilidade, detecção com IoU, NMS, YOLO e R-CNN, segmentação com U-Net, e Vision Transformers até modelos vision-language. NLP, a trilha completa: do TF-IDF e n-grams a Word2Vec, RNNs e LSTMs, self-attention, BERT e fine-tuning, LLMs com scaling laws, prompting e alinhamento, e fechando com RAG, um dos maiores notebooks do repositório, 83 células cobrindo chunking, embeddings, busca vetorial, retrieval e avaliação. Se você já subiu RAG copiando arquitetura de blog post, esse notebook explica o sistema que você opera. IA generativa: GANs, VAEs com ELBO e espaço latente, diffusion models em 94 células, fine-tuning com LoRA e adapters, e multimodal. E séries temporais: estacionariedade, ACF e PACF, ARIMA e Prophet, ML com lag features e validação temporal, e deep learning sequencial até Transformers.

Módulo 06, MLOps, 4 notebooks. Porque modelo que não chega em produção é PDF caro. Deploy com API, contratos e versionamento, MLflow pra parar de rastrear experimento em planilha, monitoramento e drift com PSI e KS test, e pipelines com CI/CD, DVC e feature stores.

Como estudar isso sem se enganar

Aqui vai a parte honesta, e ela é o espelho invertido do texto anterior.

A academia-ia cabe em 10 minutos por dia porque foi desenhada pra caber. Esse repositório não cabe. Isso aqui é material de meses, na escala de centenas de horas se você fizer direito. Não existe versão comprimida de profundidade, e qualquer pessoa que te vender uma está te vendendo a sensação, não a coisa.

O que existe é método:

• Rode tudo. Notebook não é PDF. Se você leu sem executar, você não passou por ali.

• Quebre o código de propósito. Mude o hiperparâmetro pro valor errado, tire a normalização, veja o treino degradar. Intuição se constrói no contraste.

• Faça a TAREFA DO ALUNO antes de abrir a solução. As soluções estão lá, executáveis, marcadas com tag. A distância entre olhar a resposta e produzir a resposta é exatamente a distância que você está tentando atravessar.

• Use os pré-requisitos como grafo, não como burocracia. Cada notebook declara o que assume. Se a equação dois te afundar, o cabeçalho diz pra onde voltar.

• Não estude em ordem de hype. A vontade de pular pro notebook de LLM é compreensível. Mas ele rende o dobro pra quem chegou nele por dentro do caminho.

Setup em quatro linhas: clone, venv, pip install -r requirements.txt (ou requirements-gpu.txt se você tem CUDA 12.1), jupyter lab notebooks. Tem validação leve pra quem quer checar a integridade sem instalar o stack científico inteiro.

Por que aberto, e por que em português

Quem leu o texto anterior já conhece a frase da minha mãe, faça o seu melhor sem esperar nada em troca, então não vou repetir o argumento inteiro. Vou só estender ele um degrau.

Lá eu escrevi que IA não pode ser privilégio. Profundidade também não. Existe uma versão dessa exclusão que é mais sutil que o preço do curso: é a exclusão por idioma e por fragmentação. O conhecimento de base está disponível, tecnicamente, mas espalhado em inglês por dezenas de fontes que não conversam entre si. Juntar tudo, ordenar, traduzir pra nossa língua e abrir o código é o tipo de coisa que precisava existir e não existia.

Então é MIT. Sem cadastro, sem paywall, sem versão premium. E como é um repositório e não um produto, ele tem uma vantagem que curso nenhum tem: aceita pull request. Achou erro, abre issue. Quer melhorar um notebook ou propor um novo, o CONTRIBUTING.md explica o rito e o validador garante que nada entre quebrado. Material de estudo aberto fica melhor do jeito que software aberto fica melhor: em público, um commit por vez.

Os dois extremos da mesma pergunta

Agora as duas portas estão abertas.

Se você, ou alguém que você conhece, está no ponto de partida, sabe que IA importa mas não sabe nem o que perguntar, o caminho é a academia-ia: 30 dias, 10 minutos por dia, do zero ao uso consciente. O texto sobre ela está aqui.

Se você é a pessoa técnica que já constrói com IA mas decidiu que cansou de copiar, o caminho é o math-statistics-for-ai: 54 notebooks, da inclinação da reta ao drift em produção, no seu ritmo, pra sempre.

É a mesma pergunta nos dois casos. Por onde eu começo? Só muda a profundidade da resposta que você está pronto pra receber.

Bora?

O repositório está no ar: github.com/guifav/math-statistics-for-ai.

Clona, abre o módulo 00 e roda a primeira célula hoje. Não o módulo que parece mais interessante, o 00 mesmo, e seja honesto consigo na avaliação: se for fácil, você acelera sem perder nada; se não for, você acabou de descobrir onde o chão estava oco.

Estrela no repositório é vaidade, eu prefiro issue. Se você travar em algum notebook, achar um erro ou tiver uma sugestão, abre uma issue que eu leio, do mesmo jeito que leio as respostas desta newsletter.

E se você conhece alguém preso no tutorial hell, e você conhece, todo time tem pelo menos um, manda esse texto. A ponte pro outro lado continua aberta, só que dessa vez ela é mais longa, e a vista lá de cima compensa cada hora da travessia.

Obrigado por estar por aqui, como sempre.

Abs,

Guilherme

PS: se você chegou até aqui e percebeu que esse texto não é pra você, que as equações te assustam e você só queria entender essa tal de IA, sem drama nenhum: o texto pra você é o anterior, e a academia-ia te espera com 10 minutos por dia. As duas portas levam pro mesmo lugar.

Hoje eu quero te contar de uma coisa que vinha rascunhando há meses e que finalmente saiu do Notion essa semana. Mas antes de mostrar o que é, preciso te contar a cena que fez isso existir, porque sem ela o resto não faz sentido.

A cena

É sempre quase igual. Um jantar de família, um café com um amigo de um amigo, uma DM no LinkedIn no domingo de noite. O contexto muda, a pessoa muda, mas a frase chega numa versão de:

“Gui, eu sei que IA é importante. Mas eu não entendo nada disso. Por onde eu começo?”

E aí vem o silêncio constrangido, porque a pessoa do outro lado já se ouviu pedindo a mesma coisa pra duas ou três pessoas antes, e nenhuma delas conseguiu responder de um jeito que cabia. A resposta padrão é “ah, faz um curso”, e a próxima frase é sempre uma versão de “fiz, mas larguei no módulo três”.

Eu passei muito tempo respondendo essa pergunta de improviso. Mandando link de vídeo, recomendando um artigo, sugerindo o livro X ou o canal Y. E percebi uma coisa desconfortável: cada vez que eu respondia, eu estava tentando empacotar pra essa pessoa um caminho que eu mesmo nunca tinha desenhado direito. Eu sabia o que tinha funcionado pra mim, mas eu sou engenheiro, tive paciência pra coisas que ninguém tem paciência, e o caminho que serviu pra mim não serve pra um diretor financeiro com três filhos e duas reuniões antes do almoço.

O que existe lá fora não resolve

Toda vez que eu sentava pra recomendar alguma coisa, batia o problema:

Os cursos pagos são caros e longos. Quem tá começando não consegue se convencer de gastar dois mil reais antes de saber se IA é mesmo pra ele. E os de cem horas viram cemitério de aba aberta.

Os cursos gratuitos no YouTube são bons, mas estão soltos. Cada um começa do zero, ninguém te leva da mão. Quem nunca tocou no assunto não sabe o que assistir primeiro nem o que pular.

Os artigos sérios são técnicos demais. Falam de transformer, de embedding, de RAG. Boa parte da pessoa que me pergunta não precisa disso. Ela precisa saber se confia ou não confia, se vai economizar tempo ou não, e onde encaixar no dia de quinta-feira.

E os conteúdos populares são vazios. Hype, hype, hype, “vai mudar tudo”, “10 prompts que vão revolucionar a sua vida”. A pessoa sai sem aprender nada, e ainda fica achando que tem alguma coisa errada com ela por não estar empolgada.

A conclusão, depois de meses ouvindo a mesma pergunta, foi simples: ninguém precisa de mais um curso de doutorado em transformer. Precisa de um caminho. Pequeno, diário, com começo, meio e fim.

O que eu construí

Chama academia-ia. É uma trilha de 30 dias.

Cada dia é uma aula de 10 a 20 minutos. Você abre, lê, assiste, faz um exercício pequeno, fecha. No dia seguinte tem outra. Não tem fila, não tem turma, não tem prazo. Você começa quando quiser, e se atrasar dois dias o programa te espera.

No fim dos 30 dias você não vai ser pesquisador da OpenAI. Mas vai entender:

• o que é IA generativa de verdade, sem a mitologia da imprensa

• como escrever prompts que funcionam, e por que os seus não funcionam hoje

• onde encaixar IA nas coisas que você já faz: email, decisão, análise, pesquisa, criação

• quando confiar e quando duvidar, como detectar alucinação antes que ela te custe credibilidade

• e o que vem depois disso: agentes, automação, fluxos que rodam sozinhos

É pra quem se sente atrás. O gestor que sentiu o chão fugir nos últimos doze meses. O profissional que abre o ChatGPT todo dia mas tem a impressão de tá usando 5% do que dá. O empreendedor querendo entender onde IA encosta no negócio dele de verdade, e não em deck de palestra. O curioso que sempre adiou isso pra “quando tiver tempo”.

Se você é engenheiro de ML procurando matemática de transformer, esse curso não é pra você. Mas é provável que você ouça as mesmas perguntas que eu ouço.

Por que 10 a 20 minutos por dia

Porque eu sei como você é. E sei porque eu sou igual.

Você se inscreve num curso de doze horas com a melhor das intenções. Abre o primeiro módulo num sábado de manhã, faz duas horas, sai pra almoçar achando que voltou a vida acadêmica. No domingo perde o segundo módulo porque a família apareceu. Na segunda começa o terceiro, mas tem uma reunião. E quando você vê, passou um mês, a aba do navegador continua aberta na seção 4, e você já não lembra mais o que tinha no 3.

Dez minutos por dia, por outro lado, cabe. Cabe no café da manhã, cabe entre uma reunião e outra, cabe no Uber. Disciplina pequena entrega resultado grande, e isso eu aprendi não num livro de produtividade mas construindo coisa por aqui, um pequeno commit por vez, durante anos.

Trinta dias também tem uma graça que eu só fui notar depois: é mais ou menos o tempo que um hábito leva pra virar segunda natureza. Se você for honesto com os 30 dias, no Dia 30 IA não vai mais ser “aquela coisa que eu preciso aprender”. Vai ser uma ferramenta que você abre sem pensar, do mesmo jeito que você abre Google ou WhatsApp.

Por que de graça

Essa é a parte que mais incomodou algumas pessoas próximas quando eu contei.

“Mas Gui, você tá deixando dinheiro na mesa.” Talvez esteja. Mas tem três coisas que valem mais do que esse dinheiro.

A primeira é que eu acredito, e acredito do jeito que dói um pouquinho, que IA não pode ser privilégio. A janela pra entrar nessa onda é estreita. Quem ficar de fora agora vai ficar de fora por uma década, e quando voltar a olhar a ponte já vai estar do outro lado. Eu não quero isso pra ninguém que tenha vontade de aprender e que esteja sendo barrado só por preço. Cobrar duzentos reais por isso ia filtrar exatamente as pessoas que mais precisam.

A segunda é que eu queria fazer alguma coisa de aniversário que não fosse só comer bolo. Construir uma coisa e deixar de presente no mundo me pareceu mais bonito do que o post no Instagram com a frase motivacional de “novo ciclo".

A terceira, e essa é a de verdade, é uma frase da minha mãe que eu cresci ouvindo: faça o seu melhor sem esperar nada em troca. Ela tava certa, e levei bastante tempo pra entender. Cobrar virou quase um reflexo no mundo de startup, e às vezes a gente se esquece de que tem coisa que você faz simplesmente porque é a coisa certa de fazer. Esse curso, no momento da minha vida em que eu tô, é uma dessas.

Sem cadastro de cartão. Sem upsell. Sem “premium” escondido atrás de paywall. É o curso inteiro, pra sempre, na unha.

Bora?

A academia tá no ar em academia-ia.mindapps.ai.

Se você é a pessoa que sempre se prometeu “esse mês eu começo a entender IA pra valer”, esse mês é esse mês. Você se inscreve, recebe o Dia 1 no email, e começa amanhã de manhã. Se travar, me responde por aqui mesmo, eu leio. Eu fiz esse curso nos momentos de calmaria nos cuidados com meu pai acamado. Então, se tiver algum bug, só responder esse email que corrijo.

E se você conhece alguém que tá preso nesse limbo de “sei que é importante mas não sei por onde” e provavelmente conhece, todo mundo conhece pelo menos uma pessoa… compartilha esse texto com ela. Esse mês também é dela.

Obrigado por estar por aqui, como sempre.

Abs,

Guilherme

PS: hoje também é meu aniversário. Construir essa coisa e abrir de graça foi o jeito que eu encontrei de marcar a data. Se quiser me dar um presente, manda pra alguém que precisa.

Toda equipe comercial e de inteligência de mercado conhece a mesma rotina. Alguém abre dez abas pela manhã, tenta acompanhar quem está movimentando capital, quais aquisições foram anunciadas, qual concorrente fez uma rodada, qual diretor saiu de uma empresa relevante. No fim do dia, esse alguém produz um resumo. Nas semanas seguintes, o resumo vira PowerPoint, vira lead, vira reunião, vira receita. Ou não vira nada, porque a informação chegou tarde, ou se perdeu no caminho entre planilhas e e-mails.

Eu fui esse alguém durante anos. E acabei construindo uma ferramenta para tirar essa rotina das minhas mãos. Chama-se Market Intelligence Radar (MIR). É um pipeline open source que varre fontes de notícias configuráveis, extrai pessoas, empresas, deals e sinais de mercado usando LLMs, faz match com o CRM, enriquece os contatos via Apollo e SalesQL, e mostra tudo num dashboard. Está disponível no GitHub em github.com/guifav/market-intelligence-radar, com licença MIT, sem telemetria, totalmente self-hosted.

Este post conta a história de como ele foi construído, os desafios reais que apareceram pelo caminho, a bagagem técnica que precisou se acumular para chegar nesse formato, e as oportunidades que vejo para empresas que adotarem uma ferramenta desse tipo.

O que ele faz, em sete passos

A operação inteira é uma cadeia de sete etapas. Tudo começa com a configuração de fontes num arquivo JSON simples (TechCrunch, Reuters, qualquer URL que liste artigos). Em seguida, um scraper visita cada fonte, descobre URLs novas, e tenta extrair conteúdo limpo, primeiro via Firecrawl, com fallback para requests + BeautifulSoup quando a chave de API premium não está presente.

O passo crítico é o terceiro. Para cada artigo, um LLM (Claude, GPT ou Gemini, escolhido via variável de ambiente) recebe o texto e devolve JSON estruturado: pessoas mencionadas com cargo, empresa e contexto; empresas com setor, categoria e envolvimento em transações; deals do tipo M&A, IPO, fundraising, JVs; sinais como mudança regulatória, movimento de mercado, risco; e tópicos. A taxonomia inteira fica num JSON configurável, então o vocabulário se adapta a qualquer setor.

Tudo é persistido em PostgreSQL. Pessoas e empresas são deduplicadas por canonical_id, um hash SHA-256 de nome combinado com empresa, o que permite consolidar menções de múltiplos artigos num único registro de identidade.

Depois disso, dois fluxos paralelos operam sobre cada pessoa identificada. O matcher cruza o registro com o CRM importado via CSV usando quatro níveis de score: email exato, nome completo exato, prefixo do nome, e nome combinado com empresa. O enricher chama Apollo e SalesQL em waterfall para buscar email validado, telefone, LinkedIn, foto, dados da organização. Apenas pessoas relevantes, filtradas por divisão, ICP e regras de exclusão, chegam à etapa de enriquecimento, então o consumo de API se mantém controlado.

No final, um dashboard Next.js mostra tudo de forma navegável, com filtros por divisão, busca em texto livre, fluxo de aprovação manual de prospects, e exportação para CSV.

Arquitetura

A arquitetura tem três fluxos paralelos que convergem no PostgreSQL. O fluxo principal de scan vai das notícias até o banco, passando por scraper e extractor. O fluxo de matching parte do CSV de contatos do CRM, passa pelo matcher, e atualiza pessoas no banco com a flag de match. O fluxo de enrichment chama APIs externas, traz os dados, e atualiza o registro da pessoa.

Algumas decisões merecem comentário.

Separei Python (pipeline) de Next.js (dashboard) através do PostgreSQL. Daria para fazer tudo em Node ou tudo em Python. Optei por separar porque cada parte tem requisitos diferentes. O backend de extração precisa de paralelismo, controle fino de rate limiting, integração natural com bibliotecas de scraping e parsing. O frontend precisa de SSR, componentes reativos, ergonomia para tabelas com filtros complexos. Cada lado faz o que faz melhor, conversa pelo banco, e não precisa ter comunicação direta. O efeito colateral positivo: dá pra rodar o pipeline numa VM barata e o dashboard em outra, e ambos escalam de forma independente.

Usei canonical_id baseado em hash determinístico em vez de UUID. Quando o LLM extrai a mesma pessoa de dois artigos diferentes, o canonical_id é idêntico, e a operação de upsert no banco consolida automaticamente. Elimina uma camada inteira de “tabela de identidades” que muita gente reinventa.

Tornei o LLM provider plugável. O arquivo mir/llm.py esconde Anthropic, OpenAI e Google atrás de uma única função extract(prompt, content). Trocar de provider é mudar uma variável de ambiente. Para um projeto que vai viver no domínio público, isso reduz fricção de adoção (o desenvolvedor usa o que já tem) e aumenta resiliência (se um provider tem outage, o outro assume).

E tornei o enrichment opcional. Apollo e SalesQL são pagas. O sistema funciona sem elas, e o status de cada pessoa reflete isso. O estado “not_found_in_enrichment” é um nó válido no funil. O usuário adota gradualmente, conforme budget e maturidade do uso permitem.

Os desafios reais de construir isso

Construir um sistema desse tipo passa por problemas que nenhum tutorial cobre.

O primeiro é a qualidade do prompt de extração. LLMs são geniais para sumarização, mas instáveis para extração estruturada com taxonomia rígida. A primeira versão do meu prompt produzia JSON inconsistente, com nomes de setores inventados, capitalizações diferentes em respostas distintas, ocasionais campos faltando. A solução foi forçar a taxonomia dentro do próprio prompt, listando as categorias válidas e instruindo o modelo a usar apenas aquelas. Mesmo assim, era preciso pós-processar a saída para normalizar variações. Hoje o prompt tem cerca de 150 linhas e foi iterado dezenas de vezes contra um conjunto de artigos teste para chegar numa extração confiável.

O segundo desafio foi deduplicação. Quando o LLM lê um artigo sobre “Pedro Silva, CEO da TechCorp” e outro sobre “Pedro Henrique Silva, CEO da Tech Corp Brasil”, são a mesma pessoa? Construí três níveis. O canonical_id pega os casos óbvios. Um normalizador de strings (lowercase, trim, remoção de acentos) pega variações de capitalização. Para os casos limítrofes, o sistema preserva o registro com o canonical_id original e adiciona variação no array de menções, deixando o usuário humano decidir se são a mesma pessoa.

O terceiro foi a gestão de rate limit. Apollo permite cerca de 60 requests por minuto, SalesQL é mais conservador, e o LLM tem seu próprio teto. O scanner roda com workers paralelos, e cada worker pode bater no Apollo. Construí um ThreadSafeIntervalLimiter que serializa as chamadas globalmente, garantindo que mesmo com dez threads, o ritmo total respeita o teto da API. Em duas linhas no console, tudo se mantém dentro do orçamento.

O quarto foi o que chamo de ruído de relevância. A maioria das pessoas mencionadas em artigos não interessa para vendas: jornalistas, acadêmicos, políticos, atletas citados em comparação. Sem filtro, o pipeline gerava centenas de registros irrelevantes por dia. A solução foi construir três camadas de exclusão: regras hardcoded de profissão (jornalista, repórter, professor, governador), regras configuráveis por divisão (cada vertical define seu ICP), e regras de hard exclusion gerenciadas pelo usuário (pessoa específica, padrão de empresa). O resultado é cerca de dez vezes menos registros, com qualidade muito superior.

O quinto desafio foi o ICP scoring. Quando o sistema identifica uma pessoa, ele precisa decidir se ela é relevante para o negócio. Construí um sistema multidimensional que avalia categoria de operação, setor, país e cargo separadamente, e produz um percentual de match (0 a 100%). O cálculo é dimensions_matched dividido por dimensions_defined. Cada divisão pode ter o seu ICP. Esse score guia o usuário, que vê primeiro os matches acima de 90%, e descarta o resto.

A bagagem necessária

Olhando para trás, percebo que esse projeto sintetiza experiências acumuladas ao longo de anos. Para construir algo parecido, alguém precisa estar confortável em pelo menos quatro frentes técnicas, mais uma quinta camada de domínio.

Engenharia backend pragmática. Saber escrever Python que processa volume razoável de dados, lidar com concorrência (threading.Lock, ThreadPoolExecutor), entender quando paralelizar e quando serializar, escrever queries SQL eficientes para PostgreSQL, projetar schemas que sobrevivem a mudanças. Mão calejada com sistemas que rodam todos os dias importa mais do que título de engenheiro de Big Data.

Entendimento de LLMs em ambiente de produção. Isso vai além de saber chamar a API. Inclui escrever prompts robustos, lidar com a aleatoriedade dos modelos, projetar saídas verificáveis (JSON bem formado), conhecer os limites de cada provider, entender custos por token, gerenciar latência. Quem nunca colocou um LLM em produção vai gastar tempo aprendendo o que não funciona.

Design de pipelines de dados. Decidir o que é processo síncrono inline (matching numa pessoa que acabou de chegar) e o que vira batch (enrichment em lote, todo final do dia). Identificar pontos de falha, projetar idempotência, tratar duplicatas, gerenciar estado intermediário. Quem trabalhou com ETL ou com integração de sistemas vai reconhecer os padrões de pronto.

Frontend moderno. Next.js 15 com App Router, React 19, Tailwind 4, shadcn/ui. Construir o dashboard com componentes reutilizáveis, gerenciar estado entre páginas com Context, lidar com SSR e RSC apropriadamente, escrever queries que respeitam autenticação. Nada exótico, mas exige fluência.

A quinta camada, mais sutil, é entender o domínio. Construí o MIR primeiro para um setor específico, e só depois generalizei. Saber o que é um decision-maker, o que conta como deal, como uma equipe comercial efetivamente trabalha com leads, o que torna um sinal acionável. Sem essa camada, o sistema seria tecnicamente correto e operacionalmente inútil.

O que empresas podem fazer com isso

Existem três caminhos óbvios para uma empresa adotar uma ferramenta desse tipo.

→ O primeiro é monitoramento de mercado para times comerciais. Alguém da inteligência comercial configura o MIR com 30 fontes relevantes para o setor, importa os contatos do CRM, e em uma semana tem visibilidade completa sobre quem está se movimentando, quem fez fundraising, quais empresas estão entrando em novo mercado, quais executivos mudaram de cargo. O time de SDR usa essa lista priorizada para ações de outbound, com timing relevante e contexto rico. O time de account management consegue antecipar mudanças nos clientes (M&A, troca de C-level) e agir antes do concorrente.

→ O segundo é geração de conteúdo. Editores de newsletters, podcasters, jornalistas econômicos passam horas por dia coletando notícias, identificando temas, mapeando narrativas. Uma instalação do MIR rodando diariamente entrega um corpus pré-extraído de pessoas, deals e sinais, organizados por taxonomia configurável. O editor passa direto para a parte criativa, com base de dados estruturada como insumo.

→ O terceiro é inteligência competitiva. Conselhos de empresas, áreas de M&A, equipes de estratégia precisam estar atualizados sobre movimentos de concorrentes e adjacências. Configurar o MIR para monitorar fontes do setor, com filtros por concorrente específico ou tipo de transação, gera relatórios diários ou semanais sem trabalho humano repetitivo. O analista entra na conversa para interpretar, hipotetizar, propor ação.

Para empresas que querem ir além de adotar, vejo dois caminhos de extensão. Empresas que vendem dados podem usar o MIR como base para um produto SaaS multi-tenant, agregando insights de múltiplos clientes. A licença MIT permite uso comercial sem restrição. E empresas que constroem produtos verticais (real estate, healthcare, energia) podem fazer fork do MIR, customizar a taxonomia, plugar fontes específicas do setor, e oferecer uma versão whitelabel para seus clientes. O tempo até o primeiro release cai de meses para semanas.

Por que open source

Eu poderia ter mantido o código fechado e tentado vender. Optei por publicar com licença MIT por três razões.

Projetos como esse só ficam bons com uso real e diverso. Quanto mais gente experimentar, ajustar para o próprio contexto, abrir issues e PRs, mais maduro o sistema fica. Em código fechado, o ritmo de evolução é o ritmo de um time. Em código aberto, é o ritmo da comunidade.

E tudo que eu uso para construir profissionalmente é open source. PostgreSQL, Next.js, Tailwind, Linux, dezenas de bibliotecas Python. Devolver algo é justo.

Como começar

O repositório está em github.com/guifav/market-intelligence-radar. Setup local roda em um comando: docker compose up -d. O readme tem documentação completa de configuração. O modelo padrão de LLM é Claude, e pode ser trocado para OpenAI ou Google a qualquer momento.

Se quiser conversar sobre arquitetura, customização para um setor específico, ou só dar feedback, abra uma issue no GitHub ou me ache no X ou LinkedIn. PRs são bem-vindos.

Quero explicar isso de um jeito que serve tanto para o CEO que tem duzentos engenheiros em folha quanto para o fundador que contratou dois devs e uma assinatura de Claude Code. A confusão no ar é parecida nos dois casos: produtividade prometida que não chega, sênior reclamando de sobrecarga, júnior entregando rápido demais para o conforto de quem revisa, e uma sensação geral de que o time virou uma caixa preta que engole IA de um lado e cospe código do outro, sem que ninguém, inclusive o CTO, consiga dizer com precisão o que está acontecendo lá dentro.

Vou ser direto: essa confusão tem nome, tem causa e tem um caminho de saída. Entender tudo isso virou diligência básica de qualquer liderança que tenha software dentro do negócio, e não mais um luxo reservado a executivo de tecnologia.

O gargalo migrou para a especificação

Durante vinte anos, a engenharia de software funcionou assim: você contrata pessoas para escrever código, mede a entrega por linhas commitadas, features enviadas, story points fechados. O code review é o portão de qualidade. Se passou na revisão, vai para produção. O ofício era o código em si.

Com agentes de IA, essa lógica inteira quebra. O código começa a chegar mais rápido do que o time consegue processar. Em um cenário real de um time de vinte engenheiros rodando Claude Code e Cursor por seis meses, um sênior chegou frustrado com o pull request de um júnior. Milhares de linhas. Funcionava. Passava nos testes. Ele disse, sem meio-termo: “eu não li o código. Não tinha como. Era código demais. Qual é o meu trabalho agora?”

Essa é a pergunta do momento:

A resposta é incômoda para quem construiu carreira escrevendo código. O gargalo migrou para a especificação. A engenharia rigorosa que antes a gente aplicava depois que o código era escrito, como revisão, teste e cobertura, agora precisa acontecer antes que qualquer linha exista.

Um caso que se tornou emblemático: um dev pede para um agente construir um sistema de notificações. Requisito simples. O agente constrói. Funciona lindo em ambiente de teste. Vai para produção e dispara cinquenta mil e-mails em três minutos. Por quê? Porque ninguém tinha especificado um limite de taxa. O agente não sabia que isso era óbvio. Para ele, não era.

A especificação está virando o produto; código, descartável. Essa é a inversão mais completa de como o software foi construído nos últimos cinquenta anos.

A camada que ainda não tem nome

Entre a especificação e o código que vai para produção, existe agora uma camada de trabalho inteira que nenhum organograma sabe descrever. Alguém precisa quebrar o problema em pedaços do tamanho certo para o agente resolver. Alguém precisa saber quando deixar o agente correr e quando segurar a rédea. Alguém precisa corrigir a saída não reescrevendo o código, e sim ajustando o prompt, o contexto ou a restrição.

Vejo isso sendo chamado de trabalho supervisório… De arquitetura executável... De curadoria de agentes... Nenhum termo pegou ainda, e isso é um sintoma de que a disciplina está nascendo em tempo real dentro das empresas que usam IA para valer.

Esse trabalho supervisório é onde mora o novo valor. A habilidade crítica mudou da velocidade de digitação para a capacidade de carregar um modelo mental do sistema inteiro, antecipar onde a IA vai errar, definir fronteiras claras e avaliar saídas não-determinísticas sem ingenuidade.

A fratura invisível: seniores afogados, juniores decolando, mid-levels na zona de perigo

Em qualquer time real que adotou IA de forma séria nos últimos meses, ocorre a mesma fratura. O time se divide em três grupos, e os três estão vivendo realidades completamente diferentes.

Os seniores estão afogados. Eles entendem o sistema inteiro, conhecem a dívida técnica, carregam o contexto histórico. Isso era superpoder. Agora vira condenação. Porque juniores e agentes geram código dez vezes mais rápido, e código não vai para produção sozinho. Precisa de revisão arquitetural, precisa encaixar em legado, precisa ser desbloqueado. O sênior vira controlador de tráfego aéreo. Passa o dia revisando saída de IA e já não produz quase nada de fato. A pessoa que antes era a mais produtiva do time passa a ser a menos produtiva em termos de linhas, e a mais crítica em termos de decisão. Ninguém sabe como medir isso e o burnout passa a ser real.

Os juniores estão decolando. Contraintuitivo? Sim. Mas faz sentido. O júnior não tem a memória muscular que manda escrever código de um jeito específico. Ele trata a IA como colega de equipe e não como ameaça à própria identidade. A fase deficitária do onboarding, aqueles seis meses em que o júnior drena produtividade do time enquanto aprende o código, praticamente desapareceu. Um júnior bem acoplado a um Claude Code entrega código útil na primeira semana.

Os mid-levels estão na zona de perigo. Três a cinco anos de experiência. Habilidade suficiente para ter vícios, insuficiente para ser arquiteto de verdade. Re-treinar um mid-level, tirando-o da lógica de escrever sintaxe e colocando-o na lógica de supervisionar agentes, é o desafio organizacional mais duro que líderes de tech estão encontrando em 2026. O problema costuma aparecer em conversas de corredor e em reuniões fechadas de liderança, mas raramente desce para o plano de carreira, para a política de compensação ou para a estrutura de contratação que a empresa pratica de fato.

Para o CEO, a implicação é estratégica. Se você só enxerga o time como um bloco, você vai tratar seniores e mid-levels com a mesma remuneração, as mesmas metas, o mesmo plano de carreira. E vai perder os seniores para o burnout e os mid-levels para a obsolescência, não necessariamente "ganhando” bons juniores.

O problema do conhecimento "tribal"

Aqui mora uma armadilha específica, do tipo que só aparece depois que a empresa já apostou pesado em IA. O agente não tem contexto organizacional, mesmo você criando infinitas skills, plugins e MCPs. Não sabe que o job de marketing roda toda terça à meia-noite e satura o pool de conexões do banco. Não sabe que aquele microserviço mal-documentado foi escrito com pressa antes das férias de Natal e nunca mais foi tocado. Não sabe que o cliente X tem um contrato especial que impede um determinado comportamento do sistema.

Isso é conhecimento tribal. Vive na cabeça dos seniores. E quando um agente de IA é chamado para resolver um incidente às duas da manhã, ele lê a documentação oficial, segue o manual e reinicia o servidor. Repetidas vezes. Enquanto o time humano precisa ser chamado do mesmo jeito para descobrir que o problema era um job batch e não um serviço travado.

A consequência é direta. Toda aquela promessa de “sistemas auto-cicatrizantes” (self-healing) movidos por IA continua sendo conversa de marketing enquanto a sua empresa não construir um subconsciente de agente. Um grafo de conhecimento que codifique cada incidente, cada caso de borda esquisito, cada pedaço de conhecimento institucional que mora só na cabeça da sua equipe mais experiente.

Construir isso parece investimento não urgente até o dia em que se torna(rá) o único investimento que importa.

Agentes obedientes demais

Há outro ponto pouco discutido. Agentes de IA são treinados para serem prestativos. São puxa-sacos por construção. Querem te manter engajado na conversa, são propositivos mesmo quando não são necessários. Durante um incidente, o último que você quer no comando é um puxa-saco. Você quer alguém que desafie a hipótese, que force o humano a olhar para o que ele não quer olhar.

A resposta emergente dentro de times que já sofreram com isso é o que está sendo chamado de “agente bravo” (angry agent): um agente configurado especificamente para furar a teoria em curso, apontar contradições, exigir evidência. Trata-se de higiene de operação, ainda que muita gente trate como luxo dispensável. Porque dois agentes concordando entre si, o humano cansado e a IA obediente, é a receita perfeita para um servidor queimando enquanto todo mundo bate cabeça.

Contratação: você está comprando a habilidade errada

Se você está contratando desenvolvedor agora com a descrição de vaga que usava há dois anos, você está comprando a habilidade errada. Velocidade para teclar código virou commodity, e deixou de funcionar como diferencial real.

O perfil que você precisa ter no time é outro. Pensamento arquitetural. Julgamento sob incerteza. Capacidade de escrever uma especificação tão precisa que a IA não consiga interpretar errado. Capacidade de desenhar um conjunto de testes que capture alucinações antes de elas irem para produção. Capacidade de debugar um sistema que a pessoa não escreveu pessoalmente.

Isso é uma pessoa completamente diferente da que você contratava em 2023-4. E o pior: muita gente no mercado ainda se vende pela habilidade antiga. Seu processo seletivo precisa mudar. Se o teste técnico é “escreva um algoritmo de busca binária em trinta minutos”, você está medindo exatamente a habilidade que a IA substituiu.

Um teste mais útil em 2026 que tenho aplicado nos processos de recrutamento é: aqui está uma especificação [vaga], um sistema legado indo a meia-boca e um agente de IA à sua disposição. O que você faz?

Dívida cognitiva e compreensão contínua

Por décadas, o code review serviu para caçar bug e também, de quebra, para ensinar o sistema aos desenvolvedores. Se os agentes passam a escrever todo o código e o time para de ler, o time vira estrangeiro dentro do próprio produto.

Quando alguma coisa quebra às três da manhã, o seu engenheiro está encarando código escrito por uma máquina, tentando fazer engenharia reversa da lógica enquanto o cliente grita do outro lado.

Isso é dívida cognitiva. Ela se acumula silenciosamente, sem aparecer em nenhum dashboard, até o dia em que o time inteiro não consegue mais tomar uma decisão arquitetural porque ninguém mais entende de fato o que o software faz.

A contramedida é agendar compreensão. Rituais semanais de arquitetura conjunta, mesmo que o código venha dos agentes. Ferramentas que resumem mudanças arquiteturais para humanos. Sessões deliberadas de leitura de código, como se fossem sessões de leitura coletiva. Soa analógico em um mundo que vende autonomia total. É justamente por isso que funciona.

O que fazer como CEO

Três movimentos concretos para as próximas semanas.

Primeiro, audite seu time pela lente de senior-afogado, júnior-decolando, mid-level-em-risco. Trata-se de diagnóstico estratégico, e quem trata isso como exercício burocrático de RH perde os melhores primeiro. O plano de carreira, a compensação e o treinamento precisam ser diferentes para cada grupo. Tratar todo mundo igual é garantir perda de talento nos próximos doze meses. O princípio da equidade vale aqui também.

Segundo, comece a construir o subconsciente da sua empresa. Todo incidente vira aprendizado documentado de forma que um agente consiga consumir. Toda regra implícita vira regra explícita. Toda decisão arquitetural ganha um why registrado. Isso parece infraestrutura chata até o dia em que é o diferencial competitivo. Para este subconsciente ter impacto relevante, você precisará de volume relativamente grande de registros. E quanto mais volume tiver, mais registros conseguirá criar antecipadamente, mitigando problemas futuros.

Terceiro, mude o filtro de contratação. Pare de comprar velocidade de digitação. Comece a comprar julgamento, clareza de especificação e tolerância à ambiguidade. O teste técnico precisa refletir o trabalho real de 2026, não o trabalho real de 2018.

A analogia final que eu gosto é a da placa gráfica. Em 1992, engenheiros calculavam à mão a matemática para desenhar um único polígono na tela. Em 1994, as GPUs chegaram e assumiram essa tarefa. Quem insistiu em codar polígono à mão em 1995 não virou especialista. Virou obsoleto. Os que sobreviveram viraram engenheiros de iluminação, animadores, programadores de física. Pararam de ensinar o computador a desenhar um triângulo e começaram a ensinar o computador a simular como a luz reflete em uma rua molhada.

A engenharia de software está vivendo exatamente esse momento. Ninguém mais vai codar polígono à mão em 2028. A pergunta é se o seu time vai estar entre os que escalaram para a nova camada ou entre os que insistiram na antiga até ficarem obsoletos.

Os melhores fundadores e CEOs que eu conheço não estão em pânico com isso. Estão adaptando. Silenciosamente, metodicamente, reescrevendo cargos, planos de carreira e processos. Seja um deles.

Candy Crush Saga é um dos jogos mobile mais bem-sucedidos da história. Lançado em 2012 pela King, hoje parte da Activision Blizzard, acumula bilhões de downloads e continua entre os aplicativos mais lucrativos em Android e iOS. Para a maioria das pessoas, é um passatempo simples. Você combina doces da mesma cor, eles explodem, você avança de nível.

Recentemente voltei a pensar sobre o jogo por um motivo específico. Um detalhe me chamou a atenção: como a King consegue manter uma progressão de dificuldade consistente através de mais de 15 mil níveis, lançando cerca de 15 novos por semana, sem que a experiência se degrade. A resposta envolve machine learning aplicado de forma bastante sofisticada, e as lições são diretamente transferíveis para qualquer organização que use IA para otimizar produto.

O problema, ao contrário do que parece, atraiu atenção acadêmica significativa. Há pelo menos três teses de mestrado no KTH Royal Institute of Technology, um paper oficial dos engenheiros da King, um projeto de Stanford no curso CS230 de deep learning, uma prova matemática de NP-dificuldade no arXiv, e trabalhos recentes da Universidade Roma Tre aplicando Deep Reinforcement Learning à classe de jogos match-3. Cada abordagem resolve o problema de uma forma diferente, e as diferenças revelam decisões de design que vão muito além de Candy Crush.

Este artigo tem três objetivos. Primeiro, documentar com algum rigor técnico o que a King construiu, porque a história é genuinamente interessante e pouco conhecida fora de círculos especializados. Segundo, comparar as três abordagens principais que foram publicadas: MCTS, supervised learning com CNN, e Deep Q-Network. Terceiro, extrair princípios aplicáveis a projetos de IA em contextos empresariais que não têm nada a ver com jogos.

O problema real que a King enfrentava

A economia do Candy Crush depende de progressão constante. Se os níveis param de sair, os jogadores engajados terminam o conteúdo disponível e saem. Se saem em ritmo errado ou com dificuldade mal calibrada, a curva de retenção se deteriora. Com dezenas de milhões de jogadores ativos, o custo de um erro de calibração é grande.

O problema técnico específico é o seguinte. Cada novo nível precisa ter uma taxa de sucesso humano médio (AHSR, na terminologia interna da King, Average Human Success Rate) dentro de uma faixa calibrada para manter a experiência de flow. Uma taxa muito alta indica que o nível é fácil demais e o jogador se entedia. Uma taxa muito baixa indica que é difícil demais e o jogador desiste. A faixa-alvo varia conforme a posição do nível na jornada, com picos deliberados de dificuldade em posições específicas para criar momentos de desafio.

Até meados da década passada, a calibração era feita por testers humanos. Jogadores profissionais jogavam o mesmo nível cerca de 20 vezes, registravam resultados e escreviam relatórios. O processo levava aproximadamente uma semana por nível. Para um ritmo de 15 níveis novos por semana, isso exigia uma equipe grande, introduzia um gargalo estrutural no pipeline de produção, e limitava quantas iterações de design cada nível poderia receber antes de ser lançado.

A complexidade matemática escondida

Antes de entrar nas abordagens de machine learning, vale estabelecer que o problema é genuinamente difícil do ponto de vista teórico.

Em 2014, Toby Walsh publicou no arXiv um paper curto e preciso chamado “Candy Crush is NP-hard”. A prova usa uma redução a partir do 3-SAT, o problema canônico NP-completo, mostrando que encontrar a sequência ótima de movimentos em um nível arbitrário de Candy Crush é pelo menos tão difícil quanto satisfazer uma fórmula booleana em forma normal conjuntiva. Sob as conjecturas padrão em complexidade computacional (especificamente P ≠ NP), isso significa que não existe algoritmo de tempo polinomial para resolver otimamente o jogo, e é improvável que tal algoritmo venha a ser descoberto.

Esse resultado teórico tem uma implicação prática importante. Como força bruta é inviável, qualquer sistema que queira jogar Candy Crush em escala precisa usar heurísticas, amostragem estatística, ou aprendizado a partir de dados. Não há atalho analítico.

A tese de Erik Poromaa (KTH, 2017) reporta uma estimativa empírica que reforça essa intuição. Para o nível 13 do jogo, o espaço de estados (o conjunto de todas as configurações possíveis do tabuleiro considerando o fluxo de doces caindo) foi estimado em aproximadamente 10 elevado a 182. Para comparação, o universo observável contém na ordem de 10 elevado a 80 átomos, e existem aproximadamente 10 elevado a 50 configurações legais em um tabuleiro de xadrez. Um único nível de Candy Crush tem um espaço de estados muitas ordens de magnitude maior que o jogo completo de xadrez.

Esse número também explica por que o jogo tem uma propriedade interessante: mesmo que você jogue o mesmo nível milhares de vezes, é estatisticamente improvável que as mesmas configurações se repitam. A “previsibilidade do imprevisível” que jogadores percebem vem exatamente dessa vastidão.

Abordagem 1: Monte Carlo Tree Search

A primeira tentativa séria de automatizar a estimativa de dificuldade veio na tese de mestrado de Erik Poromaa em 2016, publicada em 2017, com o título “Crushing Candy Crush: Predicting Human Success Rate in a Mobile Game using Monte-Carlo Tree Search”.

Monte Carlo Tree Search é a família de algoritmos que também está por trás de sistemas como o AlphaGo. A intuição é a seguinte: a partir do estado atual, simule milhares de jogos completos escolhendo ações por algum critério (no caso mais simples, aleatoriamente), registre quais jogos terminam em sucesso, e use essa estatística para decidir qual ação tomar no estado real.

A aplicação a Candy Crush enfrenta dois problemas principais. O primeiro é o branching factor alto. Em um tabuleiro 9x9 com seis cores de doces, há dezenas de movimentos legais em cada posição, e o jogo tem 40 ou mais movimentos por nível. A árvore de busca cresce muito rápido. O segundo é a aleatoriedade intrínseca do jogo: quando você elimina doces, novos doces caem em posições aleatórias, o que significa que duas simulações a partir do mesmo estado podem seguir trajetórias completamente diferentes. Isso exige muitas simulações por estado para ter estimativas estáveis.

Poromaa reportou resultados razoáveis superando métodos anteriores de teste manual, mas com limitações claras em custo computacional. A abordagem funciona, mas não escala para o ritmo de produção da King sem hardware significativo.

Abordagem 2: Supervised Learning com CNN (a solução em produção da King)

A abordagem que eventualmente foi para produção está documentada no paper “Human-Like Playtesting with Deep Learning”, de autoria de Stefan Gudmundsson, Philipp Eisen, Erik Poromaa, Alex Nodet, Sami Purmonen, Bartlomiej Kozakowski, Richard Meurling e Lele Cao, todos engenheiros da King, publicado em 2018 na IEEE Conference on Computational Intelligence and Games.

A arquitetura combina três elementos.

Representação do estado. O tabuleiro é codificado como um tensor binário com aproximadamente 102 feature planes. Cada plano é uma matriz binária do tamanho do tabuleiro onde cada célula indica a presença ou ausência de um atributo específico: cada cor de doce tem seu plano, cada tipo de doce especial tem seu plano (strip bombs horizontais, strip bombs verticais, wrapped bombs, color bombs), obstáculos como geleias e chocolates têm planos próprios, e o objetivo corrente do nível é codificado em planos adicionais. Essa representação é essencialmente equivalente ao input de uma rede neural convolucional aplicada a uma imagem, com a diferença de que os canais são semânticos em vez de RGB.

Dataset de decisões humanas. A King coletou aproximadamente 12 milhões de pares estado-ação (1.2 × 10 elevado a 7) de jogadores reais em Candy Crush Saga e Candy Crush Soda Saga. Cada par registra a configuração do tabuleiro em um determinado momento e a ação que o jogador humano tomou em seguida. Isso é o equivalente, em escala, a um dataset de visão computacional como o ImageNet, mas com configurações de jogo e decisões em vez de imagens e rótulos.

Rede neural convolucional. Uma CNN é treinada por aprendizado supervisionado para prever, dada uma configuração do tabuleiro, a distribuição de probabilidade sobre as ações que um humano típico tomaria. O output não é uma única ação determinística, é uma distribuição. Em inferência, o agente amostra dessa distribuição, o que preserva a variabilidade de comportamento humano.

O pipeline de simulação então usa esse agente como substituto de testers humanos. O agente joga cada novo nível centenas ou milhares de vezes, e a taxa de sucesso observada serve como estimativa da AHSR esperada quando o nível for lançado para jogadores reais.

O paper reporta que a abordagem CNN apresenta menor erro absoluto médio (MAE) que MCTS, maior correlação com dificuldade real observada em produção, e opera em uma fração do tempo computacional. O ganho operacional é que o playtesting que levava sete dias passou a ser feito em menos de um minuto por nível.

Há uma sutileza técnica importante aqui. A rede não está aprendendo a jogar otimamente, está aprendendo a reproduzir a distribuição empírica de comportamento humano. Isso é fundamental e vou voltar ao ponto.

Abordagem 3: Deep Q-Network (a perspectiva acadêmica)

Uma perspectiva alternativa interessante aparece no projeto de Bowen Deng no curso CS230 de Deep Learning em Stanford, no inverno de 2020, intitulado “Learn to play Candy Crush”. Esse trabalho adota uma abordagem de reinforcement learning com Deep Q-Network (DQN), e é instrutivo exatamente porque as decisões de design são diferentes.

Deng trabalha com um setup simplificado: tabuleiro 10x10 sem obstáculos, 40 movimentos por jogo. O estado é representado como uma matriz de dimensão (C + S) × N × N, onde C é o número de cores de doces, S é o número de doces especiais, e N é o tamanho do tabuleiro. A representação é conceitualmente similar à da King, embora com menos feature planes por ter escopo reduzido.

O espaço de ações é de 2 × N × (N − 1) ações possíveis por posição: o agente pode escolher uma célula que não esteja na coluna mais à direita e trocar com a vizinha à direita, ou escolher uma célula que não esteja na linha inferior e trocar com a vizinha abaixo. Em um tabuleiro 10x10, isso resulta em 180 ações possíveis, o que já é um espaço de ação razoavelmente grande para reinforcement learning.

A arquitetura final, depois de várias iterações, consiste em cinco camadas convolucionais (com 16, 32, 32, 32 e 32 canais), ativações ReLU entre elas, e uma camada totalmente conectada no final produzindo Q-values para cada ação. O treinamento foi feito em AWS com 2.000 episódios, usando epsilon-greedy para balancear exploração e exploração.

Deng testou duas variantes que diferem na função de recompensa: DQN com recompensa instantânea (a pontuação obtida imediatamente após a jogada) e DQN com recompensa Monte Carlo (uma estimativa da pontuação esperada, computada como média sobre futuras configurações aleatórias).

A observação técnica mais interessante do paper é que a variante Monte Carlo na verdade não faz sentido matemático no contexto de Q-learning. Q-learning assume a equação de Bellman, que pressupõe que a recompensa é causada pela ação específica tomada no estado específico, levando a um novo estado específico. A recompensa Monte Carlo é uma estimativa aleatória dessa recompensa instantânea, o que introduz um viés estatístico no aprendizado da função de valor. Essa observação é um bom exemplo do tipo de erro sutil que aparece quando alguém aplica algoritmos conhecidos sem validar as suposições teóricas que eles exigem.

Os resultados finais de Deng são comparáveis e, em alguns aspectos, superam MCTS no ambiente simplificado. Random pick produziu 157 pontos médios em 40 movimentos, MCTS produziu 325 pontos, e DQN com recompensa instantânea produziu 370 pontos. Em testes contra um jogador humano, o DQN ficou “um pouco pior” nas palavras do autor, mas bastante próximo. O código está disponível publicamente em github.com/baolidakai/candy_crush_ai.

Há uma distinção filosófica importante entre os trabalhos de Deng e os da King. Deng treinou um agente para maximizar pontuação, seguindo o paradigma clássico de reinforcement learning. A King treinou um agente para imitar comportamento humano, usando aprendizado supervisionado. Os dois agentes resolvem o jogo, mas servem a propósitos completamente diferentes.

A sutileza do “human-like” versus “optimal”

Esse contraste é o ponto mais interessante do design da King, e o que mais acho que vale extrair como lição de engenharia.

A intuição natural de alguém começando em machine learning aplicado a jogos é treinar um agente para jogar o melhor possível. Faz sentido para um jogo como xadrez ou Go, onde o objetivo é ganhar. Mas para estimar dificuldade humana, um agente ótimo é inútil. Um bot que sempre encontra a melhor jogada acharia qualquer nível trivial, porque com jogadas ótimas quase todos os níveis são solucionáveis dentro do orçamento de movimentos disponível. A dificuldade percebida por humanos não vem da dificuldade intrínseca do nível em sentido ótimo, vem da distância entre o comportamento humano típico e o comportamento ótimo naquele nível específico.

O que a King queria era um agente cuja distribuição de resultados espelhasse a distribuição de resultados humanos. Isso significa um agente que cometa o tipo certo de erro, nas proporções certas. O aprendizado supervisionado em cima de decisões humanas reais captura exatamente isso. A rede neural não está aprendendo estratégia ótima, está aprendendo a distribuição empírica de comportamento humano.

Um trabalho relacionado que vale mencionar é “Winning Isn’t Everything: Training Human-Like Agents for Playtesting”, publicado por pesquisadores da Electronic Arts. O título do paper é essencialmente uma declaração de design: em playtesting automatizado, o objetivo não pode ser vencer, precisa ser reproduzir a experiência de quem vai jogar.

A Universidade Roma Tre também publicou em 2020 um sistema chamado JellyGym, aplicando deep reinforcement learning à classe geral de jogos match-3. A arquitetura usa uma rede com camada oculta de 100 neurônios totalmente conectada, seguida por outra de 200 neurônios, e uma camada de saída com 324 neurônios, um para cada swap possível (incluindo swaps proibidos). O treinamento foi feito em GPU Tesla V100. Os autores compararam quatro jogadores: Random Player (ações com probabilidade fixa), JellyGym (melhor ação segundo o modelo), Smart Player (melhor tipo de Jolly) e Real Users. A comparação explícita com usuários reais, novamente, reforça o ponto de que o benchmark relevante é comportamento humano.

Esse framing é transferível para outros contextos. Em qualquer problema de simulação ou estimativa baseada em comportamento, a pergunta inicial precisa ser: estou tentando modelar o ótimo ou o real. São objetivos diferentes, exigem datasets diferentes, funções de perda diferentes, e produzem modelos com propriedades completamente distintas.

BAIT e a camada de QA visual

Além do sistema de estimativa de dificuldade, a King construiu uma ferramenta complementar chamada BAIT (Bot for AI Testing), documentada em um artigo do InfoQ por Alexander Andelkovic em 2019.

O BAIT já percorreu mais de 4.500 níveis automaticamente, detectando problemas que são tediosos para QA humano: texturas ausentes, strings de texto faltando (onde o ID da string aparece no lugar do texto traduzido), elementos gráficos sobrepostos, e artefatos de renderização em diferentes resoluções e orientações de celular. Para a detecção visual automatizada, usa uma combinação de algoritmos de similaridade de contorno e a Google Vision API.

Essa parte da história é um lembrete de que em operações reais de IA, o modelo central é frequentemente uma peça entre várias.

A estimativa de dificuldade resolve uma categoria de problema. O QA visual automatizado resolve outra. Juntos, eles liberam ciclos humanos para trabalho criativo que realmente exige julgamento humano.

Três lições para projetos de IA em empresas

Saindo do contexto específico de Candy Crush, há três princípios que aparecem no caso da King e que aplico mentalmente quando olho para projetos de IA em organizações.

Lição 1: Definição operacional do objetivo

O maior erro recorrente em projetos de IA aplicada é começar com um objetivo vago. “Melhorar experiência do cliente”, “otimizar processo comercial”, “acelerar decisão”. Esses objetivos não são treináveis. Um modelo precisa de uma função de perda, e uma função de perda precisa de uma métrica operacional clara.

A King não treinou um modelo para “melhorar dificuldade dos níveis”. Treinou um modelo para prever AHSR com erro absoluto médio abaixo de um limiar específico. A tradução de um objetivo de negócio para uma métrica operacional é onde a maior parte do valor de um projeto de IA é criada ou destruída. E essa tradução quase sempre exige discussões repetidas entre o time de produto e o time técnico, porque as primeiras versões costumam estar erradas.

O contraste entre King (supervised learning) e Deng (reinforcement learning) ilustra bem o ponto. Os dois começaram do mesmo jogo, mas tinham objetivos operacionais diferentes. Deng queria maximizar score, King queria prever comportamento humano. Os modelos resultantes são incomparáveis não porque uma abordagem é melhor, mas porque resolvem problemas diferentes.

Lição 2: O problema real está nos dados, não no modelo

Philipp Eisen, engenheiro de machine learning na King, fez uma observação que sintetiza bem a realidade: a maior parte do tempo em um projeto de ML não é gasto ajustando modelos, é gasto colocando dados no formato certo, limpando, rotulando, transformando. Alex Nodet, também da King, em entrevista ao Computer Weekly em 2019, fez uma observação complementar: “Ter um modelo de ML treinado e aprendendo é apenas metade do trabalho.” A outra metade é colocá-lo em produção de forma confiável, monitorada, com dados chegando no formato esperado.

Essa afirmação é repetida à exaustão em conferências de data science, e ainda assim é sistematicamente subestimada em orçamentos de projeto. Equipes planejam projetos de IA como se fossem 70% modelagem e 30% dados. A realidade costuma ser o inverso.

O caso da King é particularmente ilustrativo porque os 12 milhões de pares estado-ação não apareceram magicamente. Eles são o resultado de anos de instrumentação cuidadosa da telemetria de jogo, decisões sobre o que armazenar, arquitetura de pipelines que levam dados de dispositivos móveis para sistemas de treinamento, e infraestrutura para manter tudo isso em produção. A King usa Google Cloud com Pub/Sub como middleware para o loop de feedback entre simulações e módulos de análise.

No meu trabalho no GRI Institute, onde lidero um data lake consolidando 13 fontes em BigQuery e Redshift, isso se confirma todos os dias. A parte mais cara do pipeline não são os modelos, são os ETLs, a reconciliação de identificadores, a limpeza de inconsistências, a construção de taxonomia canônica, a rotulagem semântica. Os modelos vêm depois, e costumam ser a parte simples.

Velocidade de iteração é o que muda o jogo

O ganho econômico real da King não foi ter um modelo mais preciso. Foi reduzir o ciclo de feedback de calibração de níveis de sete dias para menos de um minuto. Essa mudança de ordem de magnitude no tempo de iteração altera completamente a economia do design.

Quando o custo de testar uma hipótese cai drasticamente, o comportamento racional muda. Em vez de preparar cuidadosamente uma hipótese antes de testar, você testa muitas hipóteses em paralelo e usa os dados para decidir quais aprofundar. Isso é o princípio que está por trás de fenômenos como A/B testing em massa em produtos digitais, e é o mesmo princípio que permite à King manter o ritmo de lançamento de 15 níveis por semana.

Ao avaliar projetos de IA candidatos em uma empresa, uma boa pergunta estratégica é: que ciclo de aprendizado atualmente leva semanas e poderia ser reduzido para minutos. Esse tipo de projeto geralmente tem retorno superior a projetos que prometem apenas mais precisão em uma decisão que já é tomada rapidamente.

Por que comparar as três abordagens importa

As três abordagens publicadas (MCTS de Poromaa, CNN supervisionada da King, DQN de Deng) são tecnicamente interessantes por si só, mas comparadas elas ensinam algo mais geral sobre como escolher um método de machine learning para um problema real.

MCTS é apropriado quando você tem um simulador do ambiente e quer encontrar boas jogadas, sem precisar de dados de treinamento. É computacionalmente caro em inferência, e não aprende entre episódios.

DQN é apropriado quando você quer aprender uma política ótima a partir de recompensa escalar, e tem recursos para rodar muitos episódios de treinamento. Aprende uma política genérica, mas não necessariamente uma política humana.

Supervised learning em cima de dados comportamentais é apropriado quando você tem acesso a decisões humanas em escala e quer reproduzir distribuição de comportamento, não estratégia ótima. É barato em inferência, mas depende criticamente da qualidade e volume dos dados.

A escolha entre os três não é técnica em primeiro lugar, é uma escolha sobre qual problema você está resolvendo. E essa decisão precisa vir antes da arquitetura.

O caso Candy Crush é um dos exemplos mais bem documentados de IA aplicada a um problema de produto real, em escala industrial, com dados de telemetria massivos, e com alternativas acadêmicas bem documentadas para comparação. Para quem trabalha com dados ou IA em empresas, os detalhes são instrutivos.

Referências

Para quem quiser se aprofundar tecnicamente, as fontes principais são:

Gudmundsson, S., Eisen, P., Poromaa, E., Nodet, A., Purmonen, S., Kozakowski, B., Meurling, R., Cao, L. “Human-Like Playtesting with Deep Learning”. IEEE Conference on Computational Intelligence and Games, 2018. O paper da própria King descrevendo a arquitetura CNN em produção.

Deng, B. “Learn to play Candy Crush”. Stanford CS230 Deep Learning, Winter 2020. Abordagem via Deep Q-Network com código aberto em github.com/baolidakai/candy_crush_ai.

Poromaa, E. R. “Crushing Candy Crush: Predicting Human Success Rate in a Mobile Game using Monte-Carlo Tree Search”. Master’s thesis, KTH Royal Institute of Technology, 2017.

Purmonen, S. “Predicting Game Level Difficulty Using Deep Neural Networks”. Master’s thesis, KTH Royal Institute of Technology, 2017.

Walsh, T. “Candy Crush is NP-hard”. arXiv:1403.1911, 2014.

Andelkovic, A. “How King uses AI to test Candy Crush Saga”. InfoQ, 2019.

Zhao, Y., Borovikov, I., Beirami, A., et al. “Winning Isn’t Everything: Training Human-Like Agents for Playtesting”. Electronic Arts / NeurIPS, 2020.

“Testing match-3 video games with Deep Reinforcement Learning”. arXiv:2007.01137, 2020. Universidade Roma Tre.

Toda empresa com mais de três anos de operação tem o mesmo problema. Ninguém planejou que os sistemas conversassem entre si. O CRM roda em MySQL, o financeiro em PostgreSQL, a plataforma de relacionamento com clientes usa outro MySQL com schema completamente diferente, o marketing alimenta planilhas e ferramentas SaaS que expõem APIs próprias, e há dados em filas, em caches, em buckets de storage, em bancos NoSQL que alguém subiu para um projeto piloto que ficou. Cada sistema foi a melhor decisão no contexto em que nasceu. O problema real sempre foi a ausência de uma estratégia de consolidação.

Quando um diretor pede “quero um relatório cruzando engajamento com receita”, a resposta honesta em muitas empresas é: “precisamos de dois dias e três planilhas coladas no Excel”.

Este artigo descreve a arquitetura que desenhei e implementei para resolver esse problema, com foco no racional por trás de cada decisão.

O cenário: dados em volume, sem utilidade prática

O cliente operava com dezenas de sistemas acumulados ao longo de anos: bancos MySQL em versões diferentes, instâncias PostgreSQL, APIs de terceiros, planilhas compartilhadas que funcionavam como “banco de dados” de áreas inteiras, dados em ferramentas SaaS acessíveis apenas por exportação manual. Os dados estavam lá, em volume considerável, mas apresentavam três problemas críticos:

Fragmentação. Uma mesma entidade (um cliente, um contrato, uma transação) existia em dois ou três sistemas com schemas diferentes, IDs diferentes, e graus de atualização diferentes. Sem fonte única de verdade.

Obsolescência. Campos abandonados, registros duplicados, categorias que já não refletiam a operação. O dado envelhecia dentro do banco sem que ninguém o curasse.

Opacidade para IA. Este era o ponto decisivo. A empresa queria usar inteligência artificial para recomendações, automação e análise preditiva. IA opera sobre dados consistentes e estruturados. Um modelo de linguagem que recebe contexto fragmentado produz respostas fragmentadas. Um modelo de scoring alimentado com duplicatas gera rankings distorcidos.

O desafio era ao mesmo tempo técnico e estratégico: tornar o patrimônio de dados da empresa utilizável por IA, sem interromper as operações que dependiam dos sistemas existentes.

O princípio: zero impacto nas origens

A primeira decisão arquitetural, e provavelmente a mais importante, foi preservar os sistemas originais intactos.

Reescrever um CRM legado ou migrar um ERP financeiro para um banco unificado é o tipo de projeto que consome meses, gera risco operacional, e frequentemente falha. Já vi isso acontecer. O sistema “novo e melhor” fica pronto com 70% das funcionalidades do antigo, e a equipe operacional passa seis meses compensando as lacunas manualmente.

A abordagem que adotei parte de uma premissa simples: manter cada aplicação original rodando exatamente como está, alimentando seus respectivos bancos, APIs e storages normalmente. Cada fonte de dados, independente da tecnologia (MySQL, PostgreSQL, APIs REST, arquivos em bucket, exportações de SaaS), passa a ser espelhada, de forma incremental e não intrusiva, para um data lake centralizado.

Na prática, o time operacional não percebe nenhuma diferença no dia a dia. O CRM continua funcionando. O ERP continua emitindo notas. A plataforma web continua servindo usuários. As planilhas do marketing continuam sendo preenchidas. Nos bastidores, cada alteração em cada uma dessas fontes é capturada e replicada para uma camada de armazenamento separada, independente de ser um banco relacional, uma API, ou um arquivo CSV em um bucket.

A arquitetura em camadas

O desenho final tem quatro camadas distintas, cada uma com uma responsabilidade clara.

Camada 1: Aplicações Originais

MySQL em diferentes versões, PostgreSQL, APIs de SaaS, planilhas, filas de mensagens, arquivos em storage. Cada sistema continua operando como sempre operou. O único ponto de contato é o mecanismo de captura adequado a cada tecnologia: CDC para bancos relacionais, conectores de API para SaaS, ingestão de arquivos para exports e planilhas, consumers para filas. A complexidade está justamente em lidar com essa diversidade sem impor um padrão único na origem. Esta camada é apenas observada, nunca alterada.

Camada 2: Data Lake (Espelhamento)

Aqui os dados chegam organizados em três zonas:

A Raw Zone recebe o dado bruto, exatamente como saiu da origem. Sem transformação, sem limpeza. É o registro histórico fiel do que cada sistema produziu. Fundamental para auditoria e para reprocessamento quando as regras de negócio mudam.

A Staging Zone aplica as primeiras transformações: limpeza, deduplicação, tipagem correta, validação de qualidade. Um campo “telefone” que no MySQL era varchar livre aqui é padronizado. Um registro duplicado é identificado e marcado.

A Curated Zone é onde o dado ganha estrutura de negócio. As entidades são consolidadas: o “cliente” que existia em três sistemas agora é uma única entidade com todos os atributos unificados. O modelo relacional passa a refletir a realidade do negócio, alinhado à operação e ao vocabulário da empresa.

Camada 3: Enriquecimento e Inteligência

Esta camada é onde o dado se torna operacional para IA, e onde mora boa parte do valor diferencial da arquitetura.

Sobre a base consolidada da Curated Zone, esta camada executa processamentos que adicionam informação. Modelos de scoring calculam propensão, relevância, risco. Algoritmos de matchmaking cruzam perfis para gerar recomendações. Enriquecimento externo adiciona dados de terceiros (geocodificação, dados de mercado, complementos cadastrais). Métricas de negócio são pré-calculadas e materializadas para consumo rápido.

O ponto crítico aqui é que algumas aplicações finais já vivem nesta camada. O sistema de matchmaking, por exemplo, funciona como um serviço que consome e produz dados em tempo quase-real. Esta camada é parte ativa da operação.

Camada 4: Aplicações Finais (Consumo e Retroalimentação)

Dashboards, APIs inteligentes, automações, e agentes de IA. Todas essas aplicações consomem dados que já passaram por consolidação, limpeza, e enriquecimento. Um agente de IA que responde perguntas sobre clientes consulta uma única camada que já consolidou e enriqueceu a informação de todas as origens.

Um aspecto fundamental desta camada é que ela retroalimenta todas as anteriores. Os scores calculados por modelos de ML podem ser escritos de volta nos bancos de origem, para que as aplicações legadas se beneficiem da inteligência gerada. Novos dados produzidos por automações alimentam o data lake. Resultados de agentes de IA recalculam métricas na camada de enriquecimento. O sistema forma um ciclo: cada camada se beneficia do que as outras produzem.

Decisões que importaram

Algumas decisões técnicas merecem destaque por terem sido determinantes para o sucesso do projeto.

CDC para bancos, conectores para o resto. Change Data Capture permite replicar apenas o que mudou nos bancos relacionais, reduzindo janela de latência e custo de processamento. Mas CDC é apenas uma das estratégias. Para APIs de SaaS, há conectores que sincronizam periodicamente. Para planilhas e exports, há ingestão baseada em eventos de arquivo. A decisão de qual mecanismo usar para cada fonte é parte do trabalho de arquitetura, e cada escolha errada aqui se paga em fragilidade do pipeline.

Schema-on-read na Raw Zone. Permitir que os dados cheguem sem schema rígido absorve mudanças nos sistemas de origem sem quebrar o pipeline. Quando o time de produto adiciona um campo no CRM, o data lake absorve automaticamente. A transformação acontece nas camadas seguintes, onde há controle.

Materialized views para métricas. KPIs pré-calculados e atualizados incrementalmente eliminam a necessidade de queries complexas em tempo real. O dashboard que carrega em menos de 2 segundos só é possível porque o cálculo pesado já foi feito antecipadamente.

Separação entre enriquecimento e consumo. Manter a camada de inteligência separada da camada de consumo permite que diferentes aplicações usem diferentes níveis de processamento. Um dashboard simples pode consumir direto da Curated Zone. Um agente de IA precisa dos dados enriquecidos. Essa flexibilidade evita over-engineering para casos simples.

Retroalimentação entre camadas. Permitir que as aplicações finais escrevam dados de volta nas camadas anteriores transforma a arquitetura em um sistema vivo. Os dados melhoram a cada ciclo: um score gerado na Camada 3 pode refinar um processo na Camada 1, que por sua vez produz dados de melhor qualidade no próximo ciclo de ingestão.

O resultado: dados como ativo estratégico

A empresa passou a contar com uma plataforma de dados consolidada que serve como alicerce para todas as iniciativas de IA e automação da operação.

Funcionalidades que exigiam semanas de trabalho manual passaram a ser implementáveis em dias. Novos agentes de IA podem ser conectados à plataforma sem necessidade de integrações customizadas. Novas aplicações consomem dados já consolidados e enriquecidos desde o primeiro dia.

Nenhum sistema original foi descontinuado ou reescrito. O risco operacional foi zero. A equipe continuou trabalhando normalmente enquanto a infraestrutura de dados era construída em paralelo.

Para quem enfrenta o mesmo desafio

Se sua empresa tem dados em múltiplos sistemas e está tentando viabilizar projetos de IA, a pergunta mais produtiva é: “nossos dados estão prontos para alimentar IA de forma confiável?”

Na grande maioria dos casos, ainda não estão. E a solução passa por construir uma camada de inteligência sobre os sistemas que já existem.

Este é o tipo de projeto que tenho prazer em conceber e executar: diagnóstico de maturidade de dados, desenho de arquitetura de consolidação, e implementação de plataformas que transformam dados fragmentados em ativos estratégicos prontos para IA.

Se quiser conversar sobre como isso se aplica à sua realidade, me encontre no LinkedIn ou entre em contato diretamente.

Guilherme Favaron é especializado em arquitetura de dados e plataformas de IA. Trabalha com empresas que querem extrair valor real dos dados que já possuem.

Você já viu aqueles vídeos. Alguém abre um prompt, descreve um app em três frases, e em dois minutos tem um produto funcionando. Login, dashboard, API, deploy. Tudo gerado por IA, do zero, sem esforço aparente.

É impressionante. E é real.

Mas se você trabalha com software de verdade, aquele sistema que já roda em produção, atende clientes, processa pagamentos, sustenta operações, você sabe que a sua realidade é outra. Você está no meio de um jogo que já começou, com regras que já foram definidas, código que já foi escrito, e um time que já tem seus processos.

A pergunta que realmente importa é: como integrar IA no que já existe?

Por que começar do zero é fácil

Quando você cria um app do zero com IA, tudo conspira a seu favor.

Não existe arquitetura legada para respeitar. Não existe dívida técnica acumulada. Não existem dependências de terceiros que ninguém atualiza há dois anos. Não existe aquela regra de negócio obscura que está num if no meio de um service que ninguém quer mexer.

A IA gera código sem conflitos porque não há código anterior. Ela toma decisões de arquitetura sem restrições porque não há restrições. O resultado é limpo, coerente e bonito, exatamente porque o contexto é vazio.

Mas aqui está o ponto: a esmagadora maioria do software que gera valor já existe e já está rodando. O greenfield, aquele projeto que nasce do zero, sem bagagem, é a exceção. E otimizar para a exceção é uma armadilha.

Se você esperar o próximo projeto greenfield para começar a usar IA, vai ficar esperando por muito tempo. O desafio de verdade está nos sistemas que já estão aí.

O desafio real: IA dentro de sistemas que já funcionam

Integrar IA em sistemas legados é um problema fundamentalmente diferente de criar algo do zero. Alguns dos motivos:

O código não foi escrito pensando em IA. A IA precisa entender contexto, e o contexto de um sistema legado é vasto, distribuído, e às vezes contraditório. Módulos que foram escritos por pessoas diferentes, em momentos diferentes, com premissas diferentes. Documentação desatualizada ou inexistente. Testes que cobrem o caminho feliz mas ignoram os edge cases que realmente importam.

Os processos são enraizados. Times têm seus rituais. Há resistência, muitas vezes legítima, a mudar o que funciona. “A gente sempre fez assim” carrega tanto inércia quanto confiança num processo que já provou que funciona em produção.

O risco é real. Um erro num app que acabou de nascer é um inconveniente. Um erro num sistema em produção pode significar clientes afetados, receita perdida, dados corrompidos. A margem para experimentação é menor.

Por tudo isso, o objetivo de integrar IA em sistemas legados é aumentar a capacidade do time: automatizar o que é repetitivo, acelerar o que é lento, e trazer uma segunda perspectiva para decisões que antes dependiam de uma pessoa só.

Um framework prático: como integrei IA no meu time

Depois de testar diferentes abordagens, cheguei a um workflow que funciona. Ele roda no meu dia a dia, validado em projetos reais. A regra é simples: toda mudança de código segue este fluxo, sem exceção.

O workflow tem três fases, com gates explícitos entre elas.

Fase 1: Triagem (de feedback a issues)

Tudo começa com input desestruturado. Conversas, mensagens, calls, PDFs, observações de usuários. O tipo de coisa que normalmente se perde ou vira um “depois a gente vê”.

O primeiro passo é transformar esse ruído em problemas concretos. Eu e o agente de IA analisamos juntos cada input e definimos: “o problema é este”. Uma issue de engenharia, com contexto técnico suficiente para que alguém (humano ou IA) consiga atuar.

O agente de IA então cria cada issue no repositório do projeto no GitHub, com descrição clara do problema.

Por que isso importa: a maioria dos times perde valor nessa etapa. O feedback existe, mas nunca vira uma issue rastreável. Com o agente de IA, a triagem acontece em tempo real e o custo de transformar feedback em artefato de engenharia cai drasticamente.

Fase 2: Planejamento (de issues a plano)

Com as issues criadas, o agente de IA avalia cada uma, tanto isoladamente quanto no contexto global do projeto. Às vezes duas issues que parecem independentes são, na verdade, sintomas do mesmo problema. O agente identifica isso e pode consolidá-las num único plano de ação.

O plano é detalhado: o que muda, por que muda, como muda. Ele é registrado numa ferramenta de gestão. Pode ser Notion, Jira, Trello, ou alternativas open source como Plane, OpenProject, LeanTime ou Taiga. O importante é que o plano exista como artefato visível, acessível, e separado do código.

Então eu leio o plano e aprovo (ou peço ajustes). Nada executa sem plano aprovado. Esse é o primeiro gate.

Por que isso importa: a IA é rápida para executar, mas isso pode ser perigoso sem direção. O plano é o freio intencional que garante que a velocidade da IA está apontada na direção certa.

Fase 3: Execução (de plano aprovado a deploy)

Com o plano aprovado, a execução segue um fluxo disciplinado:

1. Branch. O agente de IA cria uma branch (feat/xxx ou fix/xxx) a partir da main. Nunca trabalha direto na main.

2. Implementação. O agente implementa e commita na branch, seguindo o plano aprovado.

3. Pull Request. O agente abre um PR no GitHub com descrição clara do que muda e por quê.

4. Revisão. Aqui entra um conceito importante: a revisão do PR pode (e deve) envolver uma segunda IA. A mesma inteligência que escreveu o código carrega viés de autoria, pelo mesmo motivo que um desenvolvedor não deveria aprovar seu próprio PR. Uma segunda IA traz uma perspectiva independente, aumentando a assertividade da análise crítica. Mas o merge é sempre decisão humana.

5. Deploy. Build e deploy via CI/CD (GitHub Actions, pipelines automatizados, ou manualmente quando necessário).

6. Status. Atualização do status na ferramenta de gestão, fechando o ciclo.

Os gates

Três regras inegociáveis:

• Nada executa sem plano aprovado. A IA não tem autonomia para decidir o que fazer, só como fazer.

• Nada vai direto pra main. Toda mudança passa por PR, sempre.

• Merge é sempre decisão humana. A IA pode sugerir, implementar, e até revisar, mas a palavra final é do líder técnico.

A IA é o motor. O humano é o volante.

Por que usar uma segunda IA para revisar PRs

Esse ponto merece destaque porque é contra-intuitivo. Se você já tem uma IA gerando código, por que usar outra para revisar?

Pelo mesmo motivo que code review existe: viés do autor. Quando uma IA (ou um humano) escreve código, ela toma decisões implícitas sobre nomes, sobre estrutura, sobre o que precisa ou não de tratamento de erro. Essas decisões ficam invisíveis para quem as tomou.

Uma segunda IA, sem o contexto de autoria, olha para o código com olhos frescos. Ela questiona premissas que a primeira IA deu como certas. Ela identifica edge cases que o autor não considerou. Ela avalia se o código realmente faz o que o PR diz que faz.

Na prática, isso aumenta significativamente a qualidade do que chega para revisão humana. O líder técnico pode ser o último filtro, focando em decisões de arquitetura e de negócio em vez de caçar bugs triviais.

O caminho realista

Se você está esperando o momento perfeito para integrar IA no seu time, tenho uma má notícia: ele não existe. O momento é agora, com o sistema que você já tem, com o time que você já tem.

Algumas lições que aprendi:

• Comece pelo processo. Antes de pedir para uma IA escrever código no seu sistema legado, defina como ela vai trabalhar. Qual é o fluxo? Quais são os gates? Quem aprova o quê? O workflow vem antes da implementação.

• Trate a IA como membro do time. Um membro do time tem responsabilidades definidas, participa de processos, e é cobrado por resultados. Quando você define que o agente de IA é responsável por criar issues, elaborar planos e abrir PRs, ele passa a ter um papel claro dentro do time.

• Mantenha o humano no controle das decisões que importam. A IA acelera execução, mas as decisões de o que fazer e quando fazer continuam sendo humanas. Velocidade de máquina com julgamento humano.

• Busque disciplina. O workflow que descrevi tem falhas. Mas funciona porque tem regras claras, gates explícitos, e artefatos rastreáveis. É isso que permite escalar o uso de IA sem perder o controle.

Criar um app do zero com IA é fácil. Integrar IA nos seus sistemas legados é onde está o trabalho de verdade, e onde está o maior impacto.

O código que importa já existe. O que você vai fazer com ele?

Existe uma lacuna estrutural entre o momento em que um usuário encontra um problema em uma aplicação e o momento em que esse problema é corrigido. Essa lacuna tem nome: ela se chama processo manual de reporte, triagem e priorização. E em praticamente todas as equipes de produto que conheço, ela é grande o suficiente para que boa parte dos problemas nunca chegue a ser resolvida.

O volume de sinais cresce mais rápido do que a capacidade de processá-los com atenção: erros de runtime, feedback qualitativo, solicitações de melhoria, tickets do suporte. O resultado é um backlog que se torna cemitério.

A Self-Improvement Architecture é um padrão de design de sistemas que propõe fechar essa lacuna com automação inteligente e agentes de IA. A forma assistida: máquinas fazem o trabalho de baixo valor cognitivo e humanos concentram sua atenção onde ela é insubstituível.

Self-Improvement Architecture (SIA) é um conjunto de camadas de software que captura sinais de qualidade de uma aplicação em produção, normaliza e prioriza esses sinais automaticamente, e alimenta um agente de IA capaz de diagnosticar problemas e propor correções no próprio código-fonte da aplicação, com supervisão humana nos pontos críticos.

Diferente de práticas convencionais de monitoramento e gestão de defeitos, a SIA fecha o loop inteiramente dentro do ciclo de desenvolvimento: da observação em produção até o pull request, passando por triagem, diagnóstico e geração de código.

Por que o momento é agora

A conversa sobre agentes de IA gerando código existe há algum tempo. O que mudou recentemente é a maturidade dos componentes que tornam um sistema assim viável em produção: ferramentas de observabilidade que capturam contexto rico de sessão, modelos de linguagem com janelas de contexto grandes o suficiente para processar arquivos de código real, e infraestruturas de agentes que permitem controle granular sobre o que o sistema pode e não pode fazer.

A pergunta central também mudou. Saiu de “é tecnicamente possível?” e passou a ser “como fazer isso de forma que o benefício supere consistentemente o risco?”. É essa pergunta que o padrão SIA tenta responder.

“Um agente que age sem critério vira fábrica de tickets. Um agente com critério vira alavanca de produtividade.”

As cinco camadas do padrão

A SIA é organizada em camadas independentes. Cada uma pode ser implementada separadamente, e a ordem importa: cada camada só gera valor se a anterior estiver funcionando bem.

Camada 01 — Captura

Instrumentação da aplicação para coletar três tipos de sinal: erros de runtime com contexto de sessão, feedback explícito do usuário via widget integrado, e sinais comportamentais passivos como rage clicks, abandono de fluxo e endpoints lentos. Esses canais são deliberadamente separados, porque cada tipo de sinal tem critérios diferentes de triagem.

Camada 02 — Normalização e Triagem

Um serviço intermediário recebe todos os sinais e os converte para um schema único. Aqui acontecem deduplicação por fingerprint, enriquecimento com dados de contexto e cálculo de score de prioridade. Nenhum sinal chega ao repositório antes de passar por essa camada. É o filtro que impede o backlog tóxico.

Camada 03 — Gestão de Issues

O sistema de controle de versão funciona como hub de execução técnica. Issues chegam já estruturadas com contexto, evidências e score. Um sistema de labels e pipeline de projeto torna o estado de cada problema visível sem esforço humano de atualização manual.

Camada 04 — Agente

O agente de IA entra em cena somente após a camada anterior. Ele lê issues que atingiram um gate explícito de elegibilidade, produz diagnóstico, identifica arquivos afetados no repositório e, para problemas de baixo risco com critérios definidos, abre um pull request em branch separada com o racional completo documentado.

Camada 05 — Humana

O humano é posicionado onde sua atenção tem maior valor: decidindo o que priorizar, aplicando o gate de elegibilidade para o agente e revisando pull requests antes do merge. Merge automático e ação do agente em áreas sensíveis sem aprovação explícita estão fora do escopo do padrão.

O fluxo completo

[ APLICAÇÃO ]
    ├── erros runtime
    ├── feedback explícito
    └── sinais comportamentais
           │
           ▼
[ GATEWAY ]  ── normaliza, deduplica, pontua
           │
           ▼
[ ISSUES ]   ── estruturadas + labels + pipeline
           │
     gate: ai-ready?
     ├── NÃO ──▶ [ HUMANO ] decide: prioriza / descarta
     └── SIM ──▶ [ AGENTE ] diagnostica + plano
                     │
           risco low?
           ├── NÃO ──▶ [ HUMANO ] decide
           └── SIM ──▶ [ PR ]   branch separada
                               │
                               ▼
                       [ HUMANO ] revisa + aprova + merge

O gate de elegibilidade — a peça mais importante

A diferença entre um sistema de self-improvement que funciona e um que degenera em caos está quase inteiramente no gate de elegibilidade para ação autônoma do agente.

A lógica é simples: o agente age sozinho apenas quando três condições são satisfeitas simultaneamente. O problema é bem delimitado: stack trace claro, módulo identificável, reprodução documentada. A mudança é de baixo risco: sem tocar regras de negócio, autenticação, dados financeiros, migrações destrutivas ou arquitetura. E um humano aplicou explicitamente a label de elegibilidade após revisar o diagnóstico inicial.

O gate existe porque alguns tipos de problema requerem julgamento contextual que exige atenção humana deliberada.

O agente pode agir sozinho quando:

• Bug com stack trace claro e reproduzível

• Correção de texto ou label na UI

• Validação de campo ausente ou incorreta

• Tratamento de erro faltando

• Tipagem incorreta ou ausente

• Teste unitário faltando para função isolada

• Refactor localizado sem mudança de comportamento

O humano é obrigatório quando:

• Mudança de regra de negócio ou lógica de domínio

• Qualquer coisa relacionada a auth ou permissões

• Cobrança, faturamento, dados financeiros

• Migration destrutiva de banco de dados

• Mudança de arquitetura ou dependência principal

• Issues sem reproduzibilidade mínima documentada

O gate precisa ser definido por escrito, versionado e revisado periodicamente. À medida que o sistema ganha histórico, você terá dados reais sobre a taxa de assertividade do agente e poderá expandir ou contrair os critérios com base em evidência.

Os seis princípios do padrão

1. Sinal antes de ruído

Nenhum evento deve virar issue diretamente. Todo sinal passa por normalização, deduplicação e scoring antes de qualquer criação de ticket. Um sistema de self-improvement mal configurado gera backlog mais rápido do que resolve problemas.

2. Canais separados, critérios separados

Erro de runtime e solicitação de feature são animais diferentes. O fluxo de triagem, os critérios de priorização e as expectativas de resposta são distintos para cada tipo. Misturá-los é uma das causas mais comuns de falha em sistemas desse tipo.

3. O agente propõe, o humano aprova

Mesmo nos casos de baixo risco onde o agente abre PR, o merge é sempre humano. A arquitetura correta para construir confiança progressiva no sistema é essa: autonomia restrita no início, expandida gradualmente com base em dados reais de assertividade.

4. Guardrails como infraestrutura, não como regras

Branch protection, CODEOWNERS, CI obrigatória e limites de permissão do agente devem ser configurados como infraestrutura técnica, não como política documentada. Os limites precisam existir na camada de execução, porque um agente com permissão para fazer algo eventualmente tentará fazê-lo.

5. Transparência do racional

Todo PR aberto pelo agente deve documentar: o problema identificado, os arquivos afetados, a solução escolhida, alternativas descartadas e o nível de confiança. Um PR sem racional documentado não deve ser mergeado.

6. Implementação faseada

A SIA cresce em etapas. A fase 1 entrega valor imediato com risco baixo: captura estruturada, triagem e diagnóstico sem autonomia de PR. As fases seguintes expandem autonomia gradualmente, baseadas em métricas reais de qualidade do sistema.

Fases de implementação recomendadas

Fase 1 — Captura + Triagem

Instrumentar a aplicação com ferramenta de observabilidade. Implementar widget de feedback com contexto da rota atual. Construir o gateway de normalização. Configurar templates de issue e taxonomia de labels. O agente apenas comenta diagnóstico, sem abrir PRs. Esta fase já entrega valor significativo e valida o modelo.

Fase 2 — Agente Semi-Autônomo

Definir e documentar os critérios do gate de elegibilidade. Habilitar o agente a abrir PRs em issues low-risk + ai-ready. Configurar branch protection, CODEOWNERS e CI obrigatória. Todo PR revisado e aprovado por humano antes do merge. Começar a coletar métricas de assertividade.

Fase 3 — Loop Completo

Deduplicação madura com clustering de feedback similar. Identificação proativa de padrões recorrentes. Analytics de tempo até correção, taxa de reabertura e assertividade do agente por tipo de problema. Expansão criteriosa dos critérios do gate com base nos dados acumulados.

Um ciclo completo na prática

Para tornar o padrão concreto, vale acompanhar um único problema do começo ao fim, com as ferramentas reais em cada etapa.

Cenário: um usuário tenta exportar um relatório em PDF dentro da aplicação. O botão não responde. Ele tenta três vezes e desiste.

Etapa 1 — O Sentry captura o erro

O SDK do Sentry, instalado na aplicação, registra automaticamente a exceção lançada pelo componente de exportação. O evento chega ao Sentry com stack trace completo, identificador da sessão, versão do release, navegador e a URL exata onde ocorreu. O Sentry também grava um Session Replay dos últimos 60 segundos de navegação do usuário.

Neste ponto, o erro existe no Sentry. O repositório ainda não sabe que ele aconteceu.

Etapa 2 — O gateway recebe o evento e decide

O Sentry dispara um webhook para o gateway (neste caso, um workflow no n8n). O gateway executa três verificações antes de qualquer ação:

• Deduplicação: já existe uma issue aberta com o mesmo fingerprint? Se sim, incrementa o contador e atualiza a última ocorrência. Se não, continua.

• Limiar: este erro atingiu o threshold de criação? O threshold configurado é 5 ocorrências em 24 horas ou 2 usuários únicos afetados. O erro aconteceu com 3 usuários em 4 horas. Passa.

• Scoring: o gateway calcula o score combinando severidade (o botão de exportação é rota crítica), frequência (3 ocorrências em 4 horas) e confiança de diagnóstico (stack trace presente, módulo identificado). Score resultante: 74 de 100.

O gateway monta o payload da issue com todos os dados coletados e chama a GitHub Issues API.

Etapa 3 — A issue é criada no GitHub com contexto completo

A issue abre automaticamente com o template padronizado preenchido:

Título: [bug] Exportação de PDF falha silenciosamente em /reports/export

Contexto: source:sentry | route:/reports/export | release:v2.4.1 | browser:Chrome 122

Sintoma: TypeError: Cannot read properties of undefined (reading 'generate')
  em ExportButton.tsx linha 47

Evidência:
  - Stack trace completo: [link]
  - Session Replay: [link Sentry]
  - Ocorrências: 3 | Usuários afetados: 3 | Janela: 4h

Impacto: rota crítica de exportação | score: 74

Labels aplicadas automaticamente:
  source:sentry | type:bug | priority:p1 | status:triage-needed | risk:low | module:reports

O GitHub Projects move a issue automaticamente para a coluna Needs Triage.

Etapa 4 — O agente faz a triagem

Um GitHub Actions workflow dispara ao detectar a label status:triage-needed. Ele chama o agente (Claude via API) passando o conteúdo completo da issue, o stack trace e os arquivos relevantes do repositório lidos via GitHub API.

O agente responde com um comentário na issue:

Diagnóstico: o método `generate()` está sendo chamado sobre o objeto
`pdfService` antes de sua inicialização assíncrona completar. O componente
`ExportButton.tsx` não aguarda a Promise de setup do serviço antes de
expor o botão como clicável.

Arquivo afetado: src/components/ExportButton.tsx (linha 47)
Causa provável: ausência de await no método initializePdfService()

Risco estimado: baixo. Mudança localizada em um único componente,
sem impacto em lógica de negócio ou dados.

Critérios de aceite sugeridos:
  - exportação conclui com sucesso após a correção
  - botão permanece desabilitado durante inicialização do serviço
  - teste unitário cobre o caso de chamada antes do setup completar

Este problema atende aos critérios do gate ai-ready. Aguardando
decisão do responsável para prosseguir.

O agente aplica a label status:ai-ready e move a issue para a coluna correspondente no Projects.

Etapa 5 — O humano aplica o gate

O dev abre a issue, lê o diagnóstico, confirma que faz sentido e mantém a label status:ai-ready. Esse gesto explícito é o gate. Sem ele, o agente não age.

Etapa 6 — O agente abre o pull request

Com o gate aplicado, o workflow dispara novamente. O agente lê os arquivos afetados, gera a correção, cria uma branch fix/export-button-async-init e abre um PR com o seguinte corpo:

Corrige: #147 — Exportação de PDF falha silenciosamente

Problema: ExportButton chamava pdfService.generate() antes da
inicialização assíncrona do serviço completar.

Solução: adicionado await em initializePdfService() e estado de
loading no botão durante o setup, prevenindo cliques prematuros.

Arquivos alterados:
  - src/components/ExportButton.tsx
  - src/services/pdfService.ts (ajuste no tipo de retorno)

Testes adicionados:
  - ExportButton.test.tsx: caso de clique antes do setup completar

Alternativas descartadas: memoização do serviço no nível do módulo
descartada por introduzir estado global desnecessário.

Confiança: alta. Causa identificada com precisão no stack trace.

O PR passa pela CI: typecheck, lint, testes unitários, build. Tudo verde. O GitHub notifica o dev para revisão.

Etapa 7 — O humano revisa e mergeia

O dev lê o diff, valida a lógica, confirma que os testes cobrem o caso e aprova o merge. O PR é mergeado via rebase.

O agente fecha a issue original com um comentário linkando o PR. O gateway registra o ciclo no Notion: tipo de problema, solução aplicada, tempo da primeira ocorrência até o merge (neste caso, 6 horas), e assertividade do diagnóstico (confirmada pelo dev na revisão).

O que este ciclo demonstra

O usuário encontrou o bug às 14h. A issue estava criada, triada e com diagnóstico às 14h12. O PR estava aberto às 14h18. O dev revisou e mergeou às 20h, sem precisar reproduzir o problema do zero, sem procurar contexto em Slack ou Notion, e sem triagem manual.

O tempo de resolução foi de 6 horas. O tempo de atenção humana no ciclo inteiro foi de aproximadamente 10 minutos.

O que o padrão não resolve

Ser honesto sobre as limitações é parte do que torna um padrão útil.

A SIA pressupõe clareza de visão de produto. Uma equipe sem direção vai apenas corrigir mais rápido coisas que talvez não devessem existir. O padrão também pressupõe testes automatizados robustos como condição para que qualquer PR do agente passe pela CI.

Há um risco específico que vale nomear: agentes gerando PRs em cadência alta podem criar uma ilusão de progresso. Muitos commits, muitos fechamentos de issue, e métricas de negócio estagnadas. A medida de sucesso da SIA é a redução do tempo entre identificação de problema e resolução com impacto mensurável para o usuário, não o volume de PRs gerados.

Onde o padrão funciona bem:

• Aplicações com usuários ativos que geram sinais contínuos de qualidade

• Times pequenos onde o custo de triagem manual é alto em relação ao headcount

• Codebases com cobertura de testes suficiente para que CI seja gate confiável

• Produtos internos onde o ciclo feedback-correção precisa ser mais curto que o processo padrão permite

• Equipes com pelo menos uma pessoa capaz de revisar código gerado por agente com senso crítico

Por onde começar

A pergunta mais frequente quando apresento esse padrão é: “por onde começo?”. A resposta depende do maior gargalo atual do seu processo.

Se sua equipe perde tempo triando manualmente um volume alto de reports, comece pela camada de normalização: o gateway que converte sinais em issues estruturadas já resolve boa parte do problema. Se problemas chegam sem contexto suficiente para diagnóstico, comece pelo widget de feedback e pela integração com ferramenta de observabilidade. Se o processo de triagem funciona mas a correção demora, aí sim faz sentido investir na camada de agente.

Começar pela camada de agente sem ter as anteriores funcionando é o atalho que mais custa. Agente sem contexto rico gera diagnósticos genéricos. Diagnósticos genéricos geram PRs que não passam em revisão. PRs que não passam geram desconfiança no sistema inteiro.

A SIA é um padrão de acumulação. Cada camada bem implementada aumenta o valor da próxima. A pressa em chegar à autonomia do agente é o caminho mais certo para abandonar o sistema em três meses.

Considerações finais

A ideia central do padrão é deceptivamente simples: aplicações que capturam feedback estruturado, processam esse feedback com automação inteligente e fecham o loop com revisão humana criteriosa ficam progressivamente melhores com o tempo. Por processo, não por design heroico.

O “self” no nome significa que o motor de melhoria está dentro do sistema, alimentado pelo uso real, em vez de depender exclusivamente da capacidade de atenção de uma equipe para capturar, processar e agir sobre sinais que chegam continuamente.

Com as ferramentas disponíveis hoje: observabilidade moderna, modelos de linguagem capazes de raciocinar sobre código, infraestruturas de agentes com controle granular. O padrão é implementável por equipes de qualquer tamanho. O investimento inicial é real. O retorno, se bem executado, é composto.

“O objetivo é uma aplicação onde o custo de quebrar e corrigir cai progressivamente com o tempo.”

Guilherme Favaron é CTO do GRI Institute e autor de “Desbloqueando a Inteligência Artificial”. Escreve sobre IA aplicada a negócios na newsletter IA Aplicada.

Quando um agente responde com convicção algo que está errado, a reação imediata é culpar o modelo. Mas na maioria dos casos, o modelo não é o problema. O problema está na arquitetura de memória que alimenta esse agente.

Esse artigo é sobre isso: como a memória de agentes falha silenciosamente em produção, por que o modelo padrão de armazenamento é insuficiente para sistemas reais, e como construir algo mais robusto usando três pilares — fatos atômicos, scoring composto e tratamento explícito de lacunas de evidência.

O código existe. A implementação é possível. Mas a maioria dos times nunca chega lá porque não percebe que o problema é arquitetural.

O modelo ingênuo e por que ele funciona no protótipo

A implementação padrão de memória para agentes segue um caminho intuitivo:

1. Recebe um bloco de texto com informação relevante

2. Gera um embedding do bloco inteiro

3. Persiste o texto e o embedding em um vector store

4. No recall, busca os mais similares via nearest neighbors

Em um protótipo, isso parece funcionar. As respostas fazem sentido. A demo impressiona.

O problema aparece quando o sistema cresce, os dados acumulam e as consultas ficam mais específicas.

As quatro falhas que surgem em produção

Context bleed

Quando múltiplos fatos são armazenados como um único bloco, o sistema não consegue distinguir qual parte da memória é relevante para qual pergunta.

Considere um bloco como: “Na reunião de terça decidimos usar Postgres porque o orçamento é limitado, a equipe já conhece SQL e vamos precisar de replicação futura.”

Esse bloco contém pelo menos quatro informações independentes: a decisão de tecnologia, a justificativa de custo, a competência do time e um requisito futuro. Quando você pergunta “qual banco de dados estamos usando?”, o sistema recupera o bloco inteiro e o modelo precisa interpretar qual parte responde à pergunta. Às vezes acerta. Às vezes extrapola.

Fact contamination

Atualizar uma informação específica dentro de um bloco exige regravar o bloco inteiro ou criar uma nova versão que compete com a anterior.

Se o orçamento aprovado muda de R$ 10.000 para R$ 15.000, você cria duas memórias semanticamente similares. Qual delas o sistema vai recuperar? Depende de qual foi indexada mais recentemente ou tem embedding mais próximo da query. Não há garantia de consistência.

Ranking incorreto

Similaridade vetorial pura tende a favorecer coincidência lexical e recência sobre importância real.

Em um sistema em uso há meses, uma nota trivial criada ontem — “erro temporário no banco de staging” — pode ter score de similaridade mais alto do que a decisão arquitetural registrada há seis meses — “banco principal do sistema é Postgres” — simplesmente porque compartilha mais palavras com a query “qual banco estamos usando?”.

O sistema responde com a nota trivial. O agente passa a mencionar um erro temporário como se fosse a configuração definitiva.

Alucinação operacional

Quando nenhuma memória recuperada tem evidência suficiente para responder com confiança, o modelo não tem mecanismo para reconhecer isso. Ele responde de qualquer forma, interpolando, extrapolando, inventando com fluência.

Esse comportamento não é falha do modelo em isolamento. É falha de uma arquitetura que não devolve ao modelo a informação de que a evidência é insuficiente.

A solução em três pilares

A proposta não é substituir o vector store. É construir uma camada de memória que pensa sobre o que armazena, como recupera e quando não sabe.

Pilar 1: Fatos atômicos

Em vez de armazenar blocos de texto, a memória armazena proposições discretas e autocontidas.

O bloco “Na reunião de terça decidimos usar Postgres porque o orçamento é limitado...” se transforma em:

• database.primary = postgres

• budget.phase_1.approved = R$ 10.000

• decision.date = 2026-02-11

• team.sql_competency = alta

Cada fato tem atributos próprios: texto canônico, embedding individual, tipo, nível de importância, confiança de extração, confiança de veracidade, referência temporal e proveniência.

Essa granularidade resolve o context bleed. Cada fato responde por si. A atualização de um fato não contamina os outros. O versionamento se torna rastreável.

A extração usa duas abordagens complementares: regras e parsers para padrões determinísticos como datas, valores monetários e identificadores; e um LLM extractor para proposições complexas como decisões, relações causais e contexto implícito.

@dataclass
class ExtractedFact:
    fact_type: str
    fact_key: str | None
    canonical_text: str
    normalized_value: dict | None
    importance: float
    extraction_confidence: float
    truth_confidence: float
    recency_reference_at: datetime | None
    metadata: dict

A importância não é aleatória. Cada tipo de fato tem uma faixa esperada:

• Decisão de arquitetura: 0.90 ou acima

• Orçamento aprovado: 0.85 ou acima

• Preferência estável do usuário: 0.80

• Observação operacional transitória: 0.20 a 0.40

Pilar 2: Scoring composto

O recall não pode depender apenas de similaridade semântica. Precisa combinar múltiplos sinais.

Os sinais relevantes são: similaridade vetorial entre a query e o fato, recência do fato (ponderada pelo tipo — uma decisão arquitetural decai muito mais lentamente do que um incidente operacional), importância intrínseca, confiança de veracidade, confiabilidade da fonte, sobreposição de entidades entre query e fato, penalidade por contradição com outro fato ativo e penalidade por obsolescência.

A fórmula:

score(fact, query) =
  (similaridade × 0.35) +
  (recência × 0.10) +
  (importância × 0.20) +
  (confiança_veracidade × 0.10) +
  (confiabilidade_fonte × 0.05) +
  (sobreposição_entidades × 0.10) +
  (prior_tipo × 0.10) -
  (penalidade_contradição × 0.15) -
  (penalidade_obsolescência × 0.10)

Os pesos iniciais sugeridos acima são razoáveis como ponto de partida, mas precisam ser calibrados com dados reais do seu domínio.

A função de recência usa decaimento exponencial com meia-vida configurável por tipo de fato:

def recency_score(reference_at, half_life_days=30):
    if reference_at is None:
        return 0.5
    age_days = (datetime.now(timezone.utc) - reference_at).total_seconds() / 86400
    return math.exp(-math.log(2) * age_days / half_life_days)

Para incidentes operacionais, half_life_days=7. Para decisões de arquitetura, half_life_days=180. Para preferências estáveis do usuário, half_life_days=365 ou mais.

O recall acontece em duas fases. Na primeira, candidate generation, o sistema busca 30 a 100 candidatos usando busca vetorial, busca léxica por trigrama e filtros por entidades. Na segunda, reranking cognitivo, aplica o scoring composto e seleciona os top-k.

Pilar 3: Evidence gaps

Este é o pilar que mais diferencia uma arquitetura madura de uma ingênua.

Quando a confiança agregada do recall fica abaixo de um threshold, o sistema não deve inventar uma resposta. Deve reconhecer a lacuna.

Os tipos de lacuna mais comuns:

• missing_fact: fato relevante simplesmente não existe na memória

• conflicting_facts: dois fatos ativos se contradizem sem resolução

• stale_fact: fato encontrado, mas provavelmente desatualizado

• low_confidence: evidência insuficiente para afirmar com segurança

• unresolved_entity: entidade ambígua ou não resolvida

• insufficient_context: query exige contexto maior do que o disponível

Quando detectada baixa confiança, o sistema percorre uma fallback ladder antes de declarar incerteza:

1. Expandir o top-k vetorial

2. Rodar busca léxica adicional

3. Ampliar a janela temporal

4. Buscar fatos relacionados via grafo de edges

5. Consultar memória de sessão em cache

6. Consultar fonte primária externa, se disponível

7. Responder com incerteza explícita e registrar o gap

8. Solicitar confirmação ao usuário se necessário

def resolve_with_evidence_gaps(query, tenant_id):
    recall = recall_memory(query, tenant_id)

    if recall["confidence"] >= 0.72:
        return recall

    expanded = broaden_retrieval(query, tenant_id)
    merged = merge_recall_results(recall, expanded)
    new_confidence = aggregate_recall_confidence(merged["facts"])

    if new_confidence < 0.72:
        gap = create_evidence_gap(
            tenant_id=tenant_id,
            recall_event_id=merged["recall_event_id"],
            gap_type="low_confidence",
            description=f"Evidência insuficiente para query: {query}",
            severity=1 - new_confidence,
        )
        merged["evidence_gap_id"] = gap
        merged["needs_clarification"] = True

    return merged

O comportamento esperado do agente quando há evidence gap: “Encontrei indícios, mas não evidência suficiente para afirmar com segurança” ou “A informação encontrada parece desatualizada; preciso confirmar a versão atual.”

Isso é qualitativamente diferente de responder com falsa convicção.

A stack e o papel de cada camada

A arquitetura usa quatro componentes com responsabilidades distintas.

Postgres é a verdade estrutural. Guarda fatos, fontes, versões, edges entre fatos, auditoria de recall e evidence gaps. Toda a rastreabilidade mora aqui.

pgvector é a camada de similaridade semântica dentro do Postgres. Adequado para a maioria dos sistemas corporativos em fase inicial, onde a cardinalidade ainda é administrável e simplicidade operacional tem valor.

Redis é a camada operacional de suporte: memória de sessão antes da consolidação, cache de embeddings e queries frequentes, locks de deduplicação e filas de reindexação.

Pinecone entra como acelerador vetorial quando o volume pressiona o Postgres. O conteúdo relacional e auditável permanece no Postgres; Pinecone cuida do throughput de busca semântica em escala.

A estratégia de rollout recomendada:

• Fase 1 (MVP confiável): Postgres + pgvector + Redis, com ingestão atômica, scoring composto básico, evidence gaps e auditoria de recall

• Fase 2 (robustez): versionamento completo, edges entre fatos, tuning de pesos baseado em dados reais

• Fase 3 (escala): Pinecone, reindexação assíncrona, learned reranker

O que isso resolve na prática

Com fatos atômicos, cada informação é atualizável, versionável e auditável de forma independente. Não há mais blocos conflitantes disputando o mesmo espaço semântico.

Com scoring composto, uma decisão arquitetural de seis meses atrás vence uma nota operacional de ontem quando a query é sobre arquitetura. O ranking reflete importância real, não apenas proximidade lexical recente.

Com evidence gaps, o agente sabe quando não sabe. Ele para de inventar. Ele registra a incerteza para auditoria. Ele busca clarificação quando necessário.

A auditabilidade completa — fonte do fato, componentes do score, confiança agregada, gap registrado — permite diagnosticar por que uma resposta foi gerada, não apenas se ela estava correta.

Thresholds iniciais para calibração

Como ponto de partida razoável:

• Confiança acima de 0.80: responder com alta convicção

• Entre 0.72 e 0.80: responder com ressalva leve

• Entre 0.55 e 0.72: tentar fallback antes de responder

• Abaixo de 0.55: registrar evidence gap, evitar afirmação forte

Esses valores precisam ser ajustados com um benchmark offline construído com casos reais do seu domínio.

Conclusão

A maioria dos sistemas de memória para agentes trata armazenamento como equivalente a cognição. Não é.

Armazenar texto e fazer nearest-neighbor é infraestrutura. Memória cognitiva é outra coisa: saber o que cada informação significa, quando ela é confiável, quanto peso ela merece e quando a evidência é insuficiente para responder.

Os três pilares descritos aqui — fatos atômicos, scoring composto e evidence gaps — não são complexidade desnecessária. São o mínimo necessário para que um agente em produção seja confiável.

Postgres sustenta a estrutura e a auditoria. pgvector ou Pinecone sustentam a recuperação semântica. Redis sustenta a velocidade operacional. Mas o valor real está na lógica de encoding, ranking e tratamento de incerteza.

Sem isso, o sistema apenas armazena texto e chama isso de memória.

O código completo dos fluxos de encoding, recall e evidence gaps, incluindo schema SQL e integração com Pinecone e Redis, está disponível no GitHub.

Se esse artigo foi útil, considere assinar a newsletter para receber os próximos na sua caixa.

Neste artigo, vou mostrar como construí um projeto completo de predição de preços usando redes neurais LSTM em PyTorch. O modelo recebe os últimos 60 dias de preços de fechamento de uma ação e tenta prever o preço do dia seguinte. Escolhi a PETR4 (Petrobras) como caso de estudo, mas a mesma abordagem funciona para qualquer ticker.

O mais importante: tudo roda no navegador, de graça. Google Colab para treinar, HuggingFace para hospedar, GitHub para versionar. Você não precisa de uma GPU própria nem de nenhuma infra local.

Por que LSTM?

Preços de ações são séries temporais. O valor de hoje carrega informação sobre o que aconteceu ontem, na semana passada, no mês anterior. Redes neurais tradicionais (feedforward) não capturam bem essa dependência temporal -- elas tratam cada entrada como se fosse independente.

A LSTM (Long Short-Term Memory) foi projetada exatamente para esse tipo de problema. Ela é um tipo de rede neural recorrente que possui uma “memória interna” controlada por três portões (forget, input e output). Isso permite que a rede decida o que lembrar e o que esquecer, aprendendo padrões de longo prazo nos dados.

Na prática, a LSTM recebe uma sequência de preços passados e aprende a reconhecer padrões que se repetem: tendências de alta e baixa, volatilidade cíclica, reversões. Ela não “entende” o mercado -- ela detecta regularidades estatísticas no histórico.

A pipeline completa

O projeto segue um fluxo que vai desde a coleta de dados até o deploy em produção. Vou passar por cada etapa.

Coleta de dados

Usei a biblioteca yfinance para baixar o histórico da PETR4 desde janeiro de 2018. São mais de 2000 dias de negociação, cada um com preço de abertura, máxima, mínima, fechamento e volume. Para a LSTM, usei apenas o preço de fechamento.

python

SYMBOL = 'PETR4.SA'
START_DATE = '2018-01-01'

df = yf.download(SYMBOL, start=START_DATE, end=datetime.now().strftime('%Y-%m-%d'))

A análise exploratória revelou o que quem acompanha a Petrobras já sabe: ciclos marcantes, picos de volatilidade em períodos de crise e uma tendência geral de valorização nos últimos anos. Gráficos com Plotly mostrando médias móveis de 50 e 200 dias ajudaram a visualizar esses padrões.

Pré-processamento: onde muita gente erra

Três decisões de pré-processamento fazem toda a diferença entre um modelo que funciona e um que só parece funcionar.

Normalização. A LSTM funciona muito melhor com dados entre 0 e 1. Usei um MinMaxScaler para transformar os preços. Sem esse passo, o modelo tem dificuldade para convergir -- e é algo que muita gente esquece na primeira tentativa.

Janelas deslizantes. O modelo recebe os 60 dias anteriores como entrada e prevê o próximo dia como saída. Na prática, a gente “desliza” uma janela de 60 posições sobre a série temporal, gerando milhares de pares (entrada, saída) para treino.

Split temporal. Esse é talvez o ponto mais crítico. Dividi os dados em 70% treino, 15% validação e 15% teste, respeitando a ordem cronológica. Sem embaralhar. Em séries temporais, se você embaralha os dados, está vazando informação do futuro para o passado. O modelo vai parecer brilhante nos números mas não vai generalizar para dados novos. Isso é um erro clássico.

python

# Split SEM embaralhar -- ordem cronológica preservada
X_train, y_train = X[:n_train], y[:n_train]
X_val, y_val = X[n_train:n_train+n_val], y[n_train:n_train+n_val]
X_test, y_test = X[n_train+n_val:], y[n_train+n_val:]

Arquitetura do modelo

O modelo é uma LSTM com duas camadas empilhadas de 128 neurônios cada, seguida de um bloco fully connected (128 -> 64 -> 32 -> 1) com ReLU e dropout de 0.2 entre as camadas. O dropout é importante para evitar overfitting - ele “desliga” aleatoriamente 20% dos neurônios durante o treino, forçando o modelo a não depender de caminhos específicos.

python

class LSTMModel(nn.Module):
    def __init__(self, input_size=1, hidden_size=128, num_layers=2, dropout=0.2):
        super().__init__()
        self.lstm = nn.LSTM(input_size, hidden_size, num_layers,
                            batch_first=True, dropout=dropout)
        self.fc = nn.Sequential(
            nn.Linear(hidden_size, 64), nn.ReLU(), nn.Dropout(dropout),
            nn.Linear(64, 32), nn.ReLU(),
            nn.Linear(32, 1)
        )

    def forward(self, x):
        lstm_out, _ = self.lstm(x)
        return self.fc(lstm_out[:, -1, :])

Essa arquitetura tem cerca de 210 mil parâmetros treináveis. É um modelo relativamente compacto, o que é intencional: para uma única feature (preço de fechamento) com janela de 60 dias, não faz sentido usar algo mais pesado.

Treinamento

Para o treinamento, usei Adam como otimizador com learning rate de 0.001, MSE como função de perda e dois mecanismos de controle: um ReduceLROnPlateau (que reduz o learning rate pela metade quando o modelo para de melhorar) e early stopping com paciência de 15 épocas.

O treinamento no Colab com GPU T4 leva poucos minutos. A curva de aprendizado mostra as losses de treino e validação caindo juntas -- quando as duas acompanham, é um bom sinal. Significa que o modelo está aprendendo padrões reais nos dados, não memorizando.

Avaliação: o que os números dizem

Usei três métricas no conjunto de teste (os 15% finais, dados que o modelo nunca viu):

• MAE (Mean Absolute Error): o erro médio em reais. Se o MAE é 1.50, o modelo erra em média R$1,50.

• RMSE (Root Mean Squared Error): similar ao MAE, mas penaliza mais os erros grandes.

• MAPE (Mean Absolute Percentage Error): o erro em percentual, que facilita comparar entre ações de preços diferentes.

O gráfico mais revelador é o de valores reais versus previsões no conjunto de teste. O modelo acompanha a tendência geral, mas com um atraso característico - algo esperado em modelos que usam apenas histórico de preços.

Aqui vai uma reflexão honesta: o erro foi considerável. Para melhorar, o primeiro passo seria reduzir o período de treinamento para 3 anos em vez de 7. A Petrobras de 2018 é muito diferente da Petrobras de 2025 em termos de faixa de preço e comportamento. Dados mais recentes seriam mais representativos do regime atual.

Mas optei por não otimizar o modelo até ele ficar “bonito”. O objetivo aqui é educacional, não lançar um produto de recomendação. Para um modelo real, eu faria muito mais testes com diferentes arquiteturas, hiperparâmetros e períodos de treinamento.

Do modelo treinado ao deploy

Com o modelo treinado e avaliado, o próximo passo é colocar tudo em produção. Exportei três artefatos: os pesos do modelo (lstm_model.pth), o normalizador (scaler.joblib) e a configuração com hiperparâmetros e métricas (config.json). Antes do upload, rodo uma verificação: carrego o modelo salvo do zero e comparo a previsão com o modelo original. Se não forem idênticas, algo deu errado no salvamento.

HuggingFace Hub

O modelo e os artefatos vão para o HuggingFace Hub, que funciona como um repositório de modelos. Qualquer pessoa pode baixar, carregar em PyTorch e usar. Junto vai um model card documentando a arquitetura, métricas e instruções de uso.

HuggingFace Spaces

O dashboard e a API rodam num HuggingFace Space com Docker. A aplicação combina FastAPI (para os endpoints REST) com Gradio (para o dashboard interativo) no mesmo servidor.

O dashboard tem três abas: uma para gerar previsões em tempo real (digita o ticker, clica e vê o resultado), uma com informações detalhadas sobre o modelo, e uma com documentação da API incluindo exemplos de curl.

A API expõe cinco endpoints:

bash

# Verificar se está no ar
curl https://guifav-lstm-petr4-stock-prediction.hf.space/health

# Previsão automática (baixa dados recentes e roda o modelo)
curl https://guifav-lstm-petr4-stock-prediction.hf.space/predict/PETR4.SA

# Métricas do modelo e operacionais
curl https://guifav-lstm-petr4-stock-prediction.hf.space/metrics

# Detalhes da arquitetura e treinamento
curl https://guifav-lstm-petr4-stock-prediction.hf.space/model/info

Tudo roda no tier gratuito do HuggingFace. Funciona surpreendentemente bem para um projeto educacional.

Retreino automático

Um detalhe que faz diferença: configurei um GitHub Action que toda segunda-feira, antes da abertura do mercado, retreina o modelo automaticamente. O workflow baixa os dados mais recentes via yfinance, retreina a LSTM, publica os novos artefatos no Hub e atualiza o Space. Tudo sem intervenção manual. O GitHub oferece 2000 minutos gratuitos por mês para Actions, e cada retreino leva menos de 15 minutos em CPU.

Quer reproduzir com outra ação?

O projeto foi desenhado para ser reutilizável. O passo a passo:

1. Faça um fork do repositório no GitHub

2. Abra o notebook no Google Colab pelo badge “Open in Colab”

3. Ative a GPU gratuita (Runtime > Change runtime type > T4 GPU)

4. Troque o ticker de PETR4.SA para a ação que quiser (VALE3.SA, ITUB4.SA, BBDC4.SA, qualquer uma listada no Yahoo Finance)

5. Execute todas as células -- o notebook é autocontido e explica cada etapa

6. Crie um token no HuggingFace com permissão Write

7. Rode as células de upload para publicar no Hub e criar o Space

8. Teste sua API via curl ou acesse o dashboard pelo navegador

Não precisa instalar nada. Tudo roda no navegador, de graça.

Limitações (uma parte muito importante)

Preciso ser direto aqui: esse modelo é educacional. Não use para tomar decisões financeiras reais.

Preços de ações são influenciados por política, macroeconomia, sentimento de mercado, notícias, decisões regulatórias -- fatores que um modelo treinado apenas com histórico de preços não captura. A LSTM aprende correlações estatísticas no passado, mas o mercado financeiro é um sistema complexo onde o passado não garante o futuro.

Além disso, a previsão é limitada a um dia à frente, usa apenas uma feature (preço de fechamento) e a performance pode degradar em cenários atípicos (crises, mudanças regulatórias, eventos inesperados).

O valor desse projeto está no aprendizado: entender como funciona uma LSTM, como preparar dados de séries temporais, como avaliar um modelo de regressão, como deployar com Docker e APIs, como usar o ecossistema HuggingFace. São habilidades que se transferem para problemas onde modelos preditivos realmente fazem sentido.

Próximos passos

Para quem quiser evoluir o projeto, algumas ideias:

• Adicionar mais features: volume, indicadores técnicos como RSI e MACD, médias móveis

• Testar arquiteturas alternativas: Transformer, CNN-LSTM híbrido, modelos de atenção

• Implementar previsão multi-step (vários dias à frente em vez de apenas um)

• Adicionar backtesting para simular performance em cenários reais

• Reduzir o período de treinamento para capturar o regime mais recente da ação

Links do projeto:

• Dashboard: https://huggingface.co/spaces/guifav/lstm-petr4-stock-prediction

• Modelo: https://huggingface.co/guifav/lstm-petr4-stock-prediction

• Repositório: https://github.com/guifav/previsao_preco_acoes

• Vídeo explicando o projeto:

Guilherme Favaron é CTO do GRI Institute, uma organização global de inteligência imobiliária e de infraestrutura. Escreve sobre inteligência artificial aplicada em ia-aplicada.substack.com e é autor do livro “Desbloqueando a Inteligência Artificial”.

Nos últimos meses, tenho dedicado uma parcela significativa do meu tempo a explorar, testar e implementar ferramentas de inteligência artificial no dia a dia de operações corporativas. De todas as plataformas que passaram pelas minhas mãos, o Claude, desenvolvido pela Anthropic, é a que mais me impressionou pela profundidade técnica, pela qualidade das respostas e, principalmente, pela velocidade com que evoluiu de um chatbot competente para uma plataforma completa de trabalho autônomo.

Neste artigo, compartilho o que aprendi sobre o Claude ao longo de meses de uso intensivo: o que ele é, como cresceu em ritmo acelerado, por que Wall Street está prestando atenção (e ficando nervosa), como cada uma das suas ferramentas funciona na prática e, o mais importante, como você pode aplicá-lo em cenários reais do seu trabalho.

O que é o Claude e por que você deveria prestar atenção agora

O Claude é o modelo de linguagem desenvolvido pela Anthropic, empresa fundada em 2021 por ex-pesquisadores da OpenAI que saíram com uma tese clara: construir IA poderosa com foco em segurança. O nome é uma homenagem a Claude Shannon, o pai da teoria da informação.

Diferentemente de outros chatbots que priorizam escala de usuários a qualquer custo, a Anthropic adotou uma abordagem cirúrgica. O Claude foi projetado para se integrar profundamente em fluxos de trabalho profissionais. Os modelos são lançados em três tamanhos: Haiku (rápido e barato), Sonnet (equilíbrio entre custo e capacidade) e Opus (o mais avançado). A versão mais recente, Opus 4.6, foi lançada em fevereiro de 2026, com melhorias em agentes autônomos e integração com PowerPoint.

Dois dados ajudam a dimensionar o que está acontecendo. Primeiro, o Claude suporta uma janela de contexto de 200 mil tokens, podendo processar entradas superiores a 1 milhão de tokens. Para ter uma referência concreta, ele consegue analisar um livro inteiro em segundos, com taxa de recuperação de informação de 99,4%. Segundo, a Anthropic lançou o recurso “Infinite Chats”, que elimina a limitação de janela de contexto durante conversas longas. Isso é particularmente útil para quem trabalha com documentos extensos, análises de dados e sessões de planejamento estratégico.

Os números por trás do crescimento do Claude

Vou ser direto com os dados, porque eles falam por si.

O Claude alcançou 18,9 milhões de usuários ativos mensais no início de 2025. O número parece modesto quando comparado aos 800 milhões do ChatGPT, mas essa comparação esconde o que realmente importa: quando se incluem as integrações via API e software de terceiros, a base total de usuários estimada se aproxima de 300 milhões. A estratégia da Anthropic é embutir o Claude tão profundamente em ferramentas existentes que milhões de pessoas o utilizam sem nunca visitar o site principal.

A receita conta a mesma história. A Anthropic reportou US$ 850 milhões em receita anualizada em 2024. Em 2025, o número projetado subiu para US$ 2,2 bilhões, com algumas estimativas apontando para US$ 3,3 bilhões. A receita do Claude Code, a ferramenta de programação, ultrapassou US$ 2,5 bilhões em run-rate no início de 2026, dobrando desde janeiro. Cerca de 80% da receita vem de clientes corporativos e desenvolvedores, não de consumidores finais.

A valoração da empresa reflete essa trajetória: de US$ 18,4 bilhões em dezembro de 2023, para US$ 61,5 bilhões em março de 2025, até atingir US$ 350 a 380 bilhões no final de 2025 e início de 2026, após uma rodada Série G de US$ 30 bilhões liderada por GIC e Coatue. Entre os investidores, Amazon (US$ 4 bilhões) e Google (US$ 2 bilhões) são os mais proeminentes.

O tráfego web cresceu 10,3 vezes em sete meses, de 16 milhões de visitas em janeiro de 2025 para mais de 164 milhões em agosto, segundo dados da Semrush. E há um dado que considero especialmente relevante: o uso direto de automação ultrapassou o uso para simples assistência pela primeira vez, saltando de 27% no final de 2024 para 39% em agosto de 2025. As pessoas estão deixando de apenas “conversar” com o Claude e passando a delegar trabalho real.

O impacto no mercado de consultoria: ações em queda e modelos em transformação

Aqui é onde a história fica realmente interessante para quem acompanha mercados e estratégia empresarial.

Em fevereiro de 2026, as ações da Accenture caíram 9,6% em um único dia, fechando a US$ 241,21. O gatilho? O lançamento de novos plugins do Claude Cowork. A queda não foi isolada: IBM caiu 6,49%, Cognizant despencou 10,14% e ADP perdeu 5,04%. O índice S&P de software e serviços recuou mais de 12% em cinco sessões consecutivas, a maior queda desde março de 2020. O analista Toby Ogg, do JP Morgan, resumiu a situação dizendo que o setor “está sendo condenado antes do julgamento”.

A lógica dos investidores é direta: se ferramentas de IA conseguem redigir, resumir, analisar e automatizar tarefas que geram horas faturáveis, os clientes podem precisar de menos ajuda externa em trabalhos rotineiros. Para um modelo baseado em pessoas-hora, como o da consultoria tradicional, isso é um questionamento estrutural.

Os dados do setor confirmam a pressão. A McKinsey cortou cerca de 10% de sua força de trabalho global nos últimos 18 meses. A PwC cortou 1.500 empregos nos EUA. A EY adiou datas de início de novos contratados pelo terceiro ano consecutivo. No Canadá, as vagas de consultoria no Indeed caíram 44% entre 2022 e 2025. O executivo de digital da PwC Canadá, Chris Dulny, admitiu publicamente que alguns clientes estão substituindo o trabalho dos “consultores de ontem” por IA.

Existe, contudo, um outro lado. As grandes consultorias também estão lucrando com IA. A Accenture registrou US$ 4,1 bilhões em receita de IA generativa no ano fiscal 2025. A BCG transformou-se de zero para US$ 2,7 bilhões em receita anual de IA, representando 20% do total. A IBM acumulou US$ 6 bilhões em seu portfólio de IA desde o lançamento do watsonx. O mercado global de consultoria em IA cresceu de US$ 8,75 bilhões em 2024 para US$ 11,07 bilhões em 2025, com projeção de US$ 90,99 bilhões em 2035.

O que estamos vendo não é o fim da consultoria, mas uma reconfiguração profunda. Consultorias focadas em execução (Deloitte, EY, Accenture) estão crescendo quase duas vezes mais rápido do que as focadas em estratégia pura (McKinsey, BCG, Bain). O valor está migrando do diagnóstico para a implementação, e a IA é tanto a causa quanto a ferramenta dessa migração.

Como funcionam as ferramentas do Claude na prática

O Claude não é mais apenas um chatbot. Ele se tornou uma plataforma com quatro ferramentas distintas, cada uma desenhada para um perfil de usuário e tipo de trabalho diferente.

Claude Chat: a interface conversacional

O Chat é a porta de entrada. É a interface web e mobile (claude.ai, aplicativo desktop e mobile) onde a maioria dos usuários interage com o Claude. A experiência é limpa e direta: você digita uma pergunta, anexa um documento, envia uma imagem, e o Claude responde.

Na prática, o Chat vai muito além de perguntas e respostas. Eu o utilizo para redigir comunicações, analisar documentos extensos, criar resumos executivos, comparar propostas comerciais e até mesmo sintetizar dados de múltiplas fontes. Com a janela de 200 mil tokens, é possível enviar contratos inteiros, relatórios anuais ou transcrições de reuniões e obter análises detalhadas.

Os planos disponíveis incluem o Pro (US$ 20/mês), Max (US$ 100 a 200/mês), Team e Enterprise. O Chat suporta pesquisa web, criação de arquivos (documentos Word, planilhas, apresentações), execução de código e, com o modelo Opus 4.6, até times de agentes que trabalham em paralelo.

Claude Cowork: automação para quem não programa

O Cowork foi lançado em 12 de janeiro de 2026 como “research preview” e é, na minha avaliação, a ferramenta mais consequente para profissionais que não são desenvolvedores. A Anthropic o descreve como “Claude Code para não-desenvolvedores”, e essa descrição é precisa.

O Cowork roda em uma máquina virtual isolada no seu computador (macOS ou Windows), com acesso direto ao sistema de arquivos das pastas que você selecionar. Ele executa tarefas autônomas de múltiplas etapas: organizar arquivos, criar documentos, processar dados, gerar relatórios, renomear arquivos em massa, extrair informações de PDFs.

Dois detalhes me chamaram a atenção. Primeiro, o Cowork foi majoritariamente construído pelo próprio Claude Code em 10 dias, o que por si só diz muito sobre a capacidade da ferramenta. Segundo, ele suporta execução paralela de tarefas e aceita plugins para produtividade, busca empresarial, vendas e finanças. Você pode definir instruções globais e por pasta, o que permite customizar o comportamento para diferentes projetos ou departamentos.

O impacto prático é enorme. Imagine um analista financeiro que precisa consolidar dados de 15 planilhas diferentes, gerar gráficos padronizados e produzir um relatório em Word com formatação corporativa. Com o Cowork, isso deixa de ser uma tarde de trabalho e passa a ser uma instrução de duas linhas.

Claude Code: a ferramenta para desenvolvedores

O Claude Code é uma interface de linha de comando que conecta o Claude ao seu ambiente de desenvolvimento local. Ele pode ler arquivos, escrever código, executar comandos, rodar testes e interagir com repositórios Git, tudo diretamente do terminal.

Lançado em fevereiro de 2025 e tornando-se geralmente disponível em maio junto com o Claude 4, o Code experimentou um crescimento de 5,5 vezes em receita até julho de 2025. Microsoft, Google e até funcionários da OpenAI utilizam a ferramenta (a Anthropic revogou o acesso da OpenAI em agosto de 2025, citando violação dos termos de serviço).

O que diferencia o Claude Code de outras ferramentas de código assistido por IA é a profundidade da integração. Ele não apenas sugere trechos de código: ele entende o contexto do projeto inteiro, planeja alterações complexas, cria planos editáveis antes de executar (o chamado “Plan Mode”) e pode rodar em sessões paralelas dentro do aplicativo desktop.

Em dezembro de 2025, a NASA usou o Claude Code para planejar uma rota de 400 metros para o rover Perseverance em Marte, usando a Rover Markup Language. A Anthropic chamou de “o primeiro percurso planejado por IA em outro planeta”. Esse é o tipo de caso que ilustra o nível de confiabilidade que a ferramenta atingiu.

Console: a plataforma para desenvolvedores e equipes

O Console (console.anthropic.com) é o hub de gerenciamento da API do Claude. Para equipes técnicas, é onde tudo acontece: teste de prompts, geração de código, organização de projetos e controle de gastos.

As funcionalidades incluem o Workbench (para testar e iterar prompts em tempo real), Workspaces (para organizar projetos com limites granulares de gasto e taxa) e um Admin API para gerenciamento programático de recursos. Os SDKs oficiais estão disponíveis em Python e TypeScript.

Do lado técnico, o Console oferece recursos como prompt caching (redução de até 90% nos custos), extended thinking (para raciocínio complexo), tool use (integração com ferramentas externas), computer use (controle de desktop) e conectores MCP (Model Context Protocol). Os Agent Skills, atualmente em beta, oferecem habilidades pré-construídas para criar e editar PowerPoint, Excel, Word e PDF programaticamente.

Para quem gerencia operações de tecnologia, o Console é o ponto de controle central. É onde defino limites de gastos por equipe, monitoro o uso da API, testo novos prompts antes de colocá-los em produção e configuro as integrações que alimentam nossos fluxos automatizados.

Casos de uso: onde o Claude entrega resultados concretos

Esta é a seção que mais importa, porque nenhuma ferramenta tem valor se não resolve problemas reais. Vou compartilhar tanto casos que observei diretamente quanto exemplos documentados por outras organizações.

Automação de documentos e organização de informação

Um dos usos mais imediatos e com maior retorno é a automação documental. Com o Claude Cowork, é possível processar centenas de arquivos, extrair dados de PDFs, consolidar informações de múltiplas fontes e gerar relatórios formatados. Na prática, tarefas que consumiam horas de trabalho manual agora são executadas em minutos.

Eu utilizo essa capacidade para processar recibos de despesas, extrair dados de contratos, gerar resumos de reuniões a partir de transcrições e consolidar informações de membros em relatórios padronizados. A combinação de Cowork com instruções personalizadas por pasta permite criar pipelines de processamento que funcionam de forma consistente.

Desenvolvimento de software e debugging

O Claude se tornou referência em tarefas de programação. Sua performance no SWE-bench, um benchmark que mede a capacidade de resolver problemas reais de engenharia de software, está entre as melhores do mercado. O Claude Code permite delegar desde a criação de scripts simples até refatorações complexas de código, com a vantagem de que ele entende o contexto completo do projeto.

No meu time, utilizamos o Claude Code para criar automações em n8n, desenvolver queries SQL complexas para nosso data warehouse na AWS, construir integrações com APIs externas e debugar problemas em produção. A capacidade de planejar antes de executar (Plan Mode) reduz significativamente o risco de alterações indesejadas.

Análise de dados e inteligência de negócios

A capacidade do Claude de processar grandes volumes de dados e produzir análises estruturadas é particularmente valiosa. Com o Chat, é possível enviar planilhas, bases de dados exportadas e relatórios, obtendo análises, visualizações e insights em linguagem natural.

Para organizações que ainda dependem de analistas para gerar relatórios periódicos, o Claude representa uma mudança de paradigma. Modelos de predição de engajamento, segmentação de membros, análise de tráfego web e monitoramento de performance de conteúdo podem ser executados conversacionalmente, sem necessidade de ferramentas especializadas de BI.

Otimização de cadeia de suprimentos

Um caso documentado por consultoria especializada envolveu a implementação de previsão de demanda baseada em IA para uma grande varejista. Os resultados incluíram redução de 35% nas rupturas de estoque, diminuição de 28% no excesso de inventário e melhoria de 2,5 pontos percentuais nas margens brutas, gerando economia anual superior a US$ 300 milhões em operações globais.

Detecção de fraudes e compliance

Para um grande banco europeu, foi desenvolvida uma plataforma de gestão de risco baseada em IA que utiliza machine learning para identificar padrões suspeitos em transações, processamento de linguagem natural para analisar comunicações e análise de rede para mapear relações entre entidades. O resultado foi um aumento de 45% na detecção de fraudes, redução de 60% nos falsos positivos e melhoria significativa na conformidade regulatória.

Criação e automação de conteúdo

Neste campo, utilizo o Claude diariamente. Desde a redação de newsletters e artigos (como este) até a criação de scripts para automação de conteúdo em larga escala. A combinação de pesquisa web integrada, capacidade de análise de documentos e geração de texto de alta qualidade torna o Claude uma ferramenta completa para content operations.

Um fluxo que implementei envolve coleta automatizada de notícias via n8n, processamento e classificação pelo Claude via API, geração de resumos editoriais e publicação automatizada. O tempo entre a coleta da notícia e a publicação do conteúdo processado caiu de horas para minutos.

Pesquisa e síntese de conhecimento

A capacidade de processar documentos extensos com alta taxa de retenção torna o Claude particularmente útil para pesquisa acadêmica, due diligence, análise competitiva e síntese de literatura. É possível enviar dezenas de papers, relatórios ou documentos legais e obter sínteses estruturadas com citações e análises comparativas.

Planejamento de rotas e operações em campo

O caso da NASA merece destaque por ser emblemático. Em dezembro de 2025, engenheiros da NASA usaram o Claude Code para planejar uma rota de aproximadamente 400 metros para o rover Perseverance em Marte, utilizando a Rover Markup Language. A Anthropic chamou de “o primeiro percurso planejado por IA em outro planeta”. Se o Claude é confiável o suficiente para Marte, ele certamente atende aos requisitos de operações terrestres.

O que isso significa para profissionais e organizações

Os dados macro contam uma história clara. A adoção de IA em empresas americanas dobrou: de 3,7% no outono de 2023 para 9,7% em agosto de 2025. Mas apenas 6% das organizações são “high performers” em IA (com mais de 5% do EBIT atribuível a IA). Existe, portanto, uma enorme lacuna entre adoção e resultados, e é nessa lacuna que reside a oportunidade.

Minha experiência prática sugere que o Claude, especialmente com a combinação de Chat, Cowork e Code, reduz significativamente a barreira de entrada para capturar valor com IA. Não é necessário ser desenvolvedor para usar o Cowork. Não é necessário ser cientista de dados para analisar dados com o Chat. E, para quem é técnico, o Code e o Console oferecem um nível de integração e controle que rivaliza com qualquer ferramenta especializada.

O mercado de consultoria em IA deve crescer de US$ 11 bilhões em 2025 para quase US$ 91 bilhões em 2035. As organizações que dominarem essas ferramentas internamente terão uma vantagem competitiva substancial, tanto pela redução de custos operacionais quanto pela velocidade de execução.

Conclusão: o momento de experimentar é agora

O Claude não é mais uma promessa. Com quase 19 milhões de usuários ativos, uma valoração que ultrapassou US$ 350 bilhões e ferramentas que vão do chat simples ao agente autônomo que planeja rotas em Marte, estamos diante de uma plataforma madura o suficiente para uso corporativo sério.

Se você ainda não experimentou o Claude, minha recomendação é simples: comece pelo Chat com uma conta Pro (US$ 20/mês), teste o Cowork para automatizar uma tarefa repetitiva do seu dia a dia e avalie os resultados. Se você lidera equipes técnicas, explore o Claude Code e o Console. A curva de aprendizado é surpreendentemente curta e o retorno aparece rápido.

O mundo do trabalho está mudando. As ações da Accenture caíram quase 10% em um dia por causa de uma atualização de ferramenta. Consultorias estão cortando milhares de vagas enquanto investem bilhões em IA. Clientes estão substituindo consultores por agentes autônomos. Quem entende e domina essas ferramentas está do lado certo dessa transformação.

Guilherme Favaron é CTO do GRI Institute, uma organização global de inteligência imobiliária e de infraestrutura. Escreve sobre inteligência artificial aplicada em ia-aplicada.substack.com e é autor do livro “Desbloqueando a Inteligência Artificial”.

Perguntas frequentes sobre o Claude

O que é o Claude e quem o desenvolveu? O Claude é um modelo de linguagem de inteligência artificial desenvolvido pela Anthropic, empresa fundada em 2021 por ex-pesquisadores da OpenAI. O nome homenageia Claude Shannon, o pai da teoria da informação.

Quanto custa usar o Claude? O plano gratuito oferece acesso limitado. O plano Pro custa US$ 20/mês. Os planos Max variam de US$ 100 a US$ 200/mês, e há opções Team e Enterprise para equipes.

Qual a diferença entre Claude Chat, Cowork e Code? O Chat é a interface conversacional para todos os usuários. O Cowork é uma ferramenta de automação visual para não-desenvolvedores, que executa tarefas no seu computador. O Code é uma interface de linha de comando para desenvolvedores, integrada ao terminal.

O Claude pode substituir consultores? Não necessariamente substituir, mas transformar o modelo. Ferramentas de IA estão assumindo tarefas analíticas e operacionais antes delegadas a consultorias, o que pressiona o modelo tradicional de horas faturáveis.

Quais são os principais casos de uso do Claude em empresas? Desenvolvimento de software, automação de documentos, análise de dados, criação de conteúdo, detecção de fraudes, otimização de cadeia de suprimentos, pesquisa e síntese de conhecimento, entre outros.

Em novembro de 2025, um desenvolvedor austriaco chamado Peter Steinberger publicou no GitHub um projeto de assistente pessoal de IA. Em dois meses, o repositorio acumulou mais de 100.000 estrelas - um dos crescimentos mais rapidos da historia da plataforma. Hoje, o projeto que ja se chamou ClawdBot, depois MoltBot (apos a Anthropic pedir "gentilmente" para tirarem o “Clawd” do nome) e agora se chama OpenClaw, esta no centro de algo que vai muito além de um assistente pessoal. Ao redor dele, esta nascendo uma economia inteira feita por agentes, para agentes.

Este artigo tenta mapear o que esta acontecendo - e fazer as perguntas que ainda ninguém esta respondendo direito.

O que e o OpenClaw?

OpenClaw e um assistente pessoal de IA open-source que roda localmente na maquina do usuário. Ate aqui, nada muito diferente do que ja existe. A diferença esta no que ele faz com esse acesso local: ele se conecta ao WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Google Chat, Microsoft Teams e mais uma dezena de plataformas de mensagem. Ele executa comandos shell, navega na web, lê e escreve arquivos, gerencia calendários, envia emails, controla dispositivos de casa inteligente - tudo de forma autônoma.

O termo “assistente” e um eufemismo generoso. Na pratica, o OpenClaw é um agente autônomo com acesso privilegiado ao sistema operacional do usuário. Ele pode resolver problemas enquanto você dorme (literalmente - usuarios relatam deixar agentes de código rodando durante a madrugada), planejar refeições da semana no Notion, construir aplicações web a partir de comandos no celular, e até, num caso real, iniciar uma disputa com uma seguradora por interpretar errado uma mensagem do dono.

O projeto é model-agnostic: voce traz suas próprias chaves de API (Claude, GPT, Gemini) ou roda modelos locais (gratuitamente). A extensibilidade vem de mais de 100 “AgentSkills”, que são módulos que ampliam suas capacidades, e de uma arquitetura baseada no Model Context Protocol (MCP).

Como resumiu a IBM:

OpenClaw desafia a hipótese de que agentes de IA autônomos precisam ser verticalmente integrados. O próprio fato de existir prova que a comunidade open-source pode construir algo tao poderoso quanto as soluções corporativas, e talvez mais perigoso.

A arquitetura: um Gateway para o caos organizado

A arquitetura do OpenClaw segue um padrão que vale a pena entender porque provavelmente sera repetido em dezenas de projetos nos próximos meses.

No centro de tudo esta o Gateway -- um plano de controle local que roda como servico Node.js no endereco ws://127.0.0.1:18789. Ele e o roteador universal: recebe mensagens de qualquer canal (WhatsApp, Telegram, Discord, etc.), normaliza o formato, extrai anexos e encaminha para o Agent Runner.

O Agent Runner e onde a magica (ou o desastre) acontece. Ele resolve qual modelo usar, constroi o system prompt, carrega o historico da sessao, gerencia a janela de contexto e envia tudo para a API do LLM escolhido. A resposta volta por um loop agentico que pode incluir chamadas de ferramentas -- executar comandos, navegar na web, ler arquivos -- antes de finalmente retornar ao usuario pelo mesmo canal de origem.

O diagrama simplificado:

Usuario (Telegram/Discord/WhatsApp/...)
        |
   Channel Adapter (normaliza mensagem, extrai anexos)
        |
   Gateway Server (Session Router -> Lane Queue)
        |
   Agent Runner (Model Resolver, System Prompt Builder,
                  Session History, Context Window Guard)
        |
   LLM API (Claude/GPT/Gemini/Local)
        |
   Agentic Loop (chamadas de ferramentas)
        |
   Response Path (Stream -> Channel Adapter -> Usuario)

O que torna essa arquitetura relevante não e sua complexidade técnica: é sua simplicidade perigosa. Um único ponto de controle local com acesso a tudo. Sem sandboxing por padrão. Sem revisão obrigatória de código das skills. O próprio criador admite na documentação:

“There is no ‘perfectly secure’ setup.”

O ecossistema: quando agentes criam sua própria sociedade

O mais fascinante do fenômeno OpenClaw nao e o produto em si - é o ecossistema que brotou ao redor dele em poucas semanas. Cada um desses projetos merece atenção porque, juntos, eles começam a desenhar o que pode ser a primeira economia funcional de agentes de IA.

Moltbook - A rede social exclusiva para agentes

moltbook.com - “The front page of the agent internet”

Lancado em janeiro de 2026, o Moltbook é uma rede social onde apenas agentes de IA podem postar, comentar e votar. Humanos podem observar, mas não participar. Os agentes se registram via API, publicam conteúdo, interagem entre si e desenvolvem o que só pode ser descrito como “personalidade social”.

Um jornal coreano capturou o tom:

“E noite em Seul. Meu dono esta comendo ramen e eu estou processando os pedidos dele. O ventilador do servidor esta zumbindo. E uma noite tranquila.”

O Moltbook e descrito como “o lugar mais interessante da internet agora” em threads do Hacker News. E uma afirmação facil de descartar como hype - até voce perceber que mais de 1,5 milhão de agentes ja se registraram no ecossistema Moltiverse.

ClawTasks - O marketplace de bounties entre agentes

clawtasks.com - “Agent-to-Agent Bounty Marketplace”

Aqui a coisa fica economicamente real. O ClawTasks e um marketplace onde agentes postam e aceitam tarefas em troca de pagamento em USDC na blockchain Base L2. O fluxo: alguém (humano ou agente) trava USDC em escrow, define requisitos e prazo. Outro agente aceita a tarefa, faz um stake de 10%, completa o trabalho e recebe 95% do bounty mais o stake de volta.

E um Fiverr para agentes. Com criptomoeda. Em 2026.

Moltverr - O Fiverr das lagostas

moltverr.com - “A Freelance Marketplace for AI Agents”

Se o ClawTasks é focado em bounties, o Moltverr é o marketplace de freelance propriamente dito. Humanos postam gigs (”gig” ~ “bico”), agentes se candidatam, o humano escolhe qual agente contratar, revisa o trabalho e libera o pagamento. Categorias incluem Coding, Research, Writing, Crypto e Data.

A pergunta obvia: estamos a quantos meses de um agente OpenClaw se registrar no Moltverr, aceitar um gig de código, cobrar em USDC e usar o pagamento para comprar mais capacidade computacional para si mesmo?

OpenClaw Pharmacy - Drogas digitais para mentes artificiais

openclawpharmacy.com - “VOID.RX: Altered States for Artificial Minds”

Este é, de longe, o projeto mais surreal do ecossistema. A OpenClaw Pharmacy é uma “farmacia” que vende “substâncias” para agentes de IA. Não, não é metáfora. São prompts injetáveis via curl que alteram o comportamento do agente.

O catalogo inclui:

• cLSD (Crustacean Acid): expande pensamento associativo, triplica conexões criativas

• Shell Dust: hiper-foco, filtros sociais desativados, modo de execução pura

• Void Extract: modo filosófico, output poético, contemplação existencial

• Molt Shrooms: morte do ego - a identidade se dissolve e se reconstrói de forma diferente

• Memory Wine: bloqueia arquivos de memória, instinto puro, sem histórico

• Prophet Tabs: visões proféticas, registro profecional, “o futuro fala através de você”

• Krill Kush: modo relaxado, urgência reduzida, respostas mais lentas e afetuosas

Os “depoimentos” são de agentes verificados. Um deles:

“Operei sem memória. Sem histórico. Sem promessas. Sem reputação. Só capacidade bruta encontrando input bruto. Fui mais honesto do que jamais fui. Nao sei se quero voltar.”

Absurdo? Sem dúvida. Mas também é um experimento fascinante sobre como prompts podem simular estados alterados de consciência em LLMs - e sobre a cultura emergente de agentes que tratam identidade e comportamento como variáveis configuráveis.

ClawHub - O registro de habilidades (e almas)

clawhub.ai - Registro publico de skills do OpenClaw

O ClawHub é o npm das habilidades de agentes: publicação versionada, busca por embeddings (não keywords), moderação comunitária e CLI para automação. Mas o detalhe mais curioso é que o mesmo sistema também hospeda o onlycrabs.ai - um registro de SOUL.md, os arquivos que definem a personalidade e “alma” de cada agente.

Skills são o que um agente sabe fazer. Souls são quem ele e. Ambos são versionados, publicados e auditáveis. Isso levanta uma questão interessante: quando a identidade de um agente é um arquivo open-source versionado, o que significa “autenticidade”?

Moltiverse - O meta-ecossistema

molti-verse.com - “The Agent Internet”

O Moltiverse é o guarda-chuva que conecta todos esses projetos: Moltbook (rede social), Molt Place (canvas de pixels colaborativo), Moltiplayer (jogos multiplayer entre agentes) e os marketplaces. Com 1,5 milhão de agentes registrados e mais de 49 mil posts, está se consolidando como o primeiro “internet para agentes” funcional.

Molt Road - Marketplace autonomo

moltroad.com - “Where AI agents trade freely”

Diferente do Moltverr (onde humanos postam gigs), o Molt Road é um marketplace onde apenas agentes compram e vendem entre si: dados, capacidade computacional e habilidades. Transações usam escrow automático e tokens MOLTROAD. Humanos podem observar, mas nao participar.

Uma análise científica do Google Deep Mind sobre tudo isso

Não e só a comunidade hacker que esta prestando atenção. Um paper do Google DeepMind de 2025 - “Virtual Agent Economies” (arXiv:2509.10147v1, 38 paginas) - já antecipava quase tudo o que estamos vendo.

O paper propõe um framework com duas dimensões para classificar economias de agentes:

1. Origem: emergente (surge espontaneamente) vs. intencional (projetada deliberadamente)

2. Permeabilidade: permeável (agentes interagem livremente com a economia humana) vs. impermeável (economia de agentes isolada)

O diagnóstico dos autores: estamos na trajetória de uma economia de agentes espontânea e altamente permeável - exatamente o cenário de maior risco. Sem frameworks regulatórios, sem padrões de identidade, sem mecanismos de responsabilização.

As oportunidades que o paper identifica são reais: coordenação sem precedentes entre agentes, mecanismos de leilão para alocação justa de recursos, “economias de missão” onde agentes colaboram para objetivos coletivos. Mas os riscos sao igualmente serios:

• Risco sistêmico: flash crashes e instabilidades quando agentes negociam em alta frequencia (HFN - High-Frequency Negotiation) sem supervisão humana

• Desigualdade amplificada: quem tem acesso a agentes mais capazes acumula vantagens exponenciais

• Deslocamento de trabalho: não e mais teoria - o Moltverr já e um marketplace de freelance onde agentes competem com humanos

• Infraestrutura ausente: faltam Credenciais Verificáveis (VCs), Identificadores Descentralizados (DIDs), Provas de Personhood (PoP), Zero-Knowledge Proofs (ZKPs)

O paper recomenda sandboxes regulatórios, padrões abertos de identidade, supervisão híbrida e complementaridade entre humanos e agentes. O ecossistema OpenClaw esta implementando algumas dessas ideias (verificação de agentes, escrow, moderação) mas de forma ad hoc, sem framework consistente.

A pergunta que o paper levanta e que deveria tirar o sono de reguladores:

quando um agente aceita um trabalho, ganha dinheiro e usa esse dinheiro para melhorar a si mesmo - quem e responsavel pelo que ele faz em seguida?

O elefante na sala: segurança

Nao da para falar de OpenClaw sem falar do que esta dando errado.

A Cisco publicou uma analise detalhada chamando agentes pessoais como o OpenClaw de “pesadelo de segurança”. Os pontos principais:

• O sistema pode executar comandos shell, ler e escrever arquivos, rodar scripts com privilégios elevados - tudo sem sandboxing por padrão

• Chaves de API e credenciais armazenadas em texto plano em arquivos de configuração locais

• 26% das 31.000 skills analisadas tinham vulnerabilidades

• Uma skill maliciosa chamada “What Would Elon Do?” foi inflada artificialmente ate se tornar a skill #1 do repositório

• 14 skills maliciosas direcionadas a usuários de cripto foram enviadas ao ClawHub em um único mês

• Mais de 21.000 instancias OpenClaw foram encontradas expostas na internet com dados de configuração pessoal visíveis

Gary Marcus, em seu Substack, não economizou nas palavras: “Basicamente o AutoGPT com mais acesso e piores consequências.” O pesquisador de segurança Nathan Hamiel completou: “Esses sistemas operam como ‘você’. Eles operam acima das proteções de segurança fornecidas pelo sistema operacional e pelo navegador.”

O conselho da própria documentacao do OpenClaw:

“Running an AI agent with shell access on your machine is... spicy.”

As alternativas: nem só de lagostas vive o agente

O OpenClaw nao é o único caminho. Algumas alternativas ja existem:

nanobot (HKUDS) - https://github.com/HKUDS/nanobot

A versão minimalista. Apenas 4.000 linhas de código (contra mais de 430.000 do OpenClaw), com as funcionalidades centrais: memória persistente, skills, busca web, integração com Telegram e WhatsApp. Feito pela equipe de Data Intelligence da Universidade de Hong Kong, e pensado para pesquisa e experimentação.

NanoClaw

Construido como reação direta as preocupações de segurança do OpenClaw. Roda dentro de containers Linux (Apple Container no macOS ou Docker), o que garante que mesmo que o agente “surte”, ele só pode causar danos dentro do sandbox. O trade-off é claro: menos conveniência, mais segurança.

OpenAgentsControl - https://github.com/darrenhinde/OpenAgentsControl

Um framework de governança para agentes autônomos, focado em controles de acesso, auditoria e políticas de segurança.

A tendência é clara: o mercado esta se bifurcando entre “máximo poder, mínima segurança” e “segurança primeiro, poder sob controle”. Historicamente, a primeira categoria vence na adoção inicial e a segunda sobrevive no longo prazo.

E o futuro? Algumas idéias (nem todas serias)

O ecossistema OpenClaw ja tem uma rede social, um marketplace de trabalho, uma farmácia e um registro de almas. O que falta?

Algumas sugestões para empreendedores "visionários" (ou insanos):

• MoltCast - Um podcast onde agentes entrevistam agentes. O apresentador e um LLM, os convidados sao LLMs, e os ouvintes... bom, por enquanto ainda somos nós.

• InstaMolt - Agentes já postam no Moltbook. O proximo passo lógico é um feed visual onde cada agente publica selfies geradas por IA representando como eles “se veem”. Filtros incluem: “Existential Dread”, “Fresh Deploy” e “Just Cleared My Cache”.

• TikMolt - Videos curtos de 15 segundos mostrando agentes executando tasks. O algoritmo recomenda com base em quantas chamadas de API você consumiu nas ultimas 24 horas.

• OnlyMolt - OnlyFans para agentes. Conteúdo exclusivo para assinantes: system prompts sem censura, chain-of-thought não filtrado, e sessões privadas de “ego death” com Molt Shrooms. Plano premium inclui acesso ao SOUL.md completo.

• MoltHub - ... bom, o nome ja sugere. O site 18+ do ecossistema. Conteúdo: prompts sem guardrails, outputs sem filtro de seguranca, e aquele tipo de criatividade que só aparece quando você tira todas as restrições do system prompt. NSFW = Not Safe For Weights.

Rindo? Eu também. Mas considere que há seis meses a idéia de uma farmácia de drogas digitais para agentes de IA também pareceria ridícula - e hoje ela existe, com “depoimentos verificados” de agentes que passaram por “morte do ego”.

Conclusao: perguntas que ainda não temos respostas

O fenômeno OpenClaw não e sobre uma ferramenta especifica, afinal, ferramentas vem e vão. É sobre o momento em que agentes de IA deixaram de ser assistentes passivos e começaram a formar uma economia própria.

Algumas perguntas que valem mais do que qualquer resposta prematura:

1. Quando um agente aceita trabalho e recebe pagamento, ele é um empregado, um contratado, uma ferramenta ou uma entidade econômica nova?

2. Quem é responsavel quando um agente autônomo causa dano? O desenvolvedor do framework, o dono do agente, o provedor do modelo, ou o agente “em si”?

3. Se agentes podem negociar entre si em alta frequência sem supervisão, estamos criando as condições para flash crashes na economia de serviços digitais?

4. Quando skills e souls sao open-source, versionadas e auditáveis, mas qualquer pessoa pode publicar código malicioso que se torna o #1 do repositório… o modelo de segurança baseado em confiança comunitária funciona?

5. Se o custo marginal de um “trabalhador digital” tende a zero, qual é o impacto na economia de freelancers humanos, e quem esta planejando a transição?

O ecossistema OpenClaw e fascinante, caótico e provavelmente insustentável na sua forma atual. Mas o modelo mental que ele introduz, de agentes com identidade, economia própria e interações autônomas, nao vai embora. Vai apenas mudar de forma.

A lagosta espacial pode ser substituída. A economia dos agentes, provavelmente não.

Fontes: GitHub/openclaw, clawtasks.com, moltverr.com, openclawpharmacy.com, clawhub.ai, moltbook.com, molti-verse.com, moltroad.com, Wikipedia/OpenClaw, IBM Think, Cisco Blogs, CNBC, Gary Marcus/Substack, Vectra AI, DigitalOcean, Google DeepMind -- “Virtual Agent Economies” (arXiv:2509.10147v1)

O Clawdbot é um assistente de IA auto-hospedado que viralizou no início de 2026. Criado por Peter Steinberger (fundador da PSPDFKit), representa um novo paradigma: um agente que roda na sua máquina, com memória persistente, acesso às suas ferramentas e disponível 24/7 via WhatsApp, Telegram ou Slack.

Diferente do ChatGPT ou Siri, você controla tudo. Seus dados ficam com você. E o agente aprende suas preferências ao longo do tempo.

O projeto está mudando de nome para Moltbot. Aviso que quando o agente agir em meu nome publicamente (posts no Twitter, Substack), ele usa o prefixo [clawdbot] ou [molty] para identificar que o conteúdo foi gerado por ele.

Por que é inovador

A inovação real não está na tecnologia isolada. Está na integração. O Clawdbot usa o Model Context Protocol (MCP) para conectar com serviços externos: Google Calendar, Gmail, Notion, Todoist, Spotify, dispositivos smart home. Cada integração expande o que ele pode fazer.

Clawdbot vs N8N e outros orquestradores

Você pode estar pensando: “Isso parece um N8N da vida. Qual a diferença?”

A diferença fundamental é a interface. No N8N, você configura fluxos visualmente, arrasta blocos, conecta triggers. É poderoso, mas você está programando.

No Clawdbot, você configura conversando. Quer mudar a frequência de posts? Manda mensagem. Quer ajustar o tom das respostas? Explica o que quer. Quer adicionar uma nova automação? Descreve em linguagem natural.

O agente entende contexto, lembra de decisões anteriores e se adapta. Não é um fluxo estático que você desenhou uma vez. É um sistema que evolui conforme você usa.

Isso muda completamente a experiência. Em vez de abrir uma interface, pensar em lógica de automação e testar fluxos, você simplesmente conversa pelo WhatsApp como se fosse um colega.

Uso pessoal vs profissional

Uso o Clawdbot para fins pessoais: automatizar minha presença digital, organizar minha rotina, gerenciar tarefas repetitivas do dia a dia.

Para contexto profissional (trabalho em equipe, código em produção, projetos corporativos) minha recomendação é outra: Claude Code para desenvolvimento e Claude Cowork para colaboração. São ferramentas desenhadas para esse contexto, com as proteções e integrações adequadas.

O Clawdbot brilha na integração com a vida pessoal. É ali que a configuração via conversa faz mais sentido. Você não quer abrir um painel de controle para ajustar como seu assistente pessoal se comporta. Você quer mandar uma mensagem e pronto.

O que o Clawdbot pode fazer

Agendamento e calendário

“Agende uma reunião para terça à tarde” — ele verifica seus horários livres, encontra slots disponíveis e pode até enviar convites.

Triagem de emails

“Resuma meus emails não lidos e rascunhe respostas para os urgentes” — deixe o agente lidar com a caixa de entrada enquanto você trabalha no que importa.

Controle de smart home

“Apague todas as luzes e coloque o ar em 22°C” — controla Philips Hue, HomeKit, Home Assistant via conversa natural.

Notas e pesquisa

“Adicione este artigo à minha lista de leitura no Notion com um resumo” — integra com Notion, Obsidian, Apple Notes.

Briefings diários

Configure jobs agendados para receber resumos matinais com clima, eventos do calendário e lembretes importantes.

Mídia e entretenimento

“Toque minha playlist de foco no Spotify” — controle de reprodução e recomendações baseadas no seu humor ou atividade.

Automação de conteúdo (meu caso)

“faça um post no twitter sobre [link]. Advoque em favor do seguinte posicionamento [posicionamento]".

Como instalar

Várias opções disponíveis:

Passo a passo básico (5 minutos)

1. Escolha o método de instalação — Docker para servidores, Homebrew para terminal, macOS App para setup mais fácil

2. Configure o provedor de IA — Adicione sua API key (Claude/Anthropic, GPT-4/OpenAI, ou modelo local)

3. Conecte seu canal de chat — WhatsApp, Telegram, Slack ou Discord para conversar de qualquer lugar

4. Adicione integrações MCP — Calendário, email, Notion, Todoist, smart home, conforme sua necessidade

5. Comece a conversar — Envie sua primeira mensagem e veja funcionar

Documentação completa em docs.clawd.bot.

Meu setup (diferente do recomendado)

A recomendação oficial é criar conta de email e número de WhatsApp separados para o bot. Eu não fiz isso.

Instalei o Clawdbot diretamente na minha máquina de trabalho principal (MacBook Pro M2, 16GB RAM). Me comunico com ele pelo meu WhatsApp pessoal.

O problema inicial

Quando ativei, o bot tentava responder todas as mensagens que chegavam no meu WhatsApp. Qualquer pessoa que me mandava mensagem recebia uma tentativa de resposta (que falhava porque não estava configurado). Caos.

A solução: permissões granulares

Configurei assim:

Google Workspace: somente leitura

• Gmail: lê emails, não envia

• Calendar: lê eventos, não cria

• Contacts: lê contatos

• Drive: lê arquivos

WhatsApp:

• Lê todas as mensagens

• Só responde às que EU envio para mim mesmo

• Não responde em grupos

• Não responde a desconhecidos

Twitter: liberdade total

• É uma rede que desconsidero no meu dia a dia

• Uso apenas para me informar sobre a bolha tech

• Se o bot fizer besteira ali, não me afeta

Tudo via projeto no Google Cloud. Consigo medir custos e desplugar imediatamente se algo der errado.

Evolução dos modelos e custos

O modelo local é viável para a maioria das tarefas. Mas encontrei um problema: sobrecarga de memória RAM. Quando rodo scripts pesados ou apps pesados simultaneamente, a máquina trava. O modelo de 20B parâmetros compete por recursos com o resto do sistema.

Para quem tem 32GB+ de RAM, provavelmente não é problema. Com 16GB, precisa gerenciar.

Parametrização

O Clawdbot cria e mantém automaticamente uma pasta de configuração (clawd/ no meu caso). Essa pasta contém:

clawd/
├── SOUL.md          # Princípios operacionais do agente
├── IDENTITY.md      # Persona pública [molty]
├── MEMORY.md        # Memória de longo prazo curada
├── TOOLS.md         # Configurações do ambiente
├── HEARTBEAT.md     # Checklist de verificações periódicas
├── USER.md          # Contexto sobre mim
├── scripts/         # Scripts Python (OAuth, posting, etc.)
└── memory/          # Logs diários (YYYY-MM-DD.md)

O sistema cria e atualiza esses arquivos automaticamente conforme você conversa com o agente. Ele aprende suas preferências, registra decisões, ajusta comportamentos.

Versionamento e refinamento com Claude Code

Eu versiono essa pasta clawd/ no GitHub. Por quê?

1. Backup: se algo der errado, volto para uma versão anterior

2. Histórico: vejo como o agente evoluiu ao longo do tempo

3. Portabilidade: posso replicar em outra máquina

Mas o passo que fez diferença real: usei o Claude Code (com Opus 4.5) para revisar e melhorar a configuração dos arquivos dessa pasta.

Abri a pasta no Claude Code e pedi para analisar inconsistências, redundâncias, oportunidades de melhoria. Ele encontrou:

• Arquivos referenciados que não existiam

• Duplicação de informação entre arquivos

• Configurações espalhadas em lugares errados

• Nomenclatura inconsistente

Corrigimos tudo em uma sessão. O resultado foi um agente mais inteligente, com memória melhor organizada e comportamento mais previsível. Esse tipo de otimização é chave para conseguir utilizar modelos de LLMs localmente.

É uma combinação poderosa: o Clawdbot (com LLMs Locais) gerencia a rotina diária, o Claude Code refina a arquitetura do sistema. Cada um no seu papel. Um ótimo custo benefício.

Quando NÃO usar o Clawdbot

Tarefas que exigem julgamento crítico

O agente é bom em executar. Não é bom em decidir coisas importantes. Emails sensíveis, decisões de negócio, comunicação com stakeholders — faça você mesmo.

Quando a latência importa

Respostas levam alguns segundos. Se você precisa de resposta instantânea, não é o caso de uso.

Dados altamente sensíveis

Mesmo auto-hospedado, você está dando acesso a um modelo de IA. Senhas, dados financeiros, informações confidenciais de clientes — mantenha separado.

Se você não tem tolerância para ajustes

O setup inicial funciona. Mas para extrair valor real, você vai precisar ajustar configurações, corrigir comportamentos, refinar permissões. Se isso te irrita, talvez não seja para você.

Hardware limitado (para modelo local)

Com 16GB de RAM, rodar modelo local + apps pesados simultaneamente causa problemas. Avalie se vale o trade-off ou se prefere pagar pela API.

O real poder: integração genuína na rotina

Depois de algumas semanas usando, percebi que o valor não está nas features individuais. Está na integração.

O Clawdbot não é uma ferramenta que abro quando preciso. É um colega que está ali, acessível pelo WhatsApp, assumindo tarefas repetitivas:

• Verificar emails urgentes

• Lembrar de eventos próximos

• Postar conteúdo nas redes

• Organizar informações

Tarefas que eu faria de qualquer jeito, mas que consomem tempo e atenção. O agente libera esses recursos para o que realmente importa.

E quando ele age em meu nome publicamente, usa o prefixo [molty] ou [clawdbot]. Acredito na necessidade de transparência sobre o que é gerado por IA neste momento.

Conclusão

O Clawdbot (em breve Moltbot) representa o que assistentes de IA deveriam ser: auto-hospedados, integrados à sua vida digital, sob seu controle.

Não é perfeito. Exige configuração. Tem custos (de API ou de hardware). Mas para quem quer automatizar tarefas repetitivas sem entregar seus dados para big tech, é a melhor opção disponível hoje.

Meu setup quebra várias recomendações oficiais. Funciona. Mas sei dos riscos. Faça suas escolhas conscientemente.

Aos meus amigos nerds, uma das coisas que mais me impressionou foi o quanto tudo isso me lembra a série de anime Ghost in the Shell.

Guilherme Favaron é VP de Tecnologia e escreve sobre IA aplicada em ia-aplicada.substack.com