¿Cómo funciona un agente de IA?

Un agente de IA funciona repitiendo un bucle: percibe el estado del caso, razona sobre qué hacer, ejecuta una acción sobre un sistema real y observa el resultado para decidir el siguiente paso. Da esa vuelta tantas veces como haga falta hasta cerrar el trabajo o toparse con un límite que le obligue a llamar a una persona. Todo lo demás es detalle de esa mecánica.

Voy a explicarla sin tecnicismos gratuitos, porque a un directivo no le hace falta saber de redes neuronales para decidir con criterio sobre un agente. Le hace falta entender cómo decide, por qué a veces se equivoca y cómo se contiene ese error. Si antes quieres la definición y los componentes, están en qué es un agente de IA, y el nivel de negocio, en agentes de IA para empresas.

El bucle: percibir, razonar, actuar, observar

Un agente no resuelve un caso de un tirón. Lo resuelve en pasos, y en cada paso repite cuatro momentos.

Percibe. Recoge el estado actual: el caso que le ha llegado, lo que ya ha hecho hasta ahora, la información que tiene delante. Es su foto del momento.

Razona. El modelo interpreta esa foto y decide qué conviene hacer a continuación: consultar un dato, aplicar una regla, escribir un resultado, o parar y escalar. Aquí es donde el agente elige, y por eso maneja casos que nadie programó uno a uno.

Actúa. Ejecuta la acción elegida sobre un sistema real. No “piensa en” consultar el ERP: lo consulta. Esta es la parte que separa un agente de un asistente que solo habla.

Observa. Mira el resultado de su acción —el dato que ha vuelto, el error que ha saltado— y eso alimenta la siguiente percepción. Si el resultado no es el esperado, ajusta. Si le acerca al objetivo, sigue.

Vuelta tras vuelta, el agente encadena estos cuatro momentos hasta cerrar el caso. Un ejemplo: para responder al estado de un pedido, percibe la pregunta, razona que necesita el número de pedido, lo pide o lo extrae, consulta el sistema logístico, observa la fecha de entrega y redacta la respuesta. Cuatro momentos, varias vueltas, un resultado.

Cómo usa herramientas para actuar

El razonamiento por sí solo no cambia nada en tu empresa. Lo que convierte una decisión en un efecto es el uso de herramientas —lo que en el argot se llama tool use—: el agente tiene a su disposición un conjunto de acciones concretas que puede invocar, cada una conectada a uno de tus sistemas.

Funciona así: el modelo, al razonar, no solo produce texto, sino que puede emitir una llamada a una herramienta —“consulta el pedido número X”—. El sistema ejecuta esa llamada contra el ERP de verdad, recoge la respuesta y se la devuelve al modelo, que la incorpora a su siguiente vuelta de razonamiento. El modelo decide qué herramienta usar y con qué datos, y la herramienta hace el trabajo real y acota lo que el agente puede tocar.

Esa capa de herramientas es también donde vive la seguridad: cada una lleva permisos explícitos de qué puede leer y qué puede escribir. La estandarización de esta conexión mediante un protocolo común para enlazar agentes con sistemas y datos la explico en MCP, el Model Context Protocol. Y el detalle de cómo se limita cada acción, en permisos y controles de agentes.

Por qué a veces se equivoca

Aquí está la parte que ningún vendedor te va a subrayar y que yo pongo siempre encima de la mesa: un agente es probabilístico, no determinista. El modelo que razona no ejecuta una fórmula con una única salida correcta, sino que genera la continuación más plausible dado lo que ha visto. La mayoría de las veces esa continuación es acertada. Algunas veces no lo es, y no falla como falla un programa clásico —con un error que salta— sino produciendo algo que parece razonable y no lo es.

De dónde salen esos fallos, en la práctica:

• Ambigüedad del caso. Si la entrada admite dos lecturas, el agente elige una, y no siempre la que tú querías.
• Contexto incompleto. Si le falta un dato o una regla que estaba en la cabeza de alguien y nunca se escribió, rellena el hueco con una suposición.
• Afirmaciones inventadas. Un modelo puede producir un dato con total aplomo aunque no tenga base. Por eso un agente serio consulta la fuente en lugar de fiarse de lo que “recuerda”.
• Encadenado de pasos. En un bucle largo, un pequeño desvío en un paso temprano se arrastra y se amplifica en los siguientes.

Nada de esto es un defecto que se “arregle” con un modelo mejor. Es la naturaleza de la herramienta, y trabajar con ella con cabeza significa diseñar el sistema para contener el error, no para negarlo.

Cómo se contiene ese error

Que un agente pueda equivocarse no lo hace inservible, sino un sistema que necesita frenos. Un motor de coche también puede fallar y por eso lleva frenos, testigos y revisiones. Con los agentes es igual, y los frenos son tres.

Evaluaciones. Antes de dar trabajo real a un agente se mide cómo lo hace: casos de prueba con respuesta conocida, umbrales de calidad y revisión sistemática de los fallos. Es la diferencia entre “parece que funciona” y “funciona en el 98% de estos casos y estos son los que falla”. Cómo se montan y qué se mide está en evaluación de agentes de IA. Y las evaluaciones no son un examen de arranque: se repiten cada vez que cambia el modelo o el proceso, porque cualquier cambio puede degradar algo que antes iba bien.

Escalado a humanos. Los casos por encima de un umbral —importe alto, duda del agente, situación no prevista— se derivan a una persona con el contexto ya preparado. Dónde se pone ese umbral es una decisión de negocio, y de las que más gobiernan el riesgo real del sistema.

Trazabilidad. Cada vuelta del bucle queda registrada: qué percibió, qué razonó, qué herramienta invocó, qué resultado obtuvo. Sin traza no puedes depurar un fallo ni defender una decisión ante un auditor. Es lo que convierte “el sistema se equivocó” en “el sistema aplicó esta regla con estos datos, aquí está el rastro”.

Con estos tres frenos, el carácter probabilístico deja de ser un problema y pasa a ser una propiedad que se mide y se gobierna. Es exactamente por saltarse este diseño por lo que tantos pilotos lucen en una demo y mueren en producción, un patrón que analizo en por qué fracasan los pilotos de IA.

El sistema completo

El bucle, las herramientas y los frenos son las piezas móviles, pero encajan en una arquitectura mayor —orquestación, memoria, observabilidad, controles— que da la vista de conjunto. Esa vista está en arquitectura de agentes de IA. Y si de entender cómo funciona quieres pasar a saber cómo se construye uno que aguante producción, sigue por cómo se construye un agente de IA.

Preguntas frecuentes

¿Cómo funciona un agente de IA en términos simples?

Da vueltas a un bucle: mira el estado del caso, decide qué hacer, lo hace sobre un sistema real y observa el resultado para decidir el siguiente paso. Repite hasta cerrar el trabajo o hasta topar con un límite que le obliga a pasar el caso a una persona.

¿Qué es el uso de herramientas o tool use en un agente?

Es la capacidad del agente de invocar acciones concretas sobre tus sistemas —consultar el ERP, escribir en el CRM, leer un correo— en lugar de limitarse a generar texto. El modelo decide qué herramienta usar y con qué datos, y cada herramienta lleva permisos que acotan lo que puede tocar.

¿Por qué un agente de IA a veces se equivoca?

Porque el modelo que razona es probabilístico: genera la respuesta más plausible, no una única salida garantizada. Ante ambigüedad, contexto incompleto o cadenas largas de pasos puede acertar la mayoría de veces y fallar en algunas, a veces con un resultado que parece correcto y no lo es.

¿Se puede confiar en un agente si puede equivocarse?

Sí, si el sistema está diseñado para contener el error: evaluaciones que miden su calidad antes y durante la operación, escalado a una persona en los casos de riesgo y traza de cada decisión. No se confía en que el modelo “sea muy bueno”, sino en los frenos que rodean al modelo.