Publicado
- 6 min tiempo de lectura
Secretario inteligente (6): de un agente a un sistema gobernable
En el artículo anterior de esta serie te conté algo que se volvió evidente mientras construía mi sistema de agentes. El problema no era hacer un agente más potente. El problema era quién controla lo que hace el agente.
Cuando empiezas a conectar agentes con herramientas reales (servidores, automatizaciones, APIs o repositorios) aparece un riesgo muy claro: un único agente con acceso total puede hacer demasiado.
Y ese fue el momento en el que el proyecto cambió de dirección.
En lugar de intentar construir un agente omnipotente, empecé a pensar en algo distinto: no tanto un agente mejor, sino una forma de controlar lo que hacen los agentes. Una arquitectura de gobernanza.
El problema de los agentes con herramientas
Muchos sistemas de agentes siguen un patrón bastante simple:
En una demo esto es espectacular.
Pero cuando conectas ese sistema a infraestructura real (servidores, despliegues, automatizaciones…), empiezan los problemas. Un único sistema interpreta, decide y ejecuta. Todo al mismo tiempo.
Demasiada responsabilidad concentrada en un solo punto.
Imagina que en tu empresa una sola persona pudiera analizar la situación financiera, decidir una inversión y ejecutar una transferencia bancaria sin ningún control.
No suena muy buena idea.
Con los agentes ocurre exactamente lo mismo.
De un agente a un sistema de agentes
La solución que empecé a explorar fue bastante natural: separar responsabilidades.
En lugar de un único agente con todo el poder, dividir el sistema en etapas:
Cada agente tiene un rol muy concreto. Hay que decir que yo he configurado el sistema para que todo funcione con mi cuenta de ChatGPT, ya que esta es una de las muchas opciones que OpenClaw permite para conectar el modelo LLM.
Analyzer
El Analyzer interpreta lo que está ocurriendo.
Por ejemplo:
- estado de los servidores
- contenedores Docker
- errores de red
- alertas del sistema
Su trabajo es entender la situación. No ejecutar nada.
Planner
El Planner propone posibles acciones.
Por ejemplo:
- reiniciar un contenedor
- limpiar logs
- revisar un dominio
- ignorar un falso positivo
El planner sugiere, pero no ejecuta.
Human approval
Antes de ejecutar acciones potencialmente peligrosas, el sistema pide confirmación.
Esto mantiene algo muy importante: el humano sigue en control.
Executor
El Executor es el único agente que puede ejecutar acciones reales.
docker restart container
docker compose up
systemctl restartPero hay una regla clave:
el executor no piensa, solo ejecuta lo que ya ha sido aprobado.
En la práctica, la ejecución no ocurre directamente en el servidor donde corre el agente, sino a través de nodos de OpenClaw. Estos nodos actúan como dispositivos remotos que ejecutan comandos de forma controlada, permitiendo separar completamente la toma de decisiones de la ejecución real.
Auditor
El Auditor revisa lo que ha pasado después.
- si el problema se resolvió
- si hubo efectos secundarios
- si la acción tenía sentido
Aquí aparece algo fundamental cuando trabajas con sistemas reales: trazabilidad.
Lo que realmente está pasando aquí
En este punto me di cuenta de algo importante.
No estaba simplemente añadiendo tools a un agente. Estaba construyendo una forma de controlar decisiones y acciones.
Una capa que define:
- quién puede actuar
- cuándo puede actuar
- qué herramientas puede usar
- cómo se registran las acciones
Esto es lo que llamo gobernanza de agentes.
Y en mi caso, todo esto vive dentro de OpenClaw, que es el runtime que ejecuta los agentes. Es decir, no he construido un sistema desde cero, sino una arquitectura sobre él.
La siguiente figura resume la arquitectura actual del sistema. No representa un runtime nuevo, sino una forma de organizar agentes, gobernanza y ejecución sobre OpenClaw para trabajar con más control cuando los agentes interactúan con herramientas reales.
Figura 1. Arquitectura actual de ViaLabs Agent Layer: agentes configurados por rol, flujo de gobernanza, capa de ejecución y runtime OpenClaw.
Tres capas (conceptuales) del sistema
Si lo simplifico mucho, el sistema se puede entender en tres capas:
| Capa | Función |
|---|---|
| Agentes de negocio | OpenCTO, OpenCIO, OpenCMO |
| Sistema de gobernanza | Analyzer → Planner → Human → Executor → Auditor |
| Infraestructura | Tools, Skills, Memory |
Digo conceptuales porque en la práctica todo esto está bastante mezclado dentro del runtime. Pero pensar así ayuda a diseñarlo mejor.
Agentes de negocio
Aquí aparecen los roles:
- OpenCTO → infraestructura
- OpenCIO → conocimiento y proyectos
- OpenCMO → comunicación y relaciones
No son “apps” tradicionales. Son agentes especializados que usan el sistema.
Sistema de gobernanza
Este es el flujo real de decisión:
Analyzer → Planner → Human → Executor → AuditorY aquí está la clave de todo: controlar el poder del agente.
Infraestructura
En la base están los recursos:
- Tools → acciones ejecutables
- Skills → capacidades reutilizables
- Memory → contexto
Importante: nada se ejecuta directamente. Todo pasa por la gobernanza.
Un pequeño apunte técnico
Si lo quieres ver de forma más formal:
Es decir:
- primero entiendes
- luego propones
- luego validas
- y solo al final ejecutas
Puede parecer un detalle, pero cambia completamente cómo se comporta el sistema.
Por qué esto importa
La mayoría de sistemas de agentes funcionan así:
think → executeRápido. Pero arriesgado.
El modelo que estoy explorando es:
Este patrón no es nuevo. Se usa en sistemas donde el error cuesta caro:
- industria
- medicina
- aviación
Nunca se deja que una sola entidad piense y actúe sin control.
En qué punto estoy
Ahora mismo ya tengo varias piezas funcionando:
- monitorización del servidor
- alertas en Slack
- ejecución controlada de comandos
- logs de auditoría
- separación básica de roles
No es un sistema terminado. Pero ya no es solo un conjunto de scripts.
Empieza a parecerse a algo más interesante: una arquitectura de control para agentes.
El siguiente paso
El siguiente paso es seguir consolidando esta gobernanza dentro de OpenClaw y hacerla realmente útil en el día a día.
Por ejemplo:
- OpenCTO → operaciones técnicas
- OpenCIO → gestión de proyectos
- OpenCMO → comunicación
Todos usando las mismas reglas.
No sé todavía hasta dónde llegará esto.
Pero sí tengo claro algo: más que construir un “agente inteligente”, lo importante es construir sistemas en los que confiar cuando ese agente actúa.
Y eso probablemente me va a servir no solo para este proyecto, sino para los siguientes.
Chatbots y agentes de IA para procesos reales
Soy Raúl Jáuregui, consultor de I+D+i y también ayudo a diseñar chatbots y agentes de IA conectados a documentación, procesos internos y atención al cliente. Si quieres automatizar sin perder control, podemos analizar tu caso.
Ver servicio