Seu Harness, Sua Memória — e Por Que um Fosso Alugado Não é um Fosso

Harrison Chase publicou hoje um ensaio curto no blog da LangChain com um título que parece trocadilho e é tese: “Your harness, your memory”. O argumento dele é direto. Memória não é um plugin que você pluga num agente depois de pronto. Memória é parte nuclear do harness — o código que orquestra contexto, ferramentas, prompts e estado entre turnos. Sarah Wooders, da Letta, resume com precisão cirúrgica: gerenciar contexto, e portanto memória, é responsabilidade central do harness. Não dá para terceirizar uma sem terceirizar a outra.

Harrison conclui, então, que harnesses fechados criam um espectro de lock-in. No lado mais leve, APIs com estado como a Responses API da OpenAI — você ainda controla o prompt, mas o servidor mantém o histórico e você não troca de modelo no meio da sessão. No meio, harnesses fechados onde a arquitetura de memória é invisível. No fundo do poço, o Claude Managed Agents da Anthropic, lançado na semana passada, que esconde harness e memória atrás de uma API proprietária. A recomendação dele: use Deep Agents, o harness open source da LangChain, que pluga em MongoDB, PostgreSQL ou Redis conforme sua preferência.

Harrison está certo sobre quase tudo. Mas o argumento tem três dobras que o ensaio dele não abre — e que importam mais para quem precisa decidir, não para quem precisa vender.

Primeira dobra: memória é o fosso, e o fornecedor fica com o fosso

Ontem argumentei que o Claude Managed Agents transformou a decisão clássica de construir-vs-alugar numa decisão de governança. Você não está mais escolhendo entre custo de desenvolvimento e velocidade de entrega. Você está escolhendo entre ter visibilidade de como seu agente raciocina e aceitar que essa visibilidade é comercialmente cara.

O post de Harrison expõe o segundo eixo escondido dessa decisão, e é pior do que o primeiro. Mesmo que você aceite o aluguel do harness por razões legítimas — velocidade, custo de operação, falta de time para manter infra de agentes —, você não consegue levar embora o seu próprio aprendizado quando resolve sair. O ativo que torna seus agentes proprietários, a memória que eles acumulam sobre seus clientes, seu código, suas decisões, seus processos, é exatamente o ativo que o fornecedor mantém refém no formato dele.

Harrison conta uma história pequena que vale mais do que qualquer benchmark. O assistente pessoal de e-mail dele, construído sobre um harness de terceiros, foi apagado. A reconstrução ficou pior. Não porque o código novo estivesse errado, mas porque as preferências aprendidas ao longo de meses — quem ele responde rápido, qual tom usa com cada pessoa, quais e-mails ele ignora — não tinham para onde migrar. O fosso não era o código. Era a memória. E a memória morreu com o harness antigo.

É aqui que Harrison vira de observador para vendedor, e é justo nomear a tensão.

Segunda dobra: LangChain não é observadora neutra

Harrison Chase é CEO da LangChain. A LangChain vende Deep Agents. O argumento dele está correto e é honesto o suficiente para divulgar onde o ecossistema está prendendo as pessoas. Mas um harness open source que você não opera ainda é lock-in operacional. Soberania sobre agentes não é apenas uma questão de código aberto. É a soma de duas coisas distintas: transparência de código mais controle operacional.

Se o seu time pluga Deep Agents num cluster gerenciado por um SaaS da LangChain amanhã, você trocou uma dependência fechada por uma dependência aberta-mas-operada-por-terceiros. O código é auditável. A operação não é. O seu fosso de memória contínua num banco que outra pessoa mantém. O lock-in mudou de natureza, não de magnitude.

Isso não invalida o argumento de Harrison. Apenas deixa claro que o teste é mais estrito do que o ensaio dele deixa transparecer. Pergunta real: quem opera o banco onde a memória vive? Se a resposta é “nós, com credenciais nossas, num ambiente nosso, com backup nosso”, você tem soberania. Se a resposta é qualquer outra coisa, você tem um tipo mais educado de aluguel.

Terceira dobra: opacidade e lock-in são problemas diferentes

O ensaio de Harrison mistura dois problemas que governança precisa separar. Opacidade é o problema de auditoria — você não consegue ver como o agente decidiu, o que ele lembrou, o que ele esqueceu, e isso é uma lacuna de governança que regulação eventualmente vai cobrar. Lock-in é o problema de negócio — você não consegue trocar de fornecedor sem perder continuidade operacional.

Memória self-hosted auditável resolve opacidade. Você vê o schema, você roda queries, você exporta logs, você responde auditoria regulatória. Mas ela pode manter lock-in se o schema for idiossincrático o suficiente para que nenhum outro harness consiga carregar o dump. O inverso também existe: um formato portável num banco fechado resolve lock-in mas não resolve opacidade.

Um time de governança maduro precisa dos dois. Harrison trata como um problema só, e isso é o luxo de quem vende a solução, não de quem vive a operação.

Quarta dobra: nem todo agente tem fosso de memória

“Memória é o fosso” é uma frase bonita e é parcialmente falsa. Depende do trabalho.

Assistente pessoal de e-mail, sim. Agente de sales research que aprende o perfil de cada conta ao longo de meses, sim. Copiloto jurídico que lembra preferências de cláusula de cada sócio, sim. Nesses casos, a memória é exatamente o que diferencia o seu agente de um genérico, e perdê-la é perder o produto.

Agente de code review que abre cada PR do zero, não. Agente de triagem que aplica regras determinísticas, não. Agente de extração que recebe um documento e devolve JSON estruturado, também não. Nesses, o fosso está nas ferramentas, nos prompts, nos workflows internos e nos critérios de avaliação — nada disso mora na memória. Resetar o estado a cada sessão é feature, não bug. Memória é difícil mesmo quando você é dono dela, e adicionar memória a um agente que não precisa é importar complexidade sem retorno.

A pergunta certa não é “onde mora minha memória?”. É “este agente tem memória que é um ativo, ou tem estado que é um passivo?”. Responder errado nos dois sentidos custa. Tratar um agente de e-mail como stateless custa satisfação do usuário. Tratar um agente de extração como stateful custa bugs intermitentes e superfícies de ataque que ninguém queria ter.

O teste que importa

Se você é responsável por um portfólio de agentes hoje, o teste de governança que o post de Harrison indica, depois de separarmos as dobras, é este:

Para cada agente cujo valor depende de memória, você consegue sair do harness atual levando a memória em um formato que outro harness consiga, de fato, carregar — e continuar a operação sem perda de fidelidade?

A maioria dos times enterprise não consegue responder que sim. Não porque a resposta seja difícil em princípio. Porque ninguém fez a pergunta antes de assinar o contrato. O fornecedor ofereceu a conveniência de memória gerenciada, e a conveniência foi aceita sem cláusula de saída.

Isso é exatamente o problema que a governança de agentes precisa começar a tratar como cláusula padrão, não como exceção. Schemas de memória exportáveis. Formatos documentados. Direito contratual de dump. Testes de restore periódicos, do mesmo jeito que bancos já exigem testes de disaster recovery.

E isso vale para harnesses abertos também. Open source não é garantia de portabilidade. Formato é.

O que fazer na segunda-feira

Três movimentos cabem num ciclo de planejamento sem virar projeto de seis meses.

Primeiro, classifique seus agentes em dois baldes — memória-como-ativo e memória-como-passivo. Agentes no primeiro balde precisam de cláusula de portabilidade. Agentes no segundo balde provavelmente deveriam ter a memória desligada, e você economiza governança que não precisa fazer.

Segundo, para cada agente no primeiro balde, liste onde a memória mora, quem opera aquele armazenamento, e o que aconteceria com o valor do agente se o contrato de harness acabasse amanhã. Se a resposta é “o agente vira genérico de novo”, você sabe o tamanho do problema.

Terceiro, peça ao seu próximo fornecedor de harness, aberto ou fechado, um teste prático: exporte a memória de um agente de teste, carregue em outro harness, rode a mesma tarefa, compare o resultado. Se o teste passa, você comprou soberania. Se o teste falha, você comprou um fosso que não é seu.

Harrison está certo que harnesses e memória são infraestrutura permanente. Eu adicionaria que infraestrutura permanente do fornecedor é o oposto de infraestrutura permanente sua. Os dois podem coexistir por um tempo. Só não confunda um com o outro na hora de contar o fosso.

---

Fontes

• Harrison Chase. “Your harness, your memory.” LangChain Blog, abril de 2026.
• Sarah Wooders / Letta. “Letta Code.” Letta, 2026.
• Anthropic. “Claude Managed Agents overview.” Abril de 2026.

A Victorino Group ajuda líderes de engenharia a manter a memória dos agentes portável, auditável e sua: contato@victorino.com.br | www.victorino.com.br