Jeff, engenheiro fundador da Unblocked, abre um talk de 13 minutos com uma demonstração que dá errado. O agente em cena enriquece tickets: recebe um ticket no Linear, classifica se é feature ou bug, pesquisa o código, propõe próximos passos. O ticket era real — degradação na pipeline de QA, tempo até o primeiro caractere em 3 a 4 segundos onde o esperado eram centenas de milissegundos. O agente estudou o código, estudou o ticket e recomendou: reabilite o despacho assíncrono, permite rodar mais da pipeline em paralelo. Recomendação plausível, bem argumentada, entregue com confiança.

Errada. O despacho assíncrono tinha causado um outage dias antes. Um engenheiro de suporte o tinha desabilitado explicitamente antes de o ticket existir.

O que faltou não era inteligência. Faltava a discussão no Slack depois do incidente, o ticket de postmortem que ela gerou, a intenção por trás da decisão. O agente tinha o código e o ticket; não tinha a organização.

Você é a babá

Se você usa agentes de código no terminal, esse erro praticamente não acontece com você — porque você é a camada de contexto. Nas palavras do talk: você está lá para perguntar, capturar erros e fornecer o fato faltante a cada turno. Você sabe por que o código é daquele jeito, o que quebrou da última vez, o que o time decidiu fazer a respeito. O agente tem só o que está na frente dele: instruções, ferramentas, código, ticket.

O problema aparece quando o agente sai do terminal. Implantar um agente em segundo plano virou trivial — framework de um lado, primitivas de nuvem do outro, meia dúzia de linhas de configuração. Sem a babá, o erro do ticket Linear não é um episódio: é o modo de operação. Ele acontece em silêncio, desinforma colegas humanos e, pior, outros agentes que consomem a mesma saída.

A frase que fecha o talk resume a tese: “The gap isn’t intelligence, it’s context.” O diagnóstico está certo. O que ele não conta é que contexto não é um andar. São quatro.

Transporte não é semântica

A parte tecnicamente densa do talk é a crítica ao MCP, o protocolo que conecta agentes a fontes de dados. Ela cabe numa linha: “MCP is great at access, but access isn’t understanding.” Conecte um MCP do Slack, um do Linear, um do GitHub, e todo o dado fica acessível. Três falhas decorrem disso:

  1. O MCP devolve resultados crus. O ônus de decidir no que acreditar fica no agente.
  2. A janela de contexto inunda de dados irrelevantes. O custo por chamada sobe, a precisão cai.
  3. Fontes divergem — o ticket no Linear diz uma coisa, a thread no Slack diz outra — e o modelo resolve o conflito na hora, sem critério determinístico.

A crítica é correta. A solução anunciada, não. A context engine vendida no talk conecta tudo, constrói um modelo da organização e devolve ao agente uma síntese pronta — “scattered context in, grounded context out”. Mas síntese também é gerada por LLM, e LLM erra. A arquitetura não elimina o ponto de falha: troca agente confuso com dados crus por síntese enviesada com aparência de autoridade. O agente recebia informação ruidosa e podia desconfiar; agora recebe uma conclusão embalada como verificada.

Os quatro andares

Cheguei a esse mapa ao procurar no meu acervo pessoal de leituras tudo que conversa com a tese do talk — quatro buscas híbridas, semântica e palavra-chave. O material se divide em quatro camadas que o talk apresenta como uma só:

Andar 1 — dentro da sessão. A janela como recurso finito: compactação de contexto, gestão de histórico, compressão. É o andar com pesquisa mais madura. O ABBEL, do Berkeley, treina modelos a manter estados de crença — resumos em linguagem natural cujo conteúdo é supervisionado. Em colaboração de código, os autores reportam reduzir pela metade a distância até o contexto completo: no test pass, 0,46 para o resumo comum, 0,48 com crenças supervisionadas, 0,52 de contexto cheio — e na taxa de sucesso a recuperação passa de 60% — com metade dos passos de treino e 601 tokens de pico contra 1.408. E o próprio Berkeley nota que o Cursor recomenda aos usuários evitar compactação no meio de uma tarefa: a prática degrada mais do que o benchmark sugere.

Andar 2 — entre sessões. Memória persistente: o que o agente aprende numa tarefa precisa sobreviver até a próxima. Um enxame de startups e projetos abertos disputa esse andar — motores de memória em um arquivo SQLite, grafos compartilhados entre ferramentas de código, memórias locais com aprovação explícita. Um deles já admite o problema que os outros varrem para baixo do tapete: recall ciente de conflito, memória que marca o que é incerto em vez de fundir versões. Conflito, aliás, é o fio que atravessa os andares — o MCP falha nele (§ transporte), a memória tenta admiti-lo, a organização precisa de temporalidade para decidir. Categoria consolidada, commodity em formação.

Andar 3 — a organização. Contexto multi-fonte: docs, tickets, chats, decisões, com grafo de relações, permissões e recência. É o andar que a Unblocked vende — e que o talk apresenta como se fosse o prédio inteiro. A ideia de “modelo da organização” disponível aos agentes é legítima; é GraphRAG corporativo com controle de acesso.

Andar 4 — verificação. Como saber que o contexto entregue — sintetizado ou recuperado — é fiel à fonte. Quase vazio.

O andar vazio

Nenhuma stack anunciada no andar 3 inclui citação rastreável por afirmação. A síntese sai pronta; o agente confia; quem lê o resultado confia no agente. A cadeia quebra exatamente onde ninguém construiu.

A resposta determinística existe, só não entra no produto. O verbatimeter verifica ancoragem de texto gerado por IA contra a fonte: mede reúso literal (sequências contíguas de três ou mais palavras) e paráfrase literal (subsequência comum máxima), sem modelo juiz, sem rede, uma única dependência. No modo citações, ele falha o pipeline se uma citação diferir da fonte — ou se a resposta parar de citar, caso que o próprio gate trata como suspeito. O projeto é honesto sobre o limite: casamento léxico, não semântico; um piso determinístico de falhas de ancoragem, não um juiz de paráfrases fiéis.

Piso já resolve muito. Um agente em segundo plano cuja síntese precisa passar por citação verificável não pode inventar o postmortem que não leu — a fabricação vira exceção do gate, não conteúdo publicado.

O contraste com o andar 1 é o que expõe a lacuna. A academia supervisiona o conteúdo dos resumos justamente porque resumo sem supervisão degrada — o ABBEL existe porque compactação espontânea perde informação que a tarefa precisa. No andar 3, o produto trata síntese como feature. A pesquisa trata a mesma síntese como superfície de falha.

O que muda para quem constrói

  • Temporalidade no retrieval. O postmortem é posterior ao ticket. Recência é sinal de autoridade, e a ordem dos eventos decide qual versão vence o conflito que o talk quer resolver. Um índice sem carimbo de tempo resolve empates ao acaso.
  • Permissão antes da síntese, não depois. Controle de acesso aplicado no transporte (o que o agente pode buscar) deixa a síntese como novo ponto de vazamento. O filtro precisa valer para o que entra na síntese, senão o resumo vira canal lateral de dados.
  • Citação por afirmação como condição de segundo plano. Agente interativo erra e você corrige no turno seguinte. Agente autônomo que sintetiza sem citação verificável não está pronto para ser autônomo — o erro do ticket Linear é o caso de teste. O gate não adivinha o que faltou, mas força a síntese a declarar em que se apoia: a ausência de fonte fica visível na saída, em vez de invisível dentro da recomendação.

A frase do talk vai virar slogan, repetida em dez posts até sexta. A pergunta que sobra depois do slogan é a útil: dos quatro andares, qual deles você consegue verificar?