n8n Agentes de Larga Duración: Arquitectura y Escala

Un sistema SCADA en una planta embotelladora necesita revisar 120 sensores cada minuto, detectar anomalías, ajustar válvulas automáticamente, registrar eventos, notificar operadores y generar reportes horarios. Todo esto 24/7, sin intervención. ¿Lo haces con scripts que corren en cron? ¿Con un agente inteligente que aprende de sus propios errores? ¿Con redundancia para que si falla uno, otro tome el relevo?

Hace un año, una “automatización de larga duración” era cosa de scripts heredados, complejos y frágiles. Hoy, n8n permite diseñar agentes autónomos que mantienen estado, toman decisiones y escalan a producción. Pero requiere cambio de mentalidad: workflows que corren una sola vez no son lo mismo que sistemas que corren para siempre.

Este artículo te enseña los patrones, las trampas y los casos reales que funcionan en planta.

Qué es un agente n8n de larga duración

Un agente de larga duración es un workflow que:

1. Mantiene estado persistente — no empieza de cero cada ejecución. “¿Qué pasó la última vez? ¿Hay tareas pendientes?”
2. Decide automáticamente — evalúa condiciones y actúa sin esperar a humano. “Sensor A anómalo → ajusta válvula B → registra en log → sigue.”
3. Se ejecuta continuamente — cron cada 5-10 minutos (o menos), no solo cuando algo lo dispara manualmente.
4. Reintenta inteligentemente — si una tarea falla (red down, API timeout), lo intenta de nuevo sin perder contexto.
5. Es observable — cada paso queda registrado. Sabés exactamente qué pasó, cuándo, por qué.

Ejemplos reales:

• Monitoreo PLC 24/7: Agente que lee estado de 60 variables cada minuto, detecta desvíos, ejecuta correcciones y alerta al turno.
• Reconciliación ERP-WMS: Agente que compara inventario cada hora, detecta discrepancias, crea órdenes de ajuste, notifica al almacén.
• Predicción de fallas: Agente que recolecta telemetría, corre modelos ML, predice mantenimiento, programa avisos con 48h de anticipación.
• Inteligencia de mercado: Agente que monitorea precios de competencia cada 30 min, actualiza tu catálogo, notifica al comercial.

Lo que diferencia un agente de un simple workflow:

Aspecto	Workflow Normal	Agente de Larga Duración
Vida útil	Minutos	Horas/días/años
Disparador	Manual, webhook, cron (ejecuta 1 vez)	Cron continuo (ejecuta cada 5 min, indefinidamente)
Estado	Ninguno. Cada ejecución es aislada	Persistente en BD. Retoma donde quedó
Si falla un paso	Se detiene. Log de error. Fin	Reintenta automáticamente. Escala si pasa threshold
Decisión	Sigue pasos. Si condición → rama A o B	Evalúa estado, historial, métricas. Decide dinámicamente
Observabilidad	Logs de n8n. Suficiente	Logs propios + métricas + alertas + dashboard custom

Arquitectura: Cómo guardar estado

El corazón de un agente de larga duración es su almacén de estado. Sin él, cada ejecución es una isla.

Esquema de BD típico

Usamos PostgreSQL (puedes adaptar a MongoDB, Supabase, etc.):

-- Tabla de estado de agentes
CREATE TABLE agent_state (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(50) UNIQUE NOT NULL,          -- "plc-monitor", "erp-sync"
  last_execution TIMESTAMP,                      -- Cuándo corrió la última vez
  status VARCHAR(20),                            -- "running", "idle", "failed"
  state_data JSONB,                              -- Estado actual (variables, contadores, etc)
  error_count INT DEFAULT 0,                     -- Errores consecutivos
  last_error TEXT,                               -- Último error
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Tabla de tareas pendientes
CREATE TABLE agent_tasks (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(50),
  task_type VARCHAR(50),                         -- "adjust_valve", "send_alert", "update_inventory"
  status VARCHAR(20),                            -- "pending", "in_progress", "completed", "failed"
  payload JSONB,                                 -- Datos de la tarea
  retry_count INT DEFAULT 0,
  max_retries INT DEFAULT 5,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  completed_at TIMESTAMP
);

-- Tabla de logs (auditoría)
CREATE TABLE agent_logs (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(50),
  level VARCHAR(10),                             -- "info", "warning", "error"
  message TEXT,
  metadata JSONB,                                -- Contexto adicional
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Flujo típico en n8n

1. Inicio: Workflow disparado por cron cada 5 minutos.
2. Lectura de estado: Nodo SQL: SELECT * FROM agent_state WHERE agent_id = 'plc-monitor'
3. Lógica: Evalúa state_data, datos actuales (lectura de API/PLC), compara, decide.
4. Ejecutar tareas: Si hay pending en agent_tasks, procesa cada una.
5. Guardar estado: Actualiza agent_state.state_data con nuevos valores.
6. Registrar: INSERT en agent_logs con qué pasó.
7. Fin: Si hay errores graves, actualiza status = 'failed' y escala.

En n8n visualmente:

[Trigger: Cron cada 5 min]
    ↓
[SQL: Leer agent_state]
    ↓
[JS: Evaluar condiciones]
    ↓
[Condicional] ──→ [Si hay tareas] → [Loop: Procesar cada tarea]
    ↓                                      ↓
[Si error crítico]                   [Actualizar task status en BD]
    ↓                                      ↓
[Alertar a humano]                   [Continuar]
    ↓                                      ↓
[SQL: Guardar estado nuevo]  ←───────────┘
    ↓
[Fin]

Reintentos inteligentes

Un agente que reintenta ciegamente es un agente que se bloquea.

Estrategia: Reintentos exponenciales con jitter

// En nodo JS dentro del loop de tareas
const task = input.item.json;
const maxRetries = 5;
const baseDelay = 1000; // ms

function calculateDelay(retryCount) {
  // Exponencial: 1s, 2s, 4s, 8s, 16s
  const exponential = baseDelay * Math.pow(2, retryCount);
  // Añade aleatoriedad para evitar thundering herd
  const jitter = exponential * (0.5 + Math.random() * 0.5);
  return Math.min(jitter, 300000); // cap 5 minutos
}

if (task.retry_count >= maxRetries) {
  return {
    status: 'failed',
    reason: 'max_retries_exceeded',
    escalate: true // Notificar humano
  };
}

const nextRetry = new Date(Date.now() + calculateDelay(task.retry_count));
return {
  status: 'pending',
  retry_count: task.retry_count + 1,
  next_retry: nextRetry.toISOString()
};

Guardrails: Evitar bucles infinitos

Define límites en tu agent_state:

// Evalúa antes de procesar más tareas
if (state.error_count > 10) {
  return {
    error: 'too_many_errors',
    stop: true,
    alert: 'Agent exceeded error threshold. Manual intervention required.'
  };
}

// Timeout de ejecución
if (Date.now() - state.last_execution > 900000) { // 15 minutos
  return {
    warning: 'execution_timeout',
    force_stop: true
  };
}

Casos reales: Monitoreo industrial 24/7

Caso 1: Agente de monitoreo PLC (Siemens S7-1500)

Escenario: Planta de producción con 60 variables PLC críticas. Necesitas:

• Leer valores cada 30 segundos
• Detectar anomalías (valor fuera de rango)
• Ajustar automáticamente si es seguro (abrir válvula, cambiar velocidad)
• Alertar operador si falla
• Registrar historial para análisis

Arquitectura:

Agente: "plc_monitor"
Estado persistente:
  - last_read: timestamp
  - variables: { temp_reactor: 87.5, presion_salida: 2.3, ... }
  - anomalies: [ { variable: "temp_reactor", value: 87.5, exceeds: "max=85" } ]
  - auto_adjustments_count: 3
  
Ciclo:
  1. Lee 60 variables de PLC (OPC-UA)
  2. Compara con rangos esperados
  3. Si anomalía + es reversible → ajusta automáticamente
  4. Registra en BD + Influx (para Grafana)
  5. Si anomalía + requiere humano → alerta Slack + SMS
  6. Guarda estado actualizado

Nodos n8n:

• HTTP Request → OPC-UA server (o conecta directo con nodo n8n OPC UA si existe)
• JS: Comparar valores vs rangos
• SQL: Guardar en TimeSeries DB
• Condicional: ¿Puede auto-ajustarse? → Sí: ejecuta comando PLC → No: alerta
• SQL: Actualizar agent_state

Resultado esperado:

• Detección de anomalías en < 1 minuto
• Auto-ajustes logging instantáneo
• Alertas al turno sin demora
• Historial completo para auditoría + ML

---

Caso 2: Reconciliación ERP-WMS continua

Escenario: Almacén con 5.000 SKUs. Cada hora el WMS debe conciliar con ERP:

• Leer inventario WMS
• Comparar con ERP
• Detectar discrepancias
• Crear órdenes de ajuste automáticamente
• Notificar almacenero si hay manualmente algo fuera

Estado agente:

{
  "agent_id": "erp_wms_sync",
  "last_sync": "2026-09-02T10:15:00Z",
  "status": "idle",
  "state_data": {
    "last_full_sync": "2026-09-02T09:15:00Z",
    "discrepancies_detected": 23,
    "adjustments_created": 21,
    "pending_manual_review": 2,
    "sync_duration_ms": 145000
  }
}

Flujo:

[Cron cada 60 min]
  ↓
[Lectura WMS API]
  ↓
[Lectura SAP API]
  ↓
[Comparación: SKU, cantidad, ubicación]
  ↓
[Análisis discrepancias]
  ├─→ Discrepancia < 5 unidades → Auto-ajuste
  └─→ Discrepancia > 5 unidades → Crear ticket manual
  ↓
[Guardar reporte en agent_logs]
  ↓
[Notificar (Slack): "Sync OK. 21 ajustes auto. 2 requieren revisión."]

Implementación en n8n:

• 1 HTTP Request → WMS API
• 1 HTTP Request → SAP API
• 1 Nodo JS → Comparación (puede ser complejo; considerar UDF externa)
• 1 SQL INSERT → CREATE TABLE adjustment_orders
• 1 HTTP → Slack webhook

---

Observabilidad y alertas

Un agente 24/7 sin observabilidad es una bomba de tiempo.

Dashboard mínimo

Crea un segundo workflow “agent_monitor” que corre cada hora:

SELECT 
  agent_id,
  status,
  EXTRACT(EPOCH FROM (NOW() - last_execution)) / 60 AS min_since_last_exec,
  error_count,
  last_error,
  TO_CHAR(updated_at, 'YYYY-MM-DD HH24:MI:SS') AS last_updated
FROM agent_state
WHERE status != 'idle'  -- Solo agentes en ejecución
ORDER BY updated_at DESC;

Si min_since_last_exec > 10 (no ejecutó en 10 min), alerta.

Logs estruturados

Cada insert en agent_logs debe incluir:

{
  "agent_id": "plc_monitor",
  "level": "info",
  "message": "Anomaly detected: temperature out of range",
  "metadata": {
    "variable": "reactor_temp",
    "value": 91.2,
    "expected_max": 85,
    "action_taken": "auto_adjust_cooling",
    "success": true,
    "duration_ms": 234
  },
  "created_at": "2026-09-02T10:35:47Z"
}

Exporta esto a Grafana Loki o Datadog para búsqueda full-text y alertas.

Métricas clave a monitorear

agent_execution_duration_seconds{agent_id="plc_monitor"} 0.45
agent_error_count_total{agent_id="plc_monitor"} 3
agent_tasks_processed_total{agent_id="plc_monitor", status="success"} 180
agent_tasks_processed_total{agent_id="plc_monitor", status="failed"} 2
agent_last_execution_timestamp{agent_id="plc_monitor"} 1725282947

Crea alertas en Grafana:

• agent_last_execution_timestamp NOT updated en los últimos 15 min → CRÍTICO
• agent_error_count_total creció > 5 en 10 min → WARNING
• agent_execution_duration_seconds > 5 segundos → INFO (workflow lento)

Escalabilidad: múltiples agentes, un n8n

Si tienes 3-5 agentes:

1. Un workflow principal por agente (ej. “plc_monitor”, “erp_sync”, “market_watch”)
2. Tabla agent_state centralizada — todos los agentes escriben/leen aquí
3. Locks optimistas — usa UPDATE ... WHERE version = X para evitar race conditions

UPDATE agent_state 
SET state_data = '{"temp": 92}', version = version + 1
WHERE agent_id = 'plc_monitor' AND version = 5;

Si no devuelve 1 fila → otra instancia modificó el estado → reintenta.

Si tienes 10+ agentes o carga muy alta:

• Multitenancy: Cada cliente = agente separado (aislamiento BD, recursos)
• Self-hosted n8n con múltiples workers (escalado horizontal)
• Queue externo (Redis, RabbitMQ) para desacoplamiento

Errores frecuentes (y cómo evitarlos)

Error	Síntoma	Solución
Sin guardado de estado	Agente pierde contexto cada ejecución	Usa BD externa. Sé disciplinado: guarda ANTES de cada paso crítico
Reintentos ciegos	Agent entra bucle intentando lo mismo 1000 veces	Implementa exponential backoff + máximo retries + escalada
Sin observabilidad	No sabés si falló hace 1 hora o está sano	Registra TODO en logs. Crea dashboard. Alertas automáticas
Race conditions	Dos agentes escriben state_data simultáneamente	Locks en BD (versioning o pessimistic locks)
Timeout infinito	Workflow cuelga esperando respuesta API	Set timeout máximo en HTTP requests. Usa Try/Catch
Escala insostenible	5 agentes × cron cada 5 min = 1.440 ejecuciones/día = $$	Optimiza cron (¿realmente cada 5 min?). Self-hosted si es posible

Conclusión: del script al sistema

Un agente n8n de larga duración no es “un workflow que corre en cron”. Es un sistema que decide, aprende de sus errores, se recupera automáticamente y nunca te deja plantado.

La diferencia entre un script que se cuelga a las 3 AM y un agente que mantiene tu planta corriendo es estado persistente + reintentos inteligentes + observabilidad.

Si recién empiezas:

1. Define claramente qué estado necesitas guardar (no todes las variables, solo las relevantes)
2. Implementa reintentos exponenciales desde el día 1 — no es prematura optimización
3. Registra cada ejecución en BD — sin logs estructurados, no hay debugging

Próximos pasos:

• Implementar n8n en empresa: guía paso a paso — cómo desplegar n8n para producción
• n8n + Grafana: Dashboard en tiempo real — monitorea tus agentes visualmente
• Python OPC-UA: Leer datos PLC — integración directa con PLCs

¿Estás construyendo un agente ahora mismo? Documenta tu esquema de estado, comparte tu arquitectura. Los sistemas que funcionan 24/7 sin fallar no son magia: son disciplina en el diseño.