Tem muita empresa usando IA e poucas empresas sendo AI-native. A distinção não está na lista de ferramentas no stack. Está em como a operação foi desenhada para gerar, ou não, informação que um agente consiga processar.
Diana Hu, General Partner do Y Combinator, deixou isso claro num episódio recente do Startup School: IA não é o novo Excel. É o novo sistema operacional. E a diferença entre usar uma ferramenta de produtividade e rodar em cima de um sistema operacional é grande. Uma ferramenta aumenta a capacidade de quem a usa em tarefas específicas. Um sistema operacional é a infraestrutura sobre a qual tudo o mais roda.
Na minha leitura, esse é exatamente o enquadramento que falta na maioria das conversas sobre adoção de IA. A pergunta dominante ainda é "qual ferramenta vamos usar?". A pergunta que importa é "como nós operamos?".
Loop aberto, loop fechado
Hu descreve dois modos fundamentais de operar. No modo aberto: decisões são tomadas, trabalho é executado, resultados são interpretados por pessoas em reuniões, relatórios e atualizações de status. A empresa funciona, mas o conhecimento sobre o que funcionou fica comprimido em camadas hierárquicas, perdendo textura a cada nível antes de chegar em quem poderia fazer algo útil com ele.
No modo fechado: cada ação gera um artefato estruturado. Um agente lê esse artefato. O sistema aprende com o que leu. Sem uma camada de gestão no meio comprimindo informação num slide antes de ela circular.
A teoria de controle usa esses termos há décadas. O que Hu fez foi transpor o framework para design organizacional. Uma empresa de loop fechado é aquela onde o feedback volta ao sistema de forma estruturada e legível, em vez de evaporar em memória individual ou desaparecer num email thread que ninguém vai revisitar.
A empresa que o agente consegue ler
O conceito que ela chama de "queryable company" é a consequência operacional do loop fechado. Para que um agente melhore um processo, ele precisa ler o que aconteceu. Para ler, precisa que o que aconteceu tenha sido registrado de forma que um agente consiga processar.
Parece óbvio. Não é.
A maioria das empresas opera com o conhecimento organizacional em dois lugares pouco úteis para um agente: dentro das cabeças das pessoas e em documentos que ninguém atualiza. Os processos reais acontecem em conversas de mensagem instantânea, em reuniões sem ata, em decisões tomadas num corredor. Um agente não consegue ler um corredor.
Tornar a empresa queryable exige uma mudança de operação antes de uma mudança de tecnologia. Reuniões precisam gerar registros com contexto. Decisões precisam virar documentos com o raciocínio por trás delas. O trabalho executado precisa gerar artefatos processáveis. Não por amor à burocracia. Porque sem isso, a camada de inteligência não tem o que alimentar.
Isso ressoa com o que tenho argumentado sobre especificações: a barreira entre intenção e execução não é mais técnica, é semântica. O agente vai executar bem na medida em que o contexto que recebeu é rico. Só que aqui a escala muda. Não é um desenvolvedor gerando uma spec para um agente numa tarefa específica. É a organização inteira gerando os artefatos que se tornam o contexto operacional da empresa.
Tokenmaxxing é design, não conta de API
A frase que mais circulou dos slides de Hu foi "tokenmaxx, don't headcountmaxx". O maximalismo do slogan pode esconder o ponto de fundo. A ideia não é tornar a conta de API a maior possível como se isso fosse mérito em si. A ideia é que, quando o design operacional está certo, o investimento em processamento de IA substitui contratação de forma eficiente.
Uma empresa que opera em loop fechado e é queryable consegue que uma pessoa com ferramentas de IA faça o equivalente ao que levava times inteiros. Não porque o modelo é magicamente capaz. Porque o contexto disponível para o agente é rico o suficiente para que ele opere com qualidade.
Me parece que o ponto mais importante não está no número de tokens. Está na pressuposição que vem antes: para que o gasto em tokens gere retorno, a empresa precisa ser legível. Token spend alto com operação de loop aberto é só custo. Loop fechado com empresa queryable é onde o multiplicador funciona.
Quem tem e quem perdeu a janela
Hu argumenta que fundadores no início têm uma vantagem estrutural que incumbentes não têm. Uma empresa que nasce operando em loop fechado, que desde o dia um gera artefatos processáveis, acumula o que ela chama de "process depth" de forma nativa. Não tem legado para retrofitar.
Uma empresa que opera há dez anos com processos de loop aberto, com conhecimento tácito em cabeças de pessoas que já saíram, e com decisões registradas em email threads de anos atrás, tem um problema diferente. Não é impossível de resolver. É caro. E a dívida não é técnica. É operacional. Hu chama de "process debt", e é tão real quanto dívida técnica, com a diferença de ser mais difícil de quantificar e, por isso, mais fácil de ignorar.
A janela para fazer certo ainda existe para quem está começando. Para quem já tem uma operação estabelecida, o trabalho é de redesenho deliberado, não de fundação do zero.
O que Diana Hu articula não é uma estratégia de adoção de ferramentas. É um princípio de design organizacional. A IA vai amplificar o que está disponível para ser lido. Se a empresa opera de forma que o conhecimento fica em cabeças, o agente não tem o que ler. Se opera de forma que cada ação gera um artefato, o loop fecha.
A pergunta que fica: sua empresa é legível para um agente? Não os seus sistemas de TI. A sua operação.
Referências
- Diana Hu – The Playbook For Building An AI Native Company (YC Startup Library, abril/2026)
- Henry Chandonnet – Y Combinator's guide to being an AI-native company: tokenmaxx, don't headcountmaxx (Business Insider via Yahoo News, maio/2026)
- VoCAP – Watch This: Diana Hu on Building an AI-Native Company (2026)
- StartupHub.ai – Build AI-Native Companies with Closed-Loop Systems (2026)