Introducción a los agentes: roles, ciclo de ejecución (run), determinismo, idempotencia

1. Qué es un agente y para qué lo necesitas

Los agentes no son una parte obligatoria de ChatGPT App: puedes crear tantas aplicaciones geniales como quieras sin usar agentes LLM. Sin embargo, tengo tres buenas razones para hablarte de ellos.

Los agentes son una excelente forma de añadir inteligencia al backend de tu aplicación. Selección inteligente de regalos, análisis de las preferencias textuales del usuario. Escenarios complejos de búsqueda, análisis, procesamiento y elaboración de conclusiones: todo esto es muy fácil de hacer con agentes LLM.

ChatGPT publicó su AgentsSDK para TS y Python. Es muy buena. La orquestación de agentes viene lista de fábrica. En una tarea compleja trabajará no un solo agente, sino todo un equipo. Es una dirección muy prometedora.

Y además hay un objetivo didáctico. ChatGPT invoca mcp-tools del mismo modo que los agentes LLM invocan sus tools. En cuanto entiendas cómo funcionan los agentes LLM, te quedará claro, por ejemplo, cómo hacer una máquina de estados del lado del modelo en la aplicación. Asimismo, estudiar AgentsSDK te da una idea de cómo funcionará en el futuro el ChatGPT SDK.

Así que, vamos a ello.

Qué es un agente LLM

Si ChatGPT App es el «frontal» bonito y cómodo de tu servicio dentro de ChatGPT, y el servidor MCP es el «motor» con las herramientas y la lógica de negocio, entonces el agente es algo así como un dispatcher inteligente, que sabe:

• leer el objetivo;
• decidir por sí mismo qué herramientas llamar y en qué orden;
• preguntar datos adicionales si es necesario;
• repetir pasos si hubo errores;
• llegar a un resultado final claro.

En una formulación cercana a la documentación oficial de Agents SDK, un agente es un programa. Teniendo acceso a una LLM y a un conjunto de herramientas, es capaz de planificar pasos por sí mismo para alcanzar el objetivo y ejecutarlos mediante tool‑calls.

Si trazamos un paralelismo con lo que ya tienes:

• En una ChatGPT App normal, el modelo de ChatGPT orquesta las llamadas a tus herramientas MCP directamente.
• Un agente LLM en el backend también tiene la descripción de la tarea, un conjunto de herramientas y decide por sí mismo qué tools llamar, cuántos pasos dar, cuándo detenerse y qué resultado devolver.

En el contexto de nuestro GiftGenius, podría verse así:

• Aplicación sin agente: el modelo llama directamente a searchGifts, luego a filterByBudget, después a getDetails, pensando cada vez desde cero;
• Aplicación con agente: ChatGPT llama a un mcp‑tool, y el backend le plantea al agente la tarea: «Encuentra el top‑5 de regalos para tal perfil». El agente da varios pasos: recopila información adicional, llama a distintas herramientas de búsqueda, filtra, ordena, crea las tarjetas finales y devuelve ya una respuesta estructurada lista.

ChatGPT y un agente LLM en el backend son como el director de una empresa y un empleado. ChatGPT tiene mucha más libertad: habla con el usuario y decide qué tareas estratégicas lanzar (invocar mcp tools). El agente LLM trabaja solo en el backend, no interactúa con el usuario, pero también «piensa» y puede llamar a sus tool. Una especie de ChatGPT en versión mínima.

2. De qué se compone un agente: LLM, instrucciones, herramientas y estado

Es útil pensar en el agente como en varios niveles.

En primer lugar, bajo el capó tenemos la misma LLM. Puede ser GPT‑5.1 u otro modelo que use el Agents SDK. Genera texto, planifica pasos, elige herramientas; en resumen, se encarga del «razonamiento», pero ya en tu contexto de orquestación.

En segundo lugar, por encima del modelo están las instrucciones. Es el prompt del sistema del agente, que define su rol, límites, estilo, formas de usar las herramientas. Ya hiciste algo parecido para ChatGPT App, pero ahora se aplica a un agente independiente.

En tercer lugar, hay un conjunto de herramientas del agente. Pueden ser:

• funciones en TypeScript (function calling clásico);
• herramientas HTTP/REST;
• envoltorios sobre tus MCP‑tools, para que el agente pueda llegar al mismo backend que ChatGPT App;
• herramientas «hosted» integradas de OpenAI (por ejemplo, web‑search, si las conectas).

Y, por último, existen reglas para trabajar con el estado y los pasos: cómo se almacena el estado de la sesión (session state), cómo se guardan los resultados intermedios, cómo se limitan los bucles. Profundizaremos más en la próxima lección sobre memoria y estado, pero ya ahora conviene tener presente que un agente no es una «solicitud de un solo uso», sino un proceso potencialmente largo con conservación del progreso.

Si lo miras con ojos de desarrollador de TypeScript, mentalmente resulta un objeto de este tipo (pseudocódigo, cercano a Agents SDK TS):

const giftAgent = new Agent({
  model: "gpt-5.1",
  systemPrompt: giftAgentPrompt,
  tools: { searchGifts, filterGifts, checkoutDraft },
  // aquí también: ajustes de memoria, límites de pasos y etc.
});

Por ahora no profundizamos en APIs exactas; importa la imagen: modelo, instrucciones, herramientas y ajustes de comportamiento en un solo lugar.

3. Roles de los mensajes: system / user / assistant / tool en el mundo del agente

Ya conoces los roles clásicos system, user, assistant y tool de Chat Completions. En Agents SDK se conservan, pero adquieren un sentido más aplicado.

El rol system define la propia personalidad y misión del agente. Por ejemplo, para el agente de GiftGenius podría ser: «Eres un agente de selección de regalos. Tu tarea es, con el menor número de pasos, seleccionar de 3 a 7 opciones relevantes de regalos en función del perfil del destinatario y el presupuesto, y luego preparar un JSON estructurado para el widget». Aquí también defines restricciones: qué no debe hacer (por ejemplo, no realizar compras reales sin un paso aparte) y cómo debe trabajar con las herramientas.

El rol user en el contexto del agente no es necesariamente «una persona real». A menudo es una «tarea» para el agente: un objetivo formulado por tu App, un servicio o por otro agente. Por ejemplo, ChatGPT App puede invocar al agente con un mensaje user: «Selecciona 5 ideas de regalo para un colega desarrollador, presupuesto 50 $, motivo: cumpleaños».

El rol assistant es lo que «dice» el propio modelo dentro del agente. Aquí puede haber tanto razonamientos y planes intermedios como la respuesta final. Tu tarea es ajustar el prompt del sistema para que estos mensajes sean útiles y, si es necesario, se registren en logs.

El rol tool (o sus análogos en el SDK concreto) describe los resultados de las llamadas a herramientas: «a través de MCP se han encontrado 50 productos», «el API devolvió un error de timeout», «la BD devolvió el perfil del usuario». Estos mensajes, junto con los mensajes assistant, conforman el historial del ciclo de ejecución del agente.

Es cómodo resumirlo en una pequeña tabla:

system

user

assistant

tool

Esta estructura es importante porque sobre ella se construye el ciclo de ejecución (run), el protagonista de la lección de hoy.

4. Cómo una LLM llama a funciones en tu backend

Cuando te acostumbras al modo «pregunta–respuesta», parece que una LLM funciona con un esquema simple: llega un texto → el modelo responde con texto. En realidad, bajo el capó todo es un poco más complejo y por eso funciona el function calling.

El modelo no recibe una única pregunta, recibe una lista de mensajes: el historial del diálogo. Ahí ya están todas las réplicas anteriores: instrucciones del sistema («quién eres y qué se puede/no se puede»), tus mensajes, respuestas pasadas del modelo, resultados de herramientas. En cada paso el modelo mira toda esa cinta, como un chat‑log, y decide: «¿Qué mensaje hay que añadir a continuación?».

Esta es la idea clave: una LLM siempre da un paso: escribe el siguiente mensaje al final del historial. No «cambia el pasado» ni edita mensajes antiguos, simplemente continúa la lista. Escribes una pregunta y el modelo responde. Escribes la segunda y el modelo vuelve a responder, teniendo en cuenta todo el historial del diálogo (todos los mensajes).

El function calling funciona del mismo modo. En lugar de «ejecutar directamente una función», el modelo hace lo siguiente:

• ve la lista de herramientas/tools disponibles y sus descripciones junto con el historial del diálogo;
• decide: «Ahora es más lógico no responder solo con texto, sino llamar primero a tal herramienta»;
• y como siguiente mensaje añade al historial no una respuesta de texto, sino un mensaje especial con el formato «quiero llamar a tal tool con tales argumentos».

Después, ya no el modelo, sino tu backend lee ese nuevo mensaje al final del historial, entiende que es una solicitud de llamada de función y llama a la herramienta necesaria. Luego añade al historial otro mensaje con el resultado del tool y vuelve a enviar la lista completa de mensajes al modelo. El modelo vuelve a mirar toda la cinta y añade el siguiente paso: otra llamada o ya la respuesta final legible para humanos.

Es decir:

• para Q&A normal: «siguiente mensaje» = respuesta de texto;
• para function calling: «siguiente mensaje» = instrucción para llamar a una función o respuesta tras usar la función.

No hay ningún «comando mágico aparte para llamar a una función»; es solo un tipo especial del siguiente mensaje que el modelo añade al final de la cadena.

El modelo no llama a funciones de tu backend a través de un API público. Simplemente «escribe en el chat» que quiere invocar una función con parámetros. Y ya tu backend llama a la función local, y su respuesta la añade al chat. Y todo vuelve a empezar.

5. Ciclo de ejecución (run) del agente: cómo «piensa» paso a paso

En efecto, un agente LLM es un cierto objeto/algoritmo en tu servidor que dispara un ciclo de ejecución del agente: es el ciclo ampliado «pregunta → pensar → quizá hacer una acción → volver a pensar → … → respuesta final». En la documentación de OpenAI a veces se llama agent loop o patrón ReAct (Reason + Act + Observe).

A nivel conceptual, un run del agente se ve así:

1. El agente recibe la entrada: instrucciones del sistema, la tarea (mensaje user) y, posiblemente, el estado actual.
2. El modelo genera un paso: ya sea una respuesta de texto, ya sean planes y la decisión de llamar a una o varias herramientas.
3. Si el modelo eligió un tool‑call, el agente llama a la herramienta correspondiente en el código (puede ser una función local, un MCP‑tool, una solicitud HTTP, acceso a la BD, etc.).
4. Los resultados de las herramientas se agregan al historial como mensajes tool.
5. El ciclo vuelve al modelo con el nuevo contexto. El modelo decide qué hacer a continuación: continuar planificando, llamar a otra herramienta o finalizar la tarea con una respuesta final.
6. Cuando el modelo finaliza el run explícitamente o por condiciones de parada, el agente devuelve el resultado final a quien lo invocó.

Podemos mostrarlo con un pequeño diagrama:

flowchart TD
    A[Inicio del run: objetivo + system] --> B[Llamada al modelo]
    B --> C{¿El modelo quiere
responder con texto
o llamar a un tool?}
    C --> D["Respuesta de texto
(assistant)"]
    D --> E{¿La tarea está terminada?}
    E -->|Sí| F[Resultado final]
    E -->|No| B

    C --> G["Tool-call
(descripción de la llamada)"]
    G --> H[Llamada a función / MCP / HTTP]
    H --> I["Resultado del tool
(tool message)"]
    I --> B

Si lo traducimos a un pseudocódigo simplificado en TypeScript (alejado del API real, pero lógicamente correcto), se obtiene algo como:

async function runAgent(goal: string) {
  let context = buildInitialContext(goal);

  while (!isFinished(context)) {
    const decision = await callLLM(context); // paso del agente

    if (decision.type === "tool_call") {		//¿llamar a una función?
      const toolResult = await callTool(decision.tool, decision.args);	//llamamos a la función local
      context = appendToolResult(context, toolResult);		// añadimos el resultado al final de la lista
    } else {
      context = appendAssistantMessage(context, decision.message); 
    }

    enforceLimits(context); // límites de pasos/tiempo/bucles
  }

  return extractFinalResult(context);
}

Agents SDK se encarga de gran parte de esta rutina: almacenamiento del historial, marshalling de tool‑calls, lógica de reintentos, etc. A ti te queda ajustar la configuración e implementar las propias herramientas.

Run vs step

Es importante distinguir dos conceptos:

• run es una ejecución del agente para un objetivo: «selecciona regalos para este caso»;
• step es un paso del ciclo de ejecución: una llamada concreta al modelo que puede derivar en una respuesta de texto o en un tool‑call.

En el monitoreo verás muchos pasos dentro de un mismo run, y los límites de seguridad y coste a menudo se fijan ya sea «por run» o «por paso».

Ahora que está claro cómo vive el agente dentro de un run y avanza por el ciclo, veamos dónde tiene sentido montar todo esto y dónde bastan herramientas simples.

5. Dónde en GiftGenius hace falta un agente y dónde sobra

Antes de lanzarte a escribir un agente para todo, conviene hacerse una pregunta honesta: «¿Realmente hace falta aquí?».

Un buen escenario para un agente es una tarea multietapa con ramificaciones, reintentos y lógica que es incómodo mantener solo en prompts.

En GiftGenius, esa tarea podría ser un «asistente de selección inteligente de regalos» que:

• sepa pedir detalles importantes (sexo del destinatario, aficiones, nivel de cercanía);
• pueda recurrir a varias fuentes de productos (distintos vendedores a través de MCP‑tools);
• filtre y ordene resultados;
• ante errores de fuentes, repita el intento o siga una vía alternativa;
• devuelva no solo una lista de textos, sino una lista estructurada de candidatos con explicaciones y enlaces a SKU del product feed.

Aquí el agente será realmente útil como «orquestador», especialmente si después quieres complementarlo con un escenario de voz/Realtime o con comercio complejo (ACP).

En cambio, para una llamada simple como getGiftDetails(giftId) no hace falta agente: una MCP‑tool normal, invocada directamente desde ChatGPT, cubre totalmente el caso. Lo mismo con escenarios «de un solo paso» como «da la descripción de este regalo a partir del texto de la ficha de producto».

El enfoque sensato general es: si puedes describir el escenario como «una única herramienta razonable», probablemente no necesitas un agente. Si empiezas a detallar un workflow multietapa con comprobaciones y reintentos, es muy probable que un agente te resulte útil.

6. Determinismo: cómo hacer el comportamiento del agente predecible

El determinismo en el mundo de los agentes LLM es algo delicado. Teóricamente, con la misma entrada y los mismos ajustes quieres obtener el mismo plan de acciones y la misma secuencia de tool‑calls. En la práctica, el modelo sigue siendo estocástico, pero tienes varias palancas para controlar la predictibilidad.

Primero, lo clásico: temperatura y otros parámetros de generación. Cuanto más baja la temperatura, menos creatividad y más «obediencia» del modelo. Para un agente de selección de regalos, probablemente quieras tener un nivel de libertad no nulo, pero tampoco demasiado alto; de lo contrario, el modelo se inventará cada día una forma nueva de llamar a la misma herramienta.

Segundo, instrucciones del sistema claras. Si describes el comportamiento de forma difusa, tipo «puedes llamar a distintas herramientas y hacer lo que quieras», no te sorprendas si el agente ora salta por APIs, ora intenta responder «de la nada». Es mucho mejor describir explícitamente cuándo debe llamar a una herramienta, qué parámetros son válidos, cómo interpretar errores y en qué casos debe terminar la tarea.

Por ejemplo, el prompt del sistema para el agente de GiftGenius puede incluir el fragmento:

Si no tienes el perfil completo del destinatario (edad, sexo, ocasión, presupuesto aproximado),
primero formula preguntas aclaratorias por el canal orientado al usuario y espera las respuestas.
Solo después llama a la herramienta search_gifts con el perfil cumplimentado.
No inventes productos de la nada; apóyate siempre en los resultados de las herramientas.

Indicaciones así reducen la variabilidad de decisiones y hacen el comportamiento más determinista.

Tercero, el diseño de las propias herramientas. Si tienes tres herramientas que buscan «más o menos lo mismo», el modelo inevitablemente elegirá a veces una y a veces otra. Es mejor diseñar herramientas con zonas de responsabilidad claras, no superpuestas, y reflejarlo en sus descripciones.

Por último, puedes usar guardrails: reglas y esquemas que verifican las acciones del agente y los resultados del modelo. En Agents SDK hay soporte integrado de validaciones y restricciones, incluido sobre la estructura de los datos de salida. Si el modelo intenta generar algo que no respeta el esquema, puedes corregirlo suavemente o incluso repetir el paso.

Mini ejemplo: fijar el formato del resultado

Supongamos que necesitas que el agente siempre devuelva un JSON con el campo gifts, y dentro haya objetos con id, title y score. Puedes:

• describir este esquema a nivel del agente;
• indicar que la salida final debe cumplirlo;
• en caso de incumplimiento, repetir el paso o devolver un error seguro.

Pseudocódigo:

const giftResultSchema = z.object({
  gifts: z.array(z.object({
    id: z.string(),
    title: z.string(),
    score: z.number().min(0).max(1),
  }))
});

// En la configuración del agente
const agent = new Agent({
  /* ... */
  outputSchema: giftResultSchema,
});

Cuando el modelo intente devolver algo extraño, el runner informará de un error de validación y podrás volver a pedirle al modelo o registrar el incidente.

7. Idempotencia: por qué el agente puede llamar a tu API dos veces

Si el determinismo trata de «el mismo plan para las mismas entradas», la idempotencia trata de la seguridad de los reintentos. En el contexto de agentes es críticamente importante por dos razones.

Primero, aparece otro nivel de reintentos: no solo clientes HTTP y balanceadores de carga, también el propio agente puede decidir repetir la llamada a una herramienta si recibió un error o un resultado incompleto. Segundo, en escenarios reales de producción se añaden webhooks, colas, canales de streaming, y puedes procesar accidentalmente la misma etapa lógica varias veces.

Ya has hablado de idempotencia a nivel de MCP‑tools: no realizar pagos dobles, no crear el mismo pedido dos veces, usar idempotency keys en las solicitudes. Ahora es lo mismo, pero multiplicado por la naturaleza multietapa del agente.

Imaginemos que en GiftGenius apareció una herramienta create_checkout_session que, según la lista de regalos seleccionados, crea un draft de checkout en ACP/Stripe. Si el agente decide repetir esta llamada debido a un error de red, no quieres en absoluto dos pedidos distintos y dos cargos.

Entonces, necesitas:

• idear un idempotency key externo para cada acción lógica (por ejemplo, runId + stepIndex o un checkoutDraftId generado explícitamente);
• pasarlo a tu backend/endpoint de ACP;
• en el backend, comprobar si ya has procesado esa clave y devolver el resultado guardado en lugar de ejecutar de nuevo.

Pseudoejemplo en TypeScript:

async function createCheckoutDraft(runId: string, payload: DraftPayload) {
  const key = `gift-checkout-${runId}`;

  const existing = await findDraftByKey(key);
  if (existing) return existing;

  const draft = await stripe.checkout.sessions.create({
    /* ... */,
    idempotencyKey: key, // o tu propia capa por encima
  });

  await saveDraftWithKey(key, draft);
  return draft;
}

Ahora, incluso si por alguna razón el agente llama a esta herramienta dos veces con el mismo runId, tu código seguirá siendo idempotente: el mismo paso lógico → el mismo resultado real.

«Primero comprobar, luego actuar»

El segundo patrón común de idempotencia es comprobar el estado primero y luego actuar. Por ejemplo, antes de crear un pedido, comprobar si ya existe un pedido con el mismo clientReferenceId o el mismo conjunto de parámetros. Es especialmente útil en workflows largos en los que el agente puede «olvidar» que ya hizo algo en un paso anterior.

Modo seguro / modo simulado

En la fase de desarrollo es útil tener un «modo seguro» para herramientas peligrosas: en lugar de realizar la acción real, solo registran qué se habría hecho y devuelven un pseudoresultado. Para agentes es una forma cómoda de ejecutar el ciclo en un entorno real sin arriesgar dinero o datos.

8. Mini práctica: describimos el agente GiftGenius en lenguaje humano

Ya hemos hablado del ciclo de ejecución, del determinismo y de la idempotencia de las herramientas. Tomemos un minuto para alejarnos del código y ver cómo encaja todo esto en un escenario vivo.

Ahora es útil hacer un pequeño ejercicio en papel (o mentalmente), sin código.

Imagina que describes un agente simple:

• system

  : eres un asistente de selección de regalos; siempre aclaras detalles importantes, no inventas productos de la nada y usas solo los resultados de las herramientas.

• user

  : quiero un regalo para un colega hasta 50 $.

Describe con palabras qué pasos debería dar ese agente.

Un escenario típico puede verse así.

1. Primero, el agente comprueba si la información es suficiente. Si no, hace preguntas aclaratorias: a qué se dedica el colega (diseñador, desarrollador, gestor), si hay algún tabú (alcohol, regalos de broma), si hay restricciones de envío. Las respuestas van al session state o a los parámetros de la herramienta.
2. Luego, el agente llama a la herramienta search_gifts con el perfil cumplimentado: «colega desarrollador, presupuesto 50, categoría: gadgets y oficina». La herramienta devuelve una lista de candidatos con precios, categorías e IDs de producto.
3. Después, el agente puede llamar a una herramienta adicional filter_gifts_by_constraints si resultó que parte de los productos no se pueden enviar a la región deseada, o filtrar manualmente en su propio prompt. Tras eso, ordena las opciones por relevancia y coste, quizá añadiendo comentarios («apto si el colega ama el café», «buena opción para teletrabajo»).
4. Por último, el agente prepara la respuesta final estructurada para ChatGPT App: una lista de 5–7 regalos con descripciones breves, sugerencias de uso y enlaces al Checkout (o al siguiente paso: creación del draft de checkout).

¿Dónde hacen falta tool‑calls? Obviamente en la búsqueda y filtrado de productos, en la comprobación de disponibilidad y en la creación del draft de checkout. ¿Qué pasos deben ser idempotentes? Ante todo todas las operaciones relacionadas con pedidos y dinero: creación del draft de checkout y, posiblemente, el registro del historial en la BD.

9. Errores típicos en los primeros pasos con agentes

Error n.º 1: tratar al agente como «un segundo ChatGPT sin restricciones».
A veces apetece dar al modelo otro prompt y llamarlo «agente». El resultado es algo que genera mucho texto, llama a herramientas de forma caótica y es difícil de controlar. Para evitarlo, es importante describir claramente el rol del agente en system, limitar la lista de herramientas y pensar en él como un orquestador con una misión concreta, no como «otro universo de generación de texto».

Error n.º 2: ausencia de idempotencia en las herramientas.
A menudo los desarrolladores migran sus viejos handlers HTTP al agente «tal cual», sin tener en cuenta que ahora el runner puede repetir llamadas automáticamente. En pagos y pedidos puede tener consecuencias muy desagradables. El enfoque correcto es diseñar desde el principio las herramientas para que una llamada repetida con la misma clave lógica no provoque una acción duplicada.

Error n.º 3: ajustes del modelo demasiado creativos.
Una temperatura alta es estupenda para inventar brindis y poemas, pero para un agente que debe orquestar de forma fiable procesos multietapa conduce a un comportamiento impredecible: el modelo elegirá herramientas distintas cada vez, generará planes diferentes y a veces olvidará que tiene tools. Trata a los agentes como entidades «de servicio» y mantenlos en un modo más estricto.

Error n.º 4: una herramienta «para todos los casos».
A veces se quiere crear una tool universal como execute_any_sql o do_anything_with_orders, y dársela al agente. Combinada con la creatividad de una LLM, es casi una amenaza garantizada para la seguridad. Es mucho mejor tener varias herramientas de nicho, con contratos y permisos claros, que una «divina» con permisos absolutos para todo.

Error n.º 5: ausencia de criterios explícitos para terminar el run.
Si no explicas al agente cuándo detenerse, puede entrar en bucles infinitos o casi infinitos: volver a comprobar resultados, volver a preguntar al usuario, volver a intentar llamar a una herramienta ante el mismo error. A menudo esto se manifiesta solo bajo carga, cuando alguna dependencia es inestable. La forma correcta es fijar límites al número de pasos, al tiempo del run y a la cantidad de reintentos ante el mismo error, y describir en system que el agente debe «rendirse honestamente» cuando haya agotado opciones razonables.

Error n.º 6: almacenar todo y de inmediato en el estado del agente.
Como Agents SDK simplifica el trabajo con el estado de sesión, hay tentación de meter ahí todo: documentos grandes, logs sin procesar, datos sensibles. Esto infla el contexto, aumenta el coste y crea riesgos de seguridad. El estado del agente debe guardar solo lo necesario para continuar el trabajo; el resto, en la BD, logs y otras capas, con privacidad en mente.

Error n.º 7: intentar usar un agente donde basta con una MCP‑tool simple.
A veces los desarrolladores empiezan con un agente, incluso si la tarea es solo llamar a una función y devolver el resultado. Eso añade complejidad donde no hace falta: aparecen el ciclo de ejecución, el estado, logs adicionales y puntos potenciales de fallo. Si el escenario cabe en un tool‑call sin workflow complejo, es mejor dejarlo así y conectar un agente solo cuando aparezca una multietapa real.