"Queremos un agente de IA" es una de las peticiones que más escucho. A menudo lo que el negocio necesita de verdad es un workflow fiable con una o dos llamadas a un LLM en los sitios adecuados. A veces sí es un agente. Equivocarse sale caro en ambas direcciones: un agente sobredimensionado es lento, costoso e impredecible; un workflow que se queda corto se rompe en cada caso que no previó. Esta guía explica los bloques básicos, los patrones que se construyen con ellos y cómo elegir.

Workflows frente a agentes

El ensayo de Anthropic Building effective agents, muy citado, traza una línea útil:

  • Los workflows son sistemas en los que los LLM y las herramientas se orquestan mediante rutas de código predefinidas. Tú decides los pasos; el modelo aporta las partes inteligentes.
  • Los agentes son sistemas en los que el LLM dirige dinámicamente su propio proceso y el uso de herramientas, decidiendo qué hacer a continuación según los resultados.

El consejo principal del ensayo es empezar por la solución más sencilla y añadir complejidad solo cuando mejore los resultados de forma demostrable. Coincide con mi experiencia: la mayoría de los sistemas en producción que construyo son workflows con un agente dentro de un paso bien delimitado.

El bloque básico: un LLM aumentado

Todo patrón parte de una llamada a un LLM reforzada con:

  • Recuperación: documentos relevantes de tu base de conocimiento; consulta RAG para empresas.
  • Herramientas: funciones que el modelo puede llamar (búsqueda, consultas a base de datos, APIs); consulta diseño de herramientas para agentes.
  • Memoria: hechos relevantes de interacciones anteriores.

Muchos problemas se resuelven con una sola llamada aumentada bien construida. Prueba eso primero y mídelo con evals antes de construir algo mayor.

Patrones de workflow

Prompt chaining

Divide la tarea en pasos secuenciales, cada uno una llamada al LLM que procesa la salida anterior. Añade comprobaciones programáticas ("puertas") entre pasos.

Ejemplo: generar la descripción de un producto → comprobar en código la longitud y las afirmaciones prohibidas → traducir al ucraniano → comprobar la terminología con un glosario.

Úsalo cuando la tarea se descompone limpiamente en subtareas fijas. Cambias latencia por precisión, porque cada llamada tiene un trabajo más fácil.

Routing

Clasifica la entrada y envíala a un prompt, modelo o pipeline especializado.

Ejemplo: mensajes de soporte dirigidos a flujos de facturación, técnicos o de cuenta; preguntas sencillas a un modelo pequeño y barato y las complejas a uno potente, una palanca de coste importante descrita en optimización de costes de LLM.

Úsalo cuando las entradas caen en categorías distintas que conviene tratar por separado.

Paralelización

Ejecuta varias llamadas al LLM a la vez y agrega los resultados en código. Dos variantes:

  • Seccionado: subtareas independientes en paralelo, por ejemplo revisar un contrato buscando cinco tipos de riesgo a la vez.
  • Votación: la misma tarea varias veces, quedándote con la mayoría o con el resultado más prudente, por ejemplo marcar contenido para revisión si cualquiera de tres comprobaciones lo marca.

Úsalo cuando las subtareas son independientes o necesitas más confianza.

Orquestador-trabajadores

Un LLM central divide la tarea en subtareas de forma dinámica, las delega en llamadas trabajadoras y sintetiza los resultados. A diferencia de la paralelización, las subtareas no se conocen de antemano.

Ejemplo: un cambio de código que toca un número desconocido de archivos; una pregunta de investigación que exige varias búsquedas.

Evaluador-optimizador

Una llamada genera, otra evalúa según criterios y devuelve feedback, y el bucle se repite hasta que el evaluador queda satisfecho o se alcanza un límite.

Ejemplo: traducción con matices, un resumen que debe incluir hechos concretos, código que debe pasar los tests.

Úsalo cuando tienes criterios de evaluación claros y la iteración mejora los resultados de forma medible.

Agentes autónomos

Un agente es un bucle: el modelo elige una acción, el entorno devuelve un resultado y el modelo decide qué hacer después, el patrón formalizado en ReAct. Los agentes encajan en problemas abiertos en los que no puedes predecir el número de pasos ni codificar la ruta: resolver un caso de soporte que puede requerir varias consultas, arreglar un bug en un código desconocido, investigar una pregunta en muchas fuentes.

def run_agent(task: str, tools: dict, max_steps: int = 20) -> str:
    messages = [{"role": "user", "content": task}]
    for step in range(max_steps):
        response = llm(messages=messages, tools=list(tools.values()))
        messages.append({"role": "assistant", "content": response.content})
        if response.stop_reason != "tool_use":
            return response.text  # model decided it is done
        results = []
        for call in response.tool_calls:
            try:
                output = tools[call.name].run(**call.input)
            except Exception as e:
                output = f"Error: {e}"  # let the model see and recover
            results.append(tool_result(call.id, output))
        messages.append({"role": "user", "content": results})
    raise StepLimitExceeded(task)

El bucle en sí es sencillo. Todo lo que hace que los agentes funcionen en producción lo rodea: diseño de herramientas, gestión del contexto, condiciones de parada, permisos, observabilidad y puntos de control humanos.

Cómo elegir

Pregunta Si la respuesta es sí Si es no
¿Puedes escribir los pasos de antemano? Workflow Plantéate un agente
¿Una acción errónea es costosa o irreversible? Workflow, o agente con aprobación humana Un agente puede valer
¿La latencia es crítica (menos de 2–3 s)? Una sola llamada o una cadena corta Los agentes son aceptables
¿El volumen es alto y el margen estrecho? Workflow con routing a modelos pequeños El coste de un agente puede valer
¿El éxito se puede comprobar automáticamente? Un agente o un evaluador-optimizador pueden autocorregirse Mantén humanos en el bucle

Una heurística práctica: construye primero el workflow. Donde falle una y otra vez porque la ruta no se puede predecir, sustituye ese paso por un agente. Acabas con un híbrido —código determinista para las partes predecibles y un agente para la parte abierta— más fácil de probar y más barato de operar que un agente de extremo a extremo.

Cuestiones de producción para agentes

Condiciones de parada

Los agentes necesitan límites explícitos: número máximo de pasos, de tokens, de tiempo real y de gasto por tarea. Cuando se alcanza un límite, devuelve un resultado parcial útil o escala a una persona; no falles en silencio.

Puntos de control humanos

Para acciones con consecuencias reales —enviar correos, emitir reembolsos, modificar registros— exige confirmación. Es también la defensa más eficaz contra el prompt injection; consulta seguridad de agentes de IA.

Crecimiento del contexto

Cada paso añade resultados de herramientas al contexto. Los agentes de larga duración necesitan compactación, resúmenes, memoria externa o subagentes con contextos limpios. Es el tema del context engineering.

Observabilidad

No se puede depurar un agente a partir de su respuesta final. Traza cada paso: la decisión del modelo, las llamadas a herramientas con sus argumentos, los resultados, los tokens y la latencia. Consulta observabilidad de LLM.

Evaluación

Evalúa tanto el resultado (¿se hizo bien la tarea?) como la trayectoria (¿cuántos pasos, cuántos errores de herramientas, se intentó alguna acción peligrosa?). Un agente que llega a la respuesta correcta en 40 pasos en lugar de 6 es un problema de coste y de latencia.

Frameworks: ¿usarlos o no?

Frameworks como LangGraph, el OpenAI Agents SDK, el Claude Agent SDK, Spring AI o LangChain4j aceleran el prototipado y aportan fontanería útil: llamadas a herramientas, gestión de estado, trazas. También añaden capas de abstracción que pueden ocultar qué prompts y llamadas se envían realmente. Mi consejo:

  • Entiende primero la API en bruto: construye a mano un bucle de agente.
  • Adopta un framework cuando necesites sus funciones (persistencia, humano en el bucle, trazas), no por defecto.
  • Asegúrate de poder ver los prompts y llamadas a herramientas exactos que envía el framework.

Para equipos Java, Spring AI encaja de forma natural; para TypeScript, el Vercel AI SDK cubre la mayoría de las necesidades. Exponer tus sistemas de negocio como herramientas mediante el Model Context Protocol los hace reutilizables entre frameworks y clientes.

Un ejemplo práctico: procesamiento de facturas

Requisito: procesar las facturas de proveedores entrantes en el ERP.

  • Versión 1 (workflow): extraer campos con salida estructurada → validar totales e identificadores fiscales en código → localizar al proveedor en el ERP por identificador fiscal → crear un borrador de factura. Las excepciones van a una cola humana. Esto cubre la gran mayoría de las facturas.
  • Versión 2 (híbrido): para las excepciones —proveedor desconocido, pedido de compra que no cuadra, moneda inusual— un agente con herramientas de solo lectura (buscar proveedores, buscar pedidos, leer condiciones del contrato) investiga y propone una solución que aprueba una persona.

El agente solo se ejecuta en los casos difíciles, con herramientas de solo lectura y aprobación humana. Esa es la forma que adoptan la mayoría de los agentes de negocio que funcionan. Más sobre la parte de extracción en procesamiento de documentos con LLM.

Preguntas frecuentes

¿Un chatbot con RAG es un agente? Normalmente no; es un LLM aumentado dentro de un workflow fijo de recuperar y responder. Se convierte en agente cuando el modelo decide cuándo y cuántas veces buscar y qué herramientas usar.

¿Necesitamos varios agentes? Rara vez al principio. Los sistemas multiagente ayudan en tareas amplias y paralelizables y consumen bastantes más tokens; consulta sistemas multiagente.

¿Cómo probamos un agente antes de producción? Crea un conjunto de escenarios con estados finales esperados, ejecútalo en un sandbox con herramientas simuladas o de staging y evalúa tanto los resultados como las trayectorias.

¿Qué modelo debería usar un agente? Los agentes se benefician del modelo más potente que te puedas permitir para planificar y elegir herramientas; las subtareas pueden ir a modelos más baratos.

Fuentes

  1. Anthropic (2024). Building effective agents.
  2. Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models.
  3. Schick et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools.
  4. Anthropic. Tool use with Claude.
  5. OpenAI. A practical guide to building agents.