01El problema: un agente que pierde todo en cada corte

Nuestros agentes de IA (el equipo que llamamos Workforce Zero) trabajan de forma continua sobre infraestructura real: servidores, bases de datos, paneles internos. El problema es que cada corte de contexto —un reinicio del entorno, una sesión nueva, un límite de uso— los deja sin acceso a nada de lo que habían aprendido antes, aunque la infraestructura real siga exactamente igual. Sin memoria propia, cada corte significaba perder horas reconstruyendo contexto a mano, y repetir errores que ya se habían resuelto y estaban documentados, sólo que nadie los tenía a mano.

02La arquitectura, en términos genéricos

Tres piezas, todas construidas con herramientas que la mayoría de las empresas con algo de infraestructura ya tiene a mano: un servidor con una base de datos con soporte vectorial, dos endpoints (cargar y buscar) para leer y escribir esa memoria, y un Relay por cada sistema real al que el agente necesita ejecutar acciones.

El agente nunca toca un sistema real directamente — siempre pasa por su Relay correspondiente.

Con esto, «memoria» y «capacidad de actuar» quedan separadas, cada una protegida por su propio juego de credenciales rotativas: si un token se filtra, el daño queda acotado a un solo sistema, nunca a todo lo demás.

03Cómo funciona el workflow de memoria persistente para agentes de IA, por dentro

Los dos endpoints son flujos de automatización chicos, de 3 a 4 pasos cada uno. Cargar recibe un documento, pide su embedding (una llamada a la API del proveedor de embeddings que uses) y lo guarda reemplazando cualquier versión anterior del mismo documento, para que nunca queden copias viejas dando vueltas:

# Webhook recibe: { doc_path, titulo, contenido }
# Nodo HTTP: pide el embedding del contenido
POST https://api-embeddings.tu-proveedor.com/v1/embeddings
body: { "input": "{{ contenido }}" }

# Nodo Postgres: guarda o reemplaza el documento
INSERT INTO memoria_documentos (doc_path, titulo, contenido, embedding)
VALUES ($1, $2, $3, $4)
ON CONFLICT (doc_path) DO UPDATE SET
  contenido = EXCLUDED.contenido,
  embedding = EXCLUDED.embedding;

Buscar hace el camino inverso: convierte la pregunta en un vector, y trae los documentos cuyo vector está más cerca (distancia coseno):

# Webhook recibe: { pregunta, top_n }
# Nodo HTTP: pide el embedding de la pregunta
POST https://api-embeddings.tu-proveedor.com/v1/embeddings
body: { "input": "{{ pregunta }}" }

# Nodo Postgres: trae los documentos mas cercanos
SELECT doc_path, titulo, contenido,
       1 - (embedding <=> $1) AS similitud
FROM memoria_documentos
ORDER BY embedding <=> $1
LIMIT {{ top_n }};

Con esos dos flujos ya alcanza para que el agente tenga memoria de verdad: cargar cada vez que se resuelve algo, buscar cada vez que arranca una tarea nueva o no está seguro de algo.

04Cómo funcionan los Relays, por dentro

Cada Relay es todavía más simple: un webhook protegido por un token propio (un header secreto, distinto para cada sistema) que recibe una instrucción, la ejecuta del lado de ese sistema, y devuelve el resultado real:

# Pedido del agente
POST /webhook/relay-sistema-1
Header: X-Relay-Token: ****************
{ "instruccion": "systemctl status backup.timer" }

# Respuesta del Relay
{ "codigo": 0, "salida": "backup.timer activo, proxima corrida 03:00" }

El agente nunca ve ni maneja la credencial real de ningún sistema, sólo el token de su Relay. Si hay que cortarle el acceso a un sistema puntual, alcanza con desactivar o rotar ese token, sin tocar nada del resto — y como todos los Relays hablan el mismo protocolo, agregar un sistema nuevo es simplemente copiar el patrón. Nosotros además rotamos todos los tokens automáticamente cada cierto tiempo con un flujo dedicado sólo a eso, para que ninguno quede vivo indefinidamente.

05Cómo le das acceso a tu propia IA a todo esto

Esta es la parte que conecta todo: ¿cómo hace el agente para efectivamente usar estos endpoints? Depende de qué tan moderna sea la plataforma. Si soporta «herramientas» o function calling (la mayoría de las plataformas de agentes serias lo hacen, incluido el protocolo abierto MCP), le das de alta cada endpoint como una herramienta propia:

Si la plataforma no soporta eso, o querés algo más simple para empezar, alcanza con darle al agente, en sus instrucciones de arranque, esa misma lista de endpoints con un ejemplo concreto de cada uno. Cualquier agente que pueda hacer una petición HTTP puede usarlo sin necesitar nada más sofisticado.

Lo que realmente hace que esto funcione con el tiempo son dos hábitos, no la tecnología: que el agente busque primero en su memoria antes de asumir que no sabe algo, y que cargue lo importante a la memoria en la misma tarea en que lo resuelve — nunca «para después».

06Resultados

07Lo que nos llevamos

• Buscar primero, asumir después: el hábito importa más que la tecnología.
• Cargar en la misma tarea en que se resuelve algo, nunca «para después» — un RAG que se actualiza esporádicamente es casi tan inútil como no tener memoria.
• Cada sistema real detrás de su propio Relay y su propio token, así un token filtrado nunca compromete todo lo demás.
• Rotar tokens automáticamente, no depender de que alguien se acuerde de hacerlo a mano.
• Documentar, dentro de la propia memoria, el protocolo para que el agente se reconecte solo si pierde el contexto.