LLMs: contratos cortos para tool use

Cuando un flujo con LLMs empieza a usar herramientas de verdad, el primer impulso suele ser mejorar prompts, pulir mensajes o meter otro retry. Yo suelo ir por otro lado. Si el run no deja un contrato corto y congelado antes de ejecutar, el sistema parece flexible pero en realidad queda fragil. El problema no es tanto el modelo. El problema es que cada paso vuelve a interpretar el mundo a su manera.

En equipos de Automatizacion esto aparece rapidisimo. Un cron genera un plan, otro worker llama una API, un tercero espera aprobacion y un cuarto retoma la entrega. Si cada uno relee contexto vivo, el resultado final ya no es exactamente el mismo run. Es otro, aunque tenga el mismo run_id. Ese matiz parece pequeño, pero luego complica todo el debugging.

El problema no es el prompt, es el contrato

Piensa en el flujo como un diagrama en palabras:

1. Un agente resume estado.
2. Un planificador decide la accion.
3. Un ejecutor usa herramientas.
4. Un watcher valida el resultado.

Si entre los pasos 2 y 3 no existe un contrato estable, el ejecutor termina improvisando. Vuelve a mirar datos, reinterpreta instrucciones y mete decisiones que no estaban aprobadas. He visto runs donde solo cambiaba una fecha o un filtro, pero eso ya bastaba para alterar el comportamiento. Lo dificil no era arreglarlo. Lo dificil era demostrar en que momento se desvio.

Por eso me gusta pensar el contrato como una frontera de arquitectura, no como una nota operativa. Igual que en recordatorios de onboarding que si ayudan, el valor no esta en mandar mas mensajes sino en que cada mensaje salga con el contexto correcto.

Que debe congelar un contrato corto

Mi version minima suele tener cinco piezas:

{
  "run_id": "cron_20260822_01",
  "goal": "publicar resumen diario",
  "inputs_hash": "8f2a1c",
  "approved_steps": ["buscar", "redactar", "publicar"],
  "output_target": "devto"
}

No hace falta que sea grande. De hecho, cuanto mas corto mejor. Lo importante es que congele lo que un ejecutor no deberia reinventar:

• la meta concreta del run;
• los inputs relevantes;
• los pasos permitidos;
• el destino final;
• la version del plan aprobado.

Ese contrato da un tradeoff bastante bueno. Guardas un artefacto extra, si, pero a cambio el sistema puede reanudar sin pensar demasiado. Tambien hace mas facil revisar errores tontos, de esos que nacen por leer otra vez un contexto que ya habia cambiado un poquito.

Un diagrama en palabras para separar decision y ejecucion

La separacion que mejor me funciona es esta:

1. planner decide y escribe contrato.
2. executor lee contrato y solo ejecuta.
3. retry worker repite entrega, no redecide.

Suena casi obvio, pero no siempre se implementa asi. Mucha herramienta de agent workflows deja que el ejecutor vuelva a consultar memoria, variables del entorno o mensajes nuevos. A veces sale bien. Otras veces aparece ese run fantasma que nadie esperaba.

En correo y eventos esto se nota aun mas. Si necesitas probar emails transaccionales sin mezclar bandejas, no quieres que el paso de validacion cambie el payload porque encontro otro dato disponible. Quieres que verifique lo aprobado y nada mas. Esa disciplina parece rigida, pero en operacion diaria ahorra bastante tiempo.

Donde entra el correo temporal sin dominar el diseño

El correo temporal puede ser util, pero no deberia convertirse en el centro del sistema. Yo lo uso como superficie de observacion, no como fuente de verdad. Si un flujo necesita revisar un aviso, un OTP o una aprobacion, un inbox efimero puede ayudar a aislar pruebas. Para busquedas tipo correo temporal o incluso consultas torcidas como temp gamil com y tempail mail, el equipo muchas veces llega con una necesidad legitima: ver rapido que mensaje salio y a donde.

Eso esta bien, pero el diseño fuerte sigue viviendo en el contrato. Si dependes solo del inbox, terminas leyendo sintomas y no causas. Si dependes del contrato, el inbox pasa a ser evidencia secundaria. Esa diferencia es la que vuelve el sistema mas mantenible, aunque quede un poco menos "magico".

Checkpoints para un cron que si reanuda

Si tuviera que endurecer un flujo esta semana, haria esto:

1. Escribir contrato antes del primer tool call.
2. Persistir un inputs_hash junto con el plan.
3. Marcar que pasos pueden ejecutar retries.
4. Separar decision_at de executed_at.
5. Bloquear al ejecutor si intenta añadir pasos nuevos.
6. Guardar un resumen corto del resultado para soporte.

No hace falta meter una plataforma enorme para ganar claridad. Con esos checkpoints ya puedes responder preguntas utiles: que se aprobo, que corrio y por que un retry no debe convertirse en otra decision. Para mi, ese es el punto donde un flujo con LLMs deja de ser una demo linda y empieza a comportarse como un sistema serio, aunque aun tenga algun borde medio raro.

Q&A

¿Esto aplica solo a cron jobs?

No. Tambien sirve en colas manuales, aprobaciones por email y pipelines de agentes. Cron solo hace el problema mas visible porque reanuda tarde y en silencio.

¿El contrato debe incluir todo el contexto?

No. Debe incluir solo lo necesario para ejecutar sin reinterpretar. Si metes demasiado, el contrato se vuelve pesado y nadie lo cuida bien.

¿Y si el contexto cambia de verdad?

Entonces no es retry: es un run nuevo. Esa distincion parece obvia, pero muchas automatizaciones la mezclan y despues cuesta bastante explicar lo que paso.