Como criar uma startup AI-native

• Enquanto a AI processa tarefas repetitivas durante a noite, surge um novo modelo operacional em que os fundadores se concentram em melhorar o produto; a verdadeira mudança não está no uso do tempo, mas na velocidade com que a empresa aprende, itera e evolui
• Uma empresa AI-native tem o próprio modelo operacional transformado: menos gente coordena menos, agentes executam tarefas repetitivas, e humanos se concentram em direção, gosto, relacionamento, validação e responsabilidade
• A transição avança pelas etapas de mapear o trabalho, construir um sistema de contexto, escolher a automação mais simples, transformar tarefas repetitivas em skills, escrever evals que julgam a qualidade e executar um loop semanal de melhoria
• Os modelos são trocados e melhorados todos os meses, e ficam cada vez mais parecidos entre si; por isso, os ativos exclusivos da empresa são sistemas operacionais como contexto e evals
• Em um ambiente em que todos usam os mesmos modelos, o verdadeiro fosso competitivo é a disciplina (discipline): a consistência de mapear o trabalho toda semana, acumular contexto, escrever evals e rodar o loop

---

Contraste entre duas startups

• Comparação, às 9h da manhã, entre duas empresas fundadas no mesmo mês e no mesmo mercado
  • Na primeira empresa, a líder de operações resolve tickets de suporte acumulados, o analista refaz o dashboard da semana passada, e o fundador está no stand-up por causa de uma ligação com cliente que ninguém conseguiu resolver — todos estão apagando incêndios de ontem, e o produto fica estagnado
  • Na segunda empresa, agentes cuidaram de tudo isso durante a noite — classificação de tickets, atualização de dashboard e identificação do risco de churn (churn risk) em ligações já concluídas; o fundador já está corrigindo problemas e melhorando o time e o produto
• A diferença central é a velocidade de aprendizado: a segunda empresa aprende mais rápido todos os dias, e essa alavancagem se acumula em juros compostos ao longo de semanas, meses e anos

Etapa 1 - Mapear o trabalho (Map The Work)

• Liste todas as tarefas repetidas nas últimas duas semanas — notas de ligações com clientes, pesquisa de leads, rascunhos de outbound, classificação de suporte, QA de produto, onboarding, release notes, atualizações para investidores, métricas semanais, reprodução de bugs, triagem de candidatos, revisão de faturas, monitoramento de concorrentes etc.
  • Se se repete, é candidata à codificação; no calendário da maioria dos fundadores existem de 20 a 40 itens desse tipo
  • Quando um time inicial faz uma lista honesta, normalmente encontra de 10 a 15 tarefas que já eram rotina

• Classificação por nível de autonomia

  • L1 é só para humanos — decisões estratégicas, contratação final, grandes reembolsos, assinaturas legais, comunicação com o conselho
  • L2 é AI prepara e humano aprova — rascunhos de atualização para investidores, redlines de contrato, reescrita de página de preços, macros de suporte
  • L3 é AI executa e humano supervisiona — classificação de inbound, roteamento de notas de reunião, enriquecimento de leads, geração de testes
  • L4 é autônomo dentro de limites claros — monitoramento de concorrentes, geração de relatórios noturnos, extração de faturas de fornecedores conhecidos, detecção simples de anomalias

• Workflows entediantes geralmente vencem

  • Em vez de tarefas chamativas como um memo estratégico semanal, tagueamento de suporte executado todos os dias roda 10 vezes mais, recupera mais tempo e fornece dados limpos de resposta correta — frequência vence prestígio
  • Os primeiros alvos devem ser tarefas frequentes, mensuráveis, reversíveis e ligadas a gargalos reais

• Tarefas que não devem ser automatizadas

  • Exclua tarefas raras, ambíguas, que exigem alta confiança ou que ainda são instáveis
  • A equipe da C.H. Robinson levou a classificação de 10 mil emails por dia para L4, mas voltou para L2 porque a supervisão se tornou impossível — o volume escondia o custo das classificações erradas
  • Se você não consegue explicar o que é um bom resultado, então o trabalho ainda não está pronto para ser codificado; se uma única saída errada pode prejudicar a relação com o cliente, avance devagar

• Configuração inicial

  • Comece com 1 página e 3 workflows — pessoal (classificação de inbox, briefing diário, rascunho de atualização para investidores), voltado ao cliente (síntese de ligações, classificação de tickets, enriquecimento de leads), interno (geração de testes, extração de faturas, narrativa de métricas semanais)
  • Experimentar coisas demais ao mesmo tempo dispersa a atenção e leva ao modo de falha mais comum: 20 pilotos inacabados

Etapa 2 - Construir o sistema de contexto (Build The Context System)

• Contexto é a memória operacional (operating memory) de uma startup AI-native: o lugar onde tudo o que a empresa sabe sobre si mesma fica armazenado para que os agentes possam ler
  • Modelos podem ser trocados, mas o contexto é o verdadeiro ativo exclusivo da empresa — é o que separa um agente que trabalha como cofundador de um agente que trabalha como temporário confuso
  • Se revisar saídas leva mais tempo do que reescrevê-las, o problema não está no prompt nem no modelo, mas no fato de o agente não conhecer suficientemente a empresa

• Método de diagnóstico semanal

  • Dê uma tarefa representativa a um agente novo com apenas o contexto do workspace e peça três próximas ações
  • Se ao menos duas sugestões forem fortes, o contexto está funcionando; se vierem três respostas genéricas, o contexto é fraco e prompt nenhum vai salvar

• Baseado em repositório Git

  • Comece com um único repositório Git compartilhado que todos da equipe e todos os agentes possam ler — com controle de versão, diff, leitura por humanos e agentes, e sem dependência de runtime de um fornecedor específico
  • No dia 7, o workspace pode ser um único diretório raiz com CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md e GTD.md para trabalho ativo
  • Mantenha tudo em 40 a 60 linhas escritas à mão — isso é melhor do que 400 linhas de texto gerado com listas densas do que evitar

• Dividir por fronteiras de permissão

  • Conforme a empresa cresce, use um repositório compartilhado da empresa + repositórios privados por função (vendas, produto, engenharia, finanças, suporte), ou repositórios privados por projeto/cliente + uma raiz compartilhada para toda a empresa
  • Em escala enterprise, conceda permissões por diretório ou repositório em um servidor Git privado como Gitea self-hosted, GitHub Enterprise ou GitLab
  • O harness interno Goose, da Block, lê o mesmo fluxo de artefatos com escopos por função; no momento em que os escopos se desalinhavam, ele começava a misturar falas públicas com contexto privado de negociação — fronteiras importam muito

• Três tipos de dados que entram no sistema

  • Conectores — coletam dados externos de SaaS, APIs, servidores MCP, email, calendário, CRM, suporte, analytics, GitHub, Linear, Stripe, warehouse e documentos
    • Todo conector precisa de identificadores, permissões por escopo, logs de auditoria e credenciais gerenciadas; sem isso, vira o maior buraco de segurança — uma camada de IAM como Zitadel cuida da disciplina de identidade
    • No trabalho de execução de código MCP da Anthropic, o uso de contexto caiu de cerca de 150 mil tokens para cerca de 2 mil tokens, uma redução de 98,7%, em comparação com a abordagem de pré-carregar todas as definições de ferramentas pelo padrão de sistema de arquivos em pasta de servidor
  • Dados gerados pela empresa — specs, resumos de clientes, decisões, aprendizados, notas de projeto, regras operacionais; por padrão, em Markdown
    • A regra mais importante é separar bruto (raw) e destilado (distilled) — uma transcrição de ligação é o bruto; decisões tomadas nessa ligação, objeções do cliente, responsável pelo follow-up e risco de renovação são o destilado, ou seja, o que o agente realmente consulta
    • Mantenha o log de decisões em formato append-only, uma por linha, para que o raciocínio acompanhe a conclusão
  • Bancos de dados e streams — onde a fonte já vive, como dados de produto em Postgres, marketing no warehouse e eventos de analytics
    • Não copie cegamente para Markdown; mantenha o banco como fonte primária, dê ao agente um usuário de leitura restrita, documente o schema em um arquivo para agentes (data-models/postgres.md) e explicite consultas e escritas permitidas
    • Por padrão, configure o agente para não conseguir apagar dados de produção — o incidente da Replit em meados de 2025, em que um agente de programação apagou o banco de produção durante uma sessão, relembra que instruções em prompt não são fronteiras de segurança

• Versão avançada e rastreamento de fontes

  • Grafo de contexto estruturado — antes de consultar, o agente processa a fonte em entidades e relações como pessoas, empresas, objeções, compromissos, pedidos de funcionalidade, risco de renovação, follow-ups, datas, decisões e links de origem
    • Em vez de guardar a transcrição, extraia o conteúdo e encadeie ligações da mesma pessoa ou projeto, para responder a perguntas como “Qual é o risco de renovação da Vandelay Industries?” citando as linhas exatas em que isso foi dito
  • Todo resumo precisa poder ser rastreado até a fonte — transcrição, ticket, commit, fatura ou linha de banco —; sem fonte, acumulam-se resumos plausíveis porém impossíveis de verificar, e no primeiro erro a confiança no agente inteiro desmorona
    • Com fonte, o agente se torna auditável, permitindo que um membro da equipe clique uma vez para verificar a origem e resolver divergências em segundos

Etapa 3 - Escolher a automação mais simples (Choose The Simplest Automation)

• Não transforme todos os fluxos de trabalho em agentes — os melhores sistemas são uma mistura de scripts, pessoas assistidas por IA, fluxos de trabalho determinísticos e agentes
  • O papel do fundador é escolher a ferramenta mais leve que ainda supere o padrão de qualidade e possa operar com segurança

• Aplicação por ferramenta

  • Script — etapas determinísticas (exportar relatórios, converter CSV, executar testes, verificar links, validar JSON, formatar o pacote semanal de métricas)
  • Pessoa assistida por IA — saídas que exigem julgamento antes de sair da empresa (atualizações para investidores, e-mails do fundador, copy de preços, notas de contrato)
  • Workflow — quando as etapas são conhecidas de antemão (coletar chamadas → resumir → extrair objeções → escrever notas no CRM → gerar acompanhamento), com LangGraph, Temporal, Inngest e Prefect cuidando de ordem, retries e observabilidade
  • Agente — quando não dá para definir o caminho antecipadamente (investigar bugs em produção, pesquisa de mercado, casos anômalos de suporte, contas de clientes emboladas)
    • O agente bb da Browserbase carrega arquivos de skill e permissões de escopo diferentes para cada tarefa como um agente geral voltado ao Slack — melhor do que criar bots separados por tarefa (porque os bots acabam se desalinhando com o tempo)

• Harness — camada de segurança em 6 etapas

  • Preflight — verificar contexto e permissões antes de o agente gastar tokens
  • Plan — decompor a tarefa e expor a etapa de proposta
  • Approve — uma pessoa ou um gate de modelo julgador bloqueia planos ruins antes da execução
  • Execute — executar a tarefa
  • Verify — validar a saída com testes, schema, rubricas e exemplos
  • Log — registrar o que aconteceu no executável para que a próxima iteração tenha a resposta certa

• Guardrails no código e na configuração (não no prompt)

  • O prompt "não apague dados de produção" não é uma fronteira de segurança
  • Itens inegociáveis — limite de execuções e de custo diário, limite de retries, profundidade máxima de chamadas de ferramenta, credenciais com escopo por agente, proibição de escrita em produção sem aprovação, proibição de auto-merge de código, kill switch para toda a frota
  • Os incidentes de geração recursiva ocorridos ao longo de 2025 (agentes chamando agentes-filhos sem parar) geraram custos reais até que os harnesses conseguissem acompanhar — os limites precisam estar no runtime, antes que o modelo tenha a chance de ignorar instruções

Etapa 4 — Codificar skills e evals (Encode Skills And Evals)

• Até aqui foi tudo preparação; codificar trabalho repetitivo como skills e pontuar com evals é o motor que faz a empresa crescer um pouco, em juros compostos, toda semana
  • Skills são instruções reutilizáveis + exemplos para tarefas repetidas — depois de executar manualmente duas vezes, codifique as partes recorrentes
  • Toda skill precisa de uma forma clara — escopo, entradas, contexto a carregar, procedimento, formato de saída, exemplos, regras de escalonamento, responsável, log de execução
  • Se não estiver escrito o que ela recebe, o que devolve, quando pedir ajuda e quem mantém, isso não é uma skill, é só um prompt longo

• Exemplo de template de skill (customer-call-synthesis)

  • Scope: chamada comercial após obtenção da gravação / Inputs: gravação, histórico da conta, contexto do produto, oportunidade em andamento
  • Load: ICP, preços, roadmap do produto, taxonomia de objeções / Steps: extrair fatos → agrupar objeções → identificar riscos → redigir acompanhamento
  • Output: notas de CRM, briefing do cliente, pedido de feature, próximas ações / Examples: 3 chamadas anteriores com notas esperadas
  • Escalate: questões legais/de segurança, risco de churn, preço enterprise / Owner: revenue lead / Eval: 30 chamadas passadas com campos de extração esperados

• Comece por skills amigáveis ao fundador

  • Síntese de chamadas com clientes — extrair objeções, pedidos de feature, riscos, promessas e próximas ações da transcrição bruta
  • Triagem da caixa de entrada — organizar mensagens de investidores, clientes, recrutamento e operações, e rascunhar respostas para os três primeiros tipos
  • Atualização para investidores — escrever a narrativa a partir de métricas e decisões, com citação dos dois lados
  • Análise da página de preços — comparar a página ao vivo com o log mais recente de objeções de clientes
  • Narrativa semanal de métricas — explicar o que mudou, o que quebrou e o que verificar
  • Geração de testes — transformar especificações em testes e em um rascunho de PR

• As 3 camadas de eval (nessa ordem, acumulando)

  • Primeiro, ground truth rotulado manualmente — uma pessoa marca em exemplos reais o que é uma boa saída
  • Segundo, checagens determinísticas — fornecem veredito claro a custo zero (validade do schema, números consistentes com a fonte, links que abrem, citações existentes, testes aprovados)
  • Terceiro, julgamento por LLM — apenas para o que as checagens determinísticas não alcançam (qualidade da escrita, sentimento, aderência ao briefing); um modelo pequeno e rápido basta, mas antes de confiar é preciso calibrá-lo com exemplos marcados por humanos

• Estudo de caso: síntese de chamadas com clientes

  • O revenue lead marcou 30 chamadas passadas — fatos importantes, objeções, riscos, acompanhamentos
  • Verificação determinística — exatidão de nomes, valor contratual e da semana da data de acompanhamento; se o briefing soa como a chamada fica a cargo do julgamento por LLM
  • Após cerca de 50 execuções, geralmente quebram as mesmas duas coisas — falha em rastrear os interlocutores em chamadas com 3 ou mais pessoas, ou fusão de duas objeções distintas em uma só — corrige-se isso no nível do cluster e reescreve-se até o comportamento ficar consistente

• Estudo de caso: classificação de leads outbound

  • O fundador marcou 300 leads passados com yes/no para aderência ao ICP
  • Checagens mecânicas — se a empresa existe de fato, se o site carrega, se o número de funcionários foi preenchido / o resto fica para julgamento por LLM contra a descrição do ICP
  • Quando o eval está pronto, loops open source de evolução de prompts (GEPA, DSPy) reescrevem durante a noite o prompt de classificação comparando com os rótulos — o fundador não lê o prompt final; só o resultado do eval importa

• As 5 etapas de maturidade de eval

  • 1. revisar manualmente um exemplo → 2) pontuar poucos casos com uma rubrica escrita → 3) aplicar essa rubrica a 20–300 casos passados → 4) testar com um conjunto holdout que o agente nunca viu → 5) acompanhar a métrica de negócio que a skill deveria mover

• Manter bom estado após o lançamento — 6 números toda semana

  • taxa de aceitação, taxa de override, custo por execução, cycle time, tempo de revisão, número de incidentes
  • A taxa de aceitação é o principal — abaixo de cerca de 70% (edições triviais contam como aceitação), ainda não está pronto para elevar o nível de autonomia
  • Quando a taxa de aceitação está baixa, reescrever o prompt quase nunca é a resposta; normalmente é uma de quatro coisas — adicionar contexto no runtime, estreitar o escopo da skill, adicionar exemplos funcionais ao arquivo, escrever regras claras de escalonamento para casos que ela não deveria assumir

Etapa 5 — Tornar a equipe AI-native (Make The Team AI-Native)

• O fundador começa primeiro — o caminho mais rápido para migrar a equipe para um novo modo operacional é mostrar ao vivo dentro do contexto da empresa
  • Demonstre o briefing matinal puxado durante a noite do calendário, caixa de entrada e Slack; a síntese de clientes das chamadas de ontem; o PR de testes que o agente conectou à spec; e o rascunho de atualização para investidores criado a partir do último pacote de métricas
  • O objetivo é calibração — ver diretamente o que a camada de agentes consegue e não consegue fazer
  • Jack Dorsey passou horas todas as manhãs de 2025 operando essas ferramentas diretamente antes de reorganizar a Block — isso levou a uma grande reestruturação de eficiência, e a decisão veio de uma liderança que usou agentes na prática

• Instale no primeiro dia; o onboarding termina com um entregável

  • Todos os integrantes saem da primeira sessão com um entregável publicável naquele dia (briefing de cliente organizado, macro de suporte, PR de testes, crítica da página de preços) — treinamento que não produz trabalho real é esquecido na semana seguinte
  • A ferramenta Glass da Ramp saiu de 20 usuários diários para cerca de 700 em 3 meses com a regra de que cada sessão de onboarding terminava adicionando 1 nova skill ou artefato da nova pessoa à biblioteca compartilhada

• O papel humano cresce

  • Pessoas desenham o sistema, são donas das relações, julgam a saída e carregam a responsabilidade / agentes executam
  • Integrantes que só operam tarefas estreitas ficam expostos nesse modelo; quem transforma julgamento em instruções, exemplos e evals vale mais do que antes

• Contratação também muda

  • O critério para abrir uma vaga sobe — parte do que antes exigia contratação agora é skill, então novas funções só são atribuídas ao que realmente precisa de uma pessoa
  • Na contratação, em vez de curiosidades gerais, dê um projeto grande demais para ser concluído manualmente no tempo dado e observe como a pessoa orquestra agentes — veja julgamento, gosto e capacidade de recuperar quando o agente sai da rota
  • Exemplo real — analista: em 3 horas, um relatório real com coleta de fontes, extração de evidências e briefing refinado; engenheiro: em um dia, replicar uma superfície real de produto ou construir uma ferramenta interna a partir de uma spec (com testes); growth: mapa de mercado e plano de campanha para 50–100 empresas (scraping, clusterização, redação, priorização) — o ponto central é que tudo seja impossível de concluir manualmente no prazo

Etapa 6 - operar a startup como um loop de feedback (Run As A Feedback Loop)

• Startups AI-native melhoram seu sistema operacional toda semana — voltam ao início e recomeçam
  • O review deve cobrir: o que o agente fez, os pontos em que humanos fizeram override, evals que falharam, contexto ausente, habilidades que precisam ser refinadas, workflows a eliminar, workflows em que vale elevar o nível de autonomia

• Executar dois loops ao mesmo tempo

  • Loop interno — melhorar o trabalho existente (custo por execução ↓, cycle time ↓, incidentes ↓, tempo de revisão por artefato ↓)
  • Loop externo — explorar o seguinte (novos segmentos de clientes, ideias de produto, mudanças de preço, parcerias, movimentos da concorrência, mudanças regulatórias, risco de churn), com agentes em background fornecendo candidatos 24 horas por dia e humanos escolhendo o que perseguir

• Fábrica de software (a maior parte do loop interno)

  • Humanos escrevem especificações e testes, e os agentes implementam de acordo com eles; verificações determinísticas são executadas por conta própria e humanos revisam antes do merge
  • Comece onde os critérios de aceitação são claros e o raio de impacto é pequeno — geração de testes, upgrades de dependências, migrações, ferramentas internas, scaffolds de integração, scripts de QA, correções automáticas de segurança
  • Duas hard rules — nada é merged automaticamente, nenhum agente escreve em produção
    • Até a Cursor, mesmo executando agentes autônomos em nuvem em larga escala, mantém um gate de revisão humana para merges até o início de 2026 — esse gate permite escalar o restante com segurança

• Sistema de aprendizado de mercado (loop externo)

  • Registros de chamadas, extração de objeções, clusterização de pedidos de funcionalidades, acompanhamento de concorrentes, observação de mudanças de uso, leitura de padrões de suporte, estudo de negócios perdidos
  • Transforme descobertas em hipóteses e teste as mais fortes — conversas com clientes, testes de landing page, experimentos de produto, novas queries sobre os dados
  • Agentes propõem e humanos escolhem — se você deixar tanto a formulação quanto a decisão da estratégia para os agentes, eles acabam em um consenso morno ou otimizam, como quem sobe uma ladeira, a métrica mais fácil de elevar

• O núcleo da autoaperfeiçoamento em nível de empresa = capacidade de escrever evals

  • Rotule manualmente centenas de exemplos como bons/ruins, crie evals e conecte-os ao loop de evolução de prompts — frameworks como GEPA e DSPy propõem mutações de prompt com pequenos modelos de reflexão, e os evals classificam os resultados no conjunto rotulado para implantar o vencedor, repetindo o processo
  • Fundadores escrevem os evals e leem os clusters de falhas, mas não escrevem nem leem os prompts evoluídos
  • O que trava o avanço não é a capacidade do agente, e sim se você consegue codificar o critério do que é bom — saber programar ajuda, mas não é o gargalo; um especialista de domínio que consiga marcar saídas de forma confiável como boas/ruins pode operar todo o loop
  • Eval é o artefato central que sustenta a carga, e no momento em que a escrita de evals para, o crescimento composto da empresa também para

Conclusão

• O que é necessário não é genialidade nem uma grande equipe, mas a disciplina de mapear o trabalho, acumular contexto, escrever evals e girar o loop toda semana — agora que todos usam o mesmo modelo, o sistema operacional é a arma secreta