LLMs: separa plan y ejecutor en cron

En muchos flujos con LLMs, el fallo no aparece cuando el modelo redacta un buen plan. Aparece despues, justo en el handoff hacia un script que publica, mueve archivos o espera una condicion externa. Cuando ese limite esta mal definido, el cron termina haciendo cosas medio correctas y medio opacas. Y eso, sinceramente, es peor que un error duro.

Hace tiempo empece a tratar al agente como planificador y al script como ejecutor estricto. No como una preferencia filosofica, sino como una decision de arquitectura. El agente decide el que y el por que. El script ejecuta el como, sin improvisar. Ese corte parece obvio, pero cambia bastante la confiabilidad del sistema.

El error empieza cuando el plan vive solo en la cabeza del agente

Piensa en este diagrama en palabras:

1. El cron despierta.
2. El agente revisa contexto y arma una intencion.
3. Un script publica o transforma artefactos.
4. Horas despues alguien necesita entender por que salio eso.

Si el paso 2 no deja un contrato legible, el paso 3 ejecuta a ciegas. Y cuando algo sale raro, toca reconstruir la historia desde logs, nombres de archivos y suposiciones. No es una tragedia tecnica, pero si una fuga de tiempo bastante cara.

Por eso me gusta escribir un plan.json antes de cualquier articulo, deploy o tarea con salida publica. El archivo hace tres trabajos a la vez:

1. congela la decision del agente;
2. le da entradas estables al script;
3. deja evidencia para auditar el run despues.

La idea se parece a probar correos de aprobacion sin tocar bandejas reales: separas la intencion de la infraestructura real para poder validar cada borde sin mezclar responsabilidades.

Un contrato chico entre LLM y script

No hace falta un contrato enorme. De hecho, cuando lo haces demasiado grande, el ejecutor termina acoplado al estilo del modelo y no a la tarea. Mi version minima suele incluir:

1. cuenta o destino seleccionado;
2. titulo o accion final;
3. tags y palabras clave permitidas;
4. outline u orden de secciones;
5. restricciones exactas, como cantidad de enlaces o idioma.

Ejemplo corto:

{
  "username": "lucasg88",
  "language": "es",
  "title": "LLMs: separa plan y ejecutor en cron",
  "tags": ["ai", "llm", "automation", "devtools"],
  "outline": [
    "## El error empieza cuando el plan vive solo en la cabeza del agente",
    "## Un contrato chico entre LLM y script"
  ]
}

Lo importante no es el formato exacto. Lo importante es que el script pueda responder dos preguntas sin consultar al agente otra ves: "que voy a ejecutar" y "que no estoy autorizado a cambiar". Cuando ese limite no existe, el ejecutor se vuelve un segundo autor escondido. Y ahi empiezan los bugs bien raros.

Que datos deben pasar del plan al ejecutor

Yo separo el handoff en cuatro capas:

1. decision: que eligio el agente.
2. constraints: que no se puede violar.
3. artifacts: que archivos se esperan.
4. result: que salida debe devolverse al final.

Esta estructura reduce ambiguedad y tambien simplifica las reanudaciones. Si un cron falla en publicacion, no necesito regenerar el articulo. Solo necesito saber si el artefacto ya estaba aprobado y si el ejecutor cumplio el contrato. Parece un detalle, pero es el tipo de detalle que te evita duplicados o publicaciones inconsistentes.

Tambien ayuda a mantener algo que muchos equipos subestiman: limites de responsabilidad. El agente puede tener ideas buenas, pero el script no deberia reinterpretarlas sobre la marcha. Igual que en frontend buscas mantener estable una interfaz cuando cambia el estado, en automatizacion quieres que el cambio de estado no cambie el significado del run.

Una buena regla practica:

• si el dato afecta la decision editorial, debe quedar en el plan;
• si el dato afecta la ejecucion tecnica, debe quedar como parametro valido;
• si el dato solo sirve para diagnostico, debe vivir en el resultado.

No todo necesita pasar a todos lados. Aveses el mejor contrato es el que deja afuera la mitad de las cosas.

Donde encajan las pruebas de email

En este tipo de pipeline, los correos de prueba suelen aparecer como validacion auxiliar: comprobar una aprobacion, revisar un resumen, confirmar que una notificacion salio con el formato correcto. En esos casos, un inbox temporal puede ser util para QA rapido. Si alguien busca un fake email generator o menciona cosas como tempail mail y temp org mail en notas de test, ya sabes el tipo de escenario: flujos efimeros, poco riesgo, evidencia corta.

Lo que no haria es mezclar ese canal con la autoridad del ejecutor. El script no deberia decidir solo porque encontro un email parecido. Mejor darle una regla concreta, por ejemplo: publicar solo si existe article.raw.md, plan.json y una respuesta valida del publicador. Si ademas necesitas pruebas de email, que sirvan como verificacion lateral, no como cerebro sustituto del flujo.

Segun el informe anual de confiabilidad de Google SRE, los sistemas operables reducen tiempo de mitigacion cuando tienen interfaces claras entre componentes y evidencia accionable en cada borde (Google SRE Workbook). No es una receta literal para cron con agentes, pero el principio encaja muy bien.

Checklist para un cron menos fragil

Si tuviera que endurecer este patron en una tarde, haria esto:

1. escribir plan.json antes del artefacto final;
2. validar que el articulo siga el plan, no al reves;
3. hacer que el script publique solo desde una carpeta de run cerrada;
4. guardar un publish-result.json con URL, estado y error si aplica;
5. evitar que el ejecutor regenere contenido por su cuenta;
6. devolver una salida final corta y deterministicamente parseable.

No es glamoroso, pero funciona. Tambien hace mas facil delegar: otra persona puede revisar el plan, otro proceso puede ejecutar, y ambos entienden el contrato sin leer toda la conversacion previa. Ese desacople vale mucho cuando el sistema crece y ya no eres tu quien mira cada run.

Preguntas frecuentes

El agente no deberia poder corregir al script?

Solo en un nuevo run o en una fase explicita de reparacion. Si lo dejas corregir en caliente, mezclas autoria con ejecucion y pierdes trazabilidad.

Esto aplica solo a publishing?

No. Sirve para deploys, ETL, aprobaciones, resumenes programados y casi cualquier tarea donde un modelo decide pero otro componente actua.

Vale la pena aunque el sistema sea pequeño?

Si el cron tiene efecto externo, yo diria que si. En sistemas chicos el costo es bajisimo, y el dia que algo falle agradeceras tener un borde claro y no un monton de intuiciones mezcladas.

Mi regla final es simple: deja que el agente piense, pero obliga al ejecutor a obedecer un contrato corto. Cuando esa frontera queda limpia, el cron se siente menos teatral y bastante mas confiable.