En un primer momento, usar modelos de lenguaje en software significaba una cosa: enviar un prompt y recibir una respuesta. Con el aumento de la capacidad de razonamiento de los modelos, esa idea se ha quedado corta. Hoy podemos construir sistemas que no solo responden, sino que deciden, actúan y completan tareas completas. A estos sistemas los llamamos agentes.
Este artículo introduce, de forma didáctica, los principios fundamentales para construir agentes bien diseñados, basándose en las ideas expuestas en A Practical Guide to Building Agents de OpenAI. El objetivo no es aprender una librería concreta, sino entender cómo piensa un agente y por qué su diseño es distinto al de una aplicación tradicional.
🧠 ¿Qué es realmente un agente?
Un agente no es un chatbot avanzado ni una automatización con esteroides. La diferencia clave está en quién controla el flujo del trabajo.
En el software clásico, el flujo está codificado de antemano: si ocurre A, ejecutamos B; después C. El modelo de lenguaje, si aparece, suele limitarse a una tarea puntual, como clasificar texto o generar una respuesta.
En un agente ocurre lo contrario. El modelo es quien decide qué paso ejecutar en cada momento: Observa el estado actual, evalúa el contexto, selecciona una acción y comprueba si el objetivo ya se ha alcanzado. Si algo falla, puede corregirse o devolver el control al usuario. Por eso decimos que un agente ejecuta workflows completos de forma autónoma. No se limita a ayudar al usuario, actúa en su nombre.
🧩 ¿Cuándo tiene sentido construir un agente?
Antes de pensar en arquitectura o herramientas, conviene hacerse una pregunta honesta: ¿realmente necesitamos un agente?
Los agentes no sustituyen a las soluciones deterministas, las complementan. Funcionan especialmente bien cuando el problema no se deja capturar fácilmente con reglas fijas. Esto ocurre cuando hay que interpretar lenguaje natural, cuando las excepciones son frecuentes o cuando las decisiones dependen de matices difíciles de formalizar.
Un buen indicador es observar sistemas existentes que han crecido a base de reglas y parches. Cuando el comportamiento empieza a ser difícil de predecir incluso para quienes lo mantienen, suele ser señal de que el problema es más semántico que lógico. Ahí es donde un agente puede aportar valor real.
🏗️ Los fundamentos de un agente bien diseñado
Aunque los agentes puedan parecer sistemas complejos, su estructura básica es sorprendentemente simple. Todo agente se apoya en tres elementos: un modelo, un conjunto de herramientas y unas instrucciones claras.
El modelo es el responsable del razonamiento. No es necesario que sea siempre el más potente disponible, pero sí debe estar alineado con la dificultad de las decisiones que se esperan de él. Una buena práctica consiste en empezar con un modelo capaz y, una vez entendido el comportamiento del sistema, optimizar coste y latencia.
Las herramientas son el puente entre el razonamiento y el mundo real. Permiten al agente consultar información, modificar sistemas externos o incluso delegar tareas en otros agentes. Sin herramientas, el agente puede pensar, pero no puede actuar. Por eso es importante definirlas con cuidado, como si fueran una API pública: con nombres claros, parámetros bien definidos y efectos bien conocidos.
Las instrucciones, por último, son el elemento más infravalorado. En un agente no basta con decir “ayuda al usuario”. Las instrucciones deben describir cómo descomponer una tarea, qué hacer cuando falta información, cómo manejar situaciones inesperadas y cuándo detenerse. Cuanto más explícitas sean, menos ambigüedad tendrá el comportamiento del agente.
🔁 Cómo se ejecuta un agente: la idea del bucle
A diferencia de una llamada puntual a un modelo, un agente vive dentro de un ciclo. Analiza la situación, decide una acción, ejecuta esa acción y vuelve a evaluar el estado resultante. Este bucle se repite hasta que el objetivo se ha cumplido o hasta que ocurre algo que obliga a detener la ejecución.
Este enfoque permite al agente avanzar paso a paso sin necesidad de planificarlo todo desde el principio. Además, encaja bien con una idea importante en sistemas reales: el agente puede avanzar de forma optimista mientras otros mecanismos supervisan su comportamiento y lo detienen si algo va mal.
🧱 Empezar simple: un solo agente
Cuando se empieza a trabajar con agentes, es tentador diseñar sistemas complejos desde el principio, con múltiples agentes especializados. Sin embargo, la experiencia demuestra que esto suele ser contraproducente.
Un único agente, bien instruido y con buenas herramientas, puede cubrir una gran variedad de casos. Además, resulta mucho más fácil de depurar, evaluar y mejorar. Solo cuando las instrucciones se vuelven inmanejables o el agente empieza a equivocarse sistemáticamente al elegir herramientas tiene sentido dividir responsabilidades.
Pensar en agentes como componentes que se separan solo cuando aparece una necesidad real ayuda a mantener el sistema comprensible y evolutivo.
🧑🤝🧑 Sistemas multi-agente: cuándo y por qué
Cuando la complejidad lo exige, se puede pasar a un sistema con varios agentes. Hay dos enfoques habituales:
- En el primero, un agente central actúa como coordinador. Recibe la petición del usuario, decide qué subtareas hay que ejecutar y delega cada una en agentes especializados. El control del flujo sigue estando en un único punto, lo que facilita mantener una visión global.
- En el segundo enfoque, los agentes se transfieren el control entre ellos. Un agente detecta que la tarea no le corresponde y cede la ejecución a otro más adecuado. Este patrón es especialmente útil en sistemas de triage o atención al cliente, donde distintos dominios están claramente separados.
Ambos enfoques son válidos; la elección depende de si se necesita una coordinación central o se prefiere una distribución más orgánica del control.
🛡️ Guardrails: por qué los agentes necesitan límites
Un agente tiene autonomía, y precisamente por eso necesita límites claros. Los guardrails son mecanismos que supervisan su comportamiento para evitar riesgos, desde problemas de seguridad hasta daños reputacionales.
Estos controles pueden actuar sobre lo que entra al sistema, sobre las decisiones internas del agente o sobre las acciones que intenta ejecutar. Algunos se encargan de detectar intentos de manipulación del prompt o peticiones fuera de contexto; otros validan que la salida no incluya información sensible o que una acción tenga un riesgo aceptable.
Un punto importante es que estos controles no bloquean necesariamente la ejecución desde el principio. En muchos sistemas, el agente actúa de forma optimista mientras los guardrails se evalúan en paralelo y solo interrumpen el proceso si detectan una violación. Además, estos guardrails pueden implementarse como funciones independientes o incluso como agentes especializados que evalúan el comportamiento de otros agentes.
🚶♂️ Un ejemplo real: construir un agente de atención de pedidos
Para aterrizar todos los conceptos anteriores, vamos a recorrer de forma incremental el diseño de un agente realista de atención de pedidos para una tienda online. El objetivo no es implementar un sistema completo, sino mostrar cómo se estructura un agente, cómo controla el flujo de ejecución y cómo interactúa con herramientas y guardrails.
Antes de entrar en el detalle, el diagrama anterior resume el comportamiento general del agente. En él puede verse cómo el modelo de lenguaje actúa como orquestador del flujo, decide qué información necesita, selecciona herramientas en función del contexto y pasa por una capa de guardrails antes de ejecutar acciones o responder al usuario. A continuación, iremos recorriendo este flujo paso a paso. El código que se muestra es pseudocódigo, deliberadamente independiente de cualquier SDK o framework, y sirve únicamente para ilustrar cómo se materializan estos conceptos en un sistema técnico real.
Paso 1: Sistema reactivo sin control de flujo
El primer sistema que solemos construir es puramente reactivo. El usuario proporciona un identificador de pedido, el backend consulta la base de datos y devuelve el estado. No hay razonamiento, ni memoria de contexto, ni decisiones intermedias. El sistema asume que la entrada es correcta y que la consulta es válida.
function handleRequest(orderId):
order = OrdersDB.get(orderId)
return formatResponse(order.status)
Este enfoque es útil para casos simples, pero no gestiona excepciones ni workflows. Aunque pueda usar un modelo para generar texto, no es un agente.
Paso 2: Introducción del modelo como controlador del workflow
El siguiente paso consiste en introducir un modelo de lenguaje que controle la interacción. El sistema deja de asumir que la información está completa y pasa a razonar sobre el estado de la conversación.
Ahora el agente recibe una pregunta abierta, evalúa si dispone de los datos necesarios y decide el siguiente paso. Si falta información, la solicita explícitamente antes de continuar.
decision = model.reason(context)
if decision.action == "ASK_FOR_ORDER_ID":
sendMessage("¿Puedes indicarme tu número de pedido?")
Aquí aparece por primera vez una idea clave: el modelo decide qué hacer a continuación, no el código de forma rígida.
Paso 3: Ejecución en bucle y gestión del estado de la interacción
A diferencia de una llamada puntual, el agente opera dentro de un bucle. Tras cada acción, vuelve a evaluar el estado actualizado y decide si debe continuar o finalizar.
while not finished:
decision = model.reason(context)
if decision.action == "FETCH_ORDER":
context.order = OrdersDB.get(context.orderId)
if decision.action == "RESPOND":
sendMessage(decision.response)
finished = true
Este bucle es el núcleo del agente. Permite avanzar paso a paso, corregir errores y manejar interacciones largas sin necesidad de definir todo el flujo por adelantado.
Paso 4: Selección dinámica de herramientas según la intención
A medida que ampliamos el alcance, el agente deja de limitarse a una única acción. Como parte de su razonamiento, identifica la intención del usuario: consulta de estado, solicitud de devolución o incidencia en la entrega.
Cada intención activa herramientas distintas, con efectos y riesgos diferentes.
decision = model.reason(context)
switch decision.intent:
case "ORDER_STATUS":
result = getOrderStatus(context.orderId)
case "RETURN_REQUEST":
result = initiateReturn(context.orderId)
case "DELIVERY_ISSUE":
result = openIncident(context.orderId)
El flujo ya no está codificado como una secuencia fija. Emerge de las decisiones del agente a partir del contexto y de los resultados de las herramientas.
Paso 5: Incorporación de guardrails y evaluación de riesgo
Cuando el sistema se acerca a un entorno de producción, aparecen nuevas preocupaciones técnicas. No todas las herramientas son iguales: algunas solo leen datos, otras modifican estado o tienen impacto económico.
Para gestionar estos riesgos, se incorporan guardrails que supervisan las decisiones del agente antes de ejecutarlas.
decision = model.reason(context)
if guardrail.isAllowed(decision):
execute(decision)
else:
escalateToHuman(context)
finished = trueEstos controles pueden evaluar relevancia, seguridad, riesgo de la acción o cumplimiento de políticas. Importante: el agente puede avanzar de forma optimista mientras los guardrails se evalúan en paralelo y solo interrumpen el flujo si detectan una violación.
Paso 6: Límites operativos e intervención humana
Finalmente, se definen límites claros para evitar bucles infinitos o comportamientos erráticos. Si el agente supera un número máximo de intentos o intenta ejecutar una acción de alto riesgo, el control se transfiere a una persona.
if attempts > MAX_ATTEMPTS or decision.risk == "HIGH":
escalateToHuman(context)
finished = trueEste mecanismo no es un fallo del agente, sino una parte esencial de su diseño. Permite desplegar sistemas autónomos de forma progresiva sin comprometer la seguridad ni la experiencia del usuario.
Construir agentes no consiste en añadir inteligencia artificial a un sistema existente, sino en cambiar la forma en que el software toma decisiones. Los agentes realmente efectivos se apoyan en una arquitectura sólida, evolucionan de forma progresiva y se despliegan con mecanismos de control, supervisión y mejora continua. Cuando estos principios se aplican correctamente, la automatización deja de ser puntual y pasa a convertirse en workflows completos, fiables y alineados con los objetivos del negocio.
En SOLUCIONEX ayudamos a las organizaciones a diseñar e implantar este tipo de soluciones de automatización inteligente e IA aplicada, integradas con sus sistemas actuales y pensadas para escalar con seguridad. Si estás valorando cómo dar este paso en tu organización, hablemos.
