El objetivo es que un agente no dependa de una configuración manual difícil de reconstruir. La infraestructura se define y administra de forma repetible para que sus componentes, límites y dependencias puedan verificarse. Al mismo tiempo, la identidad, las instrucciones, las políticas, las herramientas y la configuración del agente se registran en versiones: cada cambio queda asociado a una revisión concreta, puede compararse con la anterior y puede desplegarse o revertirse de forma controlada.
Juntas, estas prácticas permiten responder tres preguntas operativas: qué versión debería estar activa, qué cambió respecto de la anterior y si el sistema quedó saludable después del deployment.
Topología de referencia
Cada cliente opera sobre una VPS dedicada que reúne los componentes necesarios para sus agentes. Dentro de ese límite, el gateway recibe y enruta solicitudes, los entornos aislados ejecutan tareas autorizadas, el workspace contiene la definición versionada de cada agente y el estado persistente conserva la información que debe sobrevivir a una actualización. Las conexiones con modelos, autenticación y sistemas externos salen por interfaces explícitas.
VPS dedicada por cliente
Proporciona el límite de infraestructura que separa los agentes de una organización de los agentes de otras empresas.
Gateway como servicio
El proceso Node.js recibe eventos, resuelve el agente y la sesión correspondientes y coordina modelos y herramientas.
Ejecución aislada
Las tareas se ejecutan en entornos delimitados, con recursos, montajes y capacidades definidos para el agente.
Workspace versionado
Reúne identidad, instrucciones, políticas, habilidades y referencias de configuración que describen el comportamiento esperado.
Estado persistente
Conserva memoria y datos operativos independientemente de la versión de código o configuración desplegada.
Servicios conectados
Modelos, autenticación e integraciones se alcanzan mediante contratos y credenciales explícitos, sin incorporarlos al workspace.
Versionado y flujo de deployment
Versionar significa asignar una revisión identificable a la definición del agente y a la configuración que la acompaña. En lugar de modificar un servidor de manera informal, el cambio se registra en la fuente versionada, se compara con la versión activa y se revisa antes de promoverlo. Así podemos saber exactamente qué instrucciones, políticas, herramientas y parámetros deberían estar ejecutándose en un momento determinado.
El deployment toma una versión aprobada y la convierte en configuración activa mediante automatización. Antes de aplicarla se validan su estructura y sus precondiciones; después se comprueba que los servicios hayan iniciado, que la versión esperada esté activa y que un recorrido representativo funcione. Si la verificación falla, la evidencia identifica el punto de fallo y permite volver a la versión anterior sin confundir código versionado con estado persistente.
El valor del control de versiones
El control de versiones convierte cada cambio en una decisión observable: conserva quién lo propuso, qué archivos modificó, cómo difiere de la versión anterior y qué revisión terminó desplegada. Esto reduce la ambigüedad durante una revisión y permite relacionar el comportamiento del agente con una definición concreta, en lugar de depender de cambios manuales difíciles de reconstruir.
Ejemplo. Supongamos que un agente debe solicitar aprobación financiera antes de crear órdenes de compra sobre cierto monto. La nueva regla se registra como un cambio versionado: la revisión muestra exactamente qué política cambió, las validaciones comprueban su estructura y el deployment activa esa revisión identificable. Si el comportamiento observado no es el esperado, podemos volver a la definición anterior sin reemplazar la memoria ni el estado operativo del agente.