IA aplicada a operaciones para acelerar diagnósticos y reducir complejidad

Del chat al workflow: cómo convertimos un sistema multiagente en una plataforma auditable, predecible y preparada para producción

La mayoría de los artículos sobre agentes de IA se centran en los modelos.

Qué modelo usar. Cuántos parámetros tiene. Qué benchmark supera. Qué capacidad de razonamiento incorpora.

Sin embargo, cuando empiezas a construir sistemas multiagente para entornos reales, descubres rápidamente que el modelo deja de ser el problema principal.

La complejidad aparece en la orquestación.

¿Cómo coordinas varios agentes sin duplicar lógica? ¿Cómo controlas permisos y políticas por cliente? ¿Cómo auditas decisiones? ¿Cómo diagnosticas por qué una conversación ha fallado? ¿Cómo evitas que cada nueva funcionalidad convierta la arquitectura en algo imposible de mantener?

Durante los últimos meses hemos estado evolucionando la arquitectura de Opsphere para responder precisamente a esas preguntas.

El problema de los handoffs

Nuestra arquitectura ya utilizaba varios agentes especializados:

• Un orquestador encargado de entender la intención del usuario y decidir el siguiente paso.
• Un investigador responsable de ejecutar herramientas MCP y analizar resultados.
• Un catálogo capaz de responder preguntas sobre capacidades, herramientas e inventario.

Sobre el papel parecía sencillo.

En la práctica, cada transición entre agentes introducía complejidad.

El orquestador realizaba determinadas tareas de preparación. Después transfería el control al investigador. El investigador volvía a ejecutar parte de ese trabajo inicial. Algunas validaciones aparecían duplicadas. Algunas configuraciones se reconstruían varias veces durante el mismo turno.

El resultado era una arquitectura funcional, pero difícil de seguir y optimizar.

Cada nueva mejora obligaba a pensar en múltiples rutas de ejecución.

De un flujo conversacional a un motor de workflow

La decisión fue sencilla:

Dejar de pensar en conversaciones.

Empezar a pensar en workflows.

Para ello unificamos todo el procesamiento de un turno dentro de un único motor basado en un grafo de nodos.

En lugar de tener diferentes componentes llamándose unos a otros de forma implícita, cada conversación pasa ahora por un flujo explícito gestionado por runTurn().

Cada paso del proceso se convierte en un nodo del workflow:

• Preparación inicial.
• Clasificación del orquestador.
• Aplicación de políticas.
• Investigación.
• Ejecución de herramientas.
• Generación de respuesta.

Todos los caminos quedan definidos dentro de una estructura única.

Esto aporta algo extremadamente valioso:

La ejecución deja de ser implícita.

Ahora es observable.

Eliminando trabajo repetido

Uno de los cambios más importantes fue la introducción de un pre-loop compartido.

Anteriormente, cuando el orquestador transfería el control al investigador, parte del trabajo inicial volvía a ejecutarse.

Resolución de contexto.

Carga de herramientas.

Validaciones.

Configuraciones de sesión.

Ahora todo ese trabajo se realiza una sola vez.

Los agentes consumen el mismo contexto preparado previamente.

Esto reduce latencia, elimina llamadas redundantes y simplifica enormemente la arquitectura interna.

Pequeñas optimizaciones como esta suelen pasar desapercibidas para el usuario final, pero son las que permiten que un sistema siga siendo rápido a medida que crece.

Centralizando las políticas

Otro reto importante era el control de permisos.

Opsphere opera en entornos multi-tenant donde diferentes organizaciones tienen acceso a distintas herramientas, entornos y capacidades.

La solución fue consolidar toda la lógica de autorización en un único módulo de políticas.

Ahora existe una única fuente de verdad que determina:

• Qué herramientas puede planificar un agente.
• Qué herramientas puede ejecutar realmente.
• Qué restricciones aplican a cada tenant.
• Qué entornos están autorizados.

Esto elimina inconsistencias y reduce el riesgo de que un agente intente utilizar recursos que no corresponden a un cliente determinado.

La IA puede razonar.

Pero las políticas siguen teniendo la última palabra.

Haciendo cada decisión auditable

Uno de los objetivos principales de esta evolución era mejorar la observabilidad del propio sistema de agentes.

Cuando una conversación falla, la pregunta habitual suele ser:

¿Dónde ocurrió el problema?

¿Fue el orquestador?

¿Fue el investigador?

¿Fue una herramienta externa?

¿Fue un timeout?

Responder a esas preguntas era posible, pero costoso.

Ahora cada turno genera una traza estructurada almacenada en PostgreSQL.

Las ejecuciones quedan registradas en tablas como:

• workflow_runs
• workflow_steps

Cada paso conserva información relevante sobre:

• Nodo ejecutado.
• Decisión tomada.
• Duración.
• Resultado.
• Error asociado.

Todo ello con redacción automática de secretos para evitar exposición de credenciales o datos sensibles.

Además, estas trazas pueden activarse por tenant y consultarse posteriormente desde el panel de administración utilizando el conversation_id.

Controlando los tiempos de respuesta

Los sistemas multiagente suelen sufrir un problema silencioso.

Cada componente tiene sus propios reintentos.

Y cuando esos reintentos se acumulan, la experiencia del usuario se degrada rápidamente.

Uno de los casos más habituales ocurre cuando el modelo devuelve JSON mal formado y el sistema intenta regenerarlo varias veces.

Para evitarlo, el orquestador ahora comparte un presupuesto global de tiempo cercano a los 35 segundos.

No importa cuántos reintentos sean necesarios.

Todos consumen del mismo presupuesto.

Esto permite mantener tiempos de respuesta previsibles y evita que una conversación quede atrapada en ciclos de regeneración que apenas aportan valor.

Beneficios reales para operaciones y producto

Aunque muchos de estos cambios son internos, su impacto es muy visible.

Para los usuarios:

• Menos latencia.
• Menos comportamientos inesperados.
• Menos respuestas bloqueadas por reintentos innecesarios.

Para los equipos de operaciones:

• Diagnósticos más rápidos.
• Auditoría completa de decisiones.
• Identificación precisa de puntos de fallo.

Para producto:

• Capacidad de medir calidad real de los agentes.
• Evaluación objetiva de cambios en routing.
• Evolución de políticas basada en datos y no en intuición.

Y quizás lo más importante:

Cada conversación se convierte en una fuente de aprendizaje.

Ya no es una secuencia efímera de mensajes.

Es un workflow observable, medible y mejorable.

Una lección importante sobre sistemas de IA

Existe una tendencia natural a asociar la calidad de un sistema de IA con el modelo que utiliza.

Nuestra experiencia construyendo Opsphere ha sido diferente.

Los modelos son importantes.

Pero la diferencia entre una demo y una plataforma preparada para producción suele encontrarse en elementos mucho menos visibles:

• Workflows claros.
• Políticas consistentes.
• Trazabilidad.
• Observabilidad.
• Control de costes y latencia.

En otras palabras:

La inteligencia es importante.

La arquitectura que la rodea es lo que permite convertirla en un sistema fiable.

Y esa arquitectura es, probablemente, donde se encuentra la mayor parte del trabajo real.

AI-powered operational intelligence for modern engineering teams