Editorial: Durante las últimas dos décadas, la ventaja competitiva de los SaaS se ha construido en gran medida sobre la interfaz de usuario. Los paneles de control, los campos, los flujos de aprobación y los hábitos de los usuarios no son solo interfaces de operación, sino que también han moldeado la forma en que las organizaciones trabajan y ordenan sus datos. Cuando la IA pueda leer directamente los datos, invocar herramientas y ejecutar procesos, la lealtad generada por la memoria muscular humana comienza a debilitarse, y la interfaz de usuario ya no es necesariamente la interfaz central del software empresarial.
Esto no significa que el sistema de registro pierda valor, sino que su defensa se está desplazando: desde la interfaz de usuario y los hábitos de uso, hacia el modelo de datos, el sistema de permisos, la responsabilidad de cumplimiento, la lógica de negocio, el ciclo de ejecución y la red de colaboración múltiple. El software realmente con barreras en el futuro podría ya no ser simplemente una base de datos que registra el trabajo humano, sino un sistema de acción capaz de capturar contexto, iniciar tareas, coordinar agentes y generar continuamente nuevos datos durante la ejecución.
Cuando el software se vuelve headless, el problema central del software empresarial también cambia: el valor ya no reside solo en quién posee los datos, sino en quién puede organizar acciones en torno a los datos.
The following is the original text:
El mes pasado, Salesforce anunció que abriría su API y lanzaría un producto headless (sin interfaz). En esencia, esto significa que Salesforce está apostando que, en la era de los Agentes, su valor central ya no proviene principalmente de la UI, sino de la capa de datos. Es una reubicación bastante inteligente.
Sin embargo, también es importante señalar que, desde el punto de vista técnico, este lanzamiento parece no haber aportado muchos cambios sustanciales. Las API que Salesforce ahora presenta bajo el nombre de "producto headless" han existido en gran medida durante años. En otras palabras, esto se parece más a un lanzamiento de marketing típico de Salesforce.
La idea central de este nuevo producto es que los Agentes puedan acceder directamente a los datos en el sistema de registro, sin necesidad de interactuar a través de una interfaz diseñada para humanos. El propósito de las interfaces tradicionales es ayudar a los usuarios humanos a rastrear procesos, gestionar tareas y avanzar flujos de trabajo; pero una vez que intervienen los Agentes, la necesidad de esta capa de interfaz comienza a disminuir.
Lo realmente discutible de este lanzamiento no es solo lo que Salesforce ha presentado como nuevo producto, sino la pregunta más fundamental que plantea: si se elimina la interfaz de usuario y solo se abre la base de datos subyacente, ¿qué queda de un sistema de registro? ¿Cuál es realmente la diferencia entre esto y una base de datos Postgres, un esquema de datos bien diseñado y un conjunto de API?
Dicho de otro modo, ¿siguen siendo válidos los factores clásicos que antes otorgaban al sistema de registro una defensa a largo plazo? ¿O ya han surgido nuevos estándares de competencia?
En la era de SaaS, los sistemas de registro poseen una ventaja competitiva porque los usuarios humanos viven durante mucho tiempo dentro de su interfaz. La interfaz alberga hábitos de operación, procesos organizativos y acumulación de datos, lo que genera un alto costo de migración. Pero en la era de los Agentes, esta ventaja se está debilitando. Los niveles verdaderamente defensivos están descendiendo hacia modelos de datos, sistemas de permisos, lógica de flujos de trabajo y capacidades de cumplimiento; al mismo tiempo, están ascendiendo hacia efectos de red, capacidad de generación de datos propietarios y capacidad de ejecución en el mundo real.
Cuando el software se vuelve headless, ¿dónde se trasladará la ventaja competitiva?

La interfaz de usuario solía ser el producto mismo
Un Sistema de Registro (System of Record, SoR) es la fuente autorizada de verdad para ciertos tipos de datos comerciales. Es el lugar donde se encuentra la «versión oficial» de datos como relaciones con clientes, registros de empleados o transacciones financieras, y también es el sistema central del que otros herramientas leen y escriben datos. El CRM es el sistema de registro para datos relacionados con ingresos, el HRIS es el sistema de registro para datos relacionados con personal, y el ERP es el sistema de registro para datos relacionados con fondos y finanzas.
La fuerza de estos sistemas no radica solo en que almacenan datos, sino en que finalmente se convierten en la «versión de la realidad» sobre la que depende el funcionamiento conjunto de toda la organización.
Durante los últimos veinte años, lo que Salesforce vendió a sus clientes fue en realidad un conjunto de herramientas para que los líderes de ventas gestionaran sus equipos. Los paneles de control, las vistas de canal de ventas, las herramientas de predicción y los flujos de información dinámicos fueron los productos verdaderamente comprados. Su modelo de negocio se basa en vender licencias a los usuarios, que en esencia proporcionan acceso a estas funciones. La base de datos subyacente es sin duda fundamental, pero en la experiencia del producto actúa más como una infraestructura implícita.
Es decir, lo que realmente impulsa la fidelización de los usuarios es la interfaz de usuario.
La interfaz de usuario limita las normas de datos y moldea un lenguaje común: pistas, oportunidades, cuentas de clientes. Permite que decenas de miles de representantes de ventas ingresen continuamente datos que de otro modo no habrían querido ingresar. Anteriormente, la interfaz de usuario era precisamente el mecanismo que mantenía la consistencia y la disponibilidad de los datos. Salesforce es tan adictivo que muchos gerentes de ventas lo llevan a sus nuevas empresas incluso después de cambiar de trabajo, no porque su interfaz sea especialmente excelente, sino porque se ha convertido en una memoria muscular.
Pero los agentes están comenzando a revolucionar este modelo. Ya no necesitan interactuar con el software a través de una interfaz de usuario, sino que pueden leer y escribir directamente los datos subyacentes. Esto también ha dado lugar a una nueva generación de herramientas y alternativas que evitan la interfaz tradicional. Salesforce no es el único ejemplo: recientemente también discutimos cómo está surgiendo un ecosistema completo alrededor de SAP, más adecuado para ser llamado por IA.
Al mismo tiempo, los agentes capaces de operar computadoras harán que factores tradicionales a nivel humano, como las preferencias, el entrenamiento y el contexto no documentado, se vuelvan cada vez menos importantes con el tiempo. En otras palabras, las condiciones necesarias para convertirse en un sistema de registro duradero están cambiando.
Criterios de calificación anteriores
Antes de discutir qué cambios ocurrirán en la era de los Agentes, es necesario volver con mayor precisión a una pregunta: ¿qué hizo que los sistemas de registro fueran tan persistentes en el pasado?
Los primeros factores están principalmente relacionados con cómo los humanos utilizan el software y sus propias preferencias. La dificultad para reemplazar el software depende en gran medida de la interfaz de usuario, los hábitos de uso, los flujos de trabajo humanos y los arreglos institucionales ya integrados en los procesos organizacionales.
En primer lugar, ¿con qué frecuencia se accede a él?
CRM es utilizado diariamente por el equipo de GTM y muchos otros departamentos relacionados. Es precisamente este uso frecuente lo que lo convierte en infraestructura crítica. Y la capa humana construida sobre él —por ejemplo, reuniones de equipo, hábitos operativos, ritmos de gestión, etc., que se han formado a lo largo de años como inercia organizacional— suele ser la parte más difícil de migrar. La razón es que a menudo ni siquiera se reconoce como algo «que necesita ser migrado».
Second, is it write-only, or read and write?
Un sistema de registro verdaderamente cohesivo suele ser un sistema de lectura y escritura bidireccional. Tomemos como ejemplo un CRM: no es un sistema de escritura que solo se encargue de archivar, sino que se lee continuamente. Cada registro de llamada, cada actualización de etapa y cada creación de tarea son ingresados por algún usuario, y ese usuario generalmente también se interesa en cómo se utilizarán esos datos posteriormente.
Este flujo bidireccional significa que cualquier alternativa debe ser capaz de asumir los datos de operación en tiempo real, no solo exportar un conjunto de datos históricos. Casi no existe un momento absolutamente seguro para realizar la transición. Por lo tanto, una vez que la empresa se implementa, a menudo permanece a largo plazo dentro del sistema del proveedor original.
En contraste, los sistemas de seguimiento de candidatos (ATS) suelen ser más cercanos a un sistema de «solo escritura». Una vez que los candidatos son contratados o rechazados, las empresas tienen motivos relativamente limitados para volver a utilizar esos datos.
Tercero, ¿cuántos SOP no documentados hay?
El contexto empresarial verdaderamente clave a menudo no se escribe en ningún wiki, sino que se acumula en las reglas de flujo de trabajo construidas durante años por administradores e integradores de sistemas.
Por ejemplo, en el sistema de ventas, estos contextos no documentados pueden incluir: las transacciones empresariales superiores a 100.000 dólares requieren aprobación del VP; las transacciones en la región EMEA deben pasar por una revisión de privacidad; los descuentos para clientes estratégicos solo pueden omitir la aprobación financiera al final del trimestre.
Estos contextos suelen determinar si algo puede avanzarse a tiempo o completarse sin violar procesos clave. Migrar un sistema implica descomponer nuevamente cada regla automatizada; de lo contrario, la empresa podría perder directamente parte de su memoria organizacional.
Cuarta, ¿qué tan complejas son las dependencias internas o externas?
El problema central es: ¿cuántos sistemas internos, procesos de equipo o partes interesadas externas dependen de este sistema de registro?
La conectividad interna se refiere a cuántos software o flujos de trabajo descendientes dependen de él. La conectividad externa se refiere a si entidades externas, como auditores, contadores o reguladores, necesitan acceder directamente a los datos dentro de él. ERP es un ejemplo típico.
Ya sea interno o externo, cuanto mayor sea la conectividad, más complejas serán las relaciones que se deben desmantelar y reconstruir durante la migración.
Quinto, ¿qué tan crucial son los datos desde el punto de vista de la conformidad?
La cuestión central es sencilla: ¿es este sistema clave para el cumplimiento normativo?
Sistemas críticos para el cumplimiento, como sistemas de nómina, ERP y datos de recursos humanos, deben proporcionar una fuente de hechos legalmente válida y contar con controles estrictos de permisos de administrador. Cualquier migración podría requerir la intervención directa de auditores y autoridades regulatorias. Esto hace que su nivel de adherencia sea significativamente mayor.
Los datos de ventas y herramientas de soporte al cliente como Zendesk se encuentran en el otro extremo. Las empresas por supuesto valoran la continuidad y el contexto, pero si los datos se migran o alguien obtiene acceso, generalmente no generan riesgos regulatorios inmediatos.
No todos los sistemas de registro tienen el mismo nivel de costos de cambio. Comparar CRM y ATS en el mismo conjunto de dimensiones revela diferencias muy evidentes.
ATS es una herramienta de flujo de trabajo diseñada para procesos limitados, centrada en la contratación. Una vez que un candidato es contratado o rechazado, los registros relacionados se convierten en su mayoría en datos de escritura única. Su alcance de integración es más limitado y su base de usuarios es más pequeña y más concentrada.
ERP, por otro lado, se encuentra en el otro extremo. El libro mayor es en sí mismo una pista de auditoría, y contadores, auditores y reguladores se convertirán en partes interesadas directas en el proceso de migración.
Reemplazar ATS es doloroso, pero aún soportable. Reemplazar CRM es como realizar una cirugía de tórax abierto. Reemplazar ERP es como realizar una cirugía de tórax abierto al paciente mientras corre una maratón.

Tradicionalmente, los sistemas de registro no han aprovechado realmente fuentes de ventaja competitiva como datos propietarios o efectos de red; por lo general, el propio flujo de trabajo ya era suficiente para crear barreras. En cierta medida, combinar herramientas con redes ha sido más característico de los negocios de consumo; los SoR históricos no han seguido este camino.
Datos propietarios. Muchos sistemas de registro, aunque han acumulado grandes cantidades de datos de clientes, no han aprovechado realmente estos datos en profundidad, y en muchos casos, los términos contractuales tampoco les permiten hacerlo. Por lo tanto, a pesar de que los CRM poseen conjuntos de datos ricos y teóricamente podrían consolidar datos de diferentes clientes para generar insights cruzados, nunca lo han logrado de manera verdaderamente significativa. Por supuesto, productos como Einstein de Salesforce han hecho algunos intentos.
Efecto de red. Para un sistema de registro, la ventaja competitiva ideal debería ser el efecto de red: por ejemplo, un CRM se vuelve más valioso cuando los vendedores de software pueden encontrar compradores dentro de él. Pero, al igual que los datos, históricamente el efecto de red en los sistemas de registro ha sido débil, o incluso casi inexistente.

Si la interfaz de usuario desaparece, ¿qué queda del software después de que llegue el agente?
El agente no necesita un navegador. Lo que necesita son API, contexto, instrucciones y la capacidad de ejecutar acciones. Dos factores permiten que todo esto se escale: primero, los LLM ya poseen suficiente capacidad de razonamiento, por lo que los agentes ahora pueden leer el contexto, planificar, seleccionar herramientas, ejecutar acciones y revisar los resultados, sin necesidad de intervención humana en la mayoría de las tareas; segundo, el MCP estandariza el acceso a las herramientas, proporcionando una interfaz común para que los agentes utilicen capacidades externas.
Un agente con acceso a MCP puede realizar, en milisegundos y a gran escala, operaciones que anteriormente los usuarios humanos ejecutaban en la plataforma, sin necesidad de un navegador. En contextos suficientemente completos, un agente capaz de operar una computadora puede utilizar directamente las interfaces de software existentes, sin necesidad necesariamente de una API.
En términos sencillos, los compradores de software ahora tienen tres opciones:
En primer lugar, continúe utilizando el sistema existente y agregue un agente sobre él.
Utilícelos a través de la CLI y la API del sistema existente, ya sea usando los productos de agente nativos del proveedor, como Agentforce de Salesforce o Joule de SAP, o construyendo sus propios agentes sobre ellos. Por supuesto, aquí se asume temporalmente que la API es completa y funcional, y se ignora temporalmente la complejidad que la «headlessización» podría traer en la operación real.
En segundo lugar, un sistema de registro completamente autónomo.
Las empresas pueden construir desde cero sus propios modelos de datos, lógicas operativas, sistemas de permisos, rastreo de auditoría e integración de sistemas, así como su propia pila de Agentes. Este camino probablemente utilizará herramientas de desarrollo de Agentes de terceros y herramientas de base de datos.
Tercero, compra sustitutos nativos de IA.
Las empresas también pueden comprar software de nueva generación diseñado desde el principio para la era de los Agentes. Estos productos enfatizan la legibilidad para máquinas, tratando la orquestación de Agentes como una capacidad de primer nivel, en lugar de añadir una función de IA como un parche sobre sistemas antiguos. Estos productos también podrían ser headless.
¿Qué elementos del antiguo sistema de calificación se mantendrán?
Los factores impulsados por el comportamiento y las preferencias humanas, como la frecuencia de acceso y métricas relacionadas con la memoria muscular, como la propiedad bidireccional de lectura y escritura, irán disminuyendo gradualmente. Los agentes podrían debilitar el valor de la «memoria muscular» como ventaja competitiva, pero no eliminarán la ventaja competitiva derivada de la lógica operativa y el contexto empresarial. En cierto sentido,反而 los harán más importantes, ya que los agentes deben depender de reglas, permisos y definiciones de procesos claros para ejecutar tareas de forma segura.
SOP no documentadas siguen siendo importantes a corto plazo.
La lógica institucional incrustada en las reglas de flujo de trabajo es precisamente lo que el Agente necesita para ejecutar correctamente tus tareas. Al mismo tiempo, es la parte más difícil de reconstruir. Al menos por ahora, aún no se puede exportar limpiamente, especialmente cuando partes del proceso aún requieren intervención humana. Sin embargo, capturar el contexto se está volviendo cada vez más fácil; a medida que los Agentes reemplacen más trabajo manual, la importancia de este factor irá disminuyendo gradualmente.
La conectividad sigue siendo difícil de desentrañar y se extenderá aún más profundamente.
El significado de la conectividad está cambiando. Ya no se trata solo de complementar el trabajo humano, sino de mantener la conexión entre funciones y software que tradicionalmente estaban separados.
Un agente de CRM necesita conectar los datos y el contexto de distintas etapas, como ventas, facturación y éxito del cliente. Si tu plataforma también actúa como nodo de transacción entre múltiples organizaciones externas, por ejemplo, compradores, vendedores y socios que realizan interacciones a través de ella, las dependencias se profundizarán aún más.
Cuando los fabricantes superponen Agentes, puede ser difícil lograr una colaboración fluida entre los objetos y lógicas básicas de diferentes software subyacentes; las empresas que dependen únicamente de una base de datos propia y un conjunto de Agentes también enfrentarán problemas similares.
Los datos clave de cumplimiento siguen siendo importantes.
Los datos relacionados con autoridades reguladoras, riesgos regulatorios o riesgos legales aún requieren una fuente única y confiable de hechos. Si los clientes ya confían en los productos existentes, es menos probable que cambien de sistema.
Por ejemplo, con datos de salarios y contabilidad, el agente probablemente necesite acceder a estos datos, pero las empresas normalmente no optarían por construir y mantener internamente a largo plazo este tipo de sistemas.
En un mundo completamente agentizado, uno de los problemas más difíciles de resolver es: ¿qué acciones están autorizadas para cada agente? ¿A quién representan? ¿Cómo se auditan estas acciones? Si un sistema de registro pudiera convertirse en la capa de identidad y permisos entre los agentes, adquiriría un rol estructural verdaderamente difícil de reemplazar. La barrera aquí no es solo qué datos posee, sino qué arquitectura de confianza ejecuta.
Mirando hacia adelante, para las startups nativas de IA, un nuevo conjunto de factores se volverá cada vez más importante y determinará si pueden establecer defensas.
En primer lugar, ¿qué tan difícil es reconstruir este sistema de registros?
Los datos se volverán más importantes en varios niveles.
En primer lugar, a corto plazo, lo clave es la facilidad con la que se pueden extraer y reconstruir los datos subyacentes del sistema de registro. La IA está facilitando este proceso, y una serie de herramientas están ayudando a los usuarios a realizar este tipo de migraciones y reconstrucciones.
A corto plazo, los fabricantes existentes pueden y probablemente harán que esto sea más difícil: pueden hacer que las API sean difíciles de usar, limitadas, incompletas o económicamente inviables, o incluso no proporcionar API en absoluto. Pero a medida que las herramientas de extracción sigan avanzando, especialmente con la mejora de las capacidades de los Agentes que pueden operar computadoras, la reconstrucción de datos se volverá cada vez más fácil.
Al mismo tiempo, la nueva empresa también está reconstruyendo un conjunto de datos más rico a partir de correos electrónicos, llamadas telefónicas, agentes de voz y documentación interna. La IA reduce hasta un 80 % el costo de reconstruir un sistema de registro. Lo que distingue una entrada útil de un sustituto verdadero es el 20 % restante: excepciones, procesos de aprobación, requisitos de cumplimiento y flujos de trabajo en escenarios límite.
Second, do you have truly meaningful proprietary data?
En segundo lugar, los propios datos se volverán más valiosos.
Los datos verdaderamente defensivos no son los que importas, sino los que tu producto genera de manera única. Hablamos comúnmente de «jardines amurallados de datos»: estos datos son o bien propietarios, o están sujetos a regulaciones, o requieren actualizaciones continuas. Un proveedor de software que invierte grandes recursos en recopilar datos autorizados y completos tendrá una ventaja clara frente a proveedores genéricos o competidores que carecen de estos datos.
Los datos también tienen otra dirección importante: si dependen de las acciones generadas dentro del producto.
Las mejores empresas no solo almacenan datos ingresados desde otros lugares. Generan continuamente nuevas huellas de datos debido a su participación en los procesos, como comportamientos observados, tasas de respuesta, patrones de tiempo, resultados de procesos, referencias de la industria, patrones anómalos y trayectorias de ejecución de Agentes.
Lo esencial es que los datos hoy en día son el contexto.
Tercero, ¿dominas la capa de acción?
En el mundo antiguo, simplemente almacenar registros era suficiente. Pero en el nuevo mundo, los Agentes tomarán acciones directamente; la defensa se orientará hacia productos que puedan formar un bucle cerrado: desde tomar acciones, hasta capturar resultados y utilizar retroalimentación para optimizar decisiones futuras.
Para ERP, esto podría incluir aprobar gastos, activar pagos salariales, conciliar facturas, enviar notificaciones, etc. Los productos que pueden cerrar el ciclo son más defensivos, ya que integran el proceso de ejecución y no se limitan a la observación. Generan datos únicos que mejoran continuamente con el uso y se vuelven más difíciles de reemplazar, ya que su eliminación interrumpiría el flujo de trabajo.
Of course, as more context is accumulated and edge cases are handled more thoroughly, the value here will continue to rise.
Fourth, does it include real-world execution steps?
Algunos modelos de negocio están conectados con operaciones del mundo real que no se automatizan por completo. El ejemplo más evidente son las empresas que poseen redes de operación, como DoorDash. Históricamente, no pertenecían a los sistemas de registro, pero son muy ilustrativos aquí.
Más ampliamente, cualquier empresa que pueda extender el ciclo cerrado del software hasta los servicios, la ejecución, la logística, las operaciones en el lugar o los pagos posee una defensa distinta a la de una empresa puramente SaaS. Estas empresas no solo almacenan registros ni simplemente recomiendan acciones; envían personal, mueven mercancías o completan servicios específicos.
Para los emprendedores, esto significa que las oportunidades pueden surgir en mercados donde el software cada vez más toma decisiones y los agentes coordinan procesos, pero la última milla aún requiere ejecución en el mundo real. Por ejemplo, el software vertical vinculado a servicios en el lugar es una dirección típica.
Quinto, ¿existe un efecto de red?
Históricamente, la mayoría de los sistemas de registro tenían un efecto de red débil, ya que eran principalmente software interno. Pero en la era de los Agentes, si un sistema incorpora flujos de trabajo de múltiples partes, el efecto de red podría volverse mucho más significativo.
Si un sistema se encarga de mediar interacciones repetidas entre múltiples partes, como compradores y vendedores, empleadores y empleados, empresas y auditores, proveedores y clientes, pagadores y proveedores de servicios, entonces cada parte adicional puede hacer que esta red sea más valiosa para la siguiente parte.
Una de las formas es la colaboración en flujos de trabajo: el producto se convierte en el lugar donde ambas partes del proceso realizan transacciones, intercambian contexto y manejan excepciones.
Otra forma es la inteligencia basada en referencias: el sistema puede presentar normas de la industria, anomalías y recomendaciones de acción basadas en los patrones observados en la red, lo que refuerza mutuamente el valor de los datos mencionado anteriormente.
La tercera forma es la confianza y la estandarización: una vez que las contrapartes comienzan a depender del mismo conjunto de procesos para completar aprobaciones, transferencias, cumplimiento o pagos, este producto ya no es simplemente una base de datos, sino la infraestructura colaborativa del mercado mismo, y por lo tanto, resulta más difícil de reemplazar.
Sexto, ¿qué tan fuerte es la capacidad técnica del comprador?
En un mundo donde teóricamente cualquiera puede construir su propio agente, las capacidades reales de construcción de los distintos compradores siguen siendo muy diferentes. Especialmente en industrias verticales y entre compradores funcionales que anteriormente no contaban con recursos de ingeniería interna sólidos, la probabilidad de que ellos mismos construyan, mantengan y mejoren continuamente bases de datos, lógica de flujos de trabajo, pilas de agentes y capas de gobernanza sigue siendo baja.
El costo también es importante aquí. Aunque teóricamente el enfoque DIY puede reducir los gastos de licencias de software, a menudo desplaza los gastos hacia la implementación, el mantenimiento y la complejidad interna.
Esto significa que aún existen oportunidades reales en categorías con operaciones complejas pero escasa oferta tecnológica, como la manufactura, los sistemas de respaldo de la construcción, los procesos industriales, los flujos de trabajo de servicio en el lugar y la contabilidad.
También hay otros factores igualmente importantes que poco a poco se convertirán en el umbral básico del software.
Por ejemplo, la ontología necesita cambiar. Muchas ideas de «bases de datos propias» subestiman el valor que porta el propio modelo de objetos. El software existente se construyó para paneles, informes y usuarios humanos, y captura objetos dentro del flujo de trabajo, como oportunidades de venta, tickets, candidatos, etc.
Pero el esquema de la era de los Agentes debe capturar razonamiento, acciones, seguimiento de estado, manejo de excepciones, delegación de tareas y colaboración entre sistemas. El modelo de objetos nativo ya no puede ser oportunidades, tickets y candidatos, sino tareas, intenciones, hilos, estrategias o resultados.
Asimismo, el sistema de permisos también debe actualizarse. Ya no solo gestiona usuarios humanos, sino que debe gestionar Agentes. Esto incluye: quién puede hacer qué, a través de qué Agente, bajo qué estrategia, qué aprobaciones se requieren, qué rastro de auditoría se deja y cómo se realizan los rollback y el manejo de excepciones.
Por supuesto, todo esto depende del costo, por ejemplo, cuánto cuesta construir y mantener los Agentes y las bases de datos, y cuán elevados son los costos de acceso a la API. Esto vuelve a plantear varias preguntas fundamentales: ¿qué tan difícil es reconstruir los datos, cuántas dependencias existen y qué tan profundamente está integrado el sistema?
¿Cuál es la conclusión?

A medida que los proveedores de software existentes se dirigen hacia lo headless, en realidad están haciendo una apuesta implícita: la capa de datos seguirá siendo la fuente principal de valor. En ciertas categorías, especialmente en campos como los servicios financieros, profundamente regulados por normativas, esta apuesta podría seguir siendo válida durante algún tiempo, y el proceso de headless podría ser más lento.
Pero para los emprendedores de software, a medida que los fabricantes establecidos comienzan a eliminar las interfaces, la forma de competir con ellos y de construir software con defensa a largo plazo está cambiando.
Los sistemas de registro de la próxima generación ya están adoptando formas distintas: ya no son solo almacenes de datos que registran el trabajo humano, sino que poseen atributos de Agentes: capaces de capturar contexto, iniciar trabajo de forma activa y registrar las huellas de datos generadas durante la ejecución.
Más allá, las empresas más interesantes se extenderán hasta el nivel de ejecución en el mundo real: coordinarán personal en el lugar, proveedores de logística, equipos de servicio y activos físicos, o actuarán como capas intermedias entre múltiples partes involucradas.
Estas empresas combinarán múltiples modelos de negocio del mundo antiguo. Mientras tanto, el núcleo de los sistemas de registro tradicionales, es decir, los datos, irá retrocediendo gradualmente al fondo, convirtiéndose en la base subyacente que sostiene todo el sistema.
Haz clic para conocer los puestos disponibles en BlockBeats
¡Bienvenido al grupo oficial de律动 BlockBeats!
Grupo de suscripción de Telegram: https://t.me/theblockbeats
Grupo de Telegram: https://t.me/BlockBeats_App
Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia
