Workflows frente a agentes

Esta página fija el vocabulario de toda la sección de patrones. Al terminar sabrás distinguir un workflow de un agente, colocar cualquier diseño en una escalera de complejidad y justificar por qué subes un peldaño. Todo parte del artículo Building effective agents (Anthropic, diciembre de 2024), que sigue siendo la mejor referencia corta sobre el tema.

Qué es

El artículo agrupa todo bajo el nombre de sistemas agénticos y distingue dos familias:

• Workflow: los LLM y las herramientas se coordinan a través de rutas de código predefinidas. Tú decides el orden de los pasos; el modelo hace bien cada paso.
• Agente: el LLM dirige su propio proceso y decide qué herramientas usar y cuándo, manteniendo el control sobre cómo completa la tarea. Tú das el objetivo, las herramientas y los límites.

La diferencia práctica es quién escribe el flujo de control. En un workflow, el if, el for y el orden de las llamadas están en tu código. En un agente, están dentro de un bucle donde cada iteración la decide el modelo según lo que le devuelve el entorno.

flowchart LR
  subgraph W[Workflow]
    A[Entrada] --> B[Paso 1: LLM] --> C{Comprobación} --> D[Paso 2: LLM]
  end
  subgraph G[Agente]
    E[Objetivo] --> F[LLM decide]
    F -- tool_use --> H[Herramienta]
    H -- tool_result --> F
    F -- end_turn --> I[Resultado]
  end

La escalera de complejidad

Piensa en los diseños como peldaños. Cada uno añade capacidad y también coste, latencia y formas nuevas de fallar.

La recomendación central del artículo es buscar la solución más simple posible y solo añadir complejidad cuando se demuestra necesaria. Los sistemas agénticos suelen cambiar latencia y coste por mejor rendimiento en la tarea. Ese intercambio tiene que compensar, y solo lo sabes midiendo con evals.

Cuándo usar cada familia

Workflow cuando la tarea está bien definida y puedes describir los pasos de antemano. Ganas previsibilidad: el mismo tipo de entrada recorre el mismo camino, las trazas se leen fácil y el coste por ejecución es estable.

Agente cuando el número de pasos no se puede predecir y no puedes programar una ruta fija. Por ejemplo, depurar un fallo cuya causa desconoces o investigar una pregunta abierta. Ganas flexibilidad a cambio de más coste, más latencia y errores que se acumulan entre pasos. El artículo insiste en dos condiciones: que confíes en la capacidad de decisión del modelo para esa tarea y que haya un entorno que dé feedback real en cada paso (resultados de herramientas, tests, ejecuciones).

Cuándo no

No uses esta distinción como excusa para construir un agente “por si acaso”. Muchas aplicaciones útiles se quedan en el peldaño 1: una buena llamada con recuperación y ejemplos. Y no montes un workflow de cinco pasos donde basta un prompt mejor escrito; lee antes Principios de prompting.

Ejemplo concreto

Un equipo quiere automatizar respuestas de soporte.

1. Peldaño 1: una llamada con la política de devoluciones en el contexto. Resuelve las preguntas informativas.
2. Peldaño 2: un enrutado que separa “informativa”, “pedido” y “reclamación”, con un flujo distinto para cada una. Mejora porque cada flujo tiene su propio prompt y sus herramientas.
3. Peldaño 4: solo las reclamaciones complejas, que requieren consultar pedidos, envíos y pagos en un orden imprevisible, pasan a un agente con aprobación humana. Es el sistema que describe Agente de soporte con aprobación humana.

El sistema final mezcla peldaños. Es lo normal: los patrones se combinan.

Esqueleto de código

La misma tarea, “contestar una consulta de pedido”, escrita de las dos formas. Fíjate en dónde está el control.

# El flujo está en tu código: siempre los mismos pasos, en el mismo orden.
def responder_workflow(consulta: str) -> str:
    pedido_id = extraer_id_pedido(consulta)          # paso 1: llamada al LLM
    if pedido_id is None:                            # comprobación en código
        return pedir_numero_de_pedido()
    pedido = buscar_pedido(pedido_id)                # tu código llama a la API
    return redactar_respuesta(consulta, pedido)      # paso 2: llamada al LLM

# El flujo lo decide el modelo: qué herramienta, cuántas veces y cuándo parar.
def responder_agente(consulta: str, max_pasos: int = 10) -> str:
    mensajes = [{"role": "user", "content": consulta}]
    for _ in range(max_pasos):
        resp = client.messages.create(model=MODEL, max_tokens=1024,
                                      tools=HERRAMIENTAS, messages=mensajes)
        if resp.stop_reason != "tool_use":
            return texto(resp)
        mensajes.append({"role": "assistant", "content": resp.content})
        mensajes.append({"role": "user", "content": ejecutar_herramientas(resp)})
    raise RuntimeError("Límite de pasos alcanzado")

El agente completo, con manejo de errores y de cada stop_reason, está en Agente autónomo.

Sobre los frameworks

El artículo recomienda empezar usando la API del modelo directamente: muchos patrones caben en pocas líneas. Los frameworks ayudan con la fontanería, pero añaden capas que ocultan los prompts y las respuestas, y eso complica depurar. Si usas uno, asegúrate de entender qué hace por debajo. Leer tus propias trayectorias es la mejor defensa; tienes cómo en Depurar un agente leyendo sus trazas.

Coste y latencia

Cada peldaño suele multiplicar las llamadas al modelo. Un workflow tiene un coste por ejecución acotado y predecible porque sabes cuántas llamadas hace. Un agente tiene un coste variable que depende de cuántas vueltas dé, así que necesita condiciones de parada y presupuesto.

Patrones relacionados

• La llamada aumentada: el bloque con el que se construye todo lo demás.
• Qué patrón elegir: árbol de decisión para elegir peldaño y patrón.
• Agente autónomo: el último peldaño, con sus salvaguardas.
• Cuándo NO usar multiagente: la misma prudencia aplicada a varios agentes.