Por qué la capa de aplicaciones no está muerta
La pregunta que no dejo de recibir de fundadores y posibles empleados: ¿queda algo por construir en la capa de aplicaciones de IA, o OpenAI y Anthropic van a acabar con todo?
Hay un tipo particular de psicosis de IA detrás de esta pregunta. Algunos han concluido que los únicos lugares duraderos para evitar la clase baja permanente son dentro de un gran laboratorio o en la frontera construyendo en robótica, hardtech o similares – en teoría, cualquier cosa que "los laboratorios no puedan tocar". Si cada pieza de software está a punto de ser devorada, ya sea por Codex o Claude absorbiendo el trabajo directamente, o por un modelo futuro que hará innecesario lo que hayas construido, ¡entonces corre!
Mira, yo soy tan maximalista de la IA como casi cualquiera, y creo que tienen razón a medias. Los laboratorios realmente vienen por una gran parte de la superficie de aplicaciones. Pero "la capa de aplicaciones" no es solo una oportunidad homogénea. El marco correcto es si estás en el Camino de Baldosas Amarillas o en otro lugar de Oz.
El Camino de Baldosas Amarillas es nuestra abreviatura para el camino que recorren los laboratorios, donde están comprometiendo recursos extraordinarios. La razón por la que los laboratorios son los más adecuados para problemas como la generación de código, la escritura o la creación de imágenes es porque estos problemas mejoran con la capacidad bruta del modelo: cada dólar gastado en pre-entrenamiento y post-entrenamiento mejora la calidad del producto. Mientras tanto, el resto de Oz está habitado por problemas más complejos, a menudo verticales, que no son tan simples como darle a un usuario empresarial una herramienta horizontal con acceso a herramientas estándar y uso de computadora. El valor proviene menos de la capacidad bruta del modelo subyacente (¡aunque eso sigue siendo importante!) que del andamiaje que lo rodea para que el resultado sea confiable, compatible y operativo dentro de una industria específica.
Estamos viendo esto desarrollarse en tiempo real mientras OpenAI y Anthropic le están diciendo efectivamente al mercado que no pueden resolver todos los problemas con un compañero de trabajo de IA genérico. Han anunciado empresas conjuntas masivas con despliegue adelantado para construir compañías enteras en torno a la configuración y personalización de sus modelos para la empresa. No inviertes miles de millones en esos programas si crees que el próximo lanzamiento del modelo lo va a resolver.
Así que si quieres hacerte rico construyendo aplicaciones de IA – evita el camino de baldosas amarillas y construye en otro lugar de Oz. Esto es lo que hemos aprendido, y lo que algunos de los fundadores de nuestro portafolio han aprendido, sobre lo que funciona.
El Camino de Baldosas Amarillas
Si estás comenzando una empresa, el Camino de Baldosas Amarillas es el camino más obvio para seguir, pero es el más peligroso. Toma un modelo de alto rendimiento, conecta algunos conectores estándar (como G Drive, Slack, Salesforce, Notion, GitHub) y pon una capa de orquestación de agente encima. ¡Magia!
El problema con esto es que esto es lo que los laboratorios están haciendo con Cowork y Codex. Obviamente, ellos son dueños del modelo, lo que les da mejores márgenes, control y la capacidad de ejercer poder de fijación de precios sobre cualquiera que esté río abajo. Pero quizás lo más importante es que también son dueños de las decisiones arquitectónicas que definen para qué están construidos sus productos para resolver bien. Hasta ahora han sido deliberados sobre el patrón de modelo más llamadas a herramientas, y esto es exactamente lo que requiere el trabajo horizontal de pocos pasos en el camino. Incluso si una startup pudiera de alguna manera superar a Codex o Claude Code, los laboratorios tienen brazos de distribución masivos y el halo de marca más grande en IA.
Si eres una empresa de aplicaciones de IA que ejecuta ese manual con los mismos conectores, sin subagentes ni configuración debajo, y sin distribución, probablemente estás caminando por un camino a ninguna parte.
El resto de Oz
No todo es pesimismo para las startups. Hay una enorme oportunidad fuera del Camino de Baldosas Amarillas, donde las startups tienen un camino claro para ser dueñas de su cliente y resolver problemas complejos.
Estos negocios están construyendo experiencias de agente donde el modelo se entreteje a través de una compleja red de herramientas, automatizaciones e integraciones (léase: software), lo que lleva a la mayoría de estas startups a ser verticales por defecto. Pueden enfocarse en trabajo de múltiples pasos y múltiples actores, con subagentes para tareas específicas de roles y verticales, a las que Anthropic y OpenAI no pueden llegar con plataformas horizontales: recopilar contexto a través de sistemas, luego enrutar a través de múltiples humanos que tienen que aprobar en diferentes etapas. A menudo involucra uno o más sistemas heredados, tiende a necesitar resultados deterministas donde la ambigüedad no es aceptable, y en ocasiones está vinculado a algún resultado comercial valioso. Los laboratorios entienden cuán valiosos son estos problemas: por eso están construyendo sus propias tiendas de configuración subcontratadas, y por qué existe toda una clase de mercado premium de negocios de aprendizaje por refuerzo.
Por qué el resto de Oz no será propiedad del Mago
La respuesta a lo anterior sería que hasta la fecha, ha sido una apuesta bastante mala apostar en contra de que los modelos/laboratorios mejoren. Probablemente seguirán mejorando y eventualmente se comerán el mercado atendido por estos negocios de la capa de aplicaciones.
Los laboratorios sin duda mejorarán, pero diría que hay algunas formas en que el resto de Oz puede defenderse con el tiempo:
Volantes de datos y aprendizaje:
Gran parte de lo que internalizas no está en ningún conjunto de entrenamiento: normas industriales no escritas, estándares no documentados, el conocimiento tribal que vive en las cabezas de los profesionales. Nada de eso está en la web pública. Ninguna cantidad de cómputo de entrenamiento sustituye estar dentro de los flujos de trabajo donde realmente vive este conocimiento. Hay dos volantes apilados uno sobre otro aquí: uno entre clientes – patrones que se acumulan a medida que ves más variantes del mismo problema – y uno dentro del cliente – el porqué detrás de decisiones específicas, las excepciones no dichas, las reglas prácticas de la empresa que solo surgen a través de la interacción real con el sistema.
Incluso si los datos del cliente no se pueden usar entre clientes, las empresas de aplicaciones podrán aprovechar el reconocimiento de patrones entre tipos de problemas de clientes y usarlo para informar la arquitectura correcta para problemas futuros. Una empresa que ha ejecutado sus agentes a través de cien revisiones legales, mil ciclos de suscripción de seguros o diez mil campañas de SDR ha internalizado la forma del problema de una manera que el próximo participante no puede replicar iniciando un agente nuevo por primera vez.
Un agente horizontal podría en principio construir la misma infraestructura de aprendizaje. La razón por la que no lo hace, más allá del enfoque puro, es la UX: capturar este tipo de conocimiento depende completamente de las superficies de flujo de trabajo que le das al usuario, y los jugadores verticales pueden moldear esas superficies alrededor de exactamente lo que su flujo de trabajo necesita sacar a la luz. Las herramientas horizontales no pueden. Los conjuntos de evaluación, las salidas etiquetadas y las taxonomías de casos límite pueden acumularse en un volante de datos específico de la vertical que puede alimentar el ajuste fino que el próximo participante no puede generar sin una exposición de producción comparable. Si esto es posible depende de los derechos de datos, el volumen de exposición de producción acumulado y la estructura de los contratos con los clientes, pero el reconocimiento de patrones se acumula independientemente.
Gestión de la variabilidad y complejidad del modelo: Los laboratorios ya están enrutando internamente – diferentes clases de modelo para diferentes solicitudes, conjuntos bajo el capó. Lo que no pueden hacer es enrutar entre proveedores, o evaluar el modelo de un competidor para una subtarea específica, o usar un ajuste fino de código abierto para la parte estrecha donde realmente es mejor. La empresa del Resto de Oz elige el modelo correcto para cada subtarea en todo el mercado de modelos, no solo lo que envía su laboratorio matriz. También hace el trabajo que nadie quiere hacer – volver a ejecutar evaluaciones en las actualizaciones, recalibrar indicaciones para los casos límite del cliente, implementar sin romper la producción – cada vez que llega un nuevo modelo. Los laboratorios no están haciendo esto en nombre del cliente; te venden su próximo modelo y te dicen que migres. La empresa del Resto de Oz absorbe la migración. Lo que el cliente obtiene es la mejor inteligencia disponible en todo el mercado, más continuidad a través de cada actualización.
Optimización de costos: Ejecutar cada consulta a través de Opus 4.7 es el camino más rápido hacia márgenes brutos negativos. Las mejores empresas del Resto de Oz enrutan a través de niveles de modelos – modelos fronterizos para las tareas más difíciles, nivel medio para el grueso, modelos personalizados o ajustados más pequeños donde se han ganado el derecho a usarlos. Algunas ahora están post-entrenando sus propios modelos además de eso, optimizándolos para el estrecho segmento de trabajo que le importa a su cliente y sirviéndolos a una fracción del costo de una llamada API fronteriza. Los laboratorios fijan el precio del piso: la menor inteligencia disponible a $X. La empresa del Resto de Oz vende lo inverso: el costo en dólares más bajo para el nivel específico de inteligencia que el flujo de trabajo realmente requiere. Eso solo es posible si sabes exactamente qué nivel necesita cada subtarea, lo que los laboratorios estructuralmente no pueden saber en todas las verticales. Se traduce directamente en precios más bajos y controlados para los resultados.
Gobernanza: Hay un valor considerable en convertirse en el plano de control de cómo sus clientes ejecutan la IA en esa vertical – el lugar donde confluyen los permisos, la auditoría, lo que se le permite hacer al agente y lo que el agente realmente hizo. Ese plano de control se construye a partir de barreras de seguridad específicas del caso de uso que se ven completamente diferentes entre industrias y tipos de trabajo. Debido a que son dueños de las herramientas, los flujos de trabajo y los datos que el agente toca de principio a fin, pueden proporcionar resultados deterministas de maneras en que las herramientas horizontales tendrán dificultades. También son la entidad que absorbe la complejidad regulatoria para el comprador final – FRCP y reglas del colegio de abogados en el ámbito legal, HIPAA en el cuidado de la salud, SEC y FINRA en finanzas, regulaciones de seguros estatales, y así sucesivamente. Un jugador horizontal no puede hacer eso de manera creíble sin convertirse en cien verticales diferentes a la vez. Los CIO quieren tener un socio que indique contractualmente que están manejando el cumplimiento para los agentes que están proporcionando.
Todo esto se reduce a lo mismo: enfoque. Eso podría ser una vertical (seguros, legal, contabilidad) o una función realizada en profundidad (ventas, atención al cliente, finanzas). De cualquier manera, el trabajo necesita un equipo que esté concentrado en un conjunto de clientes: sus flujos de trabajo, sus casos límite, sus regulaciones. Los laboratorios no están construidos para eso. Tienen que estar en todas partes, para todos, que es como construyeron el Camino de Baldosas Amarillas en primer lugar. La misma compensación los mantiene fuera del resto de Oz: puedes estar en todas partes a la vez, o puedes ser excelente en una cosa. No ambas.
Ventas como ejemplo – consejos prácticos del CEO técnico de 11x
¿Cómo deberías pensar en esto en la práctica? Aquí hay algunos consejos prácticos de Prabhav Jain, el CEO de 11x.
Concéntrate en los resultados
Un camino táctico para construir una empresa que sea resistente a los laboratorios es simplemente comenzar desde un resultado específico que realmente les importe a tus clientes. Para nosotros, eso fue ayudar a las empresas a generar más pipeline. A partir de ahí, las preguntas se vuelven tácticas. ¿Qué actividades queremos ser dueños de principio a fin que realmente impulsen el pipeline? Descompón cada actividad en tareas. Qué tareas son agénticas y cuáles no. Cuáles requieren una visión compleja del dominio y cuáles no. Los laboratorios también enviarán flujos de trabajo, pero cuando el flujo de trabajo tiene muchos pasos, entradas desordenadas, estado difícil de interpretar o restricciones del mundo real, un mejor modelo por sí solo no te llevará allí. El trabajo recae en la buena ingeniería de software de toda la vida, y los laboratorios no tienen ninguna ventaja sobre una empresa de aplicaciones enfocada en esa superficie. Por ejemplo, aquí hay algunas de las tareas que manejamos, algunas agénticas y otras no: prospección de clientes potenciales basada en señales personalizadas, enriquecimiento de clientes potenciales, investigación profunda de cuentas, buscador de contexto desde CRM, escritor de mensajes específicos del canal, agente de calificación de clientes potenciales y sistema de capacidad de entrega de correos electrónicos. Estas no son tareas que puedas resolver de una sola vez y requieren una profunda ingeniería.
La idea crítica en la analogía de Oz es que aproximadamente la mitad de cualquier flujo de trabajo real que no es agéntico no conlleva ninguna ventaja de laboratorio. No son mejores que tú para escribir el software determinista debajo de la capa del modelo. Y la mitad que es agéntica aún requiere que ajustes, entrenes y restrinjas los modelos contra el resultado que realmente deseas. El conocimiento del dominio a menudo no reside en los datos de entrenamiento generales. Esas habilidades se construyen desde cero para la vertical o función y se introducen en el modelo en el momento adecuado del flujo de trabajo. Cuando nuestros agentes están calificando un cliente potencial entrante por teléfono, tengo que estar entrenado sobre lo que es una buena conversación de ventas para esa industria específica y ese perfil. Eso es trabajo de la empresa de aplicaciones, y se acumula.
Más importante aún, esas habilidades se vuelven obsoletas todo el tiempo porque los negocios evolucionan, por lo que tu capacidad para evolucionar esos flujos de trabajo y contexto se convierte en una ventaja competitiva. Por ejemplo, cuando comenzamos nuestro producto de alcance por correo electrónico a escala, los correos electrónicos escritos con "IA" apenas comenzaban a entrar en juego. Avancemos hasta hoy, la gente tiene un sentido afinado de los correos electrónicos escritos por IA versus humanos y, crucialmente, esto cambia cada pocos meses. Nuestros agentes tienen que adaptarse constantemente dada la dinámica del mercado, pero aquí es donde se construye el foso. De hecho, a pesar de esta dinámica, nuestras tasas de respuesta positiva se han multiplicado por 4 en los últimos meses y hemos generado cientos de millones en pipeline para nuestros clientes.
Trabaja en problemas donde la complejidad es alta
Los problemas complejos son donde se desbloquea el verdadero valor comercial. De lo contrario, te encontrarás construyendo una capa delgada.
Descompón cualquier problema comercial suficientemente complejo y el desorden aparece rápidamente. Aquí hay un ejemplo del mundo GTM que parece trivial: no deberías contactar a un contacto en una empresa si esa empresa ya es cliente. Pero no lo es en absoluto. Tal vez tengas el dominio asociado a la empresa en tu CRM. ¿Qué pasa con empresas con docenas de subsidiarias? ¿Qué pasa si el registro del CRM tiene el dominio de la empresa matriz? ¿Qué pasa si un campo de coincidencia desactualizado en Salesforce envía un pitch en frío al CRO de un cliente actual? Los datos del mundo real son desordenados. Los humanos luchan con ellos. Los modelos no superan mágicamente esa barra. Poner orden en ese desorden requiere agentes construidos específicamente para la forma particular del problema, no un copiloto de propósito general apuntado a un CRM. De hecho, según los datos que tenemos, nos hemos dado cuenta de que la calidad y frescura de nuestros datos es mucho mayor que la de nuestros clientes, por lo que por defecto, nos anclamos en los nuestros.
Las barreras de seguridad no son solo para evitar que sucedan cosas malas. Eso es por lo que tus clientes te pagan.
Las barreras de seguridad están severamente subestimadas. Incluso dentro del mismo producto, cada caso de uso necesita las suyas propias. Para nosotros, un prospecto de servicios financieros regulados exige garantías diferentes a las de un cliente SaaS de mercado medio, y esas garantías se transmiten a cómo se le permite escribir al agente, a quién puede contactar, qué datos puede tocar, qué puede decir en una llamada y cómo se registra cada decisión.
Un sistema único para todos colapsa bajo esa variación. Las barreras de seguridad deben construirse por caso de uso, configurarse por cliente y auditarse continuamente, y ese trabajo recae directamente en la empresa de aplicaciones. Es por eso que tenemos FDE y estrategas de despliegue técnico que necesitan ajustar según los requisitos de cada cliente. Por ejemplo, trabajamos con una institución F1000 para hacer outreach saliente por voz con consentimiento a su gran base de clientes PYME. Las primeras iteraciones tuvieron bajas tasas de respuesta – tuvimos que iterar rápidamente y aprender cómo lograr que este tipo específico de audiencia se involucrara en los primeros 10 segundos de la llamada. Los dueños de negocios PYME se comportan de manera muy diferente a los compradores B2B más grandes o a los consumidores. Ahora generamos más oportunidades de venta para ellos en un día de lo que todo su equipo de ventas para ese segmento generaba en un mes.
Seguros como ejemplo – consejos prácticos del CEO de FurtherAI
Ventas es un ejemplo. Los seguros son otro, y plantea el mismo punto desde un ángulo diferente. Así es como Aman Gour, CEO de FurtherAI, piensa sobre construir fuera del camino:
Cuando comenzamos a implementar IA dentro de operaciones reales de seguros, seguíamos escuchando una suposición particular: el modelo es la inteligencia, y el flujo de trabajo es solo un andamiaje a su alrededor.
Cuanto más trabajamos con aseguradoras, más convencidos nos volvimos de que esto está al revés.
En los seguros, gran parte de la inteligencia vive dentro del flujo de trabajo mismo. Dos aseguradoras pueden pasar una solicitud a través de lo que parece el mismo camino: solicitud, revisión, cotización, emisión. Pero el camino es la parte fácil. Lo que separa a las dos aseguradoras es todo lo que hay dentro: qué riesgos se escalan, qué señales de pérdida importan, qué regla de apetito gana cuando dos de ellas entran en conflicto, cuándo un humano tiene que aprobar, qué datos externos se obtienen y cómo se documenta la decisión final.
Esa lógica no vive en un motor de reglas limpio. Está distribuida a través de SOP, revisiones de gerentes, filosofía de suscripción, apetito específico de la aseguradora y años de experiencia operativa. Gran parte no está escrita en una forma que un modelo pueda simplemente leer.
Es por eso que no creemos en un agente puro que razone desde cero cada vez, y no creemos en un flujo de trabajo rígido que se rompa en el momento en que la realidad se vuelve desordenada. En cambio, hemos estado construyendo flujos de trabajo agénticos. El flujo de trabajo te da repetibilidad, auditabilidad y control de costos. El agente maneja la variabilidad y se recupera cuando el camino feliz se rompe. El humano permanece en el bucle para las decisiones de juicio donde la responsabilidad importa.
En el día uno, esto automatiza el trabajo manual. Pero con el tiempo, cada escalamiento se convierte en una señal, cada excepción es una retroalimentación y cada corrección humana muestra dónde el manual estaba incompleto. Con el tiempo, el flujo de trabajo deja de ser un guion y comienza a convertirse en la memoria operativa de la aseguradora. Esta es la parte a la que los laboratorios encontrarán difícil llegar. Seguirán enviando mejores modelos y mejores agentes generales, y deberían hacerlo. Pero no se sientan dentro de los flujos de trabajo de producción de una aseguradora el tiempo suficiente para aprender por qué se escaló una cuenta, por qué se rechazó un riesgo, o por qué un suscriptor anuló la guía de apetito y tenía razón al hacerlo.
Esa comprensión solo proviene de ejecutar el flujo de trabajo, en producción, muchos miles de veces. El flujo de trabajo que envías el día uno no es el foso. El bucle que el uso en producción crea con el tiempo lo es.
Para nosotros, eso es lo que significa construir fuera del camino.
¿Cómo decides si estás en el resto de Oz o no?
La prueba de herramientas y pasos: ¿Cuántos pasos requiere el trabajo y qué tan complejas son las herramientas que tienes que construir para apoyarlo? Compara una búsqueda horizontal de IA en Google Drive — un paso contra una herramienta con un resultado indulgente, el usuario lee el resumen y vuelve a preguntar si está mal — con una revisión legal de múltiples pasos contra tres años de precedentes de la firma: docenas de pasos a través de muchas herramientas, un resultado que tiene que pasar la revisión del socio y puede necesitar ser argumentado en la corte. Ambos parecen "un agente haciendo trabajo", pero solo uno de ellos requiere el tipo de software profundo que un equipo enfocado tarda años en construir.
La prueba del sistema: ¿Estás construyendo un sistema a través del cual el cliente ejecuta su trabajo, o una herramienta que se sitúa sobre un sistema que ya tienen? Los sistemas son dueños del flujo de trabajo de principio a fin — la captura de datos, la gobernanza, los registros de lo que se hizo — y son a lo que el cliente apunta cuando describe cómo se realiza el trabajo real. Las herramientas, por otro lado, solo añaden inteligencia a un flujo de trabajo que el cliente ya ejecuta. El caso de la herramienta genera ingresos reales y los laboratorios pueden tomarlo porque el cliente no depende de ti como la capa de orquestación. Un ACV alto suele ser una señal de un sistema, ya que los sistemas reemplazan personal real y se pagan en consecuencia, pero no es una garantía. Pregúntate si el cliente aún necesitaría tu herramienta si un laboratorio enviara algo que supuestamente compite directamente contigo. Si es así, estás construyendo un sistema. Si no, eres una herramienta — incluso si tu ACV es alto.
La prueba del fondo de cobertura / P&L: Mientras que el rendimiento del laboratorio se juzga contra puntos de referencia, el rendimiento del resto de Oz se juzga contra el P&L de tu cliente. A tu cliente no le importa que tu modelo haya puntuado bien en SWE-Bench o MMLU — le importa si tu agente cerró el trato, revisó el contrato correctamente o emitió la póliza adecuada. Si están obsesionados con su resultado específico del flujo de trabajo, no con una puntuación de capacidad genérica, estás en el resto de Oz. Si están pagando por capacidad genérica, les estás vendiendo algo que pueden obtener con un puesto de Claude o Codex. Los mejores negocios de agentes van a necesitar ejecutarse como fondos de cobertura — ganando con alfa medido en el P&L del cliente, no en puntuaciones de referencia.
Ambos pueden (y lo harán) ganar
Vamos a ver ganadores masivos tanto dentro como fuera del Camino de Baldosas Amarillas. Los modelos continuarán ganando porque son dueños del modelo y son dueños de la distribución para las herramientas horizontales que han diseñado.
El resto de Oz puede ganar si son dueños del sistema de trabajo — la superficie donde el trabajo de la empresa realmente se ejecuta y los datos que fluyen de él se capturan. Estas empresas son dueñas de la captura de datos, el sistema de acción del flujo de trabajo y la gobernanza. A medida que los flujos de trabajo más complejos maduran en una vertical, se acumulan en una experiencia central de la que el cliente llega a depender. A medida que nuevas generaciones de modelos llegan de los titulares y nuevos participantes, la empresa se convierte en la capa que los integra y los entrega al cliente. El modelo es fungible debajo; el sistema de trabajo no lo es.
La próxima generación de software empresarial se construirá fuera del camino.
Si lo estás construyendo, contáctame: jschmidt@a16z.com.
