Un bucle libre empieza siendo sencillo: envías la solicitud al modelo, ejecutas la herramienta que elige y devuelves el resultado para la siguiente ronda. El problema aparece cuando el agente debe esperar una aprobación, repetir solo una etapa, bloquear una escritura o explicar por qué llegó a un estado terminal.

Una máquina de estados ayuda cuando el flujo tiene fases que deben ser visibles y transiciones que se pueden rechazar. No hace determinista al modelo. Coloca el modelo en lugares concretos y deja que el runtime controle qué puede ocurrir antes y después de cada llamada.

Si tu primera duda es dónde guardar checkpoints y reanudar una ejecución, empieza por la comparación entre colas y workflows para agentes de IA. Este artículo cubre otra capa: cómo representar el flujo que debe guardar el checkpoint.

Diagrama que compara un bucle libre de agente con una máquina de estados que pasa por planificar, herramienta, revisión y finalización.

Respuesta corta

  • Mantén el bucle libre cuando el camino sea exploratorio y los efectos externos sean pequeños.
  • Modela estados cuando existan fases, pausas, permisos o transiciones inválidas.
  • Deja que el modelo decida donde hay incertidumbre. Deja que el código decida lo que ya tiene contrato.
  • Persiste el estado y prueba las transiciones. Un diagrama por sí solo no protege la ejecución.

¿Qué añade una máquina de estados a un agente?

Una máquina de estados describe un conjunto finito de estados y las transiciones permitidas entre ellos. En AWS Step Functions, "Learn about state machines in Step Functions", los estados pueden ejecutar tareas, tomar decisiones, esperar, crear ramas o terminar una ejecución. El siguiente paso no es una sugerencia escondida en un prompt. Forma parte del contrato del workflow.

Para un agente, piensa en cinco piezas:

  • Estado: lo que el runtime sabe sobre la ejecución ahora.
  • Transición: el evento que puede mover la ejecución a otro estado.
  • Guardia: la condición que autoriza o rechaza la transición.
  • Efecto: una llamada a una herramienta, una escritura o una solicitud de aprobación.
  • Terminal: el estado de éxito, fallo o bloqueo que termina el flujo.

La ganancia arquitectónica está en esa frontera. El modelo puede clasificar una intención, proponer parámetros o resumir el resultado de una herramienta. El runtime todavía debe decidir si ese resultado autoriza un cambio de estado y si la herramienta correspondiente está disponible en esa fase.

¿Qué señales muestran que un bucle libre se volvió frágil?

Pasa a estados explícitos cuando el mismo tipo de error deba evitarse de forma mecánica, en lugar de quedar descrito solo en el system prompt. Cuatro señales aparecen con frecuencia: el bucle repite una etapa sin un límite claro, una tool call tiene un efecto externo, una persona debe aprobar el siguiente paso o soporte necesita reconstruir el recorrido después de un fallo.

La guía de LangGraph sobre workflows y agentes separa los workflows, con caminos predeterminados, de los agentes, que definen dinámicamente su proceso y el uso de herramientas. La elección no es moral ni binaria. Un mismo sistema puede usar un agente para interpretar una entrada y un workflow explícito para aplicar el resultado.

Usa esta prueba práctica:

Pregunta Si la respuesta es sí
¿Una etapa puede cobrar, borrar, publicar o cambiar datos? Pon una guardia antes del efecto.
¿El flujo debe esperar a una persona o evento externo? Modela un estado de espera.
¿Un fallo debe reanudarse desde un punto conocido? Persiste estado y checkpoint.
¿Una regla conocida determina el camino válido? Haz la transición en código.
¿La tarea todavía explora un camino desconocido? Mantén una sección agentic, con un límite.

No conviertas cada conversación en un grafo. Un clasificador sencillo, una búsqueda y una respuesta final pueden ser más fáciles de operar como una función. Una máquina de estados compensa su coste cuando hace visible un riesgo o una obligación.

¿Cómo modelar estados y transiciones de un agente en TypeScript?

Usa un campo discriminante para que cada estado lleve solo los datos que tienen sentido en él. El Handbook de TypeScript, "Narrowing" explica que una unión discriminada se puede refinar mediante una propiedad literal. Esto no valida por sí solo el valor recibido del modelo, pero evita que el código trate un estado de revisión como si ya tuviera un resultado final.

El ejemplo siguiente es ilustrativo. No llama a un proveedor, no persiste datos y no reemplaza la validación de entrada. Su objetivo es hacer visibles las transiciones ilegales dentro de un while.

type AgentState =
  | { kind: "planning"; request: string }
  | { kind: "tool"; request: string; toolName: "lookup"; input: string }
  | { kind: "review"; request: string; result: string }
  | { kind: "done"; request: string; result: string }
  | { kind: "blocked"; request: string; reason: string };

type Event =
  | { kind: "plan-ready"; toolName: "lookup"; input: string }
  | { kind: "tool-finished"; result: string }
  | { kind: "approved" }
  | { kind: "rejected"; reason: string };

function transition(state: AgentState, event: Event): AgentState {
  switch (state.kind) {
    case "planning":
      if (event.kind !== "plan-ready") throw new Error("invalid transition");
      return { ...state, kind: "tool", toolName: event.toolName, input: event.input };

    case "tool":
      if (event.kind !== "tool-finished") throw new Error("invalid transition");
      return { kind: "review", request: state.request, result: event.result };

    case "review":
      if (event.kind === "approved") {
        return { kind: "done", request: state.request, result: state.result };
      }
      if (event.kind === "rejected") {
        return { kind: "blocked", request: state.request, reason: event.reason };
      }
      throw new Error("invalid transition");

    case "done":
    case "blocked":
      throw new Error("terminal state cannot advance");
  }
}

El código separa la respuesta del modelo de la transición. Una capa agentic puede producir plan-ready, pero el runtime debe validar el nombre y los argumentos de la herramienta antes de ejecutarla. La validación de tool calls en TypeScript es el siguiente nivel de esta frontera: el estado controla la secuencia y el contrato de la herramienta controla la forma de los datos.

¿Dónde encaja el modelo en una arquitectura híbrida?

El modelo debe entrar donde exista incertidumbre útil, no en cada cambio de estado. Puede extraer una intención, elegir entre caminos permitidos o interpretar el resultado de una herramienta. El código puede ejecutar una secuencia conocida, contar intentos, bloquear un efecto y dirigir una solicitud de aprobación.

La Graph API de LangGraph expresa esta separación con State, Nodes y Edges: los nodos reciben estado y producen actualizaciones, mientras que las aristas fijas o condicionales eligen el siguiente nodo. La idea no depende de esa biblioteca. Puedes implementarla con una función TypeScript, una cola, Step Functions o un runtime de agentes.

Un diseño habitual se ve así:

  1. Classify: el modelo convierte la solicitud en una intención estructurada.
  2. Plan: el runtime comprueba si esa intención tiene un camino soportado.
  3. Execute: código determinista llama a la herramienta permitida.
  4. Review: una regla o una persona aprueba el efecto.
  5. Finish: el sistema registra el resultado y termina.

Si la clasificación es inválida, no crees una transición aproximada. Envía el caso a blocked o pide una aclaración. Si falla la herramienta, registra el fallo en el estado y elige entre un retry limitado, una compensación o una revisión humana. El modelo no debería decidir por sí solo si una escritura externa ya ocurrió.

¿Cómo cambian el diseño la persistencia, los retries y las aprobaciones?

Los estados solo ayudan después de sobrevivir al proceso que los ejecuta. El overview de LangGraph presenta el runtime para workflows y agentes stateful de larga duración, con ejecución durable, human-in-the-loop y memoria. Esas capacidades no eliminan la necesidad de decidir qué entra en un checkpoint.

Persiste al menos el ID de ejecución, la versión del schema, el estado actual, el número de intentos, los eventos relevantes y las referencias a efectos externos. No guardes solo el último mensaje del modelo. Para reanudar una aprobación, el sistema debe saber qué efecto estaba esperando y qué evento cierra la espera.

El retry también forma parte del diseño de la transición. Una llamada idempotente se puede repetir de forma segura. Un cobro, una publicación o un mensaje necesita una clave de operación, una confirmación observable o un estado de compensación. El artículo sobre ejecución durable, colas y workflows profundiza en la infraestructura de recuperación. Aquí el punto es no esconder este contrato dentro de un bucle genérico.

¿Cómo verificar una máquina de estados de agente?

Prueba el grafo como código antes de probar la calidad de la respuesta del modelo. Una suite pequeña debe demostrar que cada transición acepta el evento correcto, rechaza eventos de una fase incorrecta y alcanza un estado terminal. Después prueba por separado el comportamiento de la herramienta y del modelo.

Incluye al menos estos casos:

  • planning acepta un plan válido y rechaza una aprobación.
  • tool rechaza otro plan antes de terminar la llamada.
  • review llega a done solo con una aprobación válida.
  • done y blocked no pueden avanzar.
  • Un retry no duplica el efecto externo.
  • Un checkpoint restaurado mantiene una versión compatible del schema.
  • Un camino de error produce un evento investigable.

Registra execution_id, estado anterior, evento, estado siguiente, herramienta, intento y motivo del rechazo. La observabilidad de agentes de código en CI muestra por qué los eventos estructurados hacen investigable un bucle. El mismo principio vale aquí: la narración del modelo no reemplaza el historial de transiciones.

¿Cuándo es una máquina de estados la elección equivocada?

No uses una máquina de estados para dar apariencia de control a un proceso que todavía no tiene una condición de parada. Si los estados cambian después de cada prompt, el grafo no gobierna al agente. Solo registra improvisaciones. Define primero el contrato del resultado, los efectos permitidos y la condición de éxito.

Un bucle libre puede ser correcto para explorar, hacer brainstorming, investigar de forma abierta o trabajar en tareas donde la siguiente herramienta depende de un descubrimiento que todavía no existe. Incluso entonces, impón un presupuesto de pasos, timeout, allowlist de herramientas y estado de fallo. Autónomo no significa ilimitado.

En sistemas grandes, un híbrido suele ser más legible: una máquina de estados en las fronteras importantes y un agente local dentro de una etapa exploratoria. La orquestación multiagente puede ser un estado o subworkflow, sin convertir cada mensaje entre agentes en una arquitectura nueva. Consulta la orquestación multiagente para coding agents con TypeScript cuando el problema sea coordinar agentes y no el ciclo de vida de un solo agente.

Preguntas frecuentes

¿Una máquina de estados vuelve determinista a un agente?

No. Hace explícitos los estados y las transiciones aceptadas. La salida del modelo sigue siendo variable, por lo que necesita schemas, validación y pruebas. El beneficio es impedir que una salida plausible salte una aprobación o llame a una herramienta fuera de su fase permitida.

¿Necesito usar LangGraph o Step Functions?

No. Las dos documentaciones describen arquitecturas que modelan estado, trabajo y transiciones. Puedes empezar con una unión discriminada y una función transition en TypeScript. Adopta un runtime cuando la persistencia, la reanudación, las colas, las esperas o la observabilidad dejen de ser una responsabilidad pequeña de tu servicio.

¿Una cola reemplaza una máquina de estados?

No. Una cola entrega trabajo y puede distribuir intentos. La máquina de estados define el estado de la ejecución, los eventos válidos y los efectos permitidos. Muchos sistemas usan ambas: la cola transporta el evento y el workflow valida la transición.

¿Cómo empiezo sin dibujar un grafo enorme?

Elige un flujo que ya tenga una pausa, un efecto externo o un fallo difícil de investigar. Modela cuatro estados, escribe las transiciones inválidas y añade una prueba por regla. Extrae estados compartidos después. Si el diagrama no cambia una decisión de ejecución, todavía es documentación, no control.

Conclusión

Una máquina de estados para un agente de IA compensa su coste cuando el sistema debe recordar dónde está, esperar algo, proteger un efecto o explicar por qué no avanzó. El modelo puede seguir haciendo el trabajo incierto. El runtime debe guardar el estado, validar eventos, limitar herramientas y terminar el flujo.

Empieza por el camino más pequeño que contenga un riesgo real. Modela el estado, haz que las transiciones ilegales se puedan probar y persiste el checkpoint antes de añadir más autonomía. En sesiones largas de Claude Code y Codex, uso RemoteCode como herramienta del autor para continuar flujos agentic. No reemplaza los contratos de estado, los límites de herramientas ni la revisión humana.

Fuentes consultadas