De Prompts Únicos a Flujos de Trabajo del Agente

Un prompt único pide al modelo una cosa y obtiene una respuesta. Un flujo de trabajo de agente divide un objetivo complejo en múltiples pasos: el agente planifica, llama a una herramienta, lee el resultado, decide qué hacer a continuación y repite el bucle hasta terminar el trabajo. En el desarrollo de aplicaciones web, esto significa que una funcionalidad de IA puede obtener datos, transformarlos, validarlos y responder al usuario — todo ello sin que un humano escriba cada paso a mano.

El cambio es de "preguntar y responder" a "decidir y actuar". En lugar de un prompt cuidadosamente elaborado, diseñas un bucle: pensar, actuar, observar, repetir.

Bloques Fundamentales de un Flujo de Trabajo del Agente

Todo flujo de trabajo de agente, sin importar su complejidad, se construye a partir de las mismas cuatro piezas.

Primero, un prompt de sistema que define el rol del agente, sus herramientas disponibles y las reglas para cuándo detenerse. Segundo, una lista de herramientas que el agente puede llamar — funciones como `fetch_user_data`, `send_email` o `query_database`. Tercero, un objeto de memoria o estado que transporta información entre pasos para que el agente no olvide lo que ya ha aprendido. Cuarto, un bucle de control que retroalimenta la salida del agente como entrada hasta que señala la finalización.

Aquí tienes un patrón mínimo en TypeScript que muestra el bucle:

async function runAgent(goal: string) {
  let state = { goal, steps: [], done: false };

  while (!state.done) {
    const decision = await llm.decide(state);
    if (decision.action === "finish") {
      state.done = true;
    } else {
      const result = await callTool(decision.action, decision.input);
      state.steps.push({ decision, result });
    }
  }

  return state.steps;
}

El agente ve `state`, decide qué hacer, el flujo de trabajo ejecuta la herramienta y el resultado vuelve a `state` para la siguiente ronda.

Gestión del Estado y Condiciones de Parada

El estado es lo que evita que el agente sea como un pez dorado. En cada turno el agente debería ver: el objetivo original, un historial de acciones pasadas y sus resultados, y cualquier restricción (como "no gastar más de 5 pasos" o "detenerse si la API devuelve un error").

Las condiciones de parada importan tanto como las condiciones de inicio. Sin ellas, un agente puede iterar eternamente o agotar tu presupuesto de API. Los patrones comunes incluyen: el agente emite una acción especial `finish`, se alcanza un límite de pasos, ocurre un error y el flujo de trabajo abandona, o una comprobación de validación confirma que se ha cumplido el objetivo. Elige al menos un límite duro (como el máximo de pasos) como red de seguridad, incluso si el agente tiene una señal de parada "natural".

Encadenamiento de Llamadas vs Llamadas en Paralelo

No todas las tareas multi-paso necesitan un bucle. A veces basta con encadenar: la salida de la llamada A se convierte en la entrada de la llamada B, sin toma de decisiones entre medias. Esto es más rápido, más barato y más predecible.

Usa un bucle solo cuando el siguiente paso dependa de lo que devolvió el paso anterior. Si estás resumiendo una reseña de usuario, luego traduciéndola y después enviándola por correo electrónico — eso es una cadena. Si estás consultando tres bases de datos y fusionando resultados — eso es en paralelo. Si estás consultando una base de datos, comprobando si el resultado está vacío y luego decidiendo si consultar otra fuente — eso es un bucle.

Ejemplo Práctico: Un Agente de Tickets de Soporte

Imagina un flujo de trabajo que gestiona tickets de soporte entrantes. El agente lee el ticket, lo clasifica, comprueba la cuenta del usuario, y o bien redacta una respuesta o lo escala a un humano.

async function handleTicket(ticketId: string) {
  const ticket = await fetchTicket(ticketId);
  const classification = await llm.classify(ticket.body);

  if (classification.category === "billing") {
    const account = await fetchAccount(ticket.userId);
    const draft = await llm.draftReply(ticket, account);
    await sendReply(ticket.userId, draft);
    return { status: "replied", draft };
  }

  await escalateToHuman(ticketId, classification);
  return { status: "escalated" };
}

Esto mezcla encadenamiento (clasificar y luego redactar) con una decisión de ramificación. El agente no está "pensando" libremente — está siguiendo un guion que utiliza el LLM en puntos de decisión específicos. Ese suele ser el equilibrio adecuado para producción: flujo determinista, llamadas smartes.

Errores Comunes y Cómo Evitarlos

Dar al agente demasiada libertad demasiado pronto. Comienza con un flujo fijo que llame al LLM en puntos de decisión conocidos. Solo añade un bucle de forma libre cuando realmente necesites comportamiento dinámico.

Olvidar registrar el estado. Cada paso, cada llamada a herramienta, cada resultado — regístralo. Cuando algo se rompe a las 2 de la madrugada, el registro es la única forma de ver qué estaba pensando el agente.

Sin lógica de reintento o respaldo. Las herramientas fallan. Las APIs agotan el tiempo de espera. Construye reintentos con backoff y ten siempre un camino alternativo — incluso si es solo "enviar el ticket a un humano".

Dejar que el estado crezca sin límite. En cada turno el agente ve el historial completo. Después de 20 pasos, ese historial es enorme y caro. Resume o recorta los pasos antiguos cuando la conversación se alargue.

Resumen

Un flujo de trabajo de agente es un bucle: el modelo decide, una herramienta se ejecuta, el resultado actualiza el estado y el ciclo se repite hasta que se dispara una condición de parada. El estado transporta el contexto entre pasos, y siempre necesitas una señal de parada natural y un límite duro. Comienza con encadenamiento para pipelines predecibles y recurre a un bucle completo de agente solo cuando el siguiente paso realmente dependa del resultado anterior. Registra todo, reintenta los fallos y recorta el estado a medida que crezca.