Agentes de IA: cómo funciona su bucle y cuándo detenerlo

El modelo propone la siguiente acción. El software decide si puede ejecutarse, registra lo ocurrido y determina si se permite otra llamada al modelo. Ese reparto de responsabilidades es el punto de partida tanto para crear un primer agente como para investigar por qué uno no dejó de ejecutarse.

El comportamiento de los frameworks que se describe a continuación se verificó con la documentación oficial disponible de cada proveedor el 24 de octubre de 2026. La comparación pone en común qué cuenta cada framework y en qué momento aplica sus controles. Los ejemplos de solicitudes de soporte y las políticas propuestas son ilustrativos; no son resultados medidos en producción.

¿Cómo funciona el bucle de los agentes de IA?

El ciclo básico es llamada al modelo → llamada a una herramienta → observación → repetición, con una salida siempre que continuar deje de ser necesario o esté prohibido.

Imagina a alguien que coordina el trabajo de un técnico. Quien coordina elige la siguiente tarea, el técnico la ejecuta y el informe que devuelve sirve para tomar la próxima decisión. Pedir que se inspeccione una máquina no equivale a inspeccionarla; un mensaje tranquilizador tampoco demuestra que la reparación haya funcionado.

En el software, quien coordina es un modelo de lenguaje de gran tamaño, o LLM. El técnico es una herramienta: una función que consulta una base de datos, busca documentos, ejecuta un comando o modifica un registro. El entorno de ejecución que los rodea es el código que conecta ambas partes.

En una tarea hipotética de redacción de respuestas de soporte, la traza podría ser así: la primera llamada al modelo solicita el caso del cliente; la segunda pide la política aplicable; la tercera devuelve un borrador basado en ambos. Son 3 llamadas al modelo y 2 ejecuciones de herramientas dentro de una sola petición a la aplicación. Si el envío requiere aprobación, la redacción puede darse por terminada mientras el envío sigue pendiente.

Mantén el estado de la tarea separado de la transcripción. El estado debe indicar qué solicitud se está atendiendo, qué política se aceptó, si existe un borrador y si el envío está autorizado. La transcripción explica cómo se llegó hasta ahí. Pedir al modelo que deduzca todo eso una y otra vez a partir de una conversación cada vez más larga dificulta la supervisión.

¿Qué aporta un agente que trabaja en bucle?

Un agente que trabaja en bucle puede elegir su siguiente acción a partir del resultado más reciente. Un flujo fijo ya tiene definida la secuencia: obtener la solicitud, consultar la política y redactar el borrador. Usa un bucle adaptativo cuando la siguiente acción útil dependa de lo que revele la anterior. Si no existe esa incertidumbre, usa una secuencia fija.

¿Dónde encaja el bucle ReAct?

El bucle de un agente ReAct conecta razonamiento y acción: el modelo usa las observaciones para orientar sus acciones posteriores. El proyecto ReAct original describe cómo intercalar razonamiento y acciones en un entorno. Para supervisar una aplicación, registra las acciones solicitadas, las observaciones y los resultados. Una explicación del progreso en lenguaje natural no sustituye a un comprobante de ejecución.

Las tres condiciones de parada que necesita un bucle en producción

Diseña tres salidas explícitas: tarea completada, límites agotados y necesidad de intervención humana. Son categorías de ingeniería; no significa que todos los SDK ofrezcan los mismos tres controles. Los fallos de ejecución, las cancelaciones y los errores irrecuperables también necesitan un tratamiento explícito.

Detenerse cuando la tarea esté completa

Define qué significa terminar antes de la primera llamada al modelo. Para un asistente de redacción, podría ser tener un borrador válido con las referencias pertinentes. Para un asistente que ejecuta acciones, quizá también haga falta un comprobante que confirme la escritura.

Distingue entre «el modelo dejó de pedir herramientas» y «la tarea solicitada se completó con éxito». Lo primero es una señal del entorno de ejecución. Lo segundo exige pruebas específicas de la tarea. Un modelo puede detenerse porque no puede continuar; la aplicación debe registrar ese estado como bloqueado o incompleto, en lugar de presentarlo como un trabajo realizado con éxito.

No reinicies el bucle automáticamente cada vez que una respuesta no supere la validación. Cada intento de corrección debe consumir los límites de la misma tarea; de lo contrario, el validador puede convertirse en otra fuente de reintentos interminables.

Detenerse al alcanzar un límite

Establece límites independientes para los pasos, el consumo de recursos y el tiempo transcurrido. Un máximo de pasos acota la repetición. Un presupuesto de tokens o de gasto limita el consumo. Un plazo máximo evita que un modelo o una herramienta lentos mantengan la tarea abierta indefinidamente. Ninguno sustituye a los demás.

Comprueba los límites antes de admitir más trabajo y actualiza el consumo cuando termine. Un contador de llamadas completadas no puede impedir que una petición en curso siga consumiendo recursos. Si la aplicación promete un tope estricto, reserva capacidad para la siguiente operación y contabiliza el trabajo concurrente antes de iniciarla.

Aplica los límites a la tarea de negocio completa, no solo a una invocación del SDK. Un reintento, una reanudación tras una aprobación o un agente secundario no deberían generar una asignación nueva sin que se advierta. Si se justifica más trabajo, amplía la asignación mediante una decisión explícita de la aplicación.

Pausar al agente para la aprobación humana antes de actuar

Un agente de IA con supervisión humana debe detenerse antes de la operación que necesita aprobación. Muestra la acción propuesta, su destino y los argumentos pertinentes. Guarda la llamada pendiente y el estado actual de la tarea; después, espera una decisión explícita.

En el asistente de soporte, la aprobación debe corresponder a una respuesta concreta para un destinatario concreto. Aprobar un borrador no debe convertirse en un permiso general para mensajes posteriores. Si el modelo cambia el destinatario o el contenido después de la aprobación, vuelve a evaluar la acción.

Registra la pausa como awaiting_approval, no como completed. Un rechazo debe conducir a una alternativa definida o a la detención. No debe provocar intentos repetidos de ejecutar la misma operación mediante otra herramienta. La guía de supervisión humana de la IA aborda las colas de aprobación y el escalamiento.

Un bucle mínimo de agente en pseudocódigo

El bucle se mantiene pequeño si las comprobaciones de las reglas de ejecución rodean cada operación. Esto es pseudocódigo, no código ejecutable de un SDK. El máximo de 8 llamadas al modelo es una decisión ilustrativa de la aplicación; elige tus propios límites según la tarea y las trazas observadas.

state = new_job(task, max_model_calls=8, budget, deadline)

while true:
    if limit_reached(state):
        return stop("limit", partial_result=state)

    reserve_capacity_or_stop(state, next_model_call)
    response = call_model_with_deadline(state)
    record_model_call_usage_and_response(state, response)

    if response.is_final and not response.tool_calls:
        return validate_and_finish_or_stop_incomplete(response, state)

    if not response.tool_calls:
        return stop("no_action", partial_result=state)

    for index, call in enumerate(response.tool_calls):
        decision = validate_and_authorize(call, state)
        if decision == "denied":
            return stop("denied", partial_result=state)
        if decision == "needs_human":
            return pause_and_save(state, response.tool_calls[index:])

        reserve_capacity_or_stop(state, call)
        observation = execute_with_timeout_and_retry_cap(call)
        record_tool_usage(state, observation)
        append_matching_tool_result(state, call, bounded(observation))

    if no_progress(state):
        return stop("stalled", partial_result=state)

Los nombres de las funciones auxiliares implican obligaciones importantes. Las reservas deben tener en cuenta el trabajo que ya está en curso. Los reintentos de las herramientas deben estar acotados. Si vence el tiempo de espera de una escritura y se desconoce su resultado, hay que detenerse o verificar el estado de la operación antes de reintentar. Un error fatal del modelo o de una herramienta termina la ejecución y deja registrado el fallo, en lugar de dar paso a otra iteración.

Al guardar una pausa, incluye las llamadas a herramientas que quedan pendientes, los resultados ya obtenidos y la asignación consumida. Al reanudar, continúa ese trabajo guardado y vuelve a comprobar su autorización y sus límites. Reiniciar toda la tarea puede repetir efectos anteriores.

Observa dónde están las comprobaciones: la aprobación precede a la ejecución de la herramienta, el consumo se contabiliza después del trabajo completado y la siguiente iteración no puede empezar solo porque el modelo la haya pedido.

Cómo controla el bucle cada framework

OpenAI Agents SDK, Claude Agent SDK, Vercel AI SDK y LangGraph implementan el bucle de formas distintas. Compara qué unidades cuentan y en qué puntos pueden detenerse antes de comparar los nombres de sus opciones.

Estos nombres proceden de la documentación del bucle de OpenAI, la de Claude, la de Vercel y la Graph API de LangGraph. Cada apartado incluye enlaces sobre el funcionamiento de las aprobaciones.

OpenAI Agents SDK: Runner se encarga de continuar la ejecución

OpenAI Agents SDK es un framework cuyo Runner llama al modelo, ejecuta las herramientas solicitadas, incorpora sus resultados y continúa. Un traspaso cambia el agente activo y mantiene la ejecución. Según la documentación, la finalización normal se produce cuando se obtiene una salida del tipo esperado sin llamadas a herramientas; superar max_turns lanza la excepción MaxTurnsExceeded si no se gestiona. Documentación de ejecución de agentes de OpenAI.

Para un asistente de soporte, esto ofrece un punto claro donde limitar los turnos del modelo. La limitación está en la diferencia entre terminar una ejecución y completar una acción de negocio: configura el contrato de salida y comprueba las pruebas que exige la tarea.

Para las aprobaciones, las herramientas de Python pueden declarar needs_approval; las llamadas pendientes aparecen en interruptions. Guarda el RunState, aplica la aprobación o el rechazo y reanuda. Una ejecución en pausa no es una nueva petición del usuario. Documentación de OpenAI sobre supervisión humana.

El bucle de Claude: limita tanto los turnos como el gasto

Claude Agent SDK incorpora el bucle que utiliza Claude Code, incluidas las herramientas de archivos y comandos. Su opción maxTurns cuenta los turnos de uso de herramientas; maxBudgetUsd fija un umbral de gasto estimado. Si no se configuran, ambos quedan sin límite. En Python se usan max_turns y max_budget_usd. Documentación del bucle del agente de Claude.

Revisa el subtipo del resultado: success, error_max_turns y error_max_budget_usd representan desenlaces distintos. En el modo de una sola ejecución, un resultado de error va seguido de una excepción, así que hay que manejar tanto el resultado como la vía de fallo. Tratamiento de resultados en Claude.

Los permisos requieren el mismo cuidado. allowedTools aprueba automáticamente las herramientas de la lista; dejar una herramienta fuera no la elimina. En el modo de permisos predeterminado, las llamadas que necesitan aprobación y no coinciden con ninguna regla de autorización llegan a canUseTool. Revisa la política completa de permisos antes de usar este SDK para escrituras sin supervisión. Permisos de Claude.

Para contabilizar el consumo que incluye agentes secundarios, Claude distingue entre usage, del bucle principal, y modelUsage, de todo el árbol; en Python, este último es model_usage. Usa el total que corresponda al investigar el consumo de una tarea. Documentación de costos y consumo de Claude.

Para ver la implementación paso a paso, empieza por la guía de Claude Agent SDK del sitio.

Vercel AI SDK: stopWhen controla el siguiente paso

Vercel AI SDK controla la continuación mediante stopWhen. Su documentación actual usa isStepCount para limitar los pasos y permite varias condiciones: la ejecución se detiene cuando se cumple cualquiera de ellas. ToolLoopAgent tiene un valor predeterminado de 20 pasos, mientras que generateText y streamText realizan por defecto una sola generación. El punto de entrada importa. Control del bucle en Vercel, documentación de llamadas a herramientas.

Un paso incluye una generación y las ejecuciones locales de herramientas que le corresponden. Un detalle decisivo: stopWhen se evalúa cuando el último paso contiene resultados de herramientas. No puede deshacer el trabajo de las herramientas que produjo esos resultados. Por eso controla la continuación, pero no autoriza una acción antes de que ocurra. Llamadas de varios pasos en Vercel.

Usa el mecanismo documentado toolApproval para obtener la aprobación explícita del usuario. La documentación actual marca como obsoleta la antigua propiedad de herramienta needsApproval. Aprobación de herramientas en Vercel.

Para gestionar el contexto, prepareStep se ejecuta antes de cada paso y permite modificar mensajes o ajustes. Aprovecha ese punto para proporcionar el estado pertinente, en lugar de arrastrar todos los resultados sin procesar en cada paso. prepareStep de Vercel.

LangGraph y el bucle de agentes de LangChain

LangGraph es un entorno de ejecución de grafos: conecta nodos, que realizan el trabajo, mediante aristas, que determinan qué se ejecuta después. En un bucle de agentes de LangChain construido sobre un grafo, define explícitamente la ruta de regreso al modelo y la ruta hacia END. En Python, recursion_limit limita los superpasos del grafo; los nodos paralelos comparten un mismo superpaso. No es un contador de llamadas a herramientas. Graph API de LangGraph.

Configura recursion_limit en el nivel superior de la configuración de la invocación, no dentro de configurable. Alcanzar el límite genera GraphRecursionError; lo normal es que una ruta de finalización definida termine antes de llegar a esa salida de emergencia. Límite de recursión de LangGraph.

Para la revisión humana, interrupt() pausa el grafo. Usa un mecanismo de puntos de control y un thread_id estable; después, reanuda con Command(resume=...). La limitación que hay que tener presente es que la reanudación reinicia el nodo interrumpido desde el principio. El código anterior a la interrupción puede volver a ejecutarse. Sitúa las operaciones con efectos después de la aprobación o hazlas idempotentes: ejecutarlas de nuevo no debe producir efectos adicionales. Interrupciones de LangGraph.

Elige esta estructura explícita de grafo cuando las bifurcaciones y el estado que permite reanudar sean fundamentales para la tarea. Para un primer asistente de solo lectura con un ciclo sencillo de herramientas, empieza por el entorno de ejecución más pequeño que cumpla tus requisitos.

¿Por qué una ejecución llega a 40 pasos?

Antes de aumentar el límite, averigua qué cambió entre un paso y el siguiente. Una ejecución larga puede estar haciendo trabajo útil, repitiendo fallos o volviendo a empezar sin recordar lo que ya se hizo. La cifra por sí sola no permite distinguirlo.

Bucles infinitos: repetir sin obtener información nueva

Un agente de soporte puede buscar una política, recibir un resultado vacío y repetir la misma búsqueda. La siguiente observación no aporta nada, así que la siguiente decisión puede reproducir la misma acción.

Registra el nombre y los argumentos normalizados de la herramienta, una huella del resultado y un indicador de avance de la tarea. La repetición sin cambios de estado debe activar una comprobación de estancamiento. Las consultas periódicas legítimas también pueden repetirse; dales una política propia con límites, en lugar de tratar cada duplicado como un error.

Cambia algo antes de reintentar: un término de búsqueda, un identificador que falta, una fuente de datos disponible o el alcance de la tarea. Si no hay ningún cambio útil que hacer, informa del requisito que sigue sin resolverse o pide ayuda. «Vuelve a intentarlo» no es, por sí solo, una estrategia de recuperación.

Errores de herramientas: distinguir un fallo recuperable de un resultado desconocido

Un argumento mal formado, un permiso denegado y un fallo transitorio del servicio requieren respuestas distintas. Devuelve un error conciso que permita al modelo actuar. Limita los reintentos recuperables y detén la ejecución de inmediato ante errores que no puedan resolverse con los permisos de la tarea.

El vencimiento del tiempo de espera durante una escritura es más complicado: la escritura puede haberse completado aunque su respuesta nunca haya llegado. Antes de reenviar un mensaje al cliente o crear otro registro, consulta el estado de la operación o usa una clave de idempotencia: un identificador estable que permite al servicio reconocer que se trata de la misma operación.

Conserva el trabajo correcto durante la recuperación. Si se pudo leer la solicitud de soporte, pero falló la consulta de la política, repetir toda la tarea añade trabajo y puede duplicar efectos que ya se produjeron.

Crecimiento del contexto: conservar las decisiones sin arrastrar todos los datos

Cada observación compite con las instrucciones de la tarea y las pruebas anteriores por la atención del modelo en la siguiente llamada. Una respuesta extensa de una herramienta puede ser técnicamente válida y, aun así, dificultar que la siguiente decisión se centre en lo relevante.

Limita las salidas de las herramientas, guarda los archivos y resultados de gran tamaño fuera del prompt y devuelve un resultado compacto con una referencia que permita recuperarlos. Conserva las restricciones aceptadas, las aprobaciones y las acciones confirmadas en el estado persistente de la aplicación. Un resumen puede describir esos registros; no debe convertirse en su única copia.

El SDK de Claude documenta una compactación automática al acercarse al límite de contexto y advierte que las instrucciones iniciales pueden perderse en el resumen. Es una razón para preservar el estado crítico de forma deliberada. Compactación de Claude. La explicación de la degradación del contexto aborda por qué caber en la ventana de contexto no garantiza recordar lo que resulta útil.

Hacer que la traza responda a las preguntas de quien opera el sistema

Para cada tarea, registra su identificador, el número de llamadas al modelo, los intentos de uso de herramientas, el consumo, el tiempo transcurrido, las aprobaciones pendientes y el motivo de parada. Para cada operación, registra qué se solicitó, qué se completó y si cambió el estado de la tarea.

Lleva contadores separados para las peticiones al modelo, las ejecuciones de herramientas y los pasos del entorno de ejecución. Un panel que indique «40 pasos» sin especificar la unidad no explica lo ocurrido. Incluye el trabajo de agentes secundarios y los reintentos en la contabilidad de la tarea principal. La guía de orquestación de agentes de IA explica cómo se asigna la responsabilidad cuando el trabajo pasa de un agente a otro.

¿Qué se exagera sobre los bucles de agentes?

Más iteraciones no demuestran más progreso. Un bucle ofrece oportunidades sucesivas de aprovechar la retroalimentación; que la repetición sirva de algo depende de la calidad de esa información y de cómo se defina el éxito.

Un modelo que dice «listo» ha terminado su parte del intercambio. Un máximo de pasos demuestra que la ejecución tuvo un límite. Ninguna de esas señales prueba que una respuesta de soporte sea correcta ni que se haya realizado el cambio solicitado.

Usar un framework tampoco elimina la necesidad de definir permisos, persistencia y recuperación. El framework aporta los mecanismos de ejecución. La aplicación determina qué significa tener éxito y quién tiene autoridad para actuar.

El bucle de pruebas del agente es una tarea aparte

Un bucle de pruebas evalúa el comportamiento del agente frente a casos y criterios de aceptación. Puede envolver el bucle de ejecución con un verificador que acepte el resultado o envíe comentarios para otro intento. La explicación de LangChain sobre el diseño de bucles distingue entre ejecución, verificación y trabajo activado por eventos.

Pon límites también al verificador. Preguntar repetidamente a otro modelo si una respuesta es buena puede agotar la asignación sin aportar pruebas concluyentes. Siempre que sea posible, usa comprobaciones concretas: que existan los campos obligatorios, que coincidan los registros citados, que haya un comprobante de escritura o que se supere una prueba prevista.

Próximos pasos para quienes desarrollan y operan agentes

Para quienes están creando su primer agente: empieza con una tarea acotada de solo lectura, un contrato explícito de finalización y operaciones con límites. Añade escrituras cuando puedas mostrar la acción propuesta, hacer cumplir la autorización y recuperarte de un resultado ambiguo. Si la secuencia ya se conoce, puede bastar con un flujo fijo.

Para quienes investigan una ejecución costosa: revisa las llamadas repetidas, las cadenas de reintentos y el crecimiento de las observaciones antes de cambiar de modelo o elevar los límites. Identifica qué paso aportó información útil y qué contador detuvo realmente la tarea.

Para equipos con un flujo fijo fiable: consérvalo hasta que la selección adaptativa de herramientas resuelva un problema concreto. Un bucle aporta valor cuando los resultados intermedios determinan la siguiente acción; repetir, por sí solo, no justifica rehacer el sistema.

Una acción concreta para el lunes: toma una tarea representativa y prueba su ruta de finalización, su salida por límite, su pausa de aprobación, una acción denegada y un fallo de herramienta. Confirma que cada caso deja un estado claro y que, al reanudar, se conservan tanto el trabajo completado como la asignación restante.

Preguntas frecuentes sobre el bucle de un agente

Para recibir guías prácticas sobre cómo crear y operar sistemas de IA, suscríbete al boletín.