Por Qué la Capa de Aplicación 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. Algunas personas han llegado a la conclusión de que los únicos lugares duraderos para evitar la subclase permanente están dentro de un gran laboratorio o en la frontera construyendo en robótica, tecnología dura o similar – 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, soy tan maximalista de la IA como casi cualquiera, y creo que tienen razón a medias. Los laboratorios realmente están viniendo por una gran parte de la superficie de aplicaciones. Pero "la capa de aplicación" no es solo una oportunidad homogénea. El marco correcto es si estás en el Camino de Baldosas Amarillas o en algún 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, conforme 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 desplegadas por adelantado para construir empresas 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 se encargará de ello.
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 nuestros fundadores de cartera 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 a seguir, pero es el más peligroso. Toma un modelo de alto rendimiento, conéctalo con algunos conectores estándar (como G Drive, Slack, Salesforce, Notion, GitHub) y coloca una capa de orquestación de agentes encima. ¡Magia!
El problema con esto es que esto es exactamente 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é aguas abajo de ellos. 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 bajo número de 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 de juego con los mismos conectores, sin subagentes ni configuración debajo, y sin distribución, probablemente estás caminando por un camino que no lleva a ninguna parte.
El Resto de Oz
No todo es pesimismo para las startups. Hay una oportunidad enorme 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 agentes donde el modelo está tejido 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 una clase completa de negocios de aprendizaje por refuerzo en el mercado premium.
Por qué el resto de Oz no será propiedad del Mago
La respuesta a lo anterior sería que hasta la fecha, ha sido un mal negocio apostar en contra de la mejora de los modelos/laboratorios. Probablemente seguirán mejorando y eventualmente se comerán el mercado atendido por estos negocios de la capa de aplicación.
Los laboratorios ciertamente mejorarán, pero argumentarí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 de la industria 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 este conocimiento realmente vive. 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 propia empresa que solo salen a la superficie 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 los clientes, y usar eso 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 simplemente 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 actores verticales pueden moldear esas superficies exactamente alrededor de 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 extremos 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 acumulada 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 pieza 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 su laboratorio matriz envía. También hace el trabajo que nadie quiere hacer — volver a ejecutar evaluaciones en las actualizaciones, recalibrar indicaciones para los casos extremos 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 de frontera para las tareas más difíciles, nivel medio para la mayor parte, modelos más pequeños personalizados o ajustados 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 de frontera. 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, que los laboratorios estructuralmente no pueden saber en cada vertical. 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 los permisos, la auditoría, lo que se le permite hacer al agente y lo que el agente realmente hizo convergen. Ese plano de control está construido con 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 — reglas FRCP y de abogacía en el ámbito legal, HIPAA en el cuidado de la salud, SEC y FINRA en finanzas, regulaciones de seguros estatales, etc. Un actor horizontal no puede hacer eso de manera creíble sin convertirse en cien verticales diferentes a la vez. Los CIOs quieren tener un socio que establezca contractualmente que están manejando el cumplimiento de los agentes que están proporcionando.
Todo esto vuelve 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 extremos, sus regulaciones. Los laboratorios no están construidos para eso. Tienen que estar en todas partes, para todos, que es cómo 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.
Enfócate 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 le 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 poseer de principio a fin que realmente impulsen el pipeline? Descompón cada actividad en tareas. Qué tareas son agenticas y cuáles no. Cuáles requieren conocimiento intrincado 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 y vieja ingeniería de software, 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 agenticas y otras no: prospección de leads basada en señales personalizadas, enriquecimiento de leads, investigación profunda de cuentas, recuperador de contexto del CRM, escritor de mensajes específicos del canal, agente de calificación de leads y sistema de entregabilidad de correos electrónicos. Estas no son tareas que puedas resolver de una sola vez y requieren ingeniería profunda.
La idea crítica en la analogía de Oz es que aproximadamente la mitad de cualquier flujo de trabajo real que no es agentico no conlleva ninguna ventaja del laboratorio. No son mejores que tú para escribir el software determinista debajo de la capa del modelo. Y la mitad que es agentica aún requiere que ajustes, entrenes y limites 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 alimentan al modelo en el momento adecuado del flujo de trabajo. Cuando nuestros agentes están calificando un lead entrante por teléfono, tengo que estar entrenado en 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. Como ejemplo, cuando comenzamos nuestro producto de alcance por correo electrónico a escala, los correos electrónicos escritos por "IA" apenas comenzaban a entrar en juego. Avancemos hasta hoy, la gente tiene un sentido afinado de los correos electrónicos que son 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 han aumentado 4 veces 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 envoltura delgada.
Descompón cualquier problema comercial suficientemente complejo y el desorden aparece rápidamente. Aquí hay un ejemplo del mundo GTM que suena trivial: no debes contactar a un contacto en una empresa si esa empresa ya es cliente. No lo es en absoluto. Tal vez tengas el dominio asociado con la empresa en tu CRM. ¿Qué pasa con las empresas con docenas de subsidiarias? ¿Qué pasa si el registro del CRM tiene el dominio de la matriz? ¿Qué pasa si un campo de coincidencia obsoleto en Salesforce envía un discurso de venta en frío al CRO de un cliente actual? Los datos del mundo real son desordenados. Los humanos luchan con eso. Los modelos no superan mágicamente esa barrera. Sacar orden de ese desorden requiere agentes construidos a propósito para la forma específica del problema, no un copiloto de propósito general apuntando 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 están pagando.
Las barreras de seguridad están severamente subestimadas. Incluso dentro del mismo producto, cada caso de uso necesita las suyas. 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 traducen en 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 tienen que 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 FDEs y estrategas de implementación técnica que necesitan ajustar para los requisitos de cada cliente. Como ejemplo, trabajamos con una institución F1000 para hacer alcance saliente consentido por voz a su gran base de clientes SMB. Las primeras iteraciones tenían bajas tasas de respuesta: tuvimos que iterar rápidamente y aprender cómo hacer que este tipo específico de audiencia se involucrara en los primeros 10 segundos de la llamada. Los dueños de negocios SMB se comportan de manera muy diferente a los compradores B2B más grandes o a los consumidores. Ahora generamos más oportunidades de ventas para ellos en un día que todo su equipo de ventas para ese segmento en un mes.
Seguros como ejemplo – consejos prácticos del CEO de FurtherAI
Las ventas son un ejemplo. Los seguros son otro, y hacen 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 de seguros reales, seguíamos escuchando una suposición particular: el modelo es la inteligencia, y el flujo de trabajo es solo un andamiaje a su alrededor.
Cuantas más aseguradoras con las que trabajábamos, más convencidos estábamos de que esto está al revés.
En seguros, gran parte de la inteligencia vive dentro del propio flujo de trabajo. Dos aseguradoras pueden ejecutar una solicitud a través de lo que parece el mismo camino: solicitud, revisión, cotización, vinculació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 incorporan y cómo se documenta la decisión final.
Esa lógica no vive en un motor de reglas limpio. Está repartida en SOPs, 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 razona desde cero cada vez, y no creemos en un flujo de trabajo rígido que se rompe en el momento en que la realidad se vuelve desordenada. Y en su lugar, hemos estado construyendo flujos de trabajo agenticos. 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 circuito 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 estaba incompleto el manual de procedimientos. Con el tiempo, el flujo de trabajo deja de ser un guión y comienza a convertirse en la memoria operativa de la aseguradora. Esta es la parte a la que los laboratorios les resultará 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 viene 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 toma el trabajo y qué tan complejas son las herramientas que tienes que construir para soportarlo? 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 sienta 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 ocurre el trabajo real. Las herramientas, por otro lado, solo agregan 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 obtenido una buena puntuación en SWE-Bench o MMLU — les importa si tu agente cerró el trato, revisó el contrato correctamente o vinculó la póliza correcta. 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 asiento de Claude o Codex. Los mejores negocios de agentes van a necesitar ejecutarse como fondos de cobertura — ganando en alfa medido en el P&L del cliente, no en puntuaciones de referencia.
Ambos pueden (y van a) ganar
Vamos a ver ganadores masivos dentro y 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 se envían 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 va a construir fuera del camino.
Si lo estás construyendo, contáctame: jschmidt@a16z.com.
