Automatizar el contenido: de la ejecución puntual al pipeline que publica solo

Una sola pasada de diagnóstico y corrección sirve una vez. Un playbook son esos mismos pasos cableados para ejecutarse solos, con una programación o un disparador, hasta el artículo publicado. Así funciona por dentro.

~7 min de lectura . Automatización

Ejecutar analyze_content, después optimize_content y después publicar el resultado una vez es útil. Hacer esa misma secuencia cada semana, para cada borrador nuevo, sin que usted abra la herramienta cada vez, es automatización. Los playbooks de AdAstra son la forma en que una ejecución puntual se convierte en un pipeline: un grafo de pasos con ramificaciones, reintentos y una programación, que termina donde usted quiera que aterrice el contenido acabado.

De la ejecución puntual al pipeline

Un playbook es un grafo dirigido de nodos y aristas: llamadas a herramientas (analyze_content, optimize_content, optimize_headline, generate_keyword_ideas y las demás) conectadas mediante nodos de control de flujo que deciden qué se ejecuta después. Un playbook no cambia nada de lo que hace una herramienta; cambia cuándo se ejecuta, en qué orden, y qué pasa después con su salida. La misma secuencia de analizar y luego optimizar que usted ejecutaría a mano se convierte en una ejecución que lanza una vez y reutiliza indefinidamente.

Por dentro, una ejecución recorre el grafo desde sus nodos raíz, ejecuta cada uno y sigue sus aristas salientes hasta lo que venga a continuación. Cada nodo comunica su propio estado, correcto o error, y su salida; los nodos posteriores referencian esa salida directamente, así que un paso posterior lee exactamente lo que produjo una llamada anterior sin que usted copie valores a mano.

Playbooks y control de flujo

Cuatro tipos de nodo le dan a un playbook lógica de verdad en lugar de una línea recta. Un nodo if evalúa un conjunto de condiciones y envía la ejecución por su rama verdadera o falsa. Un nodo switch comprueba en orden una lista de reglas con nombre y sigue la primera que coincida, o cae en una rama por defecto si no coincide ninguna. Un nodo filter comprueba una condición y o bien deja continuar la ejecución (pass), o bien la rama se detiene ahí, sin nada por debajo. Un nodo loop recorre un array, o bien elemento a elemento (each), o bien en grupos de tamaño fijo (batch), ejecutando su cuerpo una vez por elemento o por grupo, hasta un número máximo de iteraciones configurado.

Las condiciones son en todas partes la misma pieza: comparar un valor con otro mediante operadores como igual a, contiene, mayor que, está vacío o coincide con una expresión regular, combinados con Y o con O. Un nodo con dos o más ramas entrantes, un rombo donde dos caminos vuelven a unirse, espera a todas las ramas que de verdad se van a ejecutar antes de continuar, para que una rama rápida nunca se adelante a otra más lenta que sigue en marcha.

Los fallos se gestionan por nodo de herramienta, no por playbook. Cada llamada a una herramienta lleva una política de reintentos, un número máximo de intentos y una espera entre ellos, o bien un retardo fijo, o bien un backoff exponencial que se duplica cada vez. Solo se reintentan los errores clasificados como transitorios (una caída pasajera) o como limitación de frecuencia; un error permanente, como una entrada inválida, falla de inmediato. Una vez agotados los reintentos, el ajuste onError del nodo decide qué pasa después: detener toda la ejecución, continuar de todos modos por el camino normal, o continuar por una rama de error dedicada.

Programación y disparadores

Un playbook puede arrancar de tres maneras. Un disparador manual lo ejecuta a demanda, igual que ejecutar una herramienta a mano. Un disparador webhook le da al playbook su propia URL protegida con un token, para que un sistema externo, o usted, pueda lanzar una ejecución con una petición. Un disparador cron ejecuta el playbook con una programación recurrente, definida como una expresión cron con su propia zona horaria.

cron: "0 8 * * 1"
timezone: "Europe/Berlin"
# illustrative: every Monday at 08:00, Europe/Berlin

Esa es una programación ilustrativa, no un valor por defecto fijo: se acepta cualquier expresión cron válida, y se valida al guardar el disparador en lugar de descubrirse como una sorpresa en tiempo de ejecución. La siguiente ejecución de un disparador cron se calcula a partir de la expresión y de la zona horaria juntas, así que una programación sigue queriendo decir «las ocho de la mañana» a través de un cambio de hora en lugar de desplazarse una hora.

Un tick en segundo plano enumera todos los playbooks que toca ejecutar ahora mismo y ejecuta cada uno por turno, en su propio dominio aislado de fallo y de tiempo de espera, para que una ejecución colgada no bloquee el resto del lote. Lo que más importa es qué ocurre si un playbook sigue ejecutándose cuando llega su siguiente turno: AdAstra reserva cada ejecución de forma atómica antes de iniciarla, así que un playbook que ya está en curso no puede dispararse una segunda vez encima de sí mismo. Un turno de cron que cae en plena ejecución se registra como omitido, no se inicia como una ejecución solapada. Solo una ejecución disparada por cron hace avanzar la programación; una ejecución manual nunca se come el siguiente turno de cron.

Publicar en WordPress

La publicación en WordPress no es un nodo dentro del grafo de playbook de arriba: el registro de herramientas del que bebe un playbook no tiene ninguna herramienta de WordPress, así que ningún nodo tool_call puede llevar la salida de una ejecución directamente a un sitio. Funciona a través de una segunda superficie de automatización, separada. Pedirle a AdAstra que automatice la publicación, con una cadencia diaria, semanal, cada dos semanas o mensual, registra una tarea recurrente contra un perfil de WordPress conectado, independiente del programador basado en grafos que se ha visto arriba.

Esa tarea se autentica igual que en cualquier otra parte de AdAstra: contra el propio endpoint JWT del sitio (wp-json/jwt-auth/v1/token) con sus credenciales de WordPress, y después usa el token que recibe para crear la entrada mediante la API REST estándar de WordPress (wp-json/wp/v2/posts), con título, contenido, etiquetas y, si se facilita, una imagen destacada subida antes a la biblioteca de medios. Usted elige el estado de la entrada resultante igual que si publicara a mano: publicada de inmediato, o como borrador para que primero la revise una persona.

Los límites de seguridad

La automatización no desactiva las comprobaciones que se aplican en todas las demás partes de AdAstra. Una ejecución programada o disparada por webhook sigue llamando a las mismas herramientas analyze_content, optimize_content y optimize_headline que se tratan en otros artículos: el mismo diagnóstico de tres temas, las mismas cifras ancladas de Google Ads, ningún dato de palabras clave inventado que sustituya a una consulta fallida. Un fallo dentro de un playbook tampoco es un salto silencioso: queda registrado en el nodo con su clase de error, y o bien detiene la ejecución, o bien se va por el camino de error que usted haya configurado.

La prevención de ejecuciones duplicadas importa sobre todo como límite de seguridad, no como comodidad. Sin una reserva atómica de cada ejecución, un disparador solapado podría lanzar una segunda pasada sobre un contenido que una primera no ha terminado de optimizar, o publicar un borrador duplicado desde una ejecución que debería haberse omitido. Reservar la ejecución antes de que se ejecute la más mínima herramienta es lo que hace que un pipeline programado se pueda dejar sin vigilancia.

En resumen

• Un playbook es un grafo de llamadas a herramientas más nodos de control de flujo; cambia cuándo y en qué orden se ejecutan las herramientas, no lo que hace cada herramienta.
• Los nodos if, switch, filter y loop le dan a un playbook ramificación, coincidencia por reglas con nombre, condiciones de descarte e iteración por elemento o por grupo, todo ello movido por las mismas filas de condiciones Y/O.
• Cada nodo de herramienta lleva su propia política de reintentos (retardo fijo o backoff exponencial, solo errores transitorios y de limitación de frecuencia) y un ajuste onError: detener, continuar con normalidad, o continuar por una rama de error.
• Los playbooks arrancan desde una ejecución manual, un webhook protegido con token, o una programación cron con su propia zona horaria; solo una ejecución disparada por cron hace avanzar esa programación.
• Una reserva atómica impide que un playbook se ejecute dos veces a la vez; un turno de cron que cae en plena ejecución se registra como omitido en lugar de iniciarse como una segunda ejecución solapada.
• La publicación en WordPress es una automatización aparte, basada en cadencia, y no un paso de playbook: una tarea recurrente publica en un sitio conectado mediante autenticación JWT y la API REST estándar, como entrada publicada o como borrador pendiente de revisión.
• Las ejecuciones automatizadas no tienen ninguna excepción en la calidad de los datos: se aplican el mismo diagnóstico anclado y las mismas comprobaciones de optimización, y los fallos se registran y se enrutan, nunca se omiten en silencio.