n8n + Claude API: Autonomía en Operaciones de Marketing

La automatización en operaciones de marketing ha trascendido el nivel de "enviar correos a tiempo". Cuando modelos de lenguaje como Claude 3.5 Sonnet llegan a producción, la pregunta real no es cuántos segundos tarda el workflow, sino cómo diseñaste la gestión de errores. La combinación n8n + Claude API nos permitió generar 200+ artículos sin intervención manual — pero ese resultado se logró únicamente al implementar idempotencia, estrategias de reintentos y monitoreo de estado desde el primer momento.

Definición de un workflow autónomo

Un workflow autónomo es un sistema que completa su tarea de principio a fin sin intervención humana. Si puedes decir "ejecutar y olvidar", es autónomo. En operaciones de marketing esto significa: extraer palabras clave de Google Search Console, enviarlas a Claude, recuperar contenido, hacer commit en GitHub, controlar versiones — todo en un solo disparo.

n8n actúa como orquestador. Se dispara mediante webhook, mantiene estado entre cada paso, y activa lógica de reintentos si ocurren errores. Claude API es el generador de contenido — pero tienes que arquitecturar la generación para no requerir control manual. Si codificas hardcoded el prompt en n8n, cada modificación significa cambiar 15 lugares en el workflow. Versionala el prompt desde el inicio en un repositorio.

En nuestro caso, n8n corre en una instancia self-hosted gratuita. Cinco nodos de workflow: trigger webhook, petición HTTP (Claude API), transformación de datos, commit GitHub, registro en Supabase. Completación total en 3 minutos — 90 segundos son generación de 1.500 palabras por Claude, el resto es I/O.

Idempotencia: mismo input, mismo output

Idempotencia es la garantía de que ejecutar la misma operación múltiples veces produce el mismo conjunto de resultados. En workflows basados en LLM esto no se cumple naturalmente — el mismo prompt genera salidas diferentes. Pero la lógica del sistema de archivos y commits debe ser idempotente.

Nuestro enfoque: cada pieza de contenido se asocia con un identificador único (i18nKey). El i18nKey tiene formato {category}-{seq}-{YYYY-MM}. El workflow de n8n genera esta clave, la envía a Claude, y estructura la ruta del archivo. Si se dispara nuevamente con la misma palabra clave, se verifica en Supabase — si existe, SKIP; si no existe, PROCESAR.

// Nodo Function en n8n — verificación de idempotencia
const existingRecord = await $('Supabase').first().json.data.find(
  (r) => r.i18n_key === $json.i18nKey
);
if (existingRecord) {
  return { skip: true, reason: 'already_published' };
}
return { skip: false };

Al hacer commit en GitHub también se verifica el mismo nombre de archivo. Si existe, devuelve 409 Conflict, el nodo de manejo de errores lo detecta y registra en log — pero el workflow no se detiene. De esta forma, en un batch de 50 palabras clave, si 3 ya se generaron, procesa solo las 47 restantes.

Claude API: versionado de prompts y presupuesto de tokens

Al usar Claude API en producción, el punto más crítico es la estabilidad del prompt. Si codificas hardcoded el prompt en n8n, editas el workflow cada iteración. En lugar de eso, almacena el prompt como archivo Markdown en GitHub y extráelo mediante URL raw.

Nuestro setup: archivo prompts/roibase-master-es.md en GitHub. El nodo HTTP Request de n8n obtiene esta URL, inserta el contenido como mensaje SYSTEM hacia Claude. El mensaje USER se rellena dinámicamente en el workflow — palabra clave, categoría, lista de enlaces internos, fecha actual y otros variables de contexto.

{
  "model": "claude-3-5-sonnet-20241022",
  "max_tokens": 200000,
  "system": "{{$node["Fetch_Prompt"].json.content}}",
  "messages": [
    {
      "role": "user",
      "content": "KEYWORD: {{$json.keyword}}\nCATEGORY: {{$json.category}}\n..."
    }
  ]
}

Presupuesto de tokens: la ventana de contexto de Claude 3.5 Sonnet es 200K tokens. Nuestro prompt ocupa 8K tokens (master prompt español + directivas por categoría), el mensaje USER 500 tokens, y la salida de Claude promedian 2.5K tokens (1.500 palabras). Total ~11K tokens por ejecución, con precios por lotes resulta ~$0.04 por run. 200 artículos = $8 en costo de API.

Gestión de errores: reintentos, fallback y registro de estado

En workflows basados en LLM existen tres clases de errores: transitorios (rate limit), permanentes (salida malformada) e inesperados (timeout de red). La lógica de manejo de errores de n8n no distingue entre estos tres — te corresponde diseñar la estrategia de reintentos.

Nuestro enfoque: cada nodo tiene configurados reintentos. En el nodo HTTP Request (Claude API) activamos retryOnFail: true, maxRetries: 3, waitBetweenTries: 5000ms. Si llega un rate limit (429), se aplica backoff exponencial. Si falla en 3 intentos, el nodo de captura de errores entra en acción — registra failed_generation en Supabase, detiene el workflow para esa palabra clave pero permite que continúen las demás.

Para salidas malformadas (si Claude genera menos de 1.400 palabras o falta el frontmatter) existe un nodo de validación. Analiza el JSON, verifica campos readingTime y title. Si falla, envía a Claude el mensaje "regenerate con restricción de longitud más estricta" — esta vez incrementa el parámetro max_tokens. En el segundo intento falla nuevamente, la tarea entra en una cola de revisión manual.

El registro de estado se mantiene en Supabase con este esquema:

Campo	Tipo	Descripción
`i18n_key`	text	Identificador único
`keyword`	text	Query de GSC
`status`	enum	`pending`, `generated`, `failed`
`retry_count`	int	Cuántos reintentos se ejecutaron
`error_log`	jsonb	Detalles del error
`created_at`	timestamp	Hora del primer run
`completed_at`	timestamp	Hora de finalización (null si sigue en proceso)

Esta tabla sirve tanto para monitoreo como para debugging. En Grafana, registros con retry_count > 2 aparecen en el dashboard — así identificas qué palabras clave causan problemas recurrentes en Claude.

Experiencia en producción: 200+ artículos, tasa de fallo del 4%

Las primeras 50 artículos se generaron monitoreando manualmente. Las 150 restantes completamente en modo autónomo. Resultados:

Tasa de éxito: 96% (192/200)
Tiempo promedio de completación: 3.2 minutos
Rate limit activado: 7 veces (todos con reintentos exitosos)
Intervención manual necesaria: 8 artículos (salida malformada + ambigüedad de keyword)

El 50% de fallos provenía de keywords demasiado genéricas ("marketing digital"). Claude se esfuerza por llegar a 1.500 palabras y genera contenido de relleno — el nodo de validación lo detecta pero no puede regenerar exitosamente. Para estos casos añadimos el keyword a una lista negra.

El otro 50% fue causado por race conditions en GitHub API (archivo ya existe pero el registro en Supabase no existe). Para resolverlo agregamos verificación de atomicidad: antes de hacer commit en GitHub, registra estado pending en Supabase; si el commit es exitoso, actualiza a generated. Esto redujo el problema de 4% a 1.5%.

Perfil de latencia: 90 segundos en Claude API, 45 segundos en commit GitHub (archivos Markdown grandes), 15 segundos en escritura Supabase, 30 segundos en procesamiento interno de n8n. El cuello de botella es Claude — pero no necesita paralelización porque hay rate limit. Procesamos en lotes: 10 keywords por hora, capacidad de 240 keywords diarios.

Tradeoffs: qué ganamos, qué perdimos

Al diseñar workflows autónomos existen tres tradeoffs principales:

Calidad vs velocidad: La calidad de salida de Claude depende del tuning de prompts. En la versión inicial teníamos rechazo del 40% — añadir regla "1.400-1.600 palabras OBLIGATORIO" lo redujo a 4%. Pero esto hace que Claude a veces rellene con contenido no esencial. Un editor humano lo vería, la IA no.
Costo vs confiabilidad: Si la lógica de reintentos es agresiva, el consumo de tokens sube. En la primera versión cada reintento enviaba el prompt completo (8K tokens × 3 = 24K). Ahora reutilizamos solo el mensaje USER en reintentos y usamos prompt caching de Claude (feature lanzada en mayo 2025). Costo redujo 60%.
Flexibilidad vs complejidad: Queríamos prompts separados por categoría (AI más técnico, marketing más business). Eso significaba 6 archivos de prompt diferentes — pesadilla de versionado. Solución: un prompt master + bloque CATEGORY_GUIDANCE que se inserta en el mensaje USER según categoría. Ganamos flexibilidad con complejidad controlada.

Futuro: multi-agente y auto-reparación

La arquitectura actual es single-agent — Claude trabaja solo. La siguiente iteración testea arquitectura multi-agente: un agente genera contenido, otro hace revisión, un tercero optimiza SEO. El feature de sub-workflows en n8n lo soporta pero triplica el costo de tokens.

Auto-reparación: cuando un workflow falla, realiza análisis de causa raíz y se auto-corrige. Ejemplo: si Claude genera consistentemente contenido corto, añade nota al prompt "aumentar longitud de salida", reintenta. Meta-optimización — el LLM evoluciona su propio prompt. Riesgoso pero potente.

En trabajos de Roibase como Arquitectura de Datos First-Party y Medición usamos enfoque similar: recopilar señales de conversión autónomamente, detectar anomalías, auto-corregirse. El principio base al construir sistemas autónomos en producción es idéntico: diseña gestión de errores desde el inicio, registra estado, hace reintentos idempotentes.