YC descreveu a empresa autoaperfeiçoável. Usa um Brain.

Tom Blomfield deu uma palestra de treze minutos para uma turma da Y Combinator nesta primavera, How to Build a Self-Improving Company with AI (vídeo). Depois foi além e colocou isso nos Requests for Startups da YC, onde “Company Brain” agora é uma das ideias que a YC pede explicitamente aos fundadores para construir. Desde então, ele saiu de licença da YC para se juntar à Anthropic, mas a palestra continua no ar, e vale os treze minutos. Ao assisti-la, tivemos sempre a mesma reação. Ele está descrevendo, de fora e com suas próprias palavras, o tipo de empresa que criamos o this+that para tornar possível.

Não cole IA sobre a empresa antiga

O primeiro movimento de Blomfield é rejeitar o enquadramento que a maioria das empresas usa. Adicionar um copiloto aqui e um assistente ali é, nas palavras dele, como pegar o jeito antigo de trabalhar e colocar um motor mais potente nele. A máquina por baixo continua a mesma. O que ele diz aos fundadores para construir, em vez disso, é um conjunto de loops recursivos que se aperfeiçoam sozinhos à medida que rodam, para que a empresa melhore enquanto você dorme.

Ele dá ao loop cinco camadas. Sensores, o sinal do mundo real sobre o qual a empresa opera: e-mails, tickets de suporte, telemetria de produto. Uma camada de política que decide o que a IA faz por conta própria e o que precisa da aprovação de uma pessoa. Ferramentas, as APIs e ações que o loop consegue de fato executar. Portões de qualidade, as avaliações e revisões humanas que pegam resultados ruins antes de irem ao ar. E uma camada de aprendizado, em que as falhas retroalimentam o processo para que a próxima passagem seja melhor que a anterior. Rode isso de forma consistente e o loop se aperta sozinho ao longo do tempo.

Torne a empresa legível para a IA

A instrução que ficou gravada em nós é a que está por baixo das cinco camadas. Para qualquer loop funcionar, a IA precisa conseguir ler como a empresa realmente opera, então Blomfield diz aos fundadores para capturarem isso: os e-mails e conversas onde as decisões de fato são tomadas, registrados em algum lugar de onde um modelo possa trabalhar. Ele chama isso de tornar a empresa legível para a IA.

O exemplo dele é da própria YC. A empresa pegou milhares de horas de suas office hours gravadas e usou IA para regenerar seu manual interno de usuário, e esse documento agora continua se atualizando sozinho conforme novos conselhos são dados. Essas gravações são o exemplo dele, não um modelo para copiar; o ponto que se generaliza é o que ele diz que vale a pena guardar. A coisa preciosa é o entendimento que as pessoas têm de como o trabalho é feito. O software construído sobre isso é efêmero, e se você armazenar o conhecimento como texto simples e agnóstico de modelo, ele sobrevive a qualquer aplicativo que esteja lendo-o neste ano.

Essa camada de conhecimento legível é o brain

Há um tempo já vimos defendendo uma versão desse argumento, partindo de um ponto diferente. O estado real e vivo de uma empresa, o que acabou de atrasar e quem deve o quê, vive nas mensagens que as pessoas trocam, não nos sistemas de registro. O trabalho é transformar esse fluxo em conhecimento que um agente consiga ler e, eventualmente, escrever de volta. Chamamos essa camada de brain.

O RFS vai além da palestra sobre o que isso precisa ser, e foca na parte difícil. Ele pede algo que extraia conhecimento de cada fonte fragmentada, estruture isso, mantenha isso atualizado, e transforme isso em um arquivo de habilidades executável sobre o qual os agentes possam agir. Não uma ferramenta de busca. Não um chatbot sobre documentos. Os exemplos dele são as perguntas para as quais nenhum esquema tem um campo: como sua empresa lida com reembolsos, as regras para exceções de preço, como os engenheiros respondem a incidentes.

Manter isso atualizado é a cláusula que já matou essa ideia antes. Ontologias escritas à mão morreram por causa da manutenção, não do formalismo, um argumento que já fizemos com detalhes. Pedir uma camada de conhecimento é fácil. Pedir uma que não fique obsoleta é pedir a solução para um problema que ninguém resolveu.

O brain é a empresa legível que Blomfield pede aos fundadores para construir, empacotada como produto. Ele guarda o conhecimento operacional que um time gera enquanto trabalha, capturado como texto, mantido atualizado e legível por qualquer modelo. O exemplo dele das office hours é áudio de reunião, e nós não gravamos nem transcrevemos reuniões. Nossa matéria-prima é o fluxo de mensagens escritas em e-mail, Slack e Teams, além de quaisquer transcrições que já cheguem por ali, vindas de onde quer que o time faça suas anotações.

O loop dele é nossos workflows e o brain

O loop de cinco camadas dele mapeia, camada por camada, para dois dos nossos recursos principais.

Os sensores são as mensagens que chegam. A camada de política e decisão é a lógica de ramificação que um workflow executa, o IF e o ELSE e as regras que você define para o que acontece sem você. As ferramentas são as ações que um workflow pode executar e os serviços externos que ele alcança via MCP. O portão de qualidade é a etapa de aprovação, o ponto em que uma execução pausa e espera por uma pessoa antes de qualquer coisa sair. E a camada de aprendizado é o write-back, em que o que uma execução produz volta para o brain para que a próxima comece de um ponto mais adiantado que a anterior.

O write-back já funciona hoje: um workflow pode atualizar o brain, de modo que um time consiga manter seu conhecimento operacional atualizado enquanto o trabalho acontece, e construímos exatamente isso para um cliente. O que ainda não lançamos é a versão de uso geral, um brain que se mantém sozinho em todo o fluxo de mensagens sem que ninguém precise configurá-lo. Essa é a fronteira, e não é o que o time de Blomfield construiu também. O exemplo deles foi um loop feito sob medida que regenerava um único documento a partir das próprias gravações, não um brain geral e autossustentável. Essa versão está à frente de todos nós, e é o que estamos construindo com um design partner.

Não somos mais os únicos a dizer isso. Desde que o RFS saiu, um setor inteiro se formou: Hyper, uma empresa da turma YC Spring 2026 que se autodenomina o “self-driving company brain”, e outras perseguindo o mesmo objetivo. Garry Tan, o próprio CEO da YC, escreveu um company brain para si mesmo e abriu o código dele. Em outros pontos da categoria, Lore e Sana vendem um “enterprise brain”, Glean vende busca corporativa, e Guru vende gestão do conhecimento, todos rondando o mesmo problema com palavras diferentes. Ninguém lançou uma camada de conhecimento que se mantém sozinha em todo o fluxo de mensagens de uma empresa.

O destino, e a rampa de acesso

Blomfield está falando com fundadores que conseguem montar uma equipe para isso. O exemplo mais marcante dele é um agente que percebeu consultas ao banco de dados falhando durante a noite, diagnosticou a causa, escreveu uma correção, abriu um pull request contra a base de código da YC, teve um segundo agente revisando, e lançou tudo antes de amanhecer. Esse resultado é impressionante, e pressupõe um time capaz de conectar agentes ao próprio código e infraestrutura.

A maioria dos times não consegue, e é aí que está a oportunidade. O this+that já consegue passar uma tarefa de codificação para um agente que abre um pull request em rascunho para uma pessoa revisar, o que é um degrau na mesma escada. Poderíamos rodar isso sem supervisão também. O ponto de aprovação é opcional e nada obriga uma pessoa a aprovar o pull request, então um time pode montar o mesmo loop sem intervenção humana. Deixamos uma pessoa nesse ponto por padrão porque achamos que é mais sensato, não porque o produto exige isso. A razão de existir do nosso produto é que uma empresa legível e autoaperfeiçoável não deveria exigir que você montasse a infraestrutura antes. A camada de conhecimento se monta a partir da caixa de entrada que você já tem, e os loops rodam em cima dela.

Quando as empresas realmente se reorganizarem em torno de loops como os que Blomfield descreve, a maioria não vai chegar lá contratando um time para construir o loop. Vão chegar lá porque o conhecimento foi capturado enquanto trabalhavam, e os agentes já estavam agindo sobre ele. São essas as empresas para as quais estamos construindo o brain.

Principais pontos

• Em uma palestra para uma turma da YC, Tom Blomfield defende que os fundadores parem de colar IA sobre a organização antiga e reconstruam o trabalho como loops recursivos e autoaperfeiçoáveis, e apresenta uma versão de cinco camadas: sensores, política, ferramentas, portões de qualidade e aprendizado.
• A instrução central dele é tornar a empresa legível para a IA capturando o que as pessoas sabem como texto durável e agnóstico de modelo, porque o conhecimento é o ativo precioso e o software construído sobre ele é efêmero.
• Essa camada de conhecimento legível e autoatualizável é o que chamamos de brain. Nós a construímos a partir do fluxo de mensagens escritas, não de gravações de reuniões, que é o exemplo dele e não algo que fazemos.
• O loop autoaperfeiçoável dele mapeia para nossos workflows mais o brain: gatilhos como sensores, ramificações e regras como política, ações e MCP como ferramentas, etapas de aprovação como portões de qualidade, e write-back como o início do aprendizado. O write-back para o brain já funciona hoje, então um time pode manter seu conhecimento operacional atualizado agora; a versão de uso geral e autossustentável é a fronteira, e também não é o que a YC construiu.
• Ele está descrevendo um destino que exige engenharia de verdade para ser alcançado. O this+that é como um time comum chega lá sem construir o loop do zero, partindo da caixa de entrada que já tem.