Artículo · Fundamentos de IA agéntica
Qué es un agente de IA: definición, componentes y qué no lo es
Un agente de IA es software que recibe un objetivo, decide por sí mismo la secuencia de pasos para cumplirlo y los ejecuta sobre sistemas reales, escalando a una persona cuando el caso excede lo que se le ha autorizado a hacer. Esa es la definición corta y la que uso ante un comité. La larga necesita separar dos cosas que el mercado confunde a propósito: lo que un agente es por dentro y lo que un agente no es aunque se le parezca en la pantalla.
Esta página desarrolla la anatomía. Si buscas la mecánica paso a paso —cómo razona y decide en cada vuelta—, la explico aparte en cómo funciona un agente de IA. Y si vienes del nivel de negocio, el punto de entrada al tema completo es agentes de IA para empresas.
La definición, pieza a pieza
Descompongamos la frase de arriba, porque cada palabra hace trabajo.
Recibe un objetivo. No una orden literal ni un guion. Le dices qué quieres conseguido —“concilia estas facturas con sus pedidos”—, no cómo teclear cada paso. Esa es la primera diferencia con el software clásico, que necesita que le detalles el procedimiento.
Decide la secuencia de pasos. El agente interpreta el caso concreto y elige qué hacer a continuación: qué sistema consultar, qué regla aplicar, si le falta un dato. Distintos casos producen distintas secuencias, y ahí está su valor. Maneja la excepción sin que nadie la haya previsto una por una.
Los ejecuta sobre sistemas reales. No responde en un chat: entra en tu ERP, lee tu correo, escribe en tu CRM, genera un asiento. Actúa. Sin esta parte tienes un asistente que sugiere, no un agente que trabaja.
Escala cuando excede su mandato. Un agente serio conoce sus límites. El caso raro, el importe alto o la duda por encima de un umbral van a una persona con el contexto preparado. La autonomía sin este freno no es una virtud, es un riesgo.
Los cinco componentes de un agente
Cuando abro un agente por dentro para explicárselo a un directivo, encuentro siempre las mismas cinco piezas. Ninguna es opcional en algo que vaya a operar de verdad.
| Componente | Qué aporta |
|---|---|
| Modelo | El motor de razonamiento: interpreta el caso y decide el siguiente paso |
| Instrucciones | Las reglas, el objetivo y los límites de tu operación, por escrito |
| Herramientas | Las acciones concretas sobre tus sistemas, cada una con permisos explícitos |
| Memoria y contexto | Lo que el agente sabe del caso y de tu empresa mientras trabaja |
| Controles | Dónde para, qué escala y qué queda registrado de cada decisión |
El modelo es un LLM —los de Anthropic, OpenAI o Google como categoría— que razona sobre el caso. Es la pieza más fácil de sustituir y la que menos define tu sistema. Se trata como una utility que se elige por tarea y se cambia sin rehacer el proceso.
Las instrucciones son la parte que sí es tuya. Un modelo genérico no conoce tus reglas de negocio, tus excepciones ni tus criterios. Codificar eso —qué es un caso válido, qué se hace con una desviación, cuándo se para— es el trabajo específico que convierte un modelo listo en un agente que ejecuta tu operación. Sobre cómo se codifica esa definición he escrito en el modelo operativo como código.
Las herramientas son las funciones que el agente puede invocar para actuar: consultar el stock, emitir la factura, leer el buzón. Cada una con permisos concretos de qué puede leer y qué puede escribir. Un agente es tan capaz como las herramientas que le has dado y tan seguro como los límites de esas herramientas.
La memoria y el contexto son lo que el agente arrastra: el estado del caso, lo decidido hasta ahora, el conocimiento de tu empresa que necesita para no responder en el vacío. Sin memoria, cada paso empieza de cero y el agente se pierde en cuanto el caso tiene más de dos movimientos.
Los controles son los puntos donde una persona revisa o decide, los umbrales de escalado y la traza que registra qué recibió el agente, qué regla aplicó y qué hizo. Es la pieza que un comité mira antes de aprobar nada, y la que trato como innegociable en gobernanza de agentes.
Estas cinco piezas encajan en una arquitectura más amplia cuando el sistema crece —orquestación, evaluaciones, observabilidad—, que desgloso en arquitectura de agentes de IA. Para entender qué es un agente basta con las cinco.
Qué NO es un agente de IA
La confusión más cara del mercado es llamar “agente” a cosas que no lo son. Dos en concreto.
Un chat no es un agente. Un asistente conversacional recibe una pregunta y devuelve texto. Por muy bueno que sea el texto, ahí termina: no entra en tus sistemas, no ejecuta nada, no deja resultado más allá de la respuesta en pantalla. Es una herramienta que usa una persona, y la persona sigue haciendo el trabajo. Útil, pero otra categoría. La diferencia exacta la desarrollo en la comparación entre asistir y ejecutar. Aquí basta con la frase: un chat responde, un agente actúa.
Un script no es un agente. Un flujo automatizado —una macro, una automatización de pasos grabados, un robot de RPA— ejecuta una secuencia fija que alguien programó de antemano. Funciona mientras el caso coincida con el guion, y falla, o hace algo peor que fallar, en cuanto aparece la excepción. No interpreta: repite. Un agente ocupa justo el hueco entre el chat y el script: ejecuta de verdad, como el script, pero decide según el caso, como no puede hacer el script.
La prueba práctica que uso: si el sistema no toca ningún sistema real, es un chat, no un agente. Si toca sistemas pero se rompe con el primer caso que no estaba en el guion, es un script, no un agente. Un agente actúa y decide.
Un ejemplo operativo
Imagina una distribuidora que recibe cada día decenas de facturas de proveedor. El trabajo es conciliarlas con su pedido y su albarán, aprobar las que cuadran y apartar las que no.
Un agente para esto recibe el objetivo (“concilia estas facturas”), lee cada documento (herramienta de lectura), consulta el pedido y el albarán en el ERP (herramientas de consulta), aplica la regla de tolerancia que le has fijado (instrucciones), aprueba las que cuadran dentro del margen (herramienta de escritura, con permiso acotado), y aparta con una nota las que no —proveedor nuevo, importe fuera de rango, albarán que no aparece— para que una persona las mire (control y escalado). Cada decisión queda registrada (traza).
Un chat solo te habría explicado cómo conciliar. Un script habría aprobado todo lo que encajara con su patrón exacto y se habría atascado en la primera factura rara. El agente hace el trabajo y sabe cuándo no debe hacerlo solo.
De la definición a la operación
Entender qué es un agente es el primer paso. El siguiente es saber qué trabajo de tu empresa puede ejecutar con garantías y cómo se construye eso sin quedarte con un prototipo bonito que nunca llega a producción. Lo primero lo cubre el pilar de agentes para empresas, y lo segundo, con criterio de operador, está en cómo se construye un agente de IA. Y si lo que quieres es la mecánica interna —por qué a veces acierta y a veces no—, sigue por cómo funciona un agente de IA.
Preguntas frecuentes
¿Qué es un agente de IA en palabras sencillas?
Software al que le dices qué resultado quieres, no cómo lograrlo, y él decide los pasos y los ejecuta sobre tus sistemas: lee, consulta, aplica una regla, escribe y escala a una persona cuando duda. La clave está en que actúa y decide, no solo responde.
¿Cuál es la diferencia entre un agente de IA y un chatbot?
Un chatbot conversa: recibe una pregunta y devuelve texto, y ahí acaba su trabajo. Un agente ejecuta: entra en tus sistemas y produce un resultado real. El chatbot es una herramienta que usa una persona, y el agente hace el trabajo dentro de límites que tú le has puesto.
¿Qué componentes necesita un agente de IA para funcionar?
Cinco: un modelo que razona, instrucciones con tus reglas y límites, herramientas para actuar sobre tus sistemas, memoria y contexto para no empezar de cero en cada paso, y controles que fijan dónde para, qué escala y qué queda registrado. Sin cualquiera de ellas no tienes un agente que se pueda operar en serio.
¿Un flujo de automatización o un robot de RPA es un agente de IA?
No. Un flujo automatizado repite una secuencia fija que alguien programó y se rompe cuando el caso se sale del guion. Un agente interpreta el caso concreto y decide qué hacer, incluso ante situaciones que nadie previó una por una. La automatización clásica no interpreta, solo ejecuta lo grabado.