LLMs: checkpoints de tool-use que si reanudan

Cuando un agente con LLMs toca herramientas externas, el punto debil casi nunca es el prompt bonito del demo. Lo fragil suele aparecer despues: una API lenta, un correo de aprobacion poco claro, un worker que despierta horas mas tarde y ya no sabe que evidencia era valida. En varios flujos internos note lo mismo una y otra vez: el modelo podia razonar bien, pero la reanudacion del run seguia siendo medio borrosa.

Mi solucion favorita no es hacer al agente mas listo. Es hacerlo mas facil de pausar y retomar. Para eso uso checkpoints cortos, con evidencia minima pero suficiente, antes de cualquier paso que dependa de otra herramienta, de una persona o de una espera larga. Suena chico, pero cambia bastante el tono operativo.

El fallo no suele estar en el modelo

Piensalo como un diagrama en palabras:

1. El agente decide una accion.
2. Llama a una tool externa.
3. Algo tarda, falla o necesita aprobacion.
4. Otro proceso debe reanudar despues.

El problema vive entre el paso 2 y el 4. Si solo guardas el prompt y la respuesta final, el sistema queda con huecos. Luego ves un run fallido y nadie sabe si se rompio por contexto viejo, por tool-use duplicado o porque una validacion humana llego tarde. Sincerarmente, ese tipo de fallo desgasta mas que un error obvio.

Por eso me gusta pensar el checkpoint como una frontera de contrato. Antes de cruzarla, congelas intencion, entradas y criterio de salida. Despues, cualquier worker puede retomar sin ponerse creativo. Esa misma idea de reutilizar estado ya funciona muy bien cuando necesitas reusar estado cuando una accion se repite: menos duplicados, menos adivinanzas, menos ruido raro.

Como disenar un checkpoint pequeno

Un checkpoint util no necesita guardar todo. Necesita guardar lo que evita reinterpretaciones. Mi version minima casi siempre trae estas piezas:

1. run_id y step_id
2. objetivo de una frase
3. entradas normalizadas del paso
4. condicion exacta para continuar
5. ubicacion de la evidencia producida

Un ejemplo corto:

{
  "run_id": "20260818T112222Z-lucasg88",
  "step_id": "approve_publish_copy",
  "goal": "confirmar el borrador final antes de publicar",
  "inputs_hash": "f0c82b1d",
  "resume_when": "approval_received",
  "evidence_ref": "runs/20260818T112222Z-lucasg88/approval.json"
}

Fijate en lo que no meti: no hay una novela del contexto, ni capturas eternas, ni una segunda copia del articulo entero. El tradeoff es deliberado. Un checkpoint largo parece seguro, pero despues cuesta leerlo, mantenerlo y compararlo. Uno demasiado corto, en cambio, deja grietas. El punto medio bueno es el que permite reconstruir la accion sin volver a negociar su significado.

Que guardar para reanudar sin inventar contexto

Cuando una tool externa se pone fragil, suelo separar tres capas:

1. intent: que queria hacer el agente
2. evidence: que devolvio el mundo externo
3. resume_rule: que debe cumplirse para seguir

Ese corte evita que la tool mande sobre toda la historia del run. Tambien hace que los errores sean mas locales. Si una respuesta externa cambia formato, arreglas el parser del paso; no reescribes toda la memoria operativa del agente. Es menos elegante en papel, pero bastante mas mantenible.

En sistemas con aprobaciones humanas, la capa resume_rule merece cariño extra. Si el aprobador responde por email, quiero una prueba corta y verificable, no una conversacion abierta donde el worker tenga que interpretar tono, contexto o ironia. Por eso me gusta enlazar el paso a artefactos congelados y usar aprobaciones por email con menos ruido como modelo mental: mensaje breve para humanos, contrato concreto para maquinas.

Un pseudocodigo simple podria verse asi:

async function resumeStep(checkpoint, evidence) {
  if (evidence.kind !== checkpoint.resume_when) return "wait";

  const inputs = await loadInputs(checkpoint.inputs_hash);
  const verified = await verifyEvidence(evidence, checkpoint.step_id);
  if (!verified) return "reject";

  return continueRun(inputs);
}

No hay magia aca. Solo hay fronteras mas claras. Y eso importa mucho cuando el equipo mira un fallo dos dias despues, con cansancio y poco tiempo.

Donde usar inboxes temporales y donde no

Las inboxes temporales siguen siendo utiles, pero en un lugar especifico del mapa. Yo las uso para comprobar entrega, formato y latencia en entornos de QA. Si necesito un correo temporal gratis para validar una rama o revisar un reply parser, me sirve bastante. Incluso he visto notas improvisadas con textos como tamp mail com o tem email en tickets de prueba; no es lindo, pero pasa.

Ahora bien, no las trataria como fuente canonica de aprobacion para un flujo sensible. Para eso prefiero una cuenta controlada o un storage de recibos. Si el sistema necesita validar una direccion de correo falsa de laboratorio, algo como tempmailso puede encajar bien en smoke tests y escenarios efimeros. El punto es no mezclar esa comodidad con la evidencia final de negocio. Aveces esa mezcla parece inocente y luego te rompe auditoria, soporte o los dos.

Checklist de implementacion

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

1. Congelar inputs antes de cada paso externo o humano.
2. Escribir un checkpoint por paso, no uno gigante por run.
3. Guardar hashes cortos de entradas y salidas importantes.
4. Validar evidencia con una regla binaria: sigue o espera.
5. Expirar checkpoints viejos para que no revivan por error.
6. Loggear el motivo de rechazo en una linea entendible.

Es una lista sencilla, pero baja muchisimo el drama en operaciones. Tambien ayuda a explicar decisiones a producto, QA y seguridad sin tener que recorrer todo el pipeline otra ves.

Preguntas frecuentes

Debo guardar todo el contexto del agente?

Yo no lo haria. Guarda lo necesario para retomar el paso y verificar la evidencia. Si copias todo, el checkpoint deja de ser checkpoint y se vuelve otro sistema de memoria, lo cual casi siempre sale peor.

Esto sirve solo para email?

No. Sirve para cualquier paso con latencia, aprobacion o dependencia externa: pagos, despliegues, scrapers, APIs lentas, lo que sea. Email solo hace el problema mas visible.

Cuantos checkpoints son demasiados?

Si el run no puede explicarse en una pantalla, probablemente tienes demasiada granularidad. Si no puedes saber donde continuar sin abrir cinco logs, tienes muy pocos. El buen numero suele aparecer cuando cada checkpoint coincide con una decision real, no con cada funcion del codigo.

Mi regla final es bastante simple: el modelo razona, pero el checkpoint gobierna la reanudacion. Cuando esa frontera queda clara, el flujo se vuelve menos teatral y bastante mas confiable.