Workflow, agente o LLM aumentado, el patrón lo elige el problema

El sponsor vio una demo y pide “un agente”. El área de riesgos pide que cada caso siga el mismo camino auditable. Finanzas pide que el costo por caso no se dispare. Elegir el patrón es la primera decisión de arquitectura, y casi siempre se decide por la forma del problema, no por lo que pide el cliente.

Tres patrones, una pregunta

La pregunta es: ¿se puede saber de antemano qué pasos hacen falta?

• LLM aumentado (augmented LLM): una sola llamada al modelo con recuperación, herramientas o memoria. Sirve cuando la tarea se resuelve en un paso: responder con documentos, extraer campos, clasificar.
• Flujo de trabajo (workflow): los pasos y su orden están definidos en código. El modelo resuelve cada paso, pero no decide el camino. Incluye el encadenamiento de prompts (prompt chaining), con controles en código entre pasos, el ruteo y la paralelización.
• Patrón agéntico (agentic pattern): el modelo decide qué herramienta usar y cuándo terminar, en un ciclo. Sirve cuando la cantidad de pasos no se puede prever porque cada resultado decide el siguiente.

Si el escenario dice…	Conviene
“Siempre los mismos pasos, en el mismo orden”, “auditable”, “regulado”	Workflow
“Cada resultado decide qué revisar después”, “a veces 1 paso, a veces 6”	Agente, con condición de corte
“Responder preguntas sobre la base de conocimiento”	LLM aumentado

La regla de fondo: empezá por lo más simple que funcione y sumá complejidad solo cuando mejora un resultado medible. Un agente da autonomía a cambio de previsibilidad, más costo y errores que se acumulan entre pasos.

Cuándo se justifica multiagente

Un diseño de orquestador y trabajadores (orchestrator-workers) conviene cuando se da al menos una de estas condiciones:

• el trabajo se puede paralelizar en partes independientes (40 empresas a investigar, 300 contratos a revisar);
• el trabajo no entra en un solo contexto;
• hacen falta muchas herramientas distintas que confundirían a un solo agente.

Si los pasos son secuenciales y cada uno necesita lo que vio el anterior, partirlos en subagentes solo agrega traspasos: más tokens, más latencia y contexto perdido en cada salto. Un solo agente con buenas herramientas alcanza y cuesta menos.

Cuando sí hay subagentes, cada uno necesita un objetivo claro, límites explícitos (qué le toca y qué no), las herramientas justas y un formato de salida. Y devuelve un resumen condensado al orquestador, no sus notas crudas.

Las trampas típicas

• El agente “porque lo pidió el sponsor”: un proceso regulado y predecible es un workflow, aunque el pedido diga otra cosa. Explicale el trade-off en términos de auditoría y riesgo.
• Multiagente por defecto: cuatro subagentes en secuencia que se pasan una instrucción corta cada uno. El arreglo no es otro subagente revisor ni pasarle todo el historial a cada uno, sino volver a un solo agente.
• Más ramas fijas en una cadena que no da abasto: si la cantidad de pasos no se puede prever, sumar caminos predefinidos no termina nunca. Es la señal para pasar a un agente.
• Un solo prompt gigante para una tarea grande: un pedido único que tiene que hacer todo falla por partes. Eso pide descomposición, no un modelo con más contexto.
• Agentes que “negocian” entre sí la decisión final sin un camino definido ni una persona que decida.

En el examen

Buscá en el escenario la frase que describe la forma de los pasos: “siempre en ese orden” apunta a un workflow con controles en código; “cada diagnóstico decide el siguiente” apunta a un agente con condición de corte y aprobación humana para lo que cambia algo. Si el escenario describe un sistema multiagente lento y caro donde nada corre en paralelo, la respuesta suele ser simplificar. Desconfiá de las opciones que suman componentes (otro agente, otro modelo revisor) sin atacar la causa.