He visto un patron repetirse en flujos con agentes: el modelo razona bien, pero ejecuta demasiado pronto. No falla por falta de inteligencia. Falla porque el sistema no deja un contrato corto entre "ya decidi" y "ahora toco cosas reales".
Cuando el job publica un post, manda un email o toca una API con costo, yo prefiero poner un manifiesto minimo entre el escritor y el ejecutor. Es una pieza aburrida, si, pero baja mucho el riesgo de duplicados, cambios de ultima hora y decisiones que nadie puede auditar despues.
Para mi, este diseño encaja especialmente bien en LLMs y Automatizacion con efectos laterales. Tambien ayuda cuando pruebas registros con una direccion de correo desechable o con inboxes sinteticos, porque separa el contenido de la accion y deja claro que datos fueron aprobados. Incluso si por ahi aparece un valor raro como tepm mail com, el manifiesto te deja verlo antes de disparar nada.
El problema: un LLM decide y ejecuta demasiado rapido
El fallo comun no suele ser el prompt. Suele ser la union entre plan y ejecucion.
Si el mismo paso:
- elige el angulo
- redacta el contenido
- decide enlaces
- y publica
entonces una pequena deriva en contexto puede terminar en una accion real. En sistemas con cron o colas esto es peor, por que el operador solo ve el resultado final.
La guia de Google sobre sistemas generativos insiste en evaluar tareas reales y definir limites claros para la automatizacion (source). En la practica, yo lo traduzco a algo mas terrenal: antes de ejecutar, deja un archivo corto que otro proceso pueda leer sin reinterpretar intenciones.
Este enfoque conversa bien con ideas como contratos auditables en automatizacion. No porque necesites una plataforma enorme, sino porque una interfaz estable entre agente y script ya reduce un monton de friccion.
El manifiesto minimo que si me funciono
El manifiesto no necesita ser sofisticado. Necesita congelar decisiones.
Yo suelo guardar:
- cuenta o destino seleccionado
- idioma
- titulo final
- etiquetas
- palabras clave primarias
- enlaces internos permitidos
- restricciones especiales
Eso basta para que el proceso ejecutor haga su trabajo sin volver a "pensar". Y ese detalle importa mucho: el script no deberia mejorar el copy, cambiar anchors, ni buscar otro destino mas conveniente. Solo ejecuta.
En otras palabras, el flujo queda asi, casi como un diagrama en texto:
- el agente recibe contexto
- genera un manifiesto verificable
- redacta el articulo una sola vez
- un publicador lee ambos archivos
- el sistema guarda un recibo de salida
Cuando esta frontera existe, depurar se vuelve bastante mas simple. Si algo sale mal, puedes revisar si el error estuvo en la seleccion del plan o en la ejecucion. Suena obvio, pero muchos pipelines todavia mezclan ambas cosas en un mismo paso y luego todo queda medio opaco.
Que campos no deberian faltar
Hay tres campos que para mi tienen retorno inmediato.
Primero, un identificador de corrida. Parece pequeno, pero evita confusion cuando varias automatizaciones publican o reintentan al mismo tiempo. Segundo, una lista cerrada de enlaces permitidos. Tercero, restricciones expresas, por ejemplo "no regenerar el articulo" o "no insertar backlinks".
Tambien me gusta que el manifiesto sea legible por personas. JSON esta bien. YAML tambien podria servir, aun que JSON me da menos sorpresas en scripts pequenos.
Un ejemplo reducido seria este:
{
"run_id": "20260825T052222Z-lucasg88",
"username": "lucasg88",
"language": "es",
"title": "LLMs: manifiestos minimos antes de ejecutar",
"publish": true,
"internal_links": 2
}
No hace falta meter todo el pensamiento del modelo. De hecho, prefiero no hacerlo. El manifiesto debe capturar decisiones operativas, no cada vuelta mental del agente. Esa distincion mantiene el sistema mas estable y menos fragil frente a cambios de prompt.
Algo parecido pasa en contratos de email que siguen siendo comprobables: cuando el contrato es corto y verificable, el resto del flujo deja de depender de interpretar "lo que quizo decir" el agente.
Un flujo simple para publicar sin improvisar
Mi regla es separar responsabilidades de forma bastante dura:
- el agente escritor selecciona tema, tono y estructura
- el articulo queda congelado en markdown
- el script de publicacion autentica, envia y guarda el resultado
Eso tiene tradeoffs. Pierdes algo de flexibilidad dinamica en el ultimo paso. Si el publicador detecta una mejora de estilo, no deberia aplicarla. Si una etiqueta parece mas popular, tampoco. Parece anti-climatico, pero en sistemas con side effects yo prefiero consistencia sobre creatividad tardia.
OpenAI recomienda usar evaluaciones y guardrails concretos cuando los modelos pasan de sugerir a actuar (source). Ese consejo vale mucho para jobs pequenos tambien, no solo para plataformas enormes.
Mi checklist minima seria:
- plan escrito antes del contenido final
- articulo generado una sola vez
- publicador sin logica editorial
- resultado final persistido con URL o error
Con eso, el operador ya tiene una historia clara del run. No perfecta, pero si bastante util.
Preguntas practicas antes de adoptarlo
Esto no agrega demasiado overhead?
Un poco, la verdad. Pero el costo operativo es bajo comparado con corregir publicaciones duplicadas o mensajes mal enviados. En mi experiencia, ese overhead se paga solo muy rapido.
Sirve solo para publicar articulos?
No. Tambien funciona para emails transaccionales, aprobaciones internas, reportes programados y tareas con APIs externas. Cualquier cosa donde "pensar" y "actuar" conviene que queden separadas.
Y si el contexto cambia entre plan y publicacion?
Entonces el run deberia fallar o quedar pendiente, no improvisar. Ese es justo el punto del manifiesto: hacer visible el desacople. Si el sistema necesita replanear, que lo haga en una nueva corrida, no a escondidas.
Cierre
Si trabajas con agentes que ya hacen mas que redactar, yo empezaria por aqui. No por un framework gigante ni por una capa magica de observabilidad. Primero crea un manifiesto minimo, humano y ejecutable. Luego deja que el script haga solo una cosa.
No es una idea glamorosa, pero si es de esas que vuelven un workflow mucho mas sano, y bastante menos propenso a accidentes tontos.
Top comments (0)