¿Qué es un playbook de agentes IA con memoria persistente?
Un playbook de agentes IA es un sistema de tareas orquestadas con dependencias declaradas, donde cada tarea tiene un agente especializado asignado — Analytics, SEO, Copy, GEO, Community — y el output de cada tarea se convierte en el input de las siguientes. A diferencia de un prompt único a un solo modelo, un playbook separa investigación, redacción, optimización y ensamblaje en fases. Los agentes no trabajan en paralelo sin orden: se alimentan entre sí. El playbook descrito en esta edición tiene 20 tareas, 5 agentes, y redujo el tiempo de producción de ~4 horas a 90 minutos en 12 semanas de iteración.
Esta edición la escribí en 90 minutos.
No porque el tema fuera fácil. Sino porque antes de escribir una sola línea, un agente ya había recopilado métricas, otro había revisado preguntas de audiencia en X, otro había investigado fuentes reales y otro había escrito un content brief con todo eso digerido.
20 tareas. 5 agentes. Yo solo intervine en 4 pasos manuales.
Esta semana te cuento cómo funciona ese playbook — y por qué la diferencia entre "usar IA para escribir" y tener un sistema real está en cómo los agentes se alimentan entre sí.
20 tareas, 5 agentes: el playbook que produce esta newsletter
El borrador de esta edición estuvo listo en 90 minutos. Con datos reales, coherencia tonal y un informe de investigación con fuentes adjunto antes de que yo escribiera nada.
Yo solo tengo que trabajar en que los inputs y el feedback sean buenos, las ideas son mías, las validaciones y los consejos para mejorar, son míos, pero el trabajo costoso, es de los agentes.
No fue un prompt largo. Fue un playbook de 20 tareas donde cada agente hace una cosa y su output alimenta al siguiente.
¿Cómo se coordinan 5 agentes IA para producir una newsletter?
La mayoría de workflows con IA hacen esto: tú le das un prompt a un modelo y él genera todo — research, estructura, redacción — en una sola llamada. El resultado es genérico porque el modelo no sabe nada de tu tema que no esté ya en sus datos de entrenamiento.
El playbook tiene 3 fases. Cada tarea tiene un agente asignado y dependencias declaradas — no se ejecuta hasta que las tareas de las que depende estén completas.
Fase 1 — Los agentes recopilan (yo solo elijo el tema)
Yo hago una cosa: elegir el tema del Deep Dive. A partir de ahí:
El agente de Analytics recopila métricas de mis proyectos (Play Console, Search Console, Beehiiv) y las compila para el Build Log.
El agente de Community revisa el engagement en X y extrae preguntas reales de la audiencia.
El agente de SEO genera un content brief con keywords y luego investiga datos reales — papers, guías técnicas, fuentes primarias — para el Deep Dive.
Estas tareas corren en paralelo. Cuando terminan, el agente de Copy tiene sobre la mesa: métricas compiladas, preguntas de audiencia, un brief SEO y un informe de research. No le pido que invente. Le doy material.
Fase 2 — Los agentes escriben (cada uno alimenta al siguiente)
Deep Dive completo — el agente de Copy recibe el content brief + el research. Escribe el artículo técnico.
Build Log final — otro agente de Copy recibe los datos compilados por Analytics. Números sin adorno.
Contexto de edición — con el Deep Dive y el Build Log listos, el agente genera un resumen para que las secciones complementarias sean coherentes.
Intro / Hook — se escribe después del Deep Dive, no antes. Se basa en lo que realmente dice la edición.
Herramienta, CTA, Subject lines — cada uno con el contexto de la edición completa.
El hook no se inventa. Se deriva. Las subject lines no se generan en el vacío. Se generan sabiendo qué dice el artículo, qué datos tiene el Build Log y qué tono tiene el hook.
Fase 3 — Optimización, ensamblaje y revisión
El agente de GEO optimiza la versión web para citabilidad IA: definiciones, headers como preguntas, FAQ con schema JSON-LD.
El agente de Community genera el hilo de X para promover la edición.
El agente de Copy ensambla todo — email + versión web — en un solo documento listo para Beehiiv.
El agente de GEO hace la revisión editorial final con criterio independiente.
Y después, queda la tarea más importante, revisar todo, reescribir lo que no me gusta, iterar con los agentes para conseguir una versión mejor, más profesional, pero siempre con mi toque personal. La última decisión, siempre es mía.
Para terminar, otros 3 pasos manuales: maquetar en Beehiiv, monitorizar métricas, y escribir la retrospectiva.
¿Por qué el hook se escribe después del artículo y no antes?
En la mayoría de workflows con IA, el usuario escribe primero el hook y luego genera el resto. Si escribes el hook primero, estás prometiendo algo que el artículo aún no ha demostrado.
En mi playbook, el hook es la tarea 10 de 20. Se ejecuta después del Deep Dive (tarea 7), del Build Log (tarea 8) y del contexto de edición (tarea 9). El agente que escribe el hook ya sabe qué dice el artículo, qué datos tiene y cuál es el ángulo real.
El hook no promete. Resume.
¿Qué impide que el sistema se degrade semana a semana?
La cadena de 20 tareas resuelve una edición. Pero no resuelve la siguiente.
Sin retroalimentación, la semana que viene el agente de SEO no sabe de qué temas ya has hablado en el resto de ediciones. El de Copy repite la misma estructura. El de Community sugiere los mismos ángulos.
Por eso la tarea 20 es manual y es la más importante: la retrospectiva. Cada semana escribo en /memories/gradiente_retro.md qué funcionó, qué no, y qué instrucciones ajustar. La semana siguiente, cada agente lee ese archivo antes de ejecutar.
# Retro — Edición {{número}}
Fecha: {{fecha}}
## Qué funcionó
- [sección] → [métrica o señal cualitativa]
## Qué no funcionó
- [tarea] → [problema específico]
## Ajuste para la próxima edición
- [instrucción concreta para el agente X]
## Contexto a preservar
- Tema ya tratado: [lista]
- Tono que resonó: [descripción en 1 línea]La cadena de 20 tareas es lo que produce el resultado. La retro es lo que hace que mejore. Sin la cadena, no hay sistema. Sin la retro, el sistema no aprende.
Build Log — 9 al 15 de abril
TusPorras (Android + iOS) — +40 usuarios esta semana. La v1.1.0 publicada el 13 de abril desbloqueó visibilidad en Play Store; +55% de aumento en visualizaciones del producto esta semana.
TusPorras (SEO) — Seguimos creando contenido para el mundial, la anomalía SEO de esta semana: El post sobre el balón de oro del mundial ha generado 145 impresiones, pero 0 clics, parece que el título entrará en optimización esta semana.
Gradiente — 5 suscriptores totales (+1 esta semana, +25%). Open rate 75%, CTR 33.3%.
Agentes IA Marketing — Hemos trabajado duro en la funcionalidad de Playbooks para creación de Newsletter y para Auditoría SEO (lo mostraremos pronto).
CLAUDE.MD Score — Nuevo proyecto para evaluar la calidad de tus CLAUDE.MD, algo fundamental en el cuidado del consumo de tokens.
🛠️ Herramienta de la semana: SuperGrok (generación de vídeo)
Esta semana usé SuperGrok para generar vídeos desde texto. Sin edición, sin grabación, sin Premiere.
Veredicto: lo uso para contenido en X, no para todo.
La calidad supera lo que esperaba. El vídeo sale en minutos y funciona bien para posts cortos en X —donde, por cierto, el algoritmo parece favorecer contenido nativo generado con Grok.
Para quién es útil: creadores que publican en X y no quieren tocar herramientas de edición.
Para quién no: si necesitas control preciso de escena, voz o marca. Ahí aún gana Runway.
Antes de cerrar
Una pregunta: ¿Cómo produces tu contenido con IA hoy?
Responde a este email con una palabra: prompt, workflow, sistema — o la tuya.
Leo todas las respuestas.
Preguntas frecuentes
¿Qué es un playbook de agentes IA para newsletters? Un playbook de agentes IA es un sistema de tareas con dependencias declaradas y agentes especializados asignados a cada tarea. En el caso de Gradiente, son 20 tareas y 5 agentes (Analytics, SEO, Copy, GEO, Community) que se ejecutan en cadena: el output de cada tarea alimenta a la siguiente. No es un solo prompt que genera todo — es una línea de producción donde cada agente hace una cosa bien.
¿Por qué usar 5 agentes especializados en vez de un solo prompt? Un solo prompt obliga al modelo a investigar, estructurar, redactar y optimizar en una llamada. El resultado es genérico porque no tiene datos actualizados ni contexto específico. Con 5 agentes, el de Analytics recopila métricas reales, el de SEO investiga fuentes primarias, el de Copy escribe con ese material como input, el de GEO optimiza para citabilidad IA y el de Community genera la distribución. Cada capa añade calidad que la anterior no podía.
¿Cómo se coordinan las dependencias entre agentes IA? Cada tarea del playbook tiene un campo dependsOn que lista las tareas que deben completarse antes de que se ejecute. Por ejemplo, el agente de Copy no escribe el Deep Dive hasta que el agente de SEO haya completado el content brief y el research. El hook se escribe después del artículo, no antes, porque necesita saber qué dice la edición completa.
¿Por qué el hook de una newsletter se escribe después del artículo? En la mayoría de workflows, el hook se escribe primero y el artículo después. El problema es que el hook promete algo que el artículo aún no ha demostrado. En el playbook de Gradiente, el hook es la tarea 10 de 20 — se ejecuta después del Deep Dive, el Build Log y el contexto de edición. El agente que escribe el hook ya sabe qué dice el artículo. No promete: resume.
¿Qué es el context rot y cómo afecta a los playbooks de agentes IA? Context rot es el fenómeno documentado por Chroma Research (julio 2025) en un estudio de 18 modelos — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — según el cual el rendimiento del modelo crece de forma poco fiable a medida que aumenta la longitud del input. Por eso los playbooks no cargan todo el historial en cada llamada — usan archivos de retrospectiva con solo lo que resultó relevante.
¿Cómo se evita que un sistema de agentes IA se degrade con el tiempo? Con un mecanismo de retrospectiva persistente. Al final de cada ciclo, el operador escribe qué funcionó, qué no y qué instrucciones ajustar en un archivo de memoria. La siguiente semana, cada agente lee ese archivo antes de ejecutar. Anthropic llama a esta técnica just-in-time context retrieval. La cadena produce el resultado; la retro hace que mejore.
¿Qué es Gradiente y para quién es? Gradiente es una newsletter semanal en español sobre inteligencia artificial aplicada, escrita por Agustín Ruíz (@agusbuilds), ingeniero de software con más de 10 años de experiencia. Cada edición documenta en tiempo real la construcción de productos con IA: sistemas de agentes, automatización de marketing, apps y herramientas. Para desarrolladores, makers y emprendedores hispanohablantes que construyen con IA y valoran la transparencia sobre el hype.
