La espiral de muerte del sistema — y cómo los agentes de IA la rompieron

Resumen:Después de ocho años construyendo sistemas, descubrí un patrón predecible: cada sistema eventualmente se vuelve inutilizable debido a la brecha entre los flujos de trabajo diseñados y la complejidad del mundo real. La brecha crece a partir de la creatividad humana, las limitaciones de tiempo, las herramientas superpuestas y la deuda de documentación. Dejé de intentar construir sistemas perfectos. En su lugar, construí un trío de agentes de IA que manejan la entrada de datos, la detección de anomalías y la corrección de sistemas, creando una infraestructura auto-sanadora que elimina la brecha en lugar de gestionarla.

El Patrón del que Nadie Habla

Desde 2016, Mercury ha construido y experimentado con muchos sistemas.

Construimos nuestro propio ERP y CRM. Definimos nuestros flujos de trabajo. Adoptamos herramientas listas para usar y las unimos con Zapier, n8n y integraciones personalizadas. Estábamos orgullosos de nuestra pila. Se sentía sofisticada. Se sentía como si estuviéramos haciendo lo que una empresa moderna debería hacer.

Pero en los últimos seis meses, miré hacia atrás en los últimos ocho años y vi algo que no quería ver:

Una espiral de muerte. Y está en todas partes.

Así es como funciona. Construyes un sistema. Defines el flujo de trabajo. Los casos de uso están limitados a ese flujo de trabajo por diseño. Luego, el negocio crece. Surgen nuevas situaciones. Los casos extremos se multiplican. Las personas comienzan a usar el sistema de maneras "creativas" para las que nunca fue diseñado. Los datos terminan en los campos incorrectos. Los informes se vuelven poco fiables. Alguien crea una hoja de cálculo sombra para "arreglar" el problema. Ahora tienes dos fuentes de verdad. Luego tres.

La brecha entre el sistema y la realidad sigue ampliándose.

Eventualmente, el sistema se vuelve inutilizable. No porque la tecnología fallara. Porque la distancia entre lo que el sistema asume y lo que el negocio realmente hace se volvió demasiado grande para ser puenteada.

En Mercury, esto sucedió en cámara lenta.Nuestros datos de CRM no vivían en nuestro CRM. Vivían en nuestra plataforma de mensajería, nuestro núcleo de CRM, nuestros registros de llamadas PBX y hilos de correo electrónico. Mismo cliente. Cinco representaciones diferentes. Ninguna de ellas completamente consistente. Cuando realizábamos un informe trimestral, reconciliar estas fuentes tomaba días. A veces encontrábamos discrepancias que habían existido durante meses — datos ingresados "creativamente" por personal que encontraba el flujo de trabajo oficial demasiado rígido para situaciones reales con clientes.

He observado este patrón en empresas clientes. Lo he visto en empresas con departamentos de TI de cien personas. La mecánica varía. El patrón es universal.

De dónde proviene la brecha

La brecha tiene cuatro fuentes. Ninguna de ellas es técnica.

Creatividad humana.Tu personal no son robots. Cuando el sistema no se ajusta a la situación, improvisan. Introducen datos en campos alternativos. Utilizan la sección de "notas" para datos estructurados. Crean procesos paralelos fuera del sistema porque es más rápido que esperar a que TI solucione algo.

Tiempo.Incluso cuando identificas la brecha, solucionar lleva tiempo. Siempre hay una prioridad más alta. La brecha permanece en la lista de tareas pendientes durante meses. Mientras tanto, la solución alternativa se convierte en la nueva normalidad.

Toma de decisiones.¿Qué deberías arreglar? ¿Por qué? ¿En qué orden? La mayoría de las organizaciones no pueden responder esto con claridad. La brecha persiste porque nadie tiene la autoridad y el contexto para decidir qué significa "correcto".

Documentación.Para cuando alguien documenta cómo funciona la solución alternativa, han surgido tres soluciones más. La documentación siempre está detrás de la realidad. A veces es activamente engañosa.

Y luego está el factor de acumulación: superposición.

Los datos de tu CRM no viven en tu CRM. Viven en tu plataforma de mensajería, en el núcleo de tu CRM, en tu sistema PBX, en tus hilos de correo electrónico y en las notas personales del representante de ventas. Mismo cliente. Cinco representaciones diferentes. Ninguna de ellas completamente consistente. Cuando ejecutas un informe, ¿cuál es el verdadero?

Esto no es un error. Este es el estado natural de cualquier organización que ha existido durante más de dos años.

La Respuesta Tradicional (y por qué falla)

La respuesta tradicional es construir un mejor sistema. Más flexible. Más configurable. Más "a prueba de futuro."

He intentado esto. No funciona.

Cuanto más flexible haces un sistema, más complejo se vuelve. Cuanto más complejo se vuelve, más amplia es la brecha entre la capacidad diseñada y el uso real. La flexibilidad no elimina la brecha. Solo la mueve a un nivel más alto de abstracción.

Los proveedores de software empresarial han estado vendiendo "flexibilidad" durante décadas. Cada implementación comienza con "lo configuraremos según sus flujos de trabajo" y termina con "sus flujos de trabajo necesitan cambiar para adaptarse al sistema." La brecha siempre gana.

Lo que construí en su lugar

Hace aproximadamente un mes, dejé de intentar construir el sistema perfecto.

En su lugar, diseñé para la brecha misma.

Construí un trío de agentes de IA. No chatbots. No asistentes. Una capa operativa que se sitúa entre humanos y sistemas y maneja el desorden que siempre se acumula.

Agente Uno: El Punto de Entrada.

El personal interactúa con este agente para la entrada de datos. Lenguaje natural. Sin formularios. Sin campos. El agente hace preguntas aclaratorias, estructura los datos y los escribe en el lugar correcto en el formato correcto. Si la situación no se ajusta a las categorías existentes, no fuerza una cuña en un agujero redondo. Lo señala.

Agente Dos: El Analista.

Cuando el Agente Uno detecta una anomalía — algo que no encaja en el esquema actual, un nuevo patrón, una solución alternativa en progreso — se escala al Agente Dos. Este agente analiza la anomalía, identifica la causa raíz y genera un informe: qué está sucediendo, por qué está sucediendo, qué cambios en el sistema eliminarían la brecha y cuáles son los compromisos.

El informe llega a mi escritorio. Lo reviso. Apruebo o modifico la recomendación.

Agente Tres: El Implementador.

Una vez aprobado, el Agente Tres ejecuta. Parchea el sistema. Actualiza el esquema. Modifica la integración. Escribe la documentación. Y lo hace no como un proyecto único, sino como un proceso continuo.

La brecha ya no se acumula. Se cierra en tiempo real.

Los resultados, incluso en este primer mes, son contundentes. Nuestro ciclo promedio de brecha a parche — el tiempo entre identificar un desajuste en el flujo de trabajo del sistema y solucionarlo — solía medirse en trimestres. A principios de 2026, lo habíamos comprimido a aproximadamente dos semanas gracias a una mejor disciplina de procesos. Con el trío de agentes, el ciclo actual es de menos de cuatro horas para cambios no estructurales, y el mismo día para ajustes a nivel de esquema que requieren mi aprobación.

Las hojas de cálculo sombra están desapareciendo. No porque lo hayamos impuesto. Porque el sistema ahora refleja la realidad con suficiente precisión como para que las personas no necesiten soluciones alternativas.

Este es el mismo principio que subyace a nuestra metodología GEO. Nuestro marco de auditoría GEO unificado —el que puntuó mtsoln.com con 82 (Método A 91, Método B 76) en la re-auditoría del 27 de agosto— se basa en el cierre continuo de brechas, no en una optimización única. La brecha entre cómo los sistemas de IA representan tu marca y cómo realmente operas no se cierra en proyectos. Se cierra a través de la observación y adaptación persistentes. Aplicamos esto a los sitios de los clientes. Ahora lo estamos aplicando a nuestra propia infraestructura.

Lo que esto realmente significa

Esto no es automatización. La automatización asume que el proceso es conocido y repetible. Esto es algo diferente. Esto es infraestructura adaptativa.

El sistema no intenta predecir cada caso de uso. No necesita hacerlo. Observa lo que realmente sucede, identifica desviaciones y evoluciona para acomodarlas. El "sistema perfecto" se vuelve innecesario porque el sistema nunca está terminado: se está volviendo continuamente más preciso en relación con la realidad.

Este enfoque es ahora la base de dos cosas en Mercury:

Nuestros servicios GEO.La Optimización del Motor Generativo no se trata de prácticas óptimas estáticas. Se trata de adaptarse continuamente a cómo los sistemas de IA representan tu marca. Se aplica el mismo principio: observar, analizar, adaptar, implementar.

Nuestro núcleo ERP/CRM.El sistema no impone flujos de trabajo rígidos. Aprende de los flujos de trabajo. La brecha entre el proceso diseñado y el proceso real se convierte en la señal que impulsa la mejora, no en el ruido que degrada la fiabilidad.

La Objeción Que Estás Pensando

"Esto suena inestable." "¿Qué pasa si los agentes hacen cambios incorrectos?" "¿Qué pasa con la gobernanza?"

Estas son preocupaciones válidas. Así es como las abordo:

La aprobación humana es obligatoria para los cambios estructurales.El Agente Dos propone. Yo apruebo. El Agente Tres implementa. El ciclo es rápido — a menudo el mismo día — pero la decisión humana sigue siendo la puerta de entrada. En este primer mes, he rechazado o modificado alrededor del 15% de las propuestas. Generalmente porque el agente identificó una verdadera brecha pero propuso una solución que crearía superposición en otro lugar. El analista no tiene el contexto empresarial completo. Por eso el humano permanece en el ciclo.

Los cambios son reversibles.Cada parche está documentado y versionado. Si algo falla, retrocedemos. La documentación es escrita por el agente que hizo el cambio, así que es realmente precisa — a diferencia de la documentación humana que se retrasa respecto a la realidad por meses.

La alternativa es peor.El modelo tradicional te da la ilusión de estabilidad mientras la brecha crece silenciosamente bajo la superficie. Para cuando te das cuenta, el sistema es inutilizable y la migración es un proyecto de seis meses. Prefiero tener ajustes visibles, frecuentes y pequeños que un deterioro invisible y gradual.

También hay un argumento de costo.Ejecutamos nuestra infraestructura de agentes en un enjambre de Mac Studio, enrutando a través de Mercury Flux, nuestra capa de enrutamiento de modelos que entrega ~18 mil millones de tokens por mes a un costo promedio de aproximadamente $0.07 por millón de tokens. El equivalente minorista sería de $20,000–200,000 mensuales. El trío de agentes añade un costo computacional marginal a una infraestructura que ya estamos ejecutando. Compara eso con el costo de un solo proyecto de migración de sistema, o el costo de oportunidad de informes que tardan días en reconciliarse porque los datos residen en cinco lugares.

La economía ni siquiera se acerca.

¿Será aceptado esto?

No lo sé.

Esto es un cambio radical en cómo las organizaciones piensan sobre los sistemas. Estamos entrenados para creer que los buenos sistemas son sistemas estables. Que el cambio es un riesgo. Que el objetivo es hacerlo bien la primera vez.

Pero "hacerlo bien la primera vez" es una fantasía en cualquier entorno que crece, se adapta o trata con humanos. La pregunta no es si tu sistema se desviará de la realidad. Es si tienes un mecanismo para cerrar la brecha más rápido de lo que se abre.

La mayoría de las organizaciones no lo tienen. Tienen acumulaciones. Tienen "lo arreglaremos en la próxima versión". Tienen hojas de cálculo ocultas y documentación de soluciones alternativas que vive en hilos de Slack.

Estoy proponiendo algo diferente: acepta la brecha como inevitable y construye la capacidad para cerrarla continuamente.

A algunas personas les va a disgustar esto. Amenaza el complejo industrial de planificación de proyectos. Hace que la "implementación" sea un costo operativo continuo en lugar de un proyecto capitalizable de una sola vez. Requiere confiar en agentes de IA para los cambios en el sistema que antes controlaban los humanos.

Pero he estado ejecutando esto durante un mes. La brecha que solía tardar trimestres en cerrarse ahora se cierra en horas. Las hojas de cálculo ocultas están desapareciendo porque el sistema realmente refleja la realidad. La documentación está actualizada porque se genera, no se mantiene.

No es perfecto. Pero es mejor que la espiral de la muerte.

La Implicación Más Amplia

Esto no se trata solo de los sistemas internos de Mercury.

El mismo patrón se aplica a cada organización que lucha con la transformación digital. La razón por la que tantos proyectos de transformación fracasan no es porque la tecnología no funcione. Es porque la brecha entre el nuevo sistema y el negocio real siempre crece más rápido de lo que el equipo de implementación puede cerrarla.

Los agentes de IA cambian la economía de esta ecuación. Cuando la adaptación es automatizada y continua, la brecha se vuelve manejable. Cuando es manual y basada en proyectos, la brecha siempre gana.

Las organizaciones que lo descubran primero tendrán una ventaja estructural. No porque sus sistemas estén mejor diseñados, sino porque sus sistemas son mejores en convertirse en lo que realmente necesita el negocio.

Por eso tampoco me preocupa que la IA esté convirtiendo nuestra industria en una mercancía.

¿El 43% de los leads que se pierden en la brecha entre IA y humanos? Ese número proviene de la misma observación. Los sistemas diseñados para flujos de trabajo ideales no capturan el comportamiento real. Las empresas que capturan ese 43% no serán las que tengan mejores chatbots. Serán aquellas cuya infraestructura se adapta continuamente a cómo trabajan realmente los humanos, no a cómo dicen los diagramas de proceso que deberían trabajar.

Esa es la apuesta que estoy haciendo.

Escrito desde Hong Kong, donde la humedad es alta y la diferencia entre el aire acondicionado y la realidad es de aproximadamente 12 grados.