Qué es un agente de IA y en qué se diferencia de un chatbot

«Agente de IA» se ha convertido en la etiqueta que todo producto se pone encima desde que dejó de bastar con decir «con inteligencia artificial». Se la ponen chatbots de atención al cliente que llevan seis años funcionando igual, y se la ponen sistemas que de verdad hacen cosas. Conviene saber distinguirlos, porque el valor y el riesgo son completamente distintos. Si lo que tienes delante es justo esa decisión —un asistente que responde frente a uno que además ejecuta—, los números y el plan de implantación están en montar un chatbot de atención al cliente.

La diferencia no está en el modelo. Detrás de un chatbot decente y de un agente serio puede haber exactamente el mismo modelo de lenguaje. Está en otra cosa.

Qué es un agente de IA

Un agente de IA es un sistema que recibe un objetivo —no una pregunta— y trabaja hasta cumplirlo: decide qué pasos dar, ejecuta acciones sobre herramientas reales, mira el resultado y corrige el rumbo si hace falta.

Las tres palabras que importan de esa definición:

• Objetivo. «Revisa los tickets sin responder de esta semana y contesta los que sean dudas de facturación» es un objetivo. «¿Cómo respondo a un cliente enfadado?» es una pregunta.
• Herramientas. El agente puede leer un archivo, consultar una base de datos, llamar a una API, ejecutar un comando. Sin herramientas solo puede generar texto, y entonces no es un agente.
• Iteración. Encadena pasos por su cuenta. Si el primer intento falla, lo ve y prueba otra cosa, sin que tú tengas que escribir el siguiente mensaje.

Chatbot, asistente y agente: las diferencias

Esa última fila es la que no aparece en las presentaciones de producto y la que más debería pesar en la decisión. Un chatbot que se inventa una respuesta te hace perder cinco minutos. Un agente que se la inventa con permisos de escritura manda cuarenta correos equivocados.

El bucle que hace que un agente sea un agente

Por dentro casi todos los agentes hacen lo mismo, repetido:

1. Observar. Lee el objetivo y el estado actual: los archivos, la respuesta de la última llamada, el error que acaba de salir.
2. Decidir. El modelo elige la siguiente acción entre las herramientas disponibles, o decide que ya ha terminado.
3. Actuar. Esa herramienta se ejecuta de verdad.
4. Incorporar el resultado. Lo que devuelva —incluido el fallo— entra en el contexto y arranca la siguiente vuelta.

De este bucle salen dos consecuencias que explican casi todos los comportamientos raros que verás.

El contexto se llena. Cada vuelta añade texto. En tareas largas el agente empieza a olvidar el principio o a repetir pasos que ya había hecho. Por eso funcionan mejor las tareas acotadas: quince pasos, no doscientos.

Los errores se acumulan. Si en el paso tres interpreta mal un dato, los pasos cuatro a diez trabajan sobre esa interpretación. Nadie comprueba a mitad de camino salvo que tú lo pongas.

Qué necesita un agente para servir de algo

Tres piezas, y las tres se descuidan por igual.

Herramientas con buena descripción. El agente elige entre ellas leyendo su descripción, igual que decide cargar un skill leyendo la suya. Una herramienta llamada consultar_datos con la descripción «consulta datos» se usará mal o no se usará. El estándar que se ha impuesto para conectar herramientas externas es MCP, y ahí la calidad de las descripciones es la mitad del trabajo.

Instrucciones sobre el criterio, no solo sobre el formato. «Contesta los tickets de facturación» deja fuera lo importante: qué hacer si el cliente pide un reembolso, cuándo escalar a una persona, qué tono usar con una cuenta que lleva dos años con nosotros. Eso es justo lo que resuelve un skill: un procedimiento fijo que el agente carga cuando toca.

Un perímetro de permisos. Lectura amplia, escritura estrecha. Que consulte lo que necesite; que enviar, borrar, publicar o pagar pase por ti. Esto no es una recomendación de manual: es la diferencia entre un incidente y una anécdota.

Tareas donde un agente rinde de verdad

El patrón común de las que salen bien: muchos pasos mecánicos, criterio claro y resultado verificable.

• Desarrollo. Reproducir un bug a partir del informe, localizar la causa y proponer el parche con su test. El resultado se verifica solo: o los tests pasan o no.
• Atención al cliente. Triar la bandeja: clasificar, buscar el pedido en el sistema, redactar el borrador de respuesta y dejarlo en cola para revisión humana.
• Finanzas y operaciones. Conciliar facturas contra extractos y sacar solo las discrepancias. El trabajo aburrido es el 95 %; el criterio, el 5 %.
• Marketing. Rastrear qué han publicado cinco competidores este mes y devolver un resumen con enlaces, no con impresiones.
• Recursos humanos. Cribar candidaturas contra criterios escritos de antemano, dejando por escrito por qué descarta cada una.

En cuatro de los cinco casos el entregable es un borrador o una lista para revisar, no una acción consumada. Ese es el punto dulce hoy.

Dónde no conviene dejarlo solo

• Decisiones con consecuencia legal o económica directa. Aprobar un gasto, firmar, despedir, publicar precios. Que prepare el expediente; que decida una persona.
• Tareas donde el error es silencioso. Si un fallo no se nota hasta el cierre trimestral, el agente necesita comprobación intermedia obligatoria.
• Procesos que exigen un resultado idéntico siempre. Para eso hay scripts, y son más baratos, más rápidos y auditables.
• Datos que no pueden salir de casa. Antes de conectar nada, mira qué se envía al proveedor del modelo y qué política de retención tiene.

Cómo empezar sin montar una infraestructura

No hace falta un proyecto de seis meses. La ruta corta:

1. Elige una tarea que hagas cada semana y odies. Con pasos claros y un resultado que puedas comprobar de un vistazo.
2. Escríbela como procedimiento, con criterios y casos límite. Si no eres capaz de explicársela por escrito a alguien que entra nuevo, el agente tampoco la va a entender.
3. Empieza en modo borrador. Que prepare, no que ejecute. Durante dos semanas lo revisas todo.
4. Cuenta los fallos. Si en veinte ejecuciones no ha metido la pata en nada irreversible, amplía permisos en un solo punto. Si ha fallado, arregla las instrucciones, no el modelo.

El método completo, con los controles que conviene dejar puestos antes de soltarle la mano, está en cómo automatizar tareas con IA en el trabajo.

Desde 2026 hay además una vía que no exige montar nada: los agentes de escritorio —Claude Cowork, ChatGPT Work, Gemini Spark— que reciben un encargo sobre una carpeta o sobre tus aplicaciones y devuelven ficheros terminados. Es la forma más corta de comprobar si un agente te sirve antes de invertir en procedimientos.

Y si el agente va a trabajar con datos de la empresa, la conversación pendiente no es técnica: es qué permisos tiene, con qué datos y quién responde de lo que haga. Eso se resuelve por escrito, con una política de uso de IA.

Un apunte de 2026 para quien vaya a construir uno: no todas las decisiones de un agente necesitan un modelo de texto. Las de alto volumen y salida cerrada —clasificar, enrutar, puntuar— empiezan a tener modelos propios, y el primero de esa categoría está explicado en Jev, el modelo System One de TypeSafe AI.