product

Agentes precisam de um brain em que possam escrever

this+that team
Agentes precisam de um brain em que possam escrever

Karpathy estava certo

Em abril, Andrej Karpathy cristalizou algo em torno do que muita gente vinha rondando. Um wiki em markdown mantido por um LLM, escreveu ele, é um “artefato persistente que acumula”. Quem pegou a corrente dele foi ao mesmo símile: o RAG re-deriva tudo a cada consulta, como um interpretador; um wiki compila a síntese uma vez, guarda, e reutiliza. O post bateu dezesseis milhões de visualizações.

Veio uma onda de montagens de brain pessoal. Obsidian como a versão canônica, Mem como irmão nativo de IA que organiza notas sozinho, e uma cauda longa de ferramentas parecidas. O GitHub lançou um sistema de memória de agente baseado em repositório para o Copilot. Tiago Forte declarou que a gestão de contexto pessoal estava engolindo a gestão de conhecimento pessoal. O RFS da primavera de 2026 da YC citou a peça que faltava pelo nome: um “brain da empresa” com controle de acesso, auditoria, e permissão de escrita para os agentes que deveriam mantê-lo.

O padrão é de uma pessoa só

O Obsidian como segundo cérebro funciona muito bem se você é a única pessoa cuidando do jardim. Alguns times de fato rodam um repositório Git compartilhado como brain da empresa (temos clientes que fazem exatamente isso), mas isso exige que cada pessoa que contribui seja fluente em pull requests e conflitos de merge, e as ferramentas de edição não chegam perto de um wiki de verdade. Os padrões em geral supõem uma pessoa curadora, um agente, um grafo de conhecimento. Tudo bem para pesquisa individual. Desaba no instante em que o trabalho envolve outra pessoa.

O seu colega precisa achar o fato que você registrou. O agente aprende algo durante uma rodada e não tem onde registrar. Uma corrente de cliente precisa de um preço cuja fonte da verdade não tem dono. Você quer que a resposta a “qual é a nossa posição sobre X” seja a mesma, pergunte uma pessoa ou um agente.

Os padrões de brain pessoal não estão errados. Estão delimitados demais. Aquilo que torna uma base de conhecimento útil para uma pessoa, markdown, hierarquia e links, não é o que a torna útil para um time. Isso exige identidade, permissões, edição por várias pessoas, e uma superfície em que o agente escreva em tempo real.

O que lançamos

O brain é uma camada de conhecimento com permissão de escrita dentro do this+that. Cada time ganha um espaço de time, cada pessoa ganha um espaço pessoal, e as páginas se aninham em hierarquia. Editor markdown com menções por @ para pessoas, tarefas e outras páginas. Versionamento por página, detecção de conflito quando duas pessoas ou dois agentes editam ao mesmo tempo, suporte a anexos. Cada página e cada versão é assinada por quem a escreveu. Quando um agente escreve uma página, o histórico também registra o colega que delegou o trabalho, então você sempre vê quem autorizou o quê.

A parte não óbvia é que agentes podem escrever nele. Pessoas lendo e escrevendo num wiki é o básico; todo wiki desde os anos 90 suporta isso. O que diferencia o brain é que agentes são participantes de classe igual nos dois sentidos.

Isso te dá dois padrões que valem ser projetados:

Fluxos que leem o brain. Um agente ou fluxo lê o conhecimento existente do time para agir. O exemplo canônico é um agente de vendas: perguntas de preço chegam por e-mail, o agente responde usando a tabela canônica mantida no brain do time, marca uma call de acompanhamento se houver interesse, e registra a interação como uma tarefa ligada à corrente de origem. A resposta do agente se apoia no que o seu time de fato decidiu, e não no que um modelo base adivinha.

Fluxos que escrevem no brain. Um agente ou fluxo produz conhecimento durável ao longo do tempo. O exemplo canônico é um agente de análise competitiva: cada rodada gera uma página no brain (o que o agente achou, o que era novo desde a última vez, o que mudou). A rodada seguinte lê a anterior como contexto. Ao longo de semanas o brain acumula um histórico que você busca, em vez de um relatório de uma vez só que se apaga.

Esses dois padrões se compõem. Um fluxo que lê e escreve trata a pergunta que chega de um colega: o assistente busca no seu brain (só você vê), escreve uma resposta apoiada no que você sabe, e ao enviar, grava a pergunta respondida de volta no brain, para a próxima pessoa que perguntar achar a resposta sem te incomodar.

Para fora, quando você quiser

O conteúdo do brain é privado por padrão. Mas você pode envolver uma fatia dele num artefato público: uma página escrita por IA, uma página de destino, uma apresentação ou um microsite com URL própria, que qualquer pessoa fora do seu time visita e usa. A página consulta o seu brain em tempo real por uma ação controlada, então um cliente que pergunta recebe uma resposta apoiada no que o seu time de fato registrou.

Um FAQ público que nunca fica desatualizado porque lê das mesmas páginas que o seu time edita. Uma página de destino cujos detalhes de produto ficam em dia. Um microsite de lançamento que acumula com o trabalho que o time faz internamente. Você decide o que é exposto e por qual superfície. O padrão é privado, o caminho para fora é controlado e explícito, o conhecimento por baixo é o mesmo.

E a superfície pública não é só de leitura. O mesmo artefato pode mostrar a sua disponibilidade de agenda ao vivo e deixar quem visita marcar uma demonstração, então uma página de lançamento responde perguntas a partir do brain e fecha uma reunião sem mandar a pessoa para outro lugar. Você escolhe a subárvore do brain de que o artefato público pode responder; o resto do brain segue privado.

E vale no sentido contrário também. Alguns times já têm uma base de conhecimento que funciona para eles: um espaço no Notion, um Confluence, um repositório Git compartilhado. Os nossos agentes escrevem nesses por MCP, do mesmo jeito que leem deles. O brain dentro do this+that é o padrão, mas se o seu time já escolheu outra casa para o conhecimento, os nossos agentes mantêm essa casa em dia.

Conhecimento, e não dado transacional

O brain é para o pensamento durável que o seu time faz. A razão pela qual o seu preço é o que é. O seu posicionamento em relação à concorrência. A visão da empresa. O tipo de coisa que as pessoas escreviam uma vez e depois esqueciam de atualizar.

Não é um CRM. Não é um produto de análise de marketing. Dado transacional vive nos sistemas feitos para isso (Salesforce, HubSpot, GA4, o seu data warehouse) e fica lá. O brain é para as coisas que não cabem direito em linhas de tabela.

Um terceiro pilar, com cautela

Vínhamos descrevendo o this+that como duas coisas: extração de tarefas (o que precisa ser feito) e fluxos (o que é feito sozinho). Estamos acrescentando com cautela uma terceira, o brain (o que você e os seus agentes sabem). Cada uma torna as outras mais úteis. O brain apoia os fluxos. Os fluxos põem conhecimento novo no brain. As tarefas consultam o brain por contexto.

Elas funcionam como um produto só porque as mensagens, as tarefas e o brain vivem dentro do mesmo envelope de confiança. O agente que escreve a sua resposta tem as permissões que você tem. A página que o agente escreve herda o controle de acesso do time. Nada vaza entre fronteiras porque não há fronteiras a atravessar.

Karpathy acertou o porquê

O ponto central dele, de que o trabalho de conhecimento acumula quando persiste e que o custo marginal de manter essa persistência cai a zero com LLMs, está exatamente certo. A peça que falta no enquadramento de brain pessoal é que trabalho de verdade raramente é um jogo de uma pessoa só. Metade do valor de registrar algo é para outra pessoa, ou um agente servindo outra pessoa, achar na semana seguinte.

Construímos a versão para times porque é onde o trabalho de fato acontece.