Capítulo 13: ¿Funcionalidad o estructura en tus sistemas inteligentes de IA y multiagentes orquestados?

La funcionalidad es lo que el sistema hace hoy; la estructura es lo que le permitirá seguir haciéndolo mañana.

El dilema eterno, reavivado por la IA

El autor plantea una tensión clásica de la arquitectura de software: arquitectura y estructura frente a agilidad no es rapidez. La pregunta es perenne: ¿priorizamos entregar funcionalidad ahora o construir una estructura sólida que sostenga el futuro? En los sistemas con agentes, este dilema no se ha resuelto; se ha intensificado. Porque los agentes hacen tan fácil añadir funcionalidad que la tentación de descuidar la estructura es mayor que nunca, y sus consecuencias, más rápidas.

Robert C. Martin lo formuló con precisión: la funcionalidad urgente es visible, pero la estructura es la que determina el costo de todas las funcionalidades futuras. Un sistema con buena funcionalidad y mala estructura entrega rápido al principio y se vuelve imposible de cambiar después. Cunningham (1992) articuló la metáfora de la deuda técnica precisamente para describir este fenómeno: la velocidad presente prestada a costa del costo futuro.

Versión académica: La tensión entre funcionalidad inmediata y sostenibilidad estructural en sistemas de software constituye uno de los problemas centrales de la ingeniería de software como disciplina. Kruchten et al. (2019) formalizan esta tensión en términos de deuda técnica: la funcionalidad inmediata genera valor observable a corto plazo pero introduce pasivos ocultos en la arquitectura que se materializan como costos incrementales en cada ciclo de desarrollo subsiguiente. En los sistemas multiagente con comportamiento probabilístico, estos pasivos se amplifican porque la ausencia de estructura no solo genera rigidez (patología clásica) sino también inestabilidad emergente (patología específicamente agéntica).

Por qué la estructura gana a largo plazo

La argumentación de Martin es matemática en su esencia. Si modelamos la funcionalidad como el conjunto de cosas que el sistema puede hacer, y la estructura como la facilidad con la que se puede cambiar, entonces la relación entre ambas a lo largo del tiempo es la siguiente:

Sin estructura (acoplamiento crece con n agentes): cada nueva funcionalidad añadida cuesta más que la anterior porque las dependencias implícitas se multiplican. Si cada nuevo agente genera O(n) dependencias con los agentes existentes, el costo de la n-ésima feature es proporcional a n. El sistema con 40 agentes tiene un costo de cambio 40 veces mayor que el sistema con 1 agente.

Con estructura (SOLID, interfaces bien definidas, roles claros): cada nueva funcionalidad cuesta aproximadamente lo mismo que la anterior, porque las dependencias están contenidas por las interfaces. El costo crece como O(log n) en lugar de O(n).

La inversión en estructura es recuperada cuando el costo acumulado sin estructura supera el costo de haberla construido. Para un enjambre de 20 agentes, este punto de cruce ocurre aproximadamente en la feature número 4 o 5: a partir de ahí, cada funcionalidad construida sobre una estructura sólida es más barata que la misma funcionalidad construida sobre un enjambre sin estructura.

En un enjambre, este principio se agudiza: un sistema multiagente sin estructura clara, sin SOLID (Vol. 3, cap. 24), sin roles definidos (Vol. 3, cap. 23), sin fronteras nítidas, se convierte rápidamente en un caos de agentes que se solapan, donde cada nueva funcionalidad cuesta más que la anterior. La estructura, lejos de frenar, es lo que mantiene barata la funcionalidad.

La deuda técnica agéntica: una taxonomía

La deuda técnica en enjambres no es monolítica. Lenarduzzi et al. (2024) proponen en IEEE Transactions on Software Engineering una taxonomía de deuda en sistemas con LLMs que, adaptada a enjambres, comprende cinco tipos específicos:

Deuda de Contexto: los system prompts de los agentes crecieron orgánicamente sin revisión sistemática y ahora son contradictorios entre sí, incluyen instrucciones obsoletas, y contienen ambigüedades que producen comportamientos inconsistentes. Esta deuda es invisible hasta que el sistema falla en un caso de uso que el equipo no había anticipado.

Deuda de Acoplamiento: los agentes dependen de implementaciones concretas (el nombre de un modelo específico, la estructura interna de un mensaje de otro agente, el formato exacto de una herramienta) en lugar de contratos abstractos. Cuando el modelo o la herramienta cambia, el acoplamiento se manifiesta como una cascada de fallos que requiere modificaciones en múltiples agentes.

Deuda de Observabilidad: el enjambre opera sin trazabilidad distribuida. Cuando algo falla, no se sabe qué agente tomó qué decisión, en qué momento, con qué contexto. El debugging se convierte en arqueología: reconstruir la secuencia de eventos a partir de fragmentos de logs heterogéneos. Li et al. (2024) estiman que la ausencia de observabilidad adecuada multiplica el tiempo de diagnóstico de incidentes por 4-8x.

Deuda de Conocimiento: ningún miembro del equipo comprende completamente por qué el enjambre hace ciertas cosas (solo que “funciona”). Cuando un agente exhibe un comportamiento inesperado, nadie puede predecir si es un bug o una feature hasta haberlo observado en múltiples contextos. Esta deuda se acumula silenciosamente y se materializa dramáticamente cuando un cambio de modelo o de prompt altera el comportamiento de una manera que nadie anticipó porque nadie entendía el comportamiento original.

Deuda de Gobernanza: ausencia de política formal sobre cuándo un agente puede tomar decisiones autónomas, cuándo debe escalar al humano, y quién tiene autoridad para cambiar el comportamiento de un agente en producción. Esta deuda produce incidentes donde un agente toma una decisión autónoma que ningún humano habría autorizado, y el postmortem revela que nadie había definido explícitamente que esa decisión requería aprobación humana.

La trampa de la velocidad agéntica

Aquí reside el peligro específico de esta era. Como los agentes generan funcionalidad a una velocidad asombrosa, producen la ilusión de progreso estructural. El sistema crece, hace más cosas, impresiona en las demos; pero por debajo, su estructura se degrada con cada incremento no integrado con criterio.

Matemáticamente: si cada agente aporta O(1) funcionalidad pero O(n) acoplamiento, el costo total es O(n²). 40 agentes sin estructura = 1.600 dependencias implícitas. Una línea de cambio en el agente A afecta estadísticamente a 40 otros agentes. Semana 2 es rápida (40 agentes, sin coupling detectado aún); semana 3 colapsa (coupling emerge, cambios se vuelven frágiles).

ROI de la estructura temprana: inversión de 1 semana en arquitectura SOLID paga 4x en reducción de cost-per-feature en mes 1, y 10x en mes 3. La velocidad agéntica, paradójicamente, puede ser el mayor enemigo de la estructura, porque oculta su deterioro tras una fachada de avance. Hasta que colapsa, súbitamente, sin avisar.

Lo que resulta menos evidente es que este colapso suele ocurrir en el peor momento posible: en el punto de mayor complejidad del sistema, cuando más agentes operan simultáneamente, cuando el equipo tiene menos tiempo para hacer diagnóstico cuidadoso y cuando las consecuencias de un fallo en producción son más costosas.

Patrones arquitectónicos que preservan la estructura en crecimiento

Cuatro patrones específicos permiten a un enjambre crecer en funcionalidad sin degradar su estructura:

Arquitectura Hexagonal para agentes (puertos y adaptadores): cada agente define sus dependencias como puertos (interfaces abstractas); la infraestructura provee adaptadores concretos para esos puertos. El agente puede ser testeado en completo aislamiento de sus herramientas, y las herramientas pueden cambiar sin modificar el agente. Vernon (2013) formaliza este patrón en Implementing Domain-Driven Design como fundamental para la mantenibilidad a largo plazo.

Anti-Corruption Layer (ACL): cuando un agente necesita integrarse con un sistema legado (una API antigua, un modelo de datos heterodoxo), una capa de traducción convierte el modelo legado al modelo limpio del enjambre sin contaminar la lógica de negocio del agente. El ACL absorbe la complejidad del legado y presenta una interfaz limpia al enjambre.

Aggregate Pattern (Domain-Driven Design): cada agente tiene una frontera de consistencia clara y exclusiva. Solo él puede modificar su estado interno; otros agentes interactúan con él únicamente a través de eventos o mensajes (nunca a través de modificación directa de su estado). Esta invariante elimina la categoría más común de bugs en enjambres: el estado compartido corrupto.

Event-Driven Architecture (EDA): los agentes se comunican por eventos (mensajes inmutables que describen lo que ocurrió), no por llamadas directas. Esta desacoplación permite extender el enjambre añadiendo agentes que escuchan eventos existentes, sin modificar los agentes que los emiten. Fowler (2018) documenta que los sistemas event-driven tienen un costo de extensión típicamente 3-5x menor que los sistemas con acoplamiento directo.

El modelo de inversión: una curva de rentabilidad

La decisión de invertir en estructura puede formalizarse como un problema de optimización económica. Dado un equipo que desarrolla 10 features/mes sin estructura y 7 features/mes con estructura (el 30% de overhead de diseño), ¿cuándo se recupera la inversión?

Con acoplamiento sin estructura (O(n)):

• Feature 1: costo base = 1x
• Feature 5: costo = 5x (cada feature anterior añade dependencias)
• Feature 10: costo = 10x
• Feature 20: costo = 20x

Con estructura (acoplamiento O(log n)):

• Feature 1: costo = 1.3x (overhead de diseño)
• Feature 5: costo = 1.7x
• Feature 10: costo = 2.2x
• Feature 20: costo = 2.8x

El punto de cruce ocurre en feature 4-5: a partir de la quinta funcionalidad, cada feature construida sobre una estructura sólida es más barata que la misma feature sin estructura, a pesar del overhead inicial de diseño. A la feature 20, el sistema sin estructura es 7x más caro por feature que el sistema con estructura.

La síntesis: estructura como habilitador de velocidad

El dilema es, sin embargo, en parte falso. Bien entendidas, estructura y funcionalidad no se oponen: la estructura es lo que permite sostener la velocidad de la funcionalidad en el tiempo. Como recuerda el segundo lema, agilidad no es rapidez; es la capacidad de seguir cambiando con bajo costo.

La pregunta madura es “¿cómo invierto en estructura justo lo suficiente para que la funcionalidad siga siendo barata?”, no “¿funcionalidad o estructura?”. El arquitecto sabio no sacrifica una por la otra: usa la estructura como el cimiento que mantiene veloz al enjambre durante años, no solo durante la primera demo.

McKinsey (2024) cuantifica esta intuición en el contexto de la IA: las empresas con arquitectura modular de IA escalan nuevas capacidades 4,7 veces más rápido que las que tienen arquitecturas monolíticas. La velocidad de innovación, a largo plazo, es una función de la calidad de la estructura, no de la velocidad de la primera entrega.

Perspectiva ejecutiva: la estructura como ventaja competitiva

■ PISTA EJECUTIVA

En el mercado de IA de 2025, la barrera de entrada bajó radicalmente: cualquier equipo puede llamar a una API de LLM y construir un prototipo en días. La ventaja competitiva duradera no está en el acceso al modelo (que es una commodity), sino en la arquitectura del enjambre.

Cuando GPT-5, Claude 4, o el siguiente salto de modelo llegue al mercado, el equipo con enjambre bien estructurado actualiza el modelo en un día (sustitución transparente gracias al Principio de Liskov y a las interfaces MCP bien definidas). El equipo sin estructura necesita 3 meses de reescritura para actualizar el mismo modelo.

Esta asimetría de mantenibilidad es, en última instancia, una asimetría de velocidad de innovación. En un mercado donde la ventana de oportunidad se mide en meses, la diferencia entre actualizar en un día y en tres meses puede ser la diferencia entre liderar el mercado y perderlo.

Lo esencial del capítulo 13

• El dilema funcionalidad/estructura se intensifica con agentes: añadir funcionalidad nunca fue tan fácil ni tan peligroso para la deuda estructural.
• La deuda técnica agéntica tiene 5 tipos específicos: Contexto, Acoplamiento, Observabilidad, Conocimiento y Gobernanza (cada uno invisible hasta que se materializa en un incidente).
• El acoplamiento sin estructura es O(n): 40 agentes = 1.600 dependencias; con estructura es O(log n): manejable indefinidamente.
• El punto de cruce de rentabilidad está en la feature 4-5: a partir de ahí, la estructura siempre es más barata que su ausencia.
• La ventaja competitiva duradera no está en el modelo (commodity) sino en la arquitectura del enjambre: actualizar el modelo en 1 día vs. 3 meses es la diferencia entre liderar e ir detrás.