Agentes como usuarios: qué es la agent experience (AX)
La agent experience (AX) mide qué tan fácil es para un agente de IA acceder, entender y usar un producto. Origen, cuatro áreas y cómo evaluarla.
¿De dónde viene el término?
Matt Biilmann, cofundador y CEO de Netlify, lo propuso el 28 de enero de 2025 en el texto “Introducing AX: Why Agent Experience Matters”. Lo define como “la experiencia holística que tendrán los agentes de IA como usuarios de un producto o una plataforma” (traducción libre del original). Pide empezar por preguntas como si es sencillo para un agente obtener acceso para operar una plataforma en nombre de un usuario, y reclama APIs limpias y bien descritas, además de documentación y contexto listos para máquinas.
Un año después, el 28 de enero de 2026, publicó “One Year of AX”. Allí afirma que todo producto ya tiene una experiencia de agente y que la única pregunta es si es buena o mala, porque los agentes suelen poder llegar a un producto quiera o no su proveedor. El mismo texto ordena el campo en cuatro áreas.
¿Cuáles son las cuatro áreas de la AX?
| Área | Qué significa según Biilmann | Pregunta para tu producto |
|---|---|---|
| Acceso | Que un agente pueda llegar al producto en nombre del usuario, con la menor fricción posible para ambos | ¿Puede un agente autenticarse con permisos acotados, o el único camino es un inicio de sesión pensado para humanos? |
| Contexto | Gestionar lo que el agente sabe durante su ciclo de trabajo; cita MCP y Skills, servir Markdown desde los sitios de documentación y dar mensajes útiles en las herramientas de línea de comandos | ¿Tu documentación se puede leer como texto limpio? Mira cómo escribir contenido que los LLM citen y llms.txt |
| Herramientas | Los agentes actúan mediante herramientas: protocolos como MCP, Skills propias o llamadas a una CLI o a una API | ¿Las acciones clave están expuestas como herramientas con nombre y parámetros? Mira MCP y diseñar interfaces para que las use un agente |
| Orquestación | Tratar el producto como un lugar donde se puede lanzar a un agente y darle el contexto correcto, incluidos entornos aislados | ¿Puede un agente iniciarse desde dentro de tu producto, con el contexto de lo que la persona está haciendo? |
Es el marco de un solo autor, que además dirige Netlify, una empresa con interés directo en el tema. Úsalo como lista de preguntas, no como norma.
¿En qué se diferencia de la UX y de la DX?
Netlify presenta a los agentes como una nueva figura de usuario en el desarrollo de software, después de la persona (UX) y del desarrollador (DX). La diferencia práctica está en cómo se interpreta un producto:
| UX | DX | AX | |
|---|---|---|---|
| Quién usa | Una persona | Una persona que programa | Un programa que actúa por una persona |
| Cómo percibe | Ve la pantalla | Lee documentación y código | Lee estructura, texto y respuestas de herramientas |
| Qué tolera | Ambigüedad, porque interpreta | Documentación imperfecta | Muy poco: lo que no está expuesto puede pasar desapercibido |
| Quién decide al final | La persona | La persona | La persona que delegó, que sigue siendo responsable |
¿Cómo lee un agente tu producto?
Depende del agente, y no todos miran píxeles. Playwright MCP, el servidor de Microsoft que permite a un modelo manejar un navegador, declara que usa el árbol de accesibilidad de Playwright “en lugar de entrada basada en píxeles” y que opera con datos estructurados, sin modelos de visión. Es un ejemplo, no una regla para todos los agentes: otros trabajan con capturas de pantalla.
La consecuencia para el diseño es concreta cuando el agente usa estructura: un botón sin nombre accesible o un campo sin etiqueta son difíciles de distinguir para un lector de pantalla y para ese tipo de agente. Por eso conviene conocer el árbol de accesibilidad. Trabajar accesibilidad ayuda a las personas y, por el mismo camino, a esos agentes.
¿Cómo evaluar la AX de tu producto?
No existe una métrica estándar. Un método práctico, que es criterio editorial y no un estándar, es probar una tarea real:
- Elige una tarea con inicio y fin claros, como crear un proyecto o cambiar un plan.
- Pide a un agente que la haga con acceso solo a lo que tendría un tercero: tu documentación pública, tu API o tu interfaz.
- Anota en qué área falla: no pudo entrar (acceso), no encontró la información (contexto), no había una acción que hiciera el paso (herramientas) o no supo con qué contexto empezar (orquestación).
- Repite con otro agente. Si uno lo logra y otro no, la diferencia te dice qué dependía de la herramienta y qué de tu producto.
Ejemplo
Ejemplo ilustrativo: una aplicación de reservas quiere que un agente pueda cambiar una cita. Al probarlo, el agente no consigue iniciar sesión porque el acceso exige un código que llega al celular de la persona (acceso). Cuando la persona lo resuelve, el agente no encuentra el flujo de cambio porque solo aparece al abrir un menú sin etiqueta (contexto y estructura). El equipo ofrece un permiso acotado a “gestionar citas”, etiqueta el menú y publica una acción documentada para reprogramar. Vuelve a probar y mide si la tarea termina bien, no cuántas llamadas se hicieron.
¿Quién responde si el agente se equivoca?
Antes de abrir un producto a agentes, conviene decidir qué permisos tiene el agente, qué queda registrado y cómo se revierte una acción. Esas decisiones se desarrollan en aprobación de acciones, human-in-the-loop y niveles de autonomía. Aquí basta recordar que la AX sin control humano en los pasos sensibles es solo una puerta abierta.
Errores comunes
- Creer que un agente es un usuario más y no cambiar nada en el producto.
- Tratar la AX como un sustituto de la UX: las personas siguen siendo quienes deciden.
- Ocultar los permisos o las acciones dentro de menús que el agente no ve.
- Dar acceso total para evitar fricción y perder el control humano.
- Medir la AX solo por el número de llamadas, sin ver si la tarea terminó bien.
- Tomar el marco de un solo autor como estándar de la industria.
Cuándo NO conviene priorizar la AX
Cuando el producto depende de la presencia humana, como una experiencia emocional o una sesión de aprendizaje, o cuando el riesgo de que un agente actúe sin supervisión es alto. Si tu producto aún tiene problemas básicos de UX, arréglalos primero: un agente tampoco entenderá una estructura confusa.