Un agente de IA empresarial no es un modelo de lenguaje con un prompt largo. Es un bucle cerrado: el modelo recibe un objetivo, elige una accion, llama a una herramienta externa, lee el resultado y decide el siguiente paso, hasta que el objetivo se cumple, hasta que se atasca o hasta que se agota el presupuesto de pasos. Bajo el capo solo hay cuatro componentes: modelo, herramientas, memoria y control. En la encuesta de McKinsey de noviembre de 2025 (1.993 encuestados en unos 105 paises) cerca del 62% de las organizaciones experimentaba con agentes pero solo alrededor del 23% los habia escalado, y Gartner preve que mas del 40% de los proyectos de IA agentica se cancelaran antes del final de 2027. Esa brecha casi nunca esta en el modelo.
Que separa realmente a un agente de un chatbot
La diferencia no es la calidad de la respuesta. Es quien decide el orden de las operaciones. En un chatbot decide la persona: pregunta, recibe texto y decide que hacer con el. En la automatizacion clasica decide el desarrollador de antemano: el proceso se escribe como un diagrama de flujo y cada rama se definio en tiempo de construccion. En un agente esa decision se mueve al tiempo de ejecucion: el modelo elige que herramienta llamar, en que orden y cuando parar.
Esta es la unica diferencia que importa, y es tambien el origen de todos los riesgos. Una vez que el orden de las operaciones no esta fijado de antemano, no puedes probar el sistema como pruebas el software ordinario, ni puedes confiar en que la ejecucion exitosa de ayer siga hoy el mismo camino.
| Propiedad | Chatbot | Automatizacion clasica | Agente |
|---|---|---|---|
| Quien fija el orden de las operaciones | El usuario | El desarrollador, al construirlo | El modelo, en tiempo de ejecucion |
| Acceso a sistemas | Normalmente ninguno | Fijo y predefinido | Dinamico, a traves de una capa de herramientas |
| Comportamiento ante un fallo | Devuelve una respuesta erronea | Se detiene y reporta un error | Continua y agrava el error |
| Que se prueba antes de lanzar | Calidad de la redaccion | Caminos conocidos | Distribucion de resultados en muchas ejecuciones |
El bucle de ejecucion: planificar, actuar, observar
Independientemente del proveedor, el lenguaje o el framework, todo agente ejecuta el mismo bucle. El modelo recibe el objetivo y el estado actual del mundo, produce una decision sobre el siguiente paso, emite una llamada a una herramienta externa, recibe un resultado, y despues se ejecuta de nuevo a si mismo con ese resultado como parte de su contexto. El bucle termina cuando el modelo declara que ha terminado, cuando una herramienta devuelve un error bloqueante, o cuando un mecanismo externo lo corta.
La palabra importante aqui es observar. El agente no sabe nada del mundo salvo lo que las herramientas le devuelven como texto. Si el CRM devuelve un campo vacio, entonces para el agente el cliente realmente no tiene numero de telefono. La calidad de la observacion es, por tanto, una variable de ingenieria de primer orden, no un detalle tecnico.
| Etapa del bucle | Que ocurre realmente | Modo de fallo tipico |
|---|---|---|
| Recepcion del objetivo | El objetivo pasa a ser contexto inicial junto a las instrucciones del sistema | Un objetivo vago que produce un camino distinto en cada ejecucion |
| Planificacion del paso | El modelo selecciona una herramienta y sus argumentos | Herramienta correcta, argumento equivocado: el fallo mas comun de todos |
| Ejecucion | La capa de herramientas ejecuta la llamada contra el sistema real | Un permiso demasiado amplio que permite una accion destructiva |
| Observacion | El resultado vuelve al contexto | Una carga util larga que expulsa informacion critica anterior |
| Decision | Continuar o parar | Un bucle infinito que consume presupuesto hasta el techo |
Los cuatro componentes de los que esta hecho todo agente
Desarma un agente y obtienes cuatro componentes. Tres de ellos no son el modelo, y ahi es donde vive la mayor parte del trabajo de ingenieria y casi todos los fallos.
| Componente | Su funcion | Que se rompe cuando es debil |
|---|---|---|
| Modelo | Produce la decision sobre el siguiente paso | Redaccion elegante con razonamiento defectuoso; mejorar el modelo no arregla los otros componentes |
| Herramientas | La unica interfaz del agente con la realidad | Una descripcion imprecisa lleva a un mal uso incluso con un modelo excelente |
| Memoria y contexto | Lo que el agente sabe en el momento de decidir | Informacion critica expulsada, o contexto contaminado que arrastra al agente por el camino equivocado |
| Control | Limites, permisos, presupuesto de pasos y puntos de aprobacion | Ninguna forma de detener un error antes de que toque a un cliente o a un sistema |
En los proyectos que vemos, la primera reaccion cuando algo no funciona es casi siempre cambiar el modelo. En la mayoria de los casos ese no es el problema. Descripciones de herramientas precisas, salida estructurada en lugar de texto libre y una condicion de parada clara mejoran la tasa de exito mas que cualquier mejora de modelo.
La capa de herramientas: que cambio realmente MCP
Hasta hace poco, cada conexion entre un modelo y un sistema empresarial se escribia desde cero: una integracion a medida por cada combinacion de modelo y sistema. Model Context Protocol lo reemplazo por una capa uniforme: un servidor que declara herramientas y un cliente que las llama.
La revision estable de la especificacion, con fecha del 28 de julio de 2026, es la mayor revision del protocolo desde su lanzamiento. Se eliminaron las sesiones a nivel de protocolo y la cabecera Mcp-Session-Id del transporte Streamable HTTP; se elimino el handshake de inicializacion; y las listas de herramientas, recursos y prompts ya no varian por conexion, lo que las hace cacheables. Junto a eso llegaron las solicitudes de multiples idas y vueltas, el enrutamiento por cabeceras, un marco formal de extensiones y una autorizacion reforzada. Un servidor que necesita estado entre llamadas lo recibe ahora mediante un identificador explicito emitido por el servidor y pasado como un argumento de herramienta ordinario.
Por que esto importa a quien no escribe codigo: un protocolo sin estado se puede desplegar detras de un balanceador de carga estandar, escalar horizontalmente y monitorizar con herramientas ordinarias. Dicho de otro modo, la capa de herramientas dejo de ser un proyecto de investigacion y paso a ser infraestructura que puedes presupuestar, operar y auditar.
El contexto es un presupuesto, no un almacen
El error de diseno mas comun es tratar la ventana de contexto como almacenamiento. No lo es. Es un presupuesto que se consume en cada paso, y que pagas de nuevo en cada llamada. Un agente que ejecuta veinte pasos paga veinte veces por su propio historial.
De ahi se derivan tres decisiones de diseno. Devolver salida estructurada y compacta desde las herramientas en lugar de documentos enteros. Comprimir el historial en un resumen de estado despues de un numero fijo de pasos. Recuperar el conocimiento corporativo en tiempo de ejecucion en lugar de precargarlo.
Donde se rompe esto en la practica
Errores que se acumulan. En un bucle, un error en el paso tres no se queda en el paso tres. Entra en el contexto y desde ahi alimenta cada decision posterior. El fallo visible aparece, por tanto, lejos de donde se creo, y por eso depurar un agente exige rastrear una ejecucion completa en lugar de inspeccionar una sola respuesta.
Medicion optimista. La metrica de exito habitual pregunta si el agente lo consiguio una vez en condiciones favorables. En produccion lo que cuenta es la estabilidad: la misma tarea, cien ejecuciones, cuantas terminaron correctamente. La distancia entre esos dos numeros es la distancia entre una demo impresionante y un sistema en el que puedes confiar.
Lavado de agentes. Gartner estima que de los miles de proveedores que comercializan capacidad agentica, solo unos 130 ofrecen algo real; el resto esta reetiquetando asistentes existentes, RPA y chatbots. La pregunta que filtra mas rapido en una reunion comercial: que herramientas puede invocar este agente, y quien decide cuando las invoca.
La misma nota de Gartner contiene la otra cara de la historia: para 2028, alrededor del 15% de las decisiones de trabajo cotidianas se tomaran de forma autonoma y el 33% de las aplicaciones de software empresarial incluiran capacidad agentica, frente a menos del 1% en 2024. La direccion es clara; lo que se rompe son los plazos y las expectativas.
Una lista de comprobacion antes de tu primer agente
Define una tarea que termine. Una tarea con una condicion de finalizacion inequivoca, no un area de responsabilidad abierta.
Cuenta las herramientas. Si un primer agente tiene mas de diez herramientas, probablemente has mapeado un puesto de trabajo y no una tarea.
Escribe las descripciones de herramientas como contratos. Que entra, que sale, que pasa cuando falla y cuando no se debe usar la herramienta.
Fija un presupuesto de pasos y de tokens. Un techo duro que detenga el bucle incluso cuando el modelo esta convencido de que va por buen camino.
Marca las acciones irreversibles. Enviar un correo, cobrar, borrar, actualizar un estado visible para el cliente: todas necesitan un punto de aprobacion humana.
Define los permisos antes de escribir un prompt. El modelo de permisos es lo que limita el dano, no la redaccion de las instrucciones.
Registra cada ejecucion. Sin un registro completo de llamadas y resultados no hay depuracion ni mejora.
Preguntas frecuentes
Cual es la diferencia entre un agente de IA y la automatizacion ordinaria?
En la automatizacion el orden de las operaciones lo fija de antemano un desarrollador. En un agente el modelo elige sus acciones en tiempo de ejecucion segun el objetivo y lo que observa. La automatizacion se prueba por caminos conocidos, mientras que un agente se prueba por la distribucion de resultados en ejecuciones repetidas.
Necesito un modelo especialmente potente para construir un agente?
En la mayoria de los casos no. La tasa de exito la determinan mas la calidad de las descripciones de herramientas, la gestion del contexto y las condiciones de parada que la eleccion del modelo. Un modelo mas potente oculta los problemas de diseno durante un tiempo, pero tambien encarece cada paso del bucle.
Que es MCP y por que todo el mundo habla de ello?
Model Context Protocol es un protocolo uniforme para conectar modelos con herramientas y fuentes de datos. La revision estable del 28 de julio de 2026 lo dejo sin estado: se acabaron las sesiones a nivel de protocolo, las listas de herramientas son cacheables y la autorizacion esta reforzada. En la practica esto permite desplegar una capa de herramientas como infraestructura ordinaria en lugar de como un proyecto puntual.
Cuanto se tarda en llevar un primer agente a produccion?
Una sola tarea con tres a cinco herramientas y un punto de aprobacion humana suele llegar a produccion en cuatro a ocho semanas. La mayor parte de ese tiempo no se va en construir el bucle, sino en una integracion limpia con los sistemas, el diseno de permisos y la construccion del conjunto de pruebas.
Cual es la senal de que un agente no encaja con una tarea?
Si puedes escribir el proceso como un diagrama de flujo completo sin decisiones ambiguas, no necesitas un agente: la automatizacion sera mas barata, mas rapida y comprobable. Un agente compensa cuando el espacio de posibilidades es demasiado amplio para escribirlo por adelantado.