a16z: Cuando la interfaz de usuario ya no es el producto, ¿qué queda de la ventaja competitiva del software?

Editor’s note: En los últimos veinte años, la barrera competitiva de SaaS se ha construido en gran medida sobre la interfaz de usuario. Paneles, campos, flujos de aprobación y hábitos de usuario no son solo la interfaz de operación, sino que también moldean la forma en que las organizaciones trabajan y el orden de los datos. Cuando la IA puede leer datos directamente, llamar a herramientas y ejecutar procesos, la dependencia de la memoria muscular humana y la adhesión comienzan a disminuir, y la UI ya no es necesariamente la interfaz central del software empresarial.

Esto no significa que los sistemas de registro hayan perdido valor, sino que su carácter defensivo está cambiando: de la UI y los hábitos de uso, hacia modelos de datos, sistemas de permisos, responsabilidades de cumplimiento, lógica de negocio, ciclos de ejecución y redes de colaboración entre múltiples partes. En el futuro, el software verdaderamente con barreras puede dejar de ser solo bases de datos que registran el trabajo humano, para convertirse en sistemas de acción capaces de captar contexto, iniciar tareas, coordinar agentes inteligentes y generar continuamente nuevos datos durante la ejecución.

Cuando el software se vuelve headless (sin interfaz), los problemas centrales del software empresarial también cambian: el valor ya no radica solo en quién posee los datos, sino en quién puede organizar acciones en torno a esos datos.

A continuación, el texto original:

El mes pasado, Salesforce anunció que abrirá su API y lanzó un producto headless (sin interfaz). Esencialmente, esto significa que Salesforce está apostando: en la era de los Agentes, su valor central ya no proviene principalmente de la UI, sino de la capa de datos. Es un re-posicionamiento bastante inteligente.

Sin embargo, también hay que señalar que, desde el punto de vista técnico, esta publicación no parece traer cambios sustantivos significativos. La API que Salesforce ahora presenta como un “producto headless” en realidad ha existido durante muchos años. En otras palabras, esto es más una campaña de marketing típica de Salesforce.

La idea central de este nuevo producto es que los Agentes puedan acceder directamente a los datos del sistema de registros, sin necesidad de interactuar a través de una UI diseñada para humanos. La función tradicional de la UI era ayudar a los usuarios humanos a seguir procesos, gestionar tareas y avanzar en flujos de trabajo; pero tras la intervención de los Agentes, la necesidad de esa capa de interfaz comienza a disminuir.

Lo que realmente merece discusión en este lanzamiento no es solo qué nuevo producto ha lanzado Salesforce, sino que plantea una cuestión más profunda: si se elimina la UI y solo se abre la base de datos subyacente, ¿qué queda de un sistema de registros? ¿En qué se diferencia realmente de una base de datos Postgres, un esquema de datos bien diseñado y un conjunto de API?

Más allá, ¿siguen siendo válidos los factores clásicos que hacían que un sistema de registros tuviera una defensa a largo plazo? ¿O ya han surgido nuevos estándares competitivos?

En la era SaaS, la barrera de los sistemas de registros radica en que los usuarios humanos han vivido durante mucho tiempo en su interfaz. La interfaz soporta hábitos operativos, procesos organizativos y sedimentación de datos, lo que genera costos de migración elevados. Pero en la era de los Agentes, esta ventaja se está erosionando. Los niveles verdaderamente defensivos están desplazándose, por un lado, hacia modelos de datos, sistemas de permisos, lógica de flujos de trabajo y capacidades de cumplimiento; y por otro, hacia efectos de red, generación de datos propia y capacidades de ejecución en el mundo real.

Cuando el software se vuelve headless, ¿hacia dónde se trasladarán realmente las barreras?

La UI solía ser el producto en sí mismo

El sistema de registros (System of Record, SoR) se refiere a una fuente autorizada de hechos sobre ciertos datos comerciales. Es donde se encuentran las “versiones oficiales” de relaciones con clientes, registros de empleados o transacciones financieras, y también es el sistema central que otras herramientas leen y actualizan. CRM es el sistema de registros de datos relacionados con ingresos, HRIS para datos de personal, y ERP para datos financieros y de fondos.

La fortaleza de estos sistemas no radica solo en que almacenan datos, sino en que finalmente se convierten en la “versión de realidad” en la que toda la organización confía para su funcionamiento conjunto.

En los últimos veinte años, lo que Salesforce vendía a los clientes era en realidad un método para que los responsables de ventas gestionaran sus equipos. Los paneles, vistas de pipeline, herramientas de predicción y flujos de información dinámica eran los productos realmente comprados. Su modelo de negocio se basa en vender asientos, que en esencia otorgan acceso a esas funciones. La base de datos subyacente es clave, pero en la experiencia del producto funciona más como una infraestructura implícita.

Es decir, lo que realmente impulsa la adhesión de los usuarios es la UI.

La UI restringe las normas de datos y moldea un lenguaje común: pistas, oportunidades, cuentas de clientes. Permite que miles de representantes de ventas ingresen datos que quizás no estarían dispuestos a registrar de otra forma. Antes, la UI era el mecanismo para mantener la coherencia y la usabilidad de los datos. Salesforce es tan adhesivo que muchos responsables de ventas siguen usando Salesforce en sus nuevos trabajos, no porque su interfaz sea excepcional, sino porque se ha convertido en una memoria muscular.

Pero los Agentes están comenzando a cambiar este modelo. Ya no necesitan interactuar con el software a través de la UI, sino que pueden leer y escribir directamente en los datos subyacentes. Esto ha impulsado una serie de nuevas herramientas y alternativas que saltan la interfaz tradicional. Salesforce no es el único ejemplo: recientemente hemos discutido cómo alrededor de SAP está creciendo un ecosistema más adecuado para llamadas de IA.

Al mismo tiempo, los Agentes que pueden operar en una computadora hacen que factores tradicionales humanos como preferencias, capacitación y contexto no documentado, sean cada vez menos relevantes con el tiempo. En otras palabras, las condiciones para que un sistema de registros sea duradero están cambiando.

Los estándares de evaluación del pasado

Antes de discutir qué cambios traerá la era de los Agentes, es necesario volver a un problema más preciso: ¿qué fue lo que hizo que los sistemas de registros fueran adhesivos en el pasado?

Los primeros factores están relacionados principalmente con cómo los humanos usan el software y sus preferencias. La dificultad para reemplazar un sistema radica en gran medida en la UI, los hábitos de uso, los flujos de trabajo humanos y las estructuras institucionales ya integradas en los procesos organizativos.

Primero, ¿con qué frecuencia se accede a él?

CRM se usa diariamente por los equipos de GTM y otros departamentos relacionados. Esa alta frecuencia de uso lo convierte en una infraestructura crítica. Pero la inercia organizacional, como reuniones, hábitos operativos y ritmos de gestión, que se han formado durante años, suele ser la parte más difícil de migrar. La razón es que muchas veces ni siquiera se reconoce como algo que necesita ser migrado.

Segundo, ¿es solo para escribir o también para leer?

Un sistema de registros verdaderamente adhesivo suele ser bidireccional, con capacidad de lectura y escritura. Por ejemplo, CRM no es solo un sistema de archivo, sino que se lee continuamente. Cada llamada, actualización de etapa o creación de tarea es ingresada por un usuario, y ese usuario también se preocupa por cómo se usará esa data después.

Este flujo bidireccional significa que cualquier reemplazo debe poder aceptar datos operativos en tiempo real, no solo exportar datos históricos. La migración casi nunca tiene un momento de cambio completamente seguro. Por eso, una vez en producción, las empresas tienden a permanecer en el sistema del proveedor original por mucho tiempo.

En contraste, los sistemas de seguimiento de candidatos (ATS) suelen ser más cercanos a sistemas solo de escritura. Después de aceptar o rechazar un candidato, la razón para volver a usar esos datos es relativamente limitada.

Tercero, ¿cuántos SOP no documentados existen?

El contexto empresarial clave a menudo no está en ninguna wiki, sino en las reglas de flujo de trabajo que los administradores y los integradores han construido durante años.

Por ejemplo, en sistemas de ventas, estos contextos no documentados pueden incluir: transacciones empresariales superiores a 100,000 dólares que requieren aprobación del VP; transacciones en EMEA que deben pasar por revisión de privacidad; descuentos para clientes estratégicos que solo en fin de trimestre pueden saltarse la aprobación financiera.

Estos contextos determinan si una tarea puede avanzar a tiempo o si puede completarse sin violar procesos clave. Migrar un sistema implica desglosar cada regla de automatización; de lo contrario, se puede perder parte de la memoria organizacional.

Cuarto, ¿qué tan complejas son las dependencias internas o externas?

El problema central es: ¿cuántos sistemas internos, procesos de equipo o partes externas dependen de ese sistema de registros?

La conectividad interna se refiere a cuántos softwares o flujos de trabajo dependen de él. La conectividad externa, a auditores, contadores, reguladores, etc., que necesitan acceder a los datos. ERP es un ejemplo típico.

Cuanto mayor sea la conectividad, más compleja será la desintegración y reconstrucción en la migración.

Quinto, desde la perspectiva del cumplimiento, ¿qué tan crítico es el dato?

La cuestión central aquí es simple: ¿el sistema tiene un papel clave en cumplimiento?

Sistemas como nómina, ERP, datos de recursos humanos que son críticos para cumplimiento, deben ofrecer una fuente de hechos legalmente sólida y control de permisos estrictos. La migración puede requerir la intervención de auditores y reguladores. Esto hace que su adhesión sea mucho mayor.

Por otro lado, datos de ventas y herramientas como Zendesk, que soportan atención al cliente, aunque importantes, no suelen tener un riesgo regulatorio inmediato si se migran o si alguien obtiene acceso.

No todos los sistemas de registros tienen el mismo costo de cambio. Comparar CRM y ATS en la misma dimensión revela diferencias muy marcadas.

El ATS es una herramienta de flujo de trabajo para procesos limitados, centrada en reclutamiento. Una vez que un candidato es contratado o rechazado, esos datos suelen ser de uso único. Tiene un alcance más estrecho y un grupo de usuarios más pequeño y concentrado.

El ERP, en cambio, es un libro mayor que registra toda la trazabilidad de auditoría, y los contadores, auditores y reguladores son actores directos en su migración.

Reemplazar un ATS es doloroso, pero manejable. Reemplazar un CRM es como hacer una cirugía a corazón abierto. Reemplazar un ERP es como hacer una cirugía a corazón abierto mientras el paciente corre una maratón.

Tradicionalmente, los sistemas de registros no han aprovechado realmente las barreras de datos propios o efectos de red; generalmente, los flujos de trabajo en sí mismos ya crean barreras. En cierto modo, la combinación de herramientas y redes se ha limitado más a negocios de consumo; los SoR históricos no siguieron ese camino.

Datos propios. Muchos sistemas de registros almacenan grandes volúmenes de datos de clientes, pero no los utilizan en profundidad, y en muchos casos, los contratos no permiten hacerlo. Por eso, aunque un CRM tenga conjuntos de datos ricos y pueda, en teoría, agregar insights cruzados, nunca lo ha hecho de manera significativa. Einstein de Salesforce intentó algo similar.

Efectos de red. Para los sistemas de registros, la barrera ideal sería el efecto de red: por ejemplo, un CRM sería más valioso si los vendedores pudieran encontrar compradores en él. Pero, al igual que los datos, los efectos de red en los sistemas de registros han sido débiles, casi inexistentes.

Si la UI desaparece, ¿qué queda después de la llegada de los Agentes?

Los Agentes no necesitan navegador. Lo que necesitan son API, contexto, instrucciones y capacidad de ejecutar acciones. Hay dos cosas que permiten que esto escale: primero, los LLM ya tienen suficiente capacidad de razonamiento, por lo que los Agentes ahora pueden leer contexto, planear, seleccionar herramientas, ejecutar acciones y revisar resultados, sin intervención humana en la mayoría de tareas; segundo, el estándar MCP ha normalizado el acceso a herramientas, proporcionando una interfaz universal para que los Agentes llamen capacidades externas.

Un Agente con permisos MCP puede realizar en milisegundos, a gran escala, operaciones que antes hacían los humanos en plataformas, sin necesidad de navegador. Con suficiente contexto, un Agente que opere en una computadora puede incluso usar interfaces de software existentes, sin necesidad de APIs.

En términos simples, los compradores de software tienen ahora tres caminos:

Primero, seguir usando los sistemas existentes y agregarles Agentes.
Usando CLI y API de los sistemas actuales, pueden usar productos nativos de Agentes, como Salesforce Agentforce, SAP Joule, o construir sus propios Agentes. Aquí, asumimos que las APIs son completas y funcionales, y que la complejidad de operar en modo headless en la práctica se puede gestionar.

Segundo, construir un sistema de registros desde cero.
Las empresas pueden diseñar sus modelos de datos, lógica operativa, permisos, auditorías, integraciones y su propia pila de Agentes, apoyándose en herramientas de terceros para desarrollo y bases de datos.

Tercero, adquirir productos nativos de IA como reemplazo.
Las empresas pueden comprar software de nueva generación, diseñado desde el inicio para la era de los Agentes. Estos productos enfatizan la legibilidad por máquina, la orquestación de Agentes como una capacidad de primera clase, y suelen ser headless.

Entonces, ¿qué elementos de los estándares tradicionales se mantendrán?

Factores impulsados por comportamiento y preferencias humanas, como frecuencia de acceso y atributos bidireccionales, se irán debilitando. Los Agentes pueden reducir el valor de la “memoria muscular” como barrera, pero no eliminarán las barreras basadas en lógica operativa y contexto de negocio. De hecho, estos serán aún más importantes, ya que los Agentes necesitan reglas claras, permisos y procesos definidos para ejecutar tareas de forma segura.

Las SOP no documentadas seguirán siendo relevantes a corto plazo.
La lógica institucional en reglas de flujo de trabajo es esencial para que los Agentes ejecuten tareas correctamente. Es también la parte más difícil de reconstruir, ya que no se puede exportar fácilmente y muchas veces requiere participación humana. Sin embargo, capturar contexto se vuelve más sencillo con el tiempo; a medida que los Agentes sustituyen trabajo humano, su importancia disminuirá.

La conectividad seguirá siendo difícil de descomponer y se profundizará.
El significado de conectividad está cambiando. Ya no solo para facilitar el trabajo humano, sino para mantener la integración entre funciones y sistemas que tradicionalmente estaban desconectados.

Un CRM con Agentes debe enlazar datos y contexto de ventas, facturación, éxito del cliente, etc. Si la plataforma se convierte en un nodo de transacciones entre múltiples organizaciones externas, como compradores, vendedores y socios, las dependencias se profundizarán aún más.

Cuando los proveedores existentes añaden Agentes, puede ser difícil coordinar objetos y lógicas en diferentes sistemas base; si una empresa solo construye su propia base de datos y un conjunto de Agentes, enfrentará problemas similares.

Los datos clave para cumplimiento siguen siendo importantes.
Datos relacionados con regulaciones, riesgos regulatorios o legales, necesitan una fuente única y confiable. Si los clientes confían en los productos existentes, será menos probable que cambien de sistema.

Por ejemplo, datos de nómina y contabilidad, que requieren cumplimiento, probablemente seguirán siendo gestionados en sistemas internos, no en soluciones completamente autónomas.

En un mundo totalmente Agentizado, uno de los mayores desafíos será: ¿qué agentes están autorizados a hacer qué? ¿Quién representan? ¿Cómo se auditan esas acciones? Si un sistema de registros puede actuar como capa de identidad y permisos entre agentes, adquirirá un rol estructural difícil de reemplazar. La barrera no solo es qué datos posee, sino qué confianza y arquitectura de permisos implementa.

Mirando hacia adelante, para las startups nativas en IA, un conjunto de nuevos factores será cada vez más importante y determinará su capacidad de crear barreras defensivas.

Primero, ¿qué tan difícil es reconstruir ese sistema de registros?

Los datos se volverán más importantes en varios niveles.

Primero, en el corto plazo, la clave será qué tan fácil o difícil es extraer y reconstruir los datos subyacentes. La IA ya facilita esto, con herramientas que ayudan en migraciones y reconstrucciones.

A corto plazo, los proveedores existentes pueden —y probablemente harán— que esto sea más difícil: limitando APIs, haciéndolas costosas o incompletas, o incluso sin ofrecer API. Pero a medida que las herramientas de extracción mejoren, especialmente con Agentes que operan en computadoras, la reconstrucción de datos será más sencilla.

Al mismo tiempo, nuevas empresas están reconstruyendo datos a partir de correos, llamadas, voz y documentos internos. La IA reduce en un 80% el costo de reconstruir un sistema de registros. La verdadera diferencia la marcan los últimos 20%: casos excepcionales, aprobaciones, requisitos de cumplimiento y flujos de trabajo en escenarios límite.

Segundo, ¿poseen datos verdaderamente únicos y valiosos?

Los datos con capacidad defensiva no son solo los que importan por sí mismos, sino los que tu producto genera de forma exclusiva. Hablamos de “muro de datos” o “jardín de datos”: datos propios, regulados o que requieren actualización constante. Un proveedor que invierte en recopilar datos autorizados y completos tendrá ventaja frente a competidores que solo usan datos genéricos o limitados.

Otra dimensión importante es si los datos dependen de acciones internas del producto.

Las mejores empresas no solo almacenan datos importados, sino que generan nuevos datos en su proceso, como comportamientos observados, tasas de respuesta, patrones temporales, resultados de procesos, benchmarks, anomalías y trazas de ejecución de Agentes.

La clave es que los datos ahora son contexto.

Tercero, ¿tienen control sobre la capa de acción?

En el pasado, solo almacenar registros era suficiente. En el nuevo mundo, los Agentes toman acciones directas, cerrando ciclos: desde actuar, capturar resultados, hasta usar retroalimentación para decisiones futuras.

Para ERP, esto puede incluir aprobar gastos, pagar salarios, verificar facturas o enviar notificaciones. Los productos que cierran el ciclo son más defensivos, ya que integran la ejecución y generan datos únicos que mejoran con el uso, y que son difíciles de reemplazar si se eliminan.

Por supuesto, a medida que se acumulan más contextos y se manejan mejor escenarios límite, su valor aumenta.

Cuarto, ¿incluyen la ejecución en el mundo real?

Algunos modelos de negocio están ligados a operaciones físicas, que no se automatizan por completo. Ejemplo claro son empresas con redes operativas, como DoorDash. Aunque no son sistemas de registros, su existencia es ilustrativa.

En general, cualquier empresa que extienda el ciclo de software a servicios, cumplimiento, logística, operaciones en sitio o pagos, tiene una barrera defensiva distinta a un SaaS puro. No solo almacenan datos, sino que también envían personal, mueven bienes o completan servicios específicos.

Para emprendedores, esto abre oportunidades en mercados donde el software puede tomar decisiones, coordinar procesos, pero la última milla requiere ejecución física. Por ejemplo, software vertical para servicios en sitio.

Quinto, ¿existe efecto de red?

Históricamente, la mayoría de los sistemas de registros tenían efectos de red débiles, porque eran internos. Pero en la era de los Agentes, si un sistema conecta múltiples partes en un flujo de trabajo, el efecto de red puede ser mucho más relevante.

Si un sistema facilita la interacción repetida entre varias partes, como compradores y vendedores, empleadores y empleados, empresas y auditores, proveedores y clientes, cada nuevo participante aumenta el valor para los siguientes.

Una forma es mediante flujos de trabajo compartidos: el producto como plataforma de transacción, intercambio de contexto y manejo de excepciones.

Otra es mediante benchmarks e inteligencia: el sistema puede mostrar patrones de la industria, anomalías y recomendaciones, reforzando el valor de los datos.

Una tercera es mediante confianza y estandarización: si los actores dependen de un mismo proceso para aprobaciones, transferencias, cumplimiento o pagos, el producto se convierte en infraestructura de colaboración del mercado, difícil de reemplazar.

Sexto, ¿qué tan avanzada es la capacidad técnica de los compradores?

En un mundo donde cualquiera puede construir su propio Agente, la capacidad real de los compradores varía mucho. En sectores verticales o con poca infraestructura interna, la probabilidad de que construyan y mantengan bases de datos, flujos y Agentes propios es baja.

El costo también importa. Hacerlo por cuenta propia puede reducir costos de licencia, pero aumenta gastos en implementación, mantenimiento y complejidad interna.

Esto crea oportunidades reales en categorías con operaciones complejas y poca oferta tecnológica, como manufactura, construcción, procesos industriales, servicios en sitio y contabilidad.

Otros factores también se vuelven esenciales y se convertirán en umbrales básicos del software.

Por ejemplo, la ontología debe cambiar. Muchas ideas de “autoconstrucción” subestiman el valor del modelo de objetos. Los sistemas tradicionales están diseñados para dashboards, reportes y usuarios humanos, y capturan objetos como oportunidades, órdenes o candidatos.

Pero en la era de los Agentes, los esquemas deben captar razonamiento, acciones, seguimiento de estados, manejo de excepciones, delegación de tareas y colaboración entre sistemas. Los objetos nativos pueden ser tareas, intenciones, hilos, estrategias o resultados.

Asimismo, los sistemas de permisos deben actualizarse. Ya no solo para gestionar usuarios humanos, sino también Agentes. Quién puede hacer qué, con qué Agente, bajo qué políticas, qué permisos de auditoría, cómo hacer rollback y manejar excepciones.

Por supuesto, todo esto implica costos: cuánto cuesta construir y mantener Agentes y bases de datos, y el costo de acceso a APIs. Esto vuelve a los temas centrales: qué tan difícil es extraer datos, cuántas dependencias hay y qué tan profundo está el sistema.

¿Y cuál es la conclusión?

A medida que los proveedores tradicionales se vuelven headless, en realidad están haciendo una apuesta implícita: que la capa de datos seguirá siendo la fuente de valor principal. En ciertos sectores, especialmente en servicios financieros con estrictas regulaciones, esta apuesta puede mantenerse por un tiempo, y el proceso de headless puede ser más lento.

Pero para las startups de IA nativa, a medida que los grandes proveedores se vuelven headless, la forma de competir y construir software con barreras duraderas está cambiando.

Las próximas generaciones de sistemas de registros ya muestran formas diferentes: ya no solo almacenan datos de trabajo humano, sino que adquieren atributos de Agentes—capaces de captar contexto, iniciar tareas proactivamente y registrar datos generados en la ejecución.

Más aún, las empresas más interesantes extenderán su alcance al nivel de ejecución en el mundo real: coordinarán personal en sitio, proveedores logísticos, equipos de servicio y activos físicos, o actuarán como intermediarios en múltiples partes.

Estas empresas combinarán modelos de negocio tradicionales con nuevas capacidades, y el núcleo de los sistemas de registros—los datos—gradualmente pasará a un rol secundario, sustentando toda la operación en una base de infraestructura.

[Enlace al artículo original]

Haz clic para conocer las posiciones de BlockBeats en reclutamiento

Únete a la comunidad oficial de BlockBeats:

Grupo de suscripción en Telegram: https://t.me/theblockbeats

Grupo de discusión en Telegram: https://t.me/BlockBeats_App

Cuenta oficial en Twitter: https://twitter.com/BlockBeatsAsia