¿El software se está volviendo headless?

• La decisión de Salesforce de lanzar productos headless apuesta a que la capa de datos, y no la UI, es el centro del valor, lo que plantea la pregunta de dónde queda la defensibilidad del SaaS en la era de los agentes
• En la era del SaaS, el foso de los sistemas de registro (System of Record) se formaba a partir de los hábitos de los usuarios creados por la UI, pero esa ventaja se debilita en una estructura donde los agentes leen y escriben directamente en la DB
• La defensibilidad se está desplazando hacia abajo, a modelos de datos, permisos, lógica de workflows y compliance, y hacia arriba, a redes, generación de datos propietarios y capacidad de ejecución en el mundo real
• Los sistemas de registro AI-native de próxima generación necesitan nuevos criterios: modelos de datos amigables para agentes, gestión de permisos por agente y cierre del loop de ejecución
• Los negocios de próxima generación más prometedores son los que van más allá de almacenar datos y se expanden hasta la ejecución en el mundo real y la coordinación entre múltiples partes

---

La pregunta que deja el anuncio headless de Salesforce

• El mes pasado Salesforce anunció la apertura de APIs y el lanzamiento de productos headless, apostando a que en la era de los agentes el valor está en la capa de datos, no en la UI
  • Desde el punto de vista técnico casi no hay nada nuevo: las APIs que hoy se promocionan como productos headless existen desde hace años, y el lanzamiento tiene el sello típico del marketing de Salesforce
  • La idea central es una estructura en la que los agentes acceden directamente a los datos del sistema de registro sin pasar por una UI pensada para humanos
• Si se quita la UI y solo queda la DB, surge una pregunta esencial: ¿en qué se diferencia eso de Postgres + un esquema bien diseñado + una API?
  • Hace falta revisar si los elementos que sostenían a los sistemas de registro tradicionales siguen siendo válidos tal como están, o si ahora se necesitan nuevos criterios

La era del SaaS, cuando la UI era el producto

• Un sistema de registro (System of Record) es la fuente autoritativa de verdad para un dominio específico
  • Un CRM es el sistema de registro de ingresos, un HRIS es el sistema de registro de RR. HH., y un ERP es el sistema de registro de fondos
  • Su verdadero poder no está en ser un simple repositorio, sino en ofrecer una realidad compartida por toda la organización
• Durante los últimos 20 años, lo que Salesforce vendió fue la manera en que un líder comercial opera a su equipo
  • Lo que realmente se vendía eran dashboards, vistas del pipeline, herramientas de forecast y feeds de actividad, y el modelo de negocio se basaba en vender seats de usuario
  • La DB de abajo era esencial, pero secundaria
• La UI generaba stickiness
  • Forzaba la higiene de datos, creaba vocabulario común (Lead, Opportunity, Account) y hacía que los vendedores cargaran datos que, de otro modo, no ingresarían
  • La razón por la que muchos líderes de ventas se llevan Salesforce cuando cambian de empresa no es que amen la UI, sino la familiaridad adquirida por hábito y memoria muscular
• Los agentes empiezan a dar vuelta este modelo
  • Pueden leer y escribir datos directamente sin pasar por la UI
  • También se está expandiendo rápidamente un ecosistema AI-friendly alrededor de SAP
  • Con el tiempo, los agentes que usan computadoras neutralizan factores humanos como preferencias, entrenamiento y contexto no documentado

Cómo se evaluaba antes el stickiness de los sistemas de registro

• Factores basados en la forma en que las personas interactúan con el software y en sus preferencias

• Qué tan seguido se usa

  • El CRM lo usan a diario los equipos de GTM, por lo que se convierte en infraestructura crítica
  • Lo más difícil de mover no es la herramienta en sí, sino las rutinas de trabajo, los movimientos aprendidos y las cadencias de gestión construidas durante años
  • Muchas veces ni siquiera se percibe como algo que haya que migrar

• Si es write-only o read-write

  • Los sistemas de registro con stickiness son de tipo read-write
  • El CRM se lee constantemente: registros de llamadas, actualizaciones de etapas y creación de tareas fluyen en ambas direcciones
  • Como maneja datos operativos en vivo, no existe un momento seguro para hacer el cambio, por lo que una vez adoptado es difícil abandonarlo
  • En cambio, un ATS (applicant tracking system) se parece más a un sistema write-only: una vez cerrada la contratación, casi nunca se vuelve a mirar esa información

• Cuánto SOP no documentado existe

  • El contexto clave del negocio suele estar codificado en reglas de workflow y no en un wiki
  • Ejemplo en ventas: los deals enterprise de más de 100 mil dólares requieren aprobación de un VP; los deals en EMEA necesitan revisión de privacidad; y los descuentos para logos estratégicos solo pueden saltarse Finanzas al final del trimestre
  • Ese contexto puede marcar la diferencia entre procesar algo a tiempo o dejarlo pasar
  • Migrar implica hacer ingeniería inversa de todas esas automatizaciones o perder de golpe la memoria organizacional

• Escala de dependencias internas y externas

  • Importa cuánto dependen de él los sistemas internos de nivel inferior y si auditores externos, contadores o reguladores necesitan acceso directo
  • Cuanta más conectividad haya a ambos lados, más nudos hay que desatar durante una migración

• Importancia del compliance

  • Los datos de payroll, ERP y RR. HH. requieren una fuente única de verdad legalmente defendible, controles estrictos de acceso administrativo e intervención directa de auditores y reguladores
  • Su stickiness es muy alto
  • Los datos de ventas y herramientas de soporte al cliente como Zendesk están del otro lado: la continuidad y el contexto importan, pero no hay exposición regulatoria

• Comparación de costos de cambio por sistema de registro

  • Un ATS es una herramienta de workflow con límites claros, centrada en contratación, con integraciones acotadas y pocos usuarios
  • Un ERP es lo opuesto: el libro mayor es el rastro de auditoría, y contadores, auditores y reguladores son stakeholders directos
  • Cambiar un ATS es doloroso pero soportable; cambiar un CRM es una cirugía a corazón abierto; cambiar un ERP es una cirugía a corazón abierto en un paciente que además está corriendo una maratón

• Elementos de foso históricamente débiles

  • Datos propietarios: los CRM tienen datos abundantes, pero hicieron pocos intentos de generar insights entre clientes (salvo algunos casos como Salesforce Einstein)
  • Efectos de red: eran el santo grial, pero históricamente fueron débiles en los sistemas de registro

Qué queda cuando desaparece la UI y llegan los agentes

• Los agentes no necesitan un navegador: solo requieren API, contexto, instrucciones y capacidad de actuar

• Dos cambios hacen posible esto

  • Mejora en la capacidad de razonamiento de los LLM: los agentes pueden leer contexto, armar planes, elegir herramientas, ejecutar y revisar resultados sin intervención humana
  • Estandarización del acceso a herramientas con MCP: los agentes llaman funciones externas a través de una interfaz común
  • Los agentes de uso de computadora también pueden explorar interfaces de software heredado sin API, siempre que tengan el contexto adecuado

• Tres caminos para los compradores de software

  • Sistema existente + agentes: usar el CLI/API de los incumbentes SaaS, productos de agentes nativos (Salesforce Agentforce, SAP Joule) o construir agentes propios; pero esto supone que la API sea completa, usable y que el paso a headless sea operativamente simple
  • Construir un sistema de registro propio (DIY): crear desde cero su propio modelo de datos, lógica operativa, permisos, auditoría, integraciones y agentes propios (posiblemente usando herramientas de terceros)
  • Comprar un reemplazo AI-native: software de nueva generación creado desde cero sobre legibilidad para máquinas, con orquestación de agentes integrada como capacidad de primer nivel y funcionamiento headless

• Qué sobrevive de los criterios tradicionales

  • Los factores basados en comportamiento humano (frecuencia de uso, read vs. read-write) desaparecen junto con los hábitos de uso
  • Los agentes matan el foso de los hábitos, pero no eliminan el foso de la lógica operativa y del contexto
  • De hecho, como los agentes necesitan reglas, permisos y procesos definidos explícitamente para actuar con seguridad, eso se vuelve aún más importante

• A corto plazo, el SOP no documentado sigue importando

  • La lógica organizacional codificada en reglas de workflow es clave para que los agentes funcionen correctamente
  • No se puede exportar de forma limpia, sobre todo cuando aún quedan humanos dentro de parte del proceso
  • Aun así, esto irá perdiendo relevancia gradualmente a medida que sea más fácil capturar contexto y que los agentes reemplacen trabajo humano

• La conectividad sigue siendo difícil y se amplía

  • Más que seguir a las personas, el foco pasa a ser mantener la conectividad entre funciones y software fragmentados
  • Un agente de CRM debe unir datos y contexto entre ventas, facturación y customer success
  • Si se convierte en el nodo donde transan agentes de múltiples organizaciones externas, las dependencias se profundizan todavía más
  • Tanto la combinación incumbente + agentes como la combinación DB DIY + agentes tienen dificultades para cruzar el mosaico de software subyacente

• Los datos de compliance siguen siendo importantes

  • Los datos con riesgo legal o regulatorio siguen necesitando una única fuente confiable
  • Es poco probable que payroll o contabilidad se construyan y mantengan in-house
  • El problema sin resolver más difícil en un mundo plenamente agentic es: qué agente, actuando en nombre de quién, está autorizado para hacer qué cosa y con qué nivel de auditabilidad
  • Los sistemas de registro que se convierten en la capa de identidad y permisos de las interacciones entre agentes fuerzan una arquitectura de confianza, por lo que son estructuralmente difíciles de reemplazar

Nuevos elementos de defensibilidad para startups AI-native

• Dificultad de reproducir el sistema de registro

  • En el corto plazo, será clave qué tan fácil es extraer y reproducir los datos basados en el sistema de registro
  • Los incumbentes SaaS pueden dificultarlo haciendo que sus APIs sean dolorosas, incompletas, bloqueadas o antieconómicas
  • A medida que avanzan las herramientas de extracción, especialmente los agentes de uso de computadora, esto se va facilitando
  • Al mismo tiempo, están surgiendo nuevas empresas que reconstruyen datos más ricos a partir de email, llamadas, agentes de voz y documentación interna
  • La AI reduce el costo de reproducir el primer 80% de un sistema de registro, pero el 20% restante —manejo de excepciones, aprobaciones, compliance y workflows de casos límite— es lo que separa a un reemplazo real de un simple wedge

• Si poseen datos propietarios realmente significativos

  • Los datos defendibles no son los importados, sino los datos que el producto genera de manera única
  • El jardín amurallado de los datos: datos propietarios, regulados o que requieren actualización continua
  • Los proveedores que invierten en datos autoritativos y completos obtienen ventaja frente a los generalistas
  • Datos internos generados por comportamiento: conducta observada, tasas de respuesta, patrones de timing, resultados de procesos, benchmarks, patrones de excepción y seguimiento del rendimiento de agentes
  • Los datos son el contexto

• Si controlan la capa de acción

  • Antes bastaba con almacenar registros; en la nueva era, los agentes actúan
  • La defensibilidad se desplaza hacia productos que cierran el loop de acción → captura de resultados → feedback → mejora de decisiones
  • Ejemplos en ERP: aprobar gastos, disparar payroll, conciliar facturas, enviar notificaciones
  • Los productos que cierran ese loop no están en la observación sino en la ejecución: generan datos únicos, mejoran con el uso y son difíciles de remover sin romper el workflow

• Elementos de ejecución en el mundo real

  • Modelos de negocio conectados con operaciones del mundo real que no se automatizarán por completo
  • Casos como la red operativa de DoorDash, que aunque históricamente no fue un sistema de registro, deja pistas relevantes
  • El software que cierra el loop a través de servicios, fulfillment, logística, operaciones en campo y pagos tiene un tipo de defensibilidad distinto al del SaaS puro
  • No solo almacena registros o recomienda: envía personas, mueve cosas y completa servicios
  • Para los builders, la oportunidad está en mercados donde el software decidirá cada vez más y los agentes coordinarán, pero la última milla seguirá necesitando ejecución en el mundo real; por ejemplo, software vertical combinado con field service

• Efectos de red

  • En los sistemas de registro del pasado eran débiles porque el software era principalmente interno
  • Si se incrustan en workflows multiparte, los efectos de red pueden volverse mucho más importantes
  • Cuando median interacciones repetidas entre comprador-vendedor, empleador-empleado, empresa-auditor, vendor-cliente o pagador-proveedor, el aumento de participantes eleva el valor de la red
  • Formas de implementación
    • Coordinación de workflows compartidos: se vuelven el lugar donde ambas partes transaccionan, intercambian contexto y resuelven excepciones
    • Benchmarking e inteligencia: ofrecen normas, anomalías y recomendaciones basadas en patrones de la red
    • Confianza y estandarización: si se convierten en el rail común para aprobaciones, handoffs, compliance y pagos, dejan de ser una simple DB y pasan a formar parte de la infraestructura de coordinación del mercado

• Capacidad técnica del comprador

  • Aunque en teoría cualquiera puede crear agentes, en la práctica la capacidad varía enormemente
  • Los mercados verticales y los compradores funcionales con pocos recursos internos de ingeniería tienen pocas chances de construir, mantener y mejorar su propia DB, lógica de workflows, stack de agentes y gobernanza
  • El costo también es clave: el DIY reduce licencias, pero traslada el gasto a implementación, mantenimiento y complejidad interna
  • Hay oportunidad en categorías operativamente complejas pero poco atendidas desde lo técnico: manufactura, back office de construcción, workflows industriales y de field service, y contabilidad

Otros elementos indispensables (table stakes)

• Nuevos modelos de datos (ontologías)

  • La forma de pensar en una “DB DIY” tiende a subestimar el valor del propio modelo de objetos
  • El software tradicional se construyó para capturar dashboards, reportes y workflows humanos: Opportunity, Ticket, Candidate, etc.
  • Los esquemas para agentes deben capturar razonamiento, acción, seguimiento de estado, manejo de excepciones, delegación y coordinación entre sistemas
  • El modelo de objetos nativo cambia hacia formas como task, intent, thread, policy y outcome

• Gestión de permisos para agentes

  • Hace falta un sistema de permisos pensado no solo para personas, sino también para administrar agentes
  • Debe definir quién puede hacer qué, a través de qué agente, bajo qué políticas y con qué aprobaciones, trazabilidad de auditoría, rollback y manejo de excepciones

• Contexto de costos

  • Costos de construir y mantener agentes y DBs, así como costos de acceso a APIs
  • También se relaciona con la dificultad de reproducir los datos y con la cantidad de dependencias

Conclusión: hacia dónde evolucionan los sistemas de registro

• Que los incumbentes SaaS estén yendo hacia headless es una apuesta implícita a que la capa de datos seguirá siendo la fuente de valor
• En categorías profundamente acopladas al compliance, como servicios financieros, esta apuesta probablemente siga siendo válida por un tiempo, y el paso a headless queda más lejos
• Desde la perspectiva de los builders, cambia la estructura de oportunidades para competir contra incumbentes que se vuelven headless
• El sistema de registro de próxima generación no será un simple repositorio, sino una forma amigable para agentes que capture contexto, inicie tareas y registre el data exhaust
• Los negocios más interesantes serán los que se expandan hacia la ejecución en el mundo real —coordinando personal de campo, proveedores logísticos, equipos de servicio y activos físicos— o los que se ubiquen entre múltiples partes
• La estructura combinará el núcleo de los modelos de negocio del viejo mundo y de los sistemas de registro tradicionales (los datos), pero con los datos quedando en segundo plano