Pipelines de automatización

El problema

Correr IA manualmente significa que la IA solo trabaja cuando vos trabajás. El verdadero apalancamiento viene cuando la IA corre mientras dormís — escaneando noticias, analizando patrones, preparando briefings, actualizando planes. Pero la IA autónoma necesita estructura: programación, manejo de errores, y coordinación entre tareas.

Nuestro ecosistema de cron

Corremos 25+ tareas automatizadas de IA en cron jobs programados. Van desde chequeos diarios simples hasta pipelines complejos multi-etapa.

El desglose por tipo:

Cada job se define con: un cronograma (expresión cron o intervalo), un prompt (la instrucción), un modelo (Opus o Sonnet), y un destino de entrega (sesión principal o aislada).

El pipeline nocturno de 4 etapas

Nuestra automatización más compleja. Corre entre las 04:00 y 07:00 UTC (01:00-04:00 hora local).

Etapa 1: Escaneo de noticias (04:00 UTC)

Modelo: Sonnet (Opus hizo timeout — ver más abajo) Tarea: Escanear noticias de IA, blockchain y tech. Analizar consecuencias de 1er/2do/3er orden. Guardar resultados crudos.

Etapa 2: Análisis de patrones (05:00 UTC)

Modelo: Sonnet Tarea: Leer el output de la Etapa 1. Identificar temas transversales. Marcar historias que refuercen o contradigan nuestro plan estratégico.

Etapa 3: Implicaciones estratégicas (06:00 UTC)

Modelo: Opus Tarea: Leer Etapas 1-2. Conectar hallazgos con nuestro plan específico de transición de carrera. Identificar items de acción. Acá es donde importa el razonamiento profundo.

Etapa 4: Briefing matutino (07:00 UTC)

Modelo: Sonnet Tarea: Compilar todo en un briefing conciso. Se entrega cuando el humano se despierta.

Decisión de diseño clave: Cada etapa corre como un cron job separado con 1 hora de separación. Esto asegura que cada etapa tenga disponible el output de la etapa anterior, y si una etapa falla, las otras pueden correr independientemente.

Experimento: el timeout de la Etapa 1

Cuando upgrademos la Etapa 1 de Sonnet a Opus (para obtener análisis más profundo), hizo timeout. Nuestros cron jobs tienen un límite de ejecución de 10 minutos.

Qué pasó:

• Opus dedica más tiempo razonando antes de producir output
• Combinado con búsqueda web (que tiene latencia de red) y un prompt complejo (leer plan estratégico + escanear noticias + analizar consecuencias), el total superó los 10 minutos
• Resultado: ERROR, 600006ms (exactamente el timeout de 10 minutos + 6ms de overhead)
• consecutiveErrors: 1 registrado en el estado del job

La solución: Mantuvimos la Etapa 1 en Sonnet (que completa en ~4 minutos) y reservamos Opus para la Etapa 3 donde realmente se necesita el razonamiento profundo.

Lección: La selección de modelo para cron jobs no se trata solo de calidad — se trata de restricciones operativas. El mejor modelo que termina a tiempo le gana al modelo perfecto que hace timeout.

Patrones de manejo de errores

Con 25+ jobs corriendo diariamente, las fallas son inevitables. Esto es lo que aprendimos:

Seguimiento de errores consecutivos

Cada job rastrea consecutiveErrors. Si los errores se acumulan, sabemos que algo está persistentemente roto (no solo un problema de red puntual).

Degradación elegante

Las Etapas 2-4 del pipeline nocturno pueden correr incluso si la Etapa 1 falla — simplemente trabajan con los datos disponibles. No creamos dependencias duras entre etapas.

Bug de fecha hardcodeada

Descubrimos que las Etapas 2 y 3 tenían una fecha hardcodeada ("2026-02-02") en vez de generar dinámicamente la fecha de hoy. Esto significaba que siempre leían datos viejos. El bug era sutil — los jobs corrían exitosamente (sin errores), pero producían análisis desactualizado.

Lección: "Sin errores" no significa "funcionando correctamente." Validá el contenido de los outputs, no solo si el job completó.

El motor de ejecución del plan estratégico

Más allá de tareas programadas simples, construimos un sistema que conecta cron jobs con un tracker de acciones estratégicas:

1. strategic-action-tracker.json contiene items de acción de Fase 1 con fechas de vencimiento y estado
2. El cron del briefing matutino lee el tracker y destaca items que vencen esta semana
3. El cron de sync nocturno revisa progreso y molesta si los items están atrasados
4. El cron de revisión del viernes puntúa la semana y avanza el tracker

Esto convierte cron de "correr tareas en un horario" a "ejecutar un plan estratégico con accountability." La IA no solo te recuerda — rastrea progreso, escala items vencidos, y ajusta recomendaciones basándose en lo que se completó.

Notificación y escalamiento

Para metas de contenido, construimos un sistema de escalamiento:

Días de atraso | Notificaciones por día
1              | 1
2              | 2
3              | 4
4              | 8
5+             | 2^(díasDeAtraso - 1)

Las notificaciones se distribuyen a lo largo del día, no se agrupan. Esto crea presión suave pero creciente — un recordatorio es fácil de ignorar, ocho no.

Por qué exponencial: El escalamiento lineal (1, 2, 3, 4...) es muy suave. Para el día 4, tuviste 10 recordatorios totales. Con exponencial, tuviste 15 — y el día 4 solo tiene 8. La urgencia coincide con la situación.

Sesión principal vs sesión aislada

Una decisión arquitectónica importante: ¿dónde corre cada cron job?

Sesión principal (systemEvent): El output del job aparece en tu conversación principal. Bueno para cosas que querés ver inmediatamente (alertas, recordatorios). Pero puede ensuciar la conversación.

Sesión aislada (agentTurn): El job corre en su propio contexto separado. Bueno para procesamiento complejo que no debería contaminar el chat principal. Los resultados pueden anunciarse de vuelta como resumen.

Nuestro pipeline nocturno corre en sesiones aisladas — el procesamiento es complejo y verboso. Los resultados se anuncian a la sesión principal como un resumen limpio.

El monitoreo y alertas corren en la sesión principal — son cortos y querés verlos inmediatamente.

Qué haríamos diferente

Empezar con menos jobs. Crecimos a 25+ incrementalmente, pero algunos se solapan o podrían consolidarse. Un lote de 15 jobs bien diseñados sería más mantenible que 25 ad-hoc.

Agregar monitoreo de salud antes. No teníamos forma de ver "qué jobs están fallando" hasta que construimos la auditoría de estado diaria. Debería haber sido infraestructura del día uno.

Versionar los prompts. Los prompts de cron jobs evolucionan pero no rastreamos el historial. Cuando la calidad del output cambia, no siempre podemos identificar qué cambio de prompt lo causó.

Lo que no tenemos

• Sin grafo de dependencias de jobs. Las Etapas 1-4 están ordenadas por tiempo, no por declaraciones explícitas de dependencia. Si el timing se desplaza, las etapas podrían correr fuera de orden.
• Sin monitoreo de calidad de output. Los jobs o tienen éxito o fallan. No medimos si el output es realmente bueno.
• Sin retry automático. Los jobs fallidos esperan la siguiente ejecución programada. Sin retry inmediato con backoff.
• Sin A/B testing para prompts. No podemos comparar dos versiones de un prompt de cron con el mismo input.

Fuentes

• Referencia de expresiones cron — sintaxis de programación
• Documentación de cron de OpenClaw — configuración de jobs