Como construímos o loop que decide a nossa empresa com IA

Toda empresa pequena decide no escuro. Os sinais que importam (leads, clientes, caixa, afiliados) vivem em telas separadas, e a decisão sai no feeling de quem tem o contexto na cabeça naquele dia. Pior: quase ninguém volta pra medir se a aposta deu certo. Em junho de 2026 montamos um loop que tira a decisão do feeling e a fecha em medição. Chamamos de Company OS, e ele roda dentro do nosso próprio site.

Por que rodar a empresa num loop

A decisão não é o fim do trabalho, é o começo de um ciclo: sinal vira recomendação, recomendação aceita vira decisão com hipótese e métrica, e uma semana depois a métrica diz se a hipótese valeu. Sem esse fechamento, a empresa repete os mesmos erros porque não tem memória do que funcionou. O objetivo do loop é fechar a distância entre decidir e medir.

Repo-native, não serviço separado

A primeira decisão de arquitetura foi não construir um serviço à parte. Os sinais que o loop precisa já estão no nosso Postgres (Neon): leads do pipeline, telemetria de clientes em produção, milestones e reconciliação do Stripe, referrals de afiliados. Um serviço externo só adicionaria sincronização, latência e mais um lugar pra quebrar. O loop vive no mesmo app Next.js, lê o mesmo banco e sobe no mesmo deploy.

Collectors tipados: sinal cru antes de interpretação

Cada fonte tem um collector que devolve um SignalBatch tipado, o dado bruto antes de qualquer julgamento. Essa fronteira importa. O collector não decide o que é relevante, só entrega o fato (quantos leads entraram, qual o caixa, quantos referrals). Quem interpreta é a etapa seguinte. Separar coleta de interpretação deixa cada parte testável sozinha e permite trocar a fonte sem mexer na síntese.

A parte difícil: tornar a decisão mensurável

O coração do loop não é gerar recomendação, é tornar a decisão medível automaticamente. Cada decisão carrega uma métrica-alvo estruturada: não um texto solto como "melhorar conversão", mas o suficiente pra ser consultada por máquina depois (a fonte, a query, a janela de medição, a direção de sucesso e a baseline registrada no momento em que a decisão foi aceita). Sem a baseline capturada na hora, "deu certo?" vira discussão. Com ela, a revisão semanal compara o valor medido contra o ponto de partida e responde com número.

O loop fecha em medição, não em sugestão

Aqui entra a disciplina de vocabulário que virou regra de design. Uma recomendação proposta nunca é chamada de decisão. O brief diário propõe de 1 a 3 recomendações (status proposto); elas só viram decisão quando o founder aceita. E uma decisão só está fechada quando a revisão semanal mede o resultado e grava um Outcome Score (-1, 0 ou 1). Forçar essas fronteiras no schema impede o erro mais comum de painel de gestão: confundir intenção com compromisso, e compromisso com resultado.

A IA propõe, o founder decide

É o mesmo princípio dos nossos projetos de IA voltados a cliente: o modelo não age sozinho onde a ação é difícil de reverter. O Claude sintetiza o brief e propõe; aceitar uma recomendação é um clique humano, num endpoint de ação dedicado. O loop não decide pelo founder, ele garante que toda decisão tomada tenha hipótese, métrica e data de revisão. O ganho não é remover o humano, é não deixar nenhuma aposta sem placar.

O que faríamos diferente

Teríamos capturado a baseline desde a primeira decisão. Nas primeiras versões a métrica-alvo era texto livre, e medir depois exigia reconstruir o ponto de partida de memória (impreciso e discutível). Estruturar a métrica-alvo com baseline no momento da aceitação foi o que transformou o loop de diário bonito em ciclo que aprende.

O loop que usamos é o que vendemos

O Company OS é uma aplicação interna (Track 3) rodando em produção pra nós mesmos. Arquitetura, decisões e o que ele entrega no dia a dia estão no case completo. Se a sua operação decide no escuro e você quer um loop que feche em medição, conta pra gente o contexto.