¿Qué es un agente de IA?
Un agente de IA decide sus pasos, usa herramientas para actuar y revisa los resultados hasta terminar. Cómo funciona y en qué se diferencia de un chatbot.
¿Qué significa que “decida” sus pasos?
Un chatbot tradicional responde una pregunta con un texto y espera la siguiente. Un agente recibe una tarea del tipo “corrige los tests que fallan en el módulo de autenticación” y resuelve el orden de trabajo por su cuenta: primero corre los tests, luego lee los archivos que fallan, después edita el código y finalmente vuelve a correr los tests para comprobar.
La decisión la toma el modelo en cada paso, según lo que ya ha visto. Esa es la diferencia central. En un flujo fijo, una persona escribe los pasos en código. En un agente, el modelo elige los pasos dentro de los límites que tú le pongas.
Anthropic, en su guía Building effective agents, separa dos tipos de sistemas agénticos. Los workflows son sistemas donde los LLM y las herramientas se orquestan con rutas de código predefinidas. Los agentes son sistemas donde el LLM dirige dinámicamente su propio proceso y su uso de herramientas. Un agente tiene más libertad y, por eso, más riesgo.
| Chatbot | Workflow | Agente | |
|---|---|---|---|
| Quién decide los pasos | Nadie: responde y espera | Una persona, escritos en código | El modelo, en cada vuelta |
| Puede usar herramientas | No necesariamente | Sí, en el orden fijado | Sí, cuando el modelo lo pide |
| Cuánto varía entre ejecuciones | Poco | Poco | Mucho |
| Ejemplo | Responder una duda de un cliente | Resumir un correo y guardarlo en una hoja, siempre igual | Arreglar un bug explorando el código |
¿Cómo funciona por dentro?
Casi todos los agentes actuales siguen el mismo ciclo. La documentación del Agent SDK de Claude lo describe en cinco pasos: Claude recibe el prompt, evalúa el estado y decide si responde con texto o pide una o varias herramientas, el SDK ejecuta las herramientas, los resultados vuelven a Claude y el ciclo se repite hasta que Claude responde sin pedir más herramientas.
Cada vuelta completa de ese ciclo se llama turno. Una pregunta simple puede tomar uno o dos turnos. Una tarea compleja, como refactorizar un módulo y actualizar sus tests, puede encadenar decenas de llamadas a herramientas. Ese ciclo tiene su propio artículo: el loop de un agente.
Las herramientas son lo que permite actuar. Según la documentación de la API de Claude, el modelo determina cuándo llamar a una herramienta según lo que pide el usuario y la descripción de la herramienta. En las herramientas “de cliente”, tu aplicación ejecuta la llamada y devuelve el resultado; en las “de servidor” (como la búsqueda web), las ejecuta Anthropic. Para más detalle, consulta tool use.
¿Por qué le importa a un diseñador?
Porque cambia qué tipo de interfaz necesita el producto. Un agente no solo muestra información: hace cosas en nombre de la persona. Eso obliga a diseñar piezas que antes no hacían falta:
- Cómo se ve el progreso mientras el agente trabaja (progreso de tareas largas).
- Qué acciones necesitan aprobación antes de ejecutarse (aprobación de acciones).
- Cómo se deshace un cambio que el agente ya hizo (deshacer lo que hizo un agente).
- Cómo se muestran las herramientas disponibles y sus permisos (UX de permisos).
Los niveles de autonomía de un agente definen cuántas de esas decisiones pasan por una persona. Si dudas entre agente, asistente o copiloto, mira agente vs. asistente vs. copiloto.
¿Cuándo NO conviene un agente?
Anthropic recomienda buscar la solución más simple posible y añadir complejidad solo cuando hace falta. Según la misma guía, los sistemas agénticos suelen cambiar latencia y costo por mejor rendimiento en la tarea, y su autonomía implica costos más altos y el riesgo de que los errores se acumulen. Si la tarea tiene pasos conocidos, un workflow fijo es más barato, más predecible y más fácil de probar.
Un agente conviene cuando:
- Los pasos no se pueden predecir de antemano.
- La tarea requiere explorar, leer resultados y ajustar el plan.
- El costo de un error es bajo o existe un paso de revisión humana.
No conviene cuando el resultado debe ser exacto y repetible, o cuando una acción irreversible depende de una decisión que el modelo no puede verificar.
Ejemplo
Ejemplo ilustrativo: una persona le pide a un agente que revise si todos los botones de un flujo de pago tienen estados de error. El agente lista los archivos de componentes, abre cuatro de ellos, detecta que el botón de “reintentar” no tiene estado deshabilitado, propone el cambio y pide confirmación antes de editar. La persona aprueba, el agente corrige y vuelve a correr la revisión. Todo el trabajo intermedio lo decidió el modelo; la aprobación la dio la persona.
¿Qué pasa cuando el agente se equivoca a mitad de camino?
Un agente puede equivocarse en cualquier paso, y el ciclo no se detiene solo porque algo salió mal. Si una herramienta falla o se rechaza, el mensaje vuelve al modelo como resultado, y el modelo suele probar otro camino o avisar que no pudo seguir. También puede insistir en lo mismo o dar por bueno un resultado incompleto. Por eso conviene fijar límites desde el diseño: el SDK de Claude permite, por ejemplo, topar el número de turnos o el gasto máximo de una sesión.
Antes de dar acceso a acciones, define qué debe hacer el agente ante un error: reintentar una vez, detenerse y avisar, o pedir ayuda. Diseñar ese momento es parte del trabajo de producto. Una interfaz que solo muestra el resultado final esconde los errores intermedios, y la persona descubre el problema cuando ya cambió algo que no esperaba.
¿Qué puedes hacer mañana?
Elige una tarea que hagas a diario y escribe en una hoja qué pasos sigues y cuáles dependen de tu juicio. Los que dependen de tu juicio son candidatos a un agente con control humano; los demás pueden resolverse con un script o un flujo fijo. Empieza con una sola tarea de lectura, sin permisos de escritura, y revisa lo que devuelve durante una semana antes de dar más acceso.
Errores comunes
- Llamar agente a cualquier chatbot con botones. La diferencia está en que puede actuar y repetir pasos.
- Dar permisos amplios desde el inicio, en lugar de empezar con lectura y ampliar después.
- Confiar en que el agente terminó bien porque dice que terminó. Hay que verificar el resultado.
- Usar un agente para una tarea con pasos fijos que un script resuelve mejor.
- No poner un tope de turnos o de gasto, y dejar que una tarea abierta corra sin límite.