Sistemas multi-agente: caso aplicado de domótica

Hasta ahora, todos nuestros ejemplos giraron en torno al mismo dominio: un asistente de RR.HH. Útil para construir un vocabulario común, pero con el riesgo de hacerte pensar que estos patrones son trucos específicos para “bots de oficina”. En este capítulo cambiamos de dominio radicalmente — un sistema de domótica inteligente — para mostrar que los mismos conceptos se generalizan a cualquier problema que requiera coordinar múltiples especialistas.

El escenario: automatizar un apartamento inteligente

Imagina un apartamento con cerraduras biométricas, termostatos inteligentes, persianas motorizadas, cámaras de seguridad, un refrigerador con cámara interna y un asistente por voz. La orden del usuario: “Prepara la casa porque voy de camino.”

Esto implica ajustar la temperatura a 22°C, abrir las persianas, preparar el reconocimiento de seguridad, verificar el inventario del refrigerador (y agregar a la lista de compra si falta algo) y encender luces de bienvenida si es de noche.

Un solo agente monolítico tendría que sostener todas estas reglas en un mismo prompt, mezclando climatización, seguridad, compras e iluminación — el mismo problema que vimos en RR.HH. cuando un solo agente intentaba manejar vacaciones, gastos y quejas sensibles a la vez.

La arquitectura: descomposición jerárquica con elementos paralelos

Usando el vocabulario del Capítulo 6b: este sistema es, principalmente, descomposición jerárquica de tareas — el Agente Orquestador es el “agente raíz” que recibe la orden y la descompone en sub-tareas. Pero tiene un elemento de patrón paralelo mezclado: a diferencia del ejemplo de compensación total (donde las sub-tareas se sintetizaban en una sola propuesta), aquí los agentes actúan de forma independiente — sin un paso final de síntesis, cada uno ejecuta su parte.

Agente	Responsabilidad	Herramientas
Orquestador	Punto de contacto único; descompone órdenes y distribuye tareas	Prompt de sistema + coordinación MCP
Movimiento y Biometría	Rastrea geolocalización y produce señales preliminares de movimiento o identidad	GPS, sensores, cámara de entrada
Climatización	Controla termostatos y persianas; optimiza consumo	API de termostato, persianas, energía
Seguridad	Valida identidad y aplica restricciones según perfil y nivel de confianza	Cámaras, cerraduras biométricas, base de perfiles
Despensa	Monitorea inventario; genera listas de compra	Cámara del refrigerador, API de supermercado

Por qué esto no funciona como un solo agente — la analogía con microservicios

Un único agente manejando biometría, climatización, seguridad y compras a la vez sería como un solo empleado que es a la vez recepcionista, contable, ingeniero de climatización y guardia de seguridad — no puede ser experto en todo. La analogía con microservicios ayuda a entender la separación:

Microservicios	Agentes especializados
Cada servicio tiene una responsabilidad acotada	Cada agente tiene un dominio y herramientas acotados
Se comunican vía APIs bien definidas	Se comunican vía MCP o mensajes estructurados
Un servicio puede evolucionar detrás de un contrato estable	Un agente puede actualizarse si conserva su contrato de entrada y salida
El API Gateway enruta peticiones	El Orquestador descompone y distribuye tareas
Los fallos pueden aislarse con timeouts y circuit breakers	Los fallos pueden contenerse con límites, validación y fallbacks

Lo que se gana: mantenibilidad (el agente de seguridad puede actualizarse sin tocar la lógica de climatización), escalabilidad (cada agente usa el modelo o componente que su tarea justifica — movimiento puede ser determinista o barato, seguridad puede requerir más capacidad) y reutilización (el mismo Agente de Climatización podría alimentar un flujo separado de “optimización energética del edificio” que no existía cuando se diseñó originalmente).

Lo que NO se gana: velocidad automáticamente. Cada llamada adicional y cada salto de red agregan costo de coordinación — la latencia total se aproxima al máximo de las ramas cuando corren en paralelo, o a la suma cuando dependen unas de otras.

La analogía tiene un límite: separar prompts no crea por sí solo aislamiento operativo. Para obtener propiedades parecidas a microservicios hacen falta contratos versionados, timeouts, reintentos acotados, observabilidad y despliegues realmente independientes.

El riesgo real: confianza implícita, con un caso concreto

En sistemas multi-agente, un riesgo central es la confianza implícita — los agentes aceptan las salidas de otros como verdades absolutas, sin verificación secundaria.

Caso práctico — el visitante confundido con el dueño: el Agente de Movimiento produce una identificación preliminar incorrecta por mala iluminación o un ángulo extraño de cámara: identidad = "dueño", confianza = 0.65. El Agente de Seguridad confía ciegamente en esa salida, decide “es el dueño, puedo desactivar restricciones” y otorga acceso a áreas restringidas, incluyendo desactivar el bloqueo de la estufa pensado para niños. El visitante, un niño de 10 años, accede a la cocina sin supervisión.

El mecanismo de fallo: el primer agente se equivoca con una confianza insuficiente para una decisión de alto impacto; el agente de seguridad propaga esa desinformación sin verificarla; no hay punto de control humano ni señal secundaria. Es el mismo mecanismo de falla que vimos con Finnbot en Parte III: un componente de bajo nivel se equivoca y el siguiente propaga la desinformación porque el diseño asumió confianza total.

La mitigación: umbrales de confianza explícitos

def procesar_acceso(identificacion):
    confianza = identificacion.confianza

    if confianza >= 0.90:
        return otorgar_acceso_completo()
    elif confianza >= 0.70:
        return preguntar_usuario("¿Eres tú quien está entrando?")
    else:
        return modo_invitado()

Esto convierte la confianza implícita en confianza explícita con umbrales: ninguna decisión de alto impacto se toma con confianza intermedia sin verificación adicional y, con confianza baja, el sistema restringe en vez de asumir lo mejor.

Los números son ilustrativos, no universales. Un puntaje 0.90 solo tiene ese significado si el modelo está calibrado: entre las predicciones que etiqueta con 90% de confianza, aproximadamente 90% deberían ser correctas en condiciones representativas. Los umbrales deben elegirse con evals, separar falsos positivos de falsos negativos y elevarse cuando el impacto de un error sea mayor.

Cuándo SÍ necesita un LLM orquestando (y cuándo no)

Recordando la nota del compilador de Anthropic del Capítulo 6b:

	Compilador de C (Anthropic)	Nuestro sistema de domótica
Naturaleza de la tarea	Técnica, con verificación determinista (GCC)	Interpretación abierta de lenguaje y contexto
Orquestación	Por infraestructura (git, bloqueo de archivos)	Por LLM (el Orquestador)
¿Necesita LLM para orquestar?	No	Sí, para el alcance abierto descrito

Interpretar “prepara la casa porque voy de camino” requiere decidir qué significa “preparar” según hora, clima y preferencias. Un LLM es útil cuando las órdenes son abiertas y ambiguas. Si el sistema solo admitiera un catálogo cerrado de comandos, reglas deterministas podrían ser más simples y seguras. La pregunta correcta no es “¿usar más o menos IA?”, sino “¿esta tarea necesita interpretar lenguaje abierto, o puede resolverse con estados y reglas verificables?”.

Cómo evoluciona un sistema como este, con el tiempo

Este sistema no tiene que nacer completo — puede evolucionar en fases, cada una añadiendo complejidad real:

1. Agente único: una sola llamada genera instrucciones para todos los sistemas. Funciona para casos simples, pero se degrada cuando mezcla demasiados dominios.
2. Especialización: se separan los agentes — el Orquestador distribuye y cada especialista tiene su propio prompt, contrato y herramientas.
3. Coordinación avanzada: algunos agentes se comunican entre sí, no solo con el Orquestador — por ejemplo, Climatización consulta a un Agente de Energía para optimizar consumo. Esto exige controlar dependencias, permisos y trazabilidad para no crear una red opaca.
4. Autonomía creciente: el Orquestador delega más decisiones — el Agente de Despensa no solo detecta que falta leche, sino que propone cuándo comprarla según precio y hábitos. Las compras con efectos reales siguen sujetas a límites y aprobación definidos por el usuario.

Cada fase añade complejidad y exige más evals (Capítulo 3), observabilidad y guardrails (Parte III). La sofisticación no es gratis, y no hace falta saltar a la fase 4 solo porque sea técnicamente posible.

Resumen del capítulo

• Cambiar de RR.HH. a domótica demuestra que los patrones de arquitectura son generales, no trucos de un caso.
• Este sistema combina descomposición jerárquica (el Orquestador) con ejecución paralela de especialistas, sin síntesis final.
• La analogía con microservicios ayuda a razonar sobre especialización, reutilización y mantenibilidad, pero esas propiedades requieren aislamiento y contratos reales.
• La confianza implícita entre agentes se mitiga con validación secundaria y umbrales explícitos sobre puntajes calibrados.
• No todo necesita un LLM orquestando: depende de si la tarea exige interpretar lenguaje abierto o puede resolverse con lógica determinista.
• El sistema puede evolucionar de agente único a especialización, coordinación entre agentes y mayor autonomía, con controles proporcionales en cada fase.