Por que a Camada de Aplicação Não Está Morta
A pergunta que não para de chegar de fundadores e potenciais funcionários: ainda existe alguma camada de aplicação de IA para construir, ou a OpenAI e a Anthropic vão acabar com tudo?
Há um tipo específico de psicose de IA por trás dessa pergunta. Algumas pessoas concluíram que os únicos lugares duráveis para evitar a subclasse permanente são dentro de um grande laboratório ou na fronteira, construindo em robótica, hardtech ou áreas similares – teoricamente, qualquer coisa "que os laboratórios não possam tocar". Se cada pedaço de software está prestes a ser devorado, seja pelo Codex ou pelo Claude absorvendo o trabalho diretamente, ou por um modelo futuro que tornará desnecessário tudo o que você construiu, então corra!
Olha, eu sou um maximalista de IA tanto quanto quase qualquer um, e acho que eles estão meio certos. Os laboratórios realmente estão vindo para uma enorme fatia da superfície de aplicação. Mas "a camada de aplicação" não é apenas uma oportunidade homogênea. O enquadramento correto é se você está na Estrada de Tijolos Amarelos ou em algum outro lugar de Oz.
A Estrada de Tijolos Amarelos é nossa abreviação para o caminho que os laboratórios estão percorrendo, onde estão comprometendo recursos extraordinários. A razão pela qual os laboratórios são mais adequados para problemas como geração de código, escrita ou criação de imagens é porque esses problemas melhoram com a capacidade bruta do modelo: cada dólar gasto em pré-treinamento e pós-treinamento melhora a qualidade do produto. Enquanto isso, o resto de Oz é habitado por problemas mais complexos, muitas vezes verticais, que não são tão simples quanto dar a um usuário empresarial uma ferramenta horizontal com acesso a ferramentas padrão e uso de computador. O valor vem menos da capacidade bruta do modelo subjacente (embora isso ainda seja importante!) do que do arcabouço ao seu redor que torna a saída confiável, compatível e operacional dentro de uma indústria específica.
Estamos vendo isso acontecer em tempo real, enquanto OpenAI e Anthropic estão efetivamente dizendo ao mercado que não podem resolver todos os problemas com um colega de trabalho de IA genérico. Eles anunciaram joint ventures massivas de implantação avançada para construir empresas inteiras em torno da configuração e personalização de seus modelos para o enterprise. Você não despeja bilhões nesses programas se acha que o próximo lançamento de modelo vai resolver tudo.
Então, se você quer ficar rico construindo aplicativos de IA – evite a estrada de tijolos amarelos e construa em outro lugar de Oz. Aqui está o que aprendemos, e o que alguns de nossos fundadores de portfólio aprenderam, sobre o que funciona.
A Estrada de Tijolos Amarelos
Se você está começando uma empresa, a Estrada de Tijolos Amarelos é o caminho mais óbvio a seguir, mas é o mais perigoso. Pegue um modelo de alto desempenho, conecte alguns conectores prontos para uso (como G Drive, Slack, Salesforce, Notion, GitHub) e coloque alguma camada de orquestração agentiva por cima disso. Mágica!
O problema com isso é que é exatamente isso que os laboratórios estão fazendo com o Cowork e o Codex. Obviamente, eles são donos do modelo, o que lhes dá melhores margens, controle e a capacidade de exercer poder de precificação sobre qualquer um que esteja a jusante deles. Mas talvez o mais importante é que eles também são donos das escolhas arquitetônicas que definem para que seus produtos são construídos para resolver bem. Eles têm sido deliberados até agora sobre o padrão de modelo mais chamadas de ferramentas, e isso é exatamente o que o trabalho horizontal de baixo número de etapas na estrada exige. Mesmo que uma startup pudesse de alguma forma superar o Codex ou o Claude Code, os laboratórios têm braços de distribuição massivos e o maior halo de marca em IA.
Se você é uma empresa de aplicativos de IA executando esse manual com os mesmos conectores, sem subagentes ou configuração abaixo deles, e sem distribuição, você provavelmente está andando por uma estrada que não leva a lugar nenhum.
O Resto de Oz
Não é só desgraça e tristeza para startups. Há uma oportunidade enorme fora da Estrada de Tijolos Amarelos, onde as startups têm um caminho claro para serem donas de seu cliente e resolver problemas complexos.
Esses negócios estão construindo experiências agentivas onde o modelo é tecido através de uma teia complexa de ferramentas, automações e integrações (leia-se: software), levando a maioria dessas startups a serem verticais por padrão. Elas podem se concentrar em trabalho multi-etapas e multi-player, com subagentes para tarefas específicas de função e vertical, que a Anthropic e a OpenAI não conseguem alcançar com plataformas horizontais: reunir contexto entre sistemas, depois rotear por vários humanos que precisam aprovar em diferentes estágios. Muitas vezes envolve um ou mais sistemas legados, tende a exigir resultados determinísticos onde a ambiguidade não é aceitável e, às vezes, está ligada a algum resultado comercial valioso. Os laboratórios entendem o quão valiosos esses problemas são: é por isso que estão construindo suas próprias lojas de configuração terceirizadas, e por que existe uma classe inteira de negócios de aprendizado por reforço no mercado premium.
Por que o resto de Oz não será dominado pelo Mágico
A resposta ao que foi dito acima seria que, até hoje, tem sido uma troca muito ruim apostar contra a melhoria dos modelos/laboratórios. Eles provavelmente continuarão melhorando e eventualmente vão comer o mercado atendido por esses negócios da camada de aplicação.
Os laboratórios certamente melhorarão, mas eu diria que há algumas maneiras pelas quais o resto de Oz pode se defender ao longo do tempo:
Volantes de dados e aprendizado:
Muito do que você internaliza não está em nenhum conjunto de treinamento — normas não escritas da indústria, padrões não documentados, o conhecimento tribal que vive na cabeça dos profissionais. Nada disso está na web pública. Nenhuma quantidade de poder computacional de treinamento substitui estar dentro dos fluxos de trabalho onde esse conhecimento realmente vive. Há dois volantes empilhados um sobre o outro aqui: um entre clientes — padrões que se acumulam à medida que você vê mais variantes do mesmo problema — e um dentro do cliente — o porquê por trás de decisões específicas, as exceções não ditas, as regras práticas da própria empresa que só vêm à tona através da interação real com o sistema.
Mesmo que os dados do cliente não possam ser usados entre clientes, as empresas de aplicação poderão alavancar o reconhecimento de padrões entre os tipos de problema do cliente e usar isso para informar a arquitetura certa para problemas futuros. Uma empresa que executou seus agentes através de cem revisões jurídicas, mil ciclos de subscrição de seguros ou dez mil campanhas de SDR internalizou a forma do problema de uma maneira que o próximo participante não consegue replicar ao iniciar um agente novo pela primeira vez.
Um agente horizontal poderia, em princípio, construir a mesma infraestrutura de aprendizado. A razão pela qual não o faz, além do foco puro, é a UX: capturar esse tipo de conhecimento depende inteiramente das superfícies de fluxo de trabalho que você dá ao usuário, e os players verticais podem moldar essas superfícies exatamente em torno do que seu fluxo de trabalho precisa revelar. Ferramentas horizontais não conseguem. Conjuntos de avaliação, saídas rotuladas e taxonomias de casos extremos podem se acumular em um volante de dados específico da vertical que pode alimentar o ajuste fino que o próximo participante não consegue gerar sem exposição de produção comparável. Se isso é possível depende dos direitos de dados, do volume de exposição de produção acumulada e da estrutura dos contratos com clientes, mas o reconhecimento de padrões se acumula independentemente disso.
Gerenciando a variabilidade e complexidade do modelo: Os laboratórios já estão roteando internamente — diferentes classes de modelo para diferentes solicitações, ensembles nos bastidores. O que eles não podem fazer é rotear entre fornecedores, ou avaliar o modelo de um concorrente para uma subtarefa específica, ou usar um ajuste fino de código aberto para a parte estreita onde ele é realmente melhor. A empresa do Resto de Oz escolhe o modelo certo para cada subtarefa em todo o mercado de modelos, não apenas o que seu laboratório-mãe lança. Ela também faz o trabalho que ninguém quer fazer — reexecutar avaliações em atualizações, recalibrar prompts para os casos extremos do cliente, implantar sem quebrar a produção — toda vez que um novo modelo chega. Os laboratórios não estão fazendo isso em nome do cliente; eles vendem a você seu próximo modelo e mandam você migrar. A empresa do Resto de Oz absorve a migração. O que o cliente obtém é a melhor inteligência disponível em todo o mercado, mais continuidade através de cada atualização.
Otimização de custos: Executar cada consulta através do Opus 4.7 é o caminho mais rápido para margens brutas negativas. As melhores empresas do Resto de Oz roteiam entre camadas de modelos — modelos de fronteira para as tarefas mais difíceis, camada intermediária para a maior parte, modelos menores personalizados ou ajustados onde elas ganharam o direito de usá-los. Algumas agora estão pós-treinando seus próprios modelos sobre isso, otimizando-os para a fatia estreita de trabalho que seu cliente valoriza e servindo-os a uma fração do custo de uma chamada de API de fronteira. Os laboratórios definem o piso: a menor inteligência disponível a $X. A empresa do Resto de Oz vende o inverso — o menor custo em dólar para o nível específico de inteligência que o fluxo de trabalho realmente exige. Isso só é possível se você souber exatamente qual nível cada subtarefa precisa, o que os laboratórios estruturalmente não podem saber em todas as verticais. Isso se traduz diretamente em preços mais baixos e controlados para resultados.
Governança: Há um valor considerável em se tornar o plano de controle de como seus clientes executam IA naquela vertical – o lugar onde permissões, auditoria, o que o agente pode fazer e o que o agente realmente fez convergem. Esse plano de controle é construído a partir de barreiras de proteção específicas do caso de uso que parecem completamente diferentes entre indústrias e tipos de trabalho. Por serem donos das ferramentas, dos fluxos de trabalho e dos dados que o agente toca de ponta a ponta, eles podem fornecer resultados determinísticos de maneiras que as ferramentas horizontais terão dificuldade. Eles também são a entidade que absorve a complexidade regulatória para o comprador final — regras FRCP e da Ordem dos Advogados no jurídico, HIPAA na saúde, SEC e FINRA nas finanças, regulamentações estaduais de seguros, e assim por diante. Um player horizontal não pode fazer isso de forma crível sem se tornar cem verticais diferentes ao mesmo tempo. CIOs querem ter um parceiro que declare contratualmente que está lidando com a conformidade para os agentes que está fornecendo.
Tudo isso volta para a mesma coisa: foco. Isso pode ser uma vertical (seguros, jurídico, contabilidade) ou uma função feita em profundidade (vendas, suporte ao cliente, finanças). De qualquer forma, o trabalho precisa de uma equipe que esteja focada em um conjunto de clientes — seus fluxos de trabalho, seus casos extremos, suas regulamentações. Os laboratórios não são construídos para isso. Eles têm que estar em todos os lugares, para todos, que é como construíram a Estrada de Tijolos Amarelos em primeiro lugar. A mesma troca os mantém fora do resto de Oz — você pode estar em todos os lugares ao mesmo tempo, ou pode ser ótimo em uma coisa. Não ambos.
Vendas como exemplo – dicas práticas do CEO técnico da 11x
Como você deve pensar sobre isso na prática? Aqui estão algumas dicas práticas de Prabhav Jain, CEO da 11x.
Foco em resultados
Um caminho tático para construir uma empresa resiliente aos laboratórios é simplesmente começar a partir de um resultado específico que seus clientes realmente valorizam. Para nós, isso foi ajudar empresas a gerar mais pipeline. A partir daí, as perguntas se tornam táticas. Quais atividades queremos possuir de ponta a ponta que realmente geram pipeline? Decomponha cada atividade em tarefas. Quais tarefas são agentivas e quais não são. Quais exigem insights complexos de domínio e quais não exigem. Os laboratórios também lançarão fluxos de trabalho, mas quando o fluxo de trabalho tem muitas etapas, entradas confusas, estado difícil de interpretar ou restrições do mundo real, um modelo melhor sozinho não vai te levar até lá. O trabalho recai sobre a boa e velha engenharia de software, e os laboratórios não têm vantagem sobre uma empresa de aplicação focada nessa superfície. Por exemplo, aqui estão algumas das tarefas que gerenciamos, algumas agentivas e outras não: prospecção de leads com base em sinais personalizados, enriquecimento de leads, pesquisa profunda de contas, buscador de contexto do CRM, escritor de mensagens específico do canal, agente de qualificação de leads e sistema de entregabilidade de e-mail. Essas não são tarefas que você pode resolver de uma só vez e exigem engenharia profunda.
O insight crítico na analogia de Oz é que aproximadamente metade de qualquer fluxo de trabalho real que não é agentivo não carrega vantagem do laboratório. Eles não são melhores do que você em escrever o software determinístico abaixo da camada do modelo. E a metade que é agentiva ainda exige que você ajuste, treine e restrinja os modelos em relação ao resultado que você realmente deseja. O conhecimento de domínio muitas vezes não está nos dados de treinamento gerais. Essas habilidades são construídas do zero para a vertical ou função e alimentadas no modelo no momento certo do fluxo de trabalho. Quando nossos agentes estão qualificando um lead recebido por telefone, tenho que ser treinado sobre o que é uma boa conversa de vendas para aquela indústria específica e aquele perfil. Isso é trabalho de empresa de aplicação, e ele se acumula.
Mais importante, essas habilidades se tornam desatualizadas o tempo todo porque os negócios evoluem, então sua capacidade de evoluir esses fluxos de trabalho e contexto se torna uma vantagem competitiva. Como exemplo, quando começamos nosso produto de outreach de e-mail em escala, e-mails escritos por "IA" estavam apenas começando a entrar em jogo. Avançando para hoje, as pessoas têm uma noção apurada de e-mails que são escritos por IA versus humanos e, crucialmente, isso muda a cada poucos meses. Nossos agentes têm que se adaptar constantemente dada a dinâmica do mercado, mas é aí que o fosso é construído. Na verdade, apesar dessa dinâmica, nossas taxas de resposta positiva aumentaram 4x nos últimos meses e geramos centenas de milhões em pipeline para nossos clientes.
Trabalhe em problemas onde a complexidade é alta
Problemas complexos são onde o valor real do negócio é desbloqueado. Caso contrário, você se verá construindo uma camada fina.
Decomponha qualquer problema de negócio suficientemente complexo e a bagunça aparece rapidamente. Aqui está um exemplo do mundo GTM que parece trivial: você não deve entrar em contato com um contato em uma empresa se essa empresa já for cliente. Não é nada disso. Talvez você tenha o domínio associado à empresa no seu CRM. E quanto a empresas com dezenas de subsidiárias? E se o registro do CRM tiver o domínio da matriz? E se um campo de correspondência desatualizado no Salesforce enviar um pitch frio para o CRO de um cliente atual? Dados do mundo real são confusos. Humanos lutam com isso. Modelos não superam essa barreira magicamente. Trazer ordem a essa bagunça requer agentes construídos sob medida, projetados para a forma específica do problema, não um copiloto de uso geral apontado para um CRM. Na verdade, com base nos dados que temos, percebemos que a qualidade e a atualidade de nossos dados são muito maiores do que as de nossos clientes, então, por padrão, nos ancoramos nos nossos próprios.
Barreiras de proteção não são apenas para evitar que coisas ruins aconteçam. É para isso que seus clientes estão pagando.
Barreiras de proteção são severamente subestimadas. Mesmo dentro do mesmo produto, cada caso de uso precisa das suas próprias. Para nós, um prospect de serviços financeiros regulamentado exige garantias diferentes de um cliente SaaS de médio porte, e essas garantias se desdobram em como o agente pode escrever, quem ele pode contatar, quais dados pode tocar, o que pode dizer em uma chamada e como cada decisão é registrada.
Um sistema único para todos colapsa sob essa variação. As barreiras de proteção têm que ser construídas por caso de uso, configuradas por cliente e auditadas continuamente, e esse trabalho recai diretamente sobre a empresa de aplicação. É por isso que temos FDEs e estrategistas de implantação técnica que precisam ajustar para os requisitos de cada cliente. Como exemplo, trabalhamos com uma instituição F1000 para fazer outreach externo consentido por voz para sua grande base de clientes SMB. As primeiras iterações tiveram baixas taxas de atendimento – tivemos que iterar rapidamente e aprender como fazer esse tipo específico de público se engajar nos primeiros 10 segundos da chamada. Proprietários de negócios SMB se comportam de forma muito diferente de compradores B2B maiores ou consumidores. Agora geramos mais oportunidades de vendas para eles em um dia do que toda a equipe de vendas deles para aquele segmento em um mês.
Seguros como exemplo – dicas práticas do CEO da FurtherAI
Vendas é um exemplo. Seguros é outro, e faz o mesmo ponto de um ângulo diferente. Aqui está como Aman Gour, CEO da FurtherAI, pensa sobre construir fora da estrada:
Quando começamos a implantar IA dentro de operações reais de seguros, continuávamos ouvindo uma suposição particular: o modelo é a inteligência, e o fluxo de trabalho é apenas o arcabouço ao redor dele.
Quanto mais seguradoras com as quais trabalhávamos, mais convencidos ficávamos de que isso está ao contrário.
Em seguros, muita da inteligência vive dentro do próprio fluxo de trabalho. Duas seguradoras podem executar uma submissão através do que parece ser o mesmo caminho: submissão, revisão, cotação, vinculação. Mas o caminho é a parte fácil. O que separa as duas seguradoras é tudo dentro dele: quais riscos são escalados, quais sinais de perda importam, qual regra de apetite vence quando duas delas entram em conflito, quando um humano tem que aprovar, quais dados externos são puxados e como a decisão final é documentada.
Essa lógica não vive em um mecanismo de regras limpo. Ela está espalhada por SOPs, revisões de gerentes, filosofia de subscrição, apetite específico da seguradora e anos de experiência operacional. Muito disso não está escrito em uma forma que um modelo possa simplesmente ler.
É por isso que não acreditamos em um agente puro que raciocina do zero toda vez, e não acreditamos em um fluxo de trabalho rígido que quebra no momento em que a realidade fica confusa. E, em vez disso, estamos construindo fluxos de trabalho agentivos. O fluxo de trabalho te dá repetibilidade, auditabilidade e controle de custos. O agente lida com a variabilidade e se recupera quando o caminho feliz quebra. O humano permanece no loop para os julgamentos onde a responsabilidade importa.
No primeiro dia, isso automatiza o trabalho manual. Mas com o tempo, cada escalação se torna um sinal, cada exceção é um feedback e cada correção humana mostra onde o manual estava incompleto. Com o tempo, o fluxo de trabalho deixa de ser um script e começa a se tornar a memória operacional da seguradora. Esta é a parte que os laboratórios acharão difícil de alcançar. Eles continuarão lançando modelos melhores e agentes gerais melhores, e devem fazê-lo. Mas eles não ficam dentro dos fluxos de trabalho de produção de uma seguradora por tempo suficiente para aprender por que uma conta foi escalada, por que um risco foi recusado ou por que um subscritor anulou o guia de apetite e estava certo ao fazê-lo.
Essa compreensão só vem de executar o fluxo de trabalho, em produção, muitos milhares de vezes. O fluxo de trabalho que você envia no primeiro dia não é o fosso. O loop que o uso em produção cria ao longo do tempo é.
Para nós, é isso que significa construir fora da estrada.
Como você decide se está no resto de Oz ou não?
O teste das ferramentas e etapas: Quantas etapas o trabalho leva, e quão complexas são as ferramentas que você tem que construir para suportá-lo? Compare uma busca horizontal de IA no Google Drive — uma etapa contra uma ferramenta com um resultado tolerante, o usuário lê o resumo e pergunta novamente se estiver errado — a uma revisão jurídica multi-etapas contra três anos de precedentes do escritório: dezenas de etapas em muitas ferramentas, saída que tem que passar pela revisão do sócio e pode precisar ser argumentada no tribunal. Ambos parecem "um agente fazendo trabalho", mas apenas um deles requer o tipo de software profundo que uma equipe focada leva anos para construir.
O teste do sistema: Você está construindo um sistema pelo qual o cliente executa seu trabalho, ou uma ferramenta que fica em cima de um sistema que eles já têm? Sistemas são donos do fluxo de trabalho de ponta a ponta — a captura de dados, a governança, os registros do que foi feito — e são o que o cliente aponta ao descrever como o trabalho real acontece. Ferramentas, por outro lado, apenas adicionam inteligência a um fluxo de trabalho que o cliente já executa. O caso da ferramenta gera receita real e os laboratórios podem tomá-la porque o cliente não depende de você como a camada de orquestração. ACV alto é geralmente um sinal de um sistema, já que sistemas substituem headcount real e são pagos de acordo, mas não é uma garantia. Pergunte a si mesmo se o cliente ainda precisaria da sua ferramenta se um laboratório lançasse algo que supostamente compete diretamente com você. Se sim, você está construindo um sistema. Se não, você é uma ferramenta — mesmo que seu ACV seja alto.
O teste do hedge fund / P&L: Enquanto o desempenho do laboratório é julgado contra benchmarks, o desempenho do resto de Oz é julgado contra o P&L do seu cliente. Seu cliente não se importa que seu modelo tenha pontuado bem no SWE-Bench ou MMLU — eles se importam se seu agente fechou o negócio, revisou o contrato corretamente ou vinculou a apólice certa. Se eles estão fixados no resultado específico do fluxo de trabalho deles, não em uma pontuação de capacidade genérica, você está no resto de Oz. Se eles estão pagando por capacidade genérica, você está vendendo a eles algo que eles podem obter com um assento do Claude ou Codex. Os melhores negócios de agentes vão precisar executar como hedge funds — vencendo no alfa medido no P&L do cliente, não em pontuações de benchmark.
Ambos podem (e vão) vencer
Vamos ver vencedores massivos dentro e fora da Estrada de Tijolos Amarelos. Os modelos continuarão a vencer porque eles são donos do modelo e são donos da distribuição para as ferramentas horizontais que projetaram.
O resto de Oz pode vencer se for dono do sistema de trabalho — a superfície onde o trabalho da empresa realmente executa e os dados que fluem dele são capturados. Essas empresas são donas da captura de dados, do sistema de ação do fluxo de trabalho e da governança. À medida que fluxos de trabalho mais complexos amadurecem em uma vertical, eles se acumulam em uma experiência central da qual o cliente passa a depender. À medida que novas gerações de modelos são lançadas por incumbentes e novos entrantes, a empresa se torna a camada que os integra e os entrega ao cliente. O modelo é fungível por baixo; o sistema de trabalho não é.
A próxima geração de software empresarial será construída fora da estrada.
Se você está construindo isso, entre em contato: jschmidt@a16z.com.
