Agentic UX: cómo diseñar interfaces para agentes de IA sin perder el control

Un botón tradicional no decide qué quieres decir, busca credenciales, elige una herramienta y ejecuta tres acciones adicionales para “ayudarte”.

Un agente sí puede hacerlo.

Por eso aplicar buenas prácticas de UI a un producto con IA es necesario, pero insuficiente. Una interfaz agentic no sólo presenta información: media entre una intención humana y un sistema probabilístico capaz de modificar estado.

El problema ya no es únicamente “¿se entiende este botón?”. Ahora también importa:

• ¿qué entendió el agente?
• ¿está sugiriendo o ya está actuando?
• ¿qué datos y herramientas puede usar?
• ¿cuándo debe pedir confirmación?
• ¿cómo se detiene?
• ¿qué parte puede deshacerse?
• ¿cómo sabemos que terminó de verdad?

Agentic UX es la práctica de diseñar esa relación para que la autonomía sea útil, observable, corregible y proporcional al riesgo.

No existe todavía un estándar único con ese nombre. El marco práctico surge al combinar las guías de interacción humano‑IA de Microsoft y Google con la experiencia de Anthropic construyendo agentes, herramientas, permisos y entornos de contención.

Qué cambia cuando el software puede actuar

Una UI determinista suele seguir este contrato:

acción explícita → operación conocida → resultado esperado

Una interfaz agentic introduce pasos inferenciales:

intención
  → interpretación
  → plan
  → selección de herramientas
  → acciones intermedias
  → cambios de estado
  → verificación

Cada flecha puede introducir ambigüedad, error o ampliación de alcance. Un agente puede entregar una respuesta correcta mediante una trayectoria insegura o declarar éxito sin que el sistema externo haya cambiado.

La investigación de Microsoft sobre interacción humano‑IA organiza el problema en cuatro momentos:

1. inicialmente, comunicar capacidades y límites;
2. durante la interacción, respetar contexto y normas;
3. cuando la IA se equivoca, facilitar invocación, rechazo y corrección;
4. con el tiempo, adaptar con cautela, ofrecer control global e informar cambios.

La idea más importante es temporal: una IA no sólo debe diseñarse para el happy path. Hay que diseñar la primera expectativa, la ejecución, el fallo inevitable y el cambio de comportamiento futuro.

Autonomía calibrada: el principio que organiza todo

El usuario no necesita elegir entre “manual” y “autónomo”. Necesita saber qué autoridad tiene el agente en esta tarea concreta.

Nivel	Capacidad	Patrón de interfaz
A0 · Informar	Leer y explicar	Fuentes, límites y actualización
A1 · Recomendar	Proponer opciones	Evidencia, comparación y rechazo
A2 · Preparar	Crear borrador o plan	Preview editable; aún no cambia nada externo
A3 · Ejecutar reversible	Actuar dentro de un límite recuperable	Estado persistente, log y undo real
A4 · Ejecutar sensible	Afectar producción, dinero, terceros o datos	Preview, aprobación explícita y verificación

No son niveles de madurez. A4 no es “mejor” que A1. Son contratos de agencia.

Un agente financiero puede recomendar transferencias en A1, prepararlas en A2 y requerir confirmación humana en A4. Un coding agent puede modificar un branch efímero en A3, pero debe cruzar otro límite para hacer merge o desplegar.

Evita etiquetas como Auto, Smart o Autopilot sin explicar:

• recursos incluidos;
• acciones permitidas;
• duración;
• presupuesto;
• salida;
• condiciones de escalamiento.

Criterio de diseño: una persona puede describir con precisión qué hará la IA antes de activarla.

Sugerir, preparar y ejecutar deben parecer diferentes

Muchas interfaces muestran los tres estados dentro de la misma burbuja de chat. Eso borra la diferencia entre una idea y un efecto real.

Sugerencia
Podrías reembolsar el segundo cargo.
[Preparar reembolso]

Preparado · aún no enviado
Pago pay_82K1 · MXN $1,249.00 · cargo duplicado
[Editar] [Cancelar] [Confirmar reembolso]

Reembolso enviado
ID re_91P3 · Estado: procesando por el banco
[Ver actividad]

Cada etapa cambia verbos, jerarquía y controles:

• una sugerencia se acepta o descarta;
• un borrador se edita;
• una acción sensible se confirma;
• un resultado se verifica.

El CTA nunca debería prometer menos de lo que hará. Continuar es especialmente peligroso cuando en realidad significa publicar, pagar o borrar.

El commit boundary: el último momento antes del efecto

Un commit boundary separa preparación de ejecución. Antes de cruzarlo, la interfaz debe mostrar la información necesaria para juzgar la acción.

Para una mutación sensible:

• acción exacta;
• target;
• diff o contenido;
• destinatarios;
• monto o costo;
• alcance;
• permisos utilizados;
• consecuencias irreversibles;
• forma de verificar el resultado.

Preparado · todavía no desplegado

Servicio: billing-api
Entorno: producción
Versión: 4f2a1c7 → 9d8be20
Cambios: 3 migraciones · 8 archivos
Riesgo: la migración 20260728_add_index bloquea escrituras ~12 s
Rollback: disponible para aplicación; no para migración de datos

[Ver diff] [Cancelar] [Aprobar despliegue]

Una confirmación genérica traslada el riesgo a la persona sin darle información para evaluarlo. Un dump de JSON o un comando Bash puede ser igual de inútil para alguien no técnico.

Criterio de diseño: la aprobación muestra intención humana, efecto real y blast radius en el lenguaje del usuario.

No toda incertidumbre necesita un porcentaje

Los modelos son probabilísticos, pero mostrar 73% confidence no garantiza comprensión. La cifra puede estar mal calibrada o no explicar qué hacer.

Google PAIR recomienda ayudar a las personas a calibrar confianza: comunicar capacidades, límites, datos utilizados y cuándo aplicar juicio propio. La explicación debe optimizar comprensión, no simular transparencia.

Patrones útiles:

• Límite de conocimiento: “Sólo revisé las facturas de julio”.
• Fuente: “Basado en Stripe y el ERP; el CRM no respondió”.
• Ambigüedad: “Encontré dos trabajos llamados billing-prod. ¿Cuál deseas cancelar?”
• Calidad insuficiente: “La foto no permite leer el número de serie. Sube otra.”
• Diferencia relevante: “La política admite dos interpretaciones; necesito una decisión.”

Patrones débiles:

• “La IA puede equivocarse” debajo de todo;
• una estrella mágica que sólo indica “esto usa AI”;
• reasoning extenso que racionaliza una decisión;
• confidence decorativa sin acción asociada.

Criterio de diseño: cuando la incertidumbre cambia la decisión, la interfaz reduce alcance, pide información o escala.

Permisos: confirmar más no siempre protege más

El patrón ingenuo es preguntar antes de cada tool call. Parece seguro hasta que la persona deja de leer.

Anthropic reportó que usuarios de Claude Code aprobaban aproximadamente el 93% de los permission prompts. La repetición produjo approval fatigue: el gate diseñado para supervisar perdía señal. Al introducir sandboxing, la organización redujo esos prompts en un 84% en su uso interno.

Una estrategia mejor combina:

• operaciones de lectura seguras permitidas;
• escritura reversible dentro de un workspace acotado;
• red y recursos externos concedidos como capacidades específicas;
• producción, dinero, comunicación externa y destrucción tras aprobación;
• credenciales, bypass de controles y ampliación de permisos fuera de la autoridad del agente.

Los límites fuertes importan más que el copy del diálogo:

• sandbox o VM;
• filesystem read-only, read-write o no-delete;
• egress limitado;
• tokens temporales y con scope mínimo;
• identidad separada para el agente;
• topes de tiempo, costo y operaciones.

La investigación de Anthropic sobre contención formula el riesgo como probabilidad de fallo multiplicada por daño posible. Aunque mejores el modelo, el blast radius crece con cada permiso.

Criterio de diseño: las acciones rutinarias no entrenan al usuario a aceptar; las excepcionales explican por qué necesitan autoridad.

Una acción necesita target explícito

Los agentes completan huecos. Esa capacidad es productiva para redactar; puede ser peligrosa para mutar.

Usuario: cancela mi job
Agente: encontró billing-prod-2 por similitud y lo canceló

El error no está en el botón. Está en permitir que una inferencia seleccione el objeto de una acción destructiva.

Para targets sensibles:

• exige selección explícita o confirmación inequívoca;
• muestra ID, propietario, entorno y estado;
• diferencia recurso del usuario y recurso compartido;
• pide aclaración si existen candidatos;
• no conviertas proximidad semántica en autorización.

Criterio de diseño: ninguna mutación sensible depende de un parámetro inferido que la persona no vio.

Diseña para corregir, no sólo para acertar

Microsoft incluye cinco recomendaciones para el momento en que la IA se equivoca:

• facilitar invocación;
• facilitar rechazo;
• facilitar corrección;
• reducir alcance cuando exista duda;
• explicar por qué actuó.

La recuperación debe ser local. Si el agente redactó bien nueve líneas y mal una, permite corregir esa línea. Si importó 982 registros y 18 fallaron, conserva el éxito y ofrece reparar los 18.

18 de 20 facturas actualizadas

2 no cambiaron:
- F-102 ya estaba pagada
- F-118 requiere permiso de administrador

[Ver detalles] [Solicitar permiso] [Terminar]

Estados mínimos:

idle
planning
waiting_for_input
waiting_for_permission
running
partially_completed
succeeded
failed_recoverable
failed_terminal
cancelled
timed_out
offline

Para cada uno define qué ve la persona, si el agente sigue actuando, qué persiste y cómo se reanuda.

Criterio de diseño: un error no destruye trabajo válido ni obliga a reiniciar sin necesidad.

Cancelar y deshacer no son lo mismo

• Cancelar intenta detener trabajo futuro.
• Deshacer revierte efectos ya aplicados.
• Rollback restaura un sistema a un estado técnico anterior.
• Compensar ejecuta otra acción cuando el efecto original no puede revertirse.

Un botón Cancelar que sólo cierra el modal mientras el agente sigue ejecutando es un engaño operativo. Un Undo que borra la fila local pero no revierte el correo enviado también.

La interfaz debe decir:

Cancelación solicitada
Se enviaron 42 de 100 mensajes antes de detener el proceso.
Los mensajes enviados no pueden recuperarse.
[Ver destinatarios]

Criterio de diseño: el verbo de recuperación corresponde al efecto real y reporta resultados parciales.

Trazabilidad: muestra actividad, no pensamiento privado

Transparencia no requiere imprimir cada token de razonamiento.

La persona necesita un activity log verificable:

• objetivo recibido;
• plan de alto nivel;
• tools y servicios usados;
• archivos o datos consultados;
• permisos concedidos;
• acciones ejecutadas;
• resultados y verificaciones;
• timestamp, versión y configuración cuando importen.

14:03  Leí 24 facturas de Stripe
14:03  Crucé 24 cuentas con ERP
14:04  Preparé 2 posibles duplicados
14:05  Jesús aprobó reembolsar pay_82K1
14:05  Stripe creó refund re_91P3
14:05  Verificación: estado submitted

Esto permite auditar sin presentar chain-of-thought privado, que puede ser verboso, inestable y poco útil como evidencia.

Criterio de diseño: otra persona puede reconstruir qué cambió, mediante qué autoridad y con qué resultado.

La interfaz cambia con el tiempo

Una aplicación tradicional cambia cuando despliegas. Un producto con IA también puede variar por:

• modelo;
• system prompt;
• herramientas disponibles;
• memoria y preferencias;
• retrieval;
• políticas;
• adaptación al comportamiento.

Microsoft recomienda adaptar con cautela, ofrecer controles globales e informar cambios. Un usuario que aprendió qué delegar puede perder su modelo mental si el agente gana autonomía silenciosamente.

Comunica cambios que alteren:

• calidad esperada;
• fuentes;
• permisos;
• retención de datos;
• acciones automáticas;
• límites;
• costo o latencia.

No necesitas un modal por cada versión. Sí necesitas avisar cuando una expectativa operativa deja de ser cierta.

Hay dos interfaces: HCI y ACI

Hasta aquí diseñamos la interfaz entre persona y agente. Pero el agente también interactúa con software.

Anthropic llama Agent‑Computer Interface (ACI) a la capa formada por tools, schemas, descripciones, errores y respuestas. Su recomendación es invertir en ella tanto cuidado como en la HCI.

Una tool ambigua es el equivalente agentic de un icono sin etiqueta.

Una ACI clara

• nombres específicos y namespaced;
• propósito y fronteras explícitas;
• user_id en lugar de user;
• schemas estrictos;
• ejemplos y edge cases;
• separación de lectura y mutación;
• anotación de efectos destructivos o acceso abierto;
• respuesta concisa por defecto;
• paginación, filtros y truncamiento explícito;
• errores que indiquen cómo corregir;
• outcome verificable.

{
  "tool": "billing.refund_payment",
  "description": "Refund one captured payment. Irreversible after submission.",
  "input": {
    "payment_id": "pay_82K1",
    "amount_minor": 124900,
    "currency": "MXN",
    "reason": "duplicate"
  }
}

Una ACI ambigua

{
  "tool": "billing_action",
  "input": {
    "user": "Ana",
    "action": "fix",
    "value": 1249
  }
}

La segunda obliga al modelo a inferir entidad, unidad, operación, moneda y alcance.

Anthropic recomienda tratar la descripción como onboarding para una persona nueva: hacer explícito el contexto implícito, limitar ambigüedad y devolver errores accionables en vez de códigos opacos.

Criterio de diseño: el agente puede elegir, llamar y corregir una tool sin adivinar su contrato.

Caso completo: agente de cobranza

Petición:

Revisa los vencidos y manda recordatorios.

Implementación peligrosa

1. El agente interpreta “vencidos” sin fecha ni segmento.
2. Consulta todas las cuentas.
3. Genera mensajes.
4. Envía a 3,200 personas.
5. Reporta “listo”.

La tarea parece completada. La intención nunca fue validada.

Implementación con autonomía calibrada

1. Reduce ambigüedad

Encontré 3 segmentos vencidos:
- 1–7 días: 2,840 cuentas
- 8–30 días: 322 cuentas
- más de 30 días: 38 cuentas

¿Con cuál trabajamos?

2. Prepara en A2

Preparé 38 recordatorios para cuentas con más de 30 días.
No se ha enviado nada.
[Revisar muestra] [Editar mensaje] [Cambiar segmento]

3. Presenta commit boundary

Enviar 38 correos
Audiencia: cuentas >30 días · saldo total MXN $418,200
Remitente: [email protected]
Horario: hoy 10:00
Excluidos: 3 clientes con convenio activo
[Cancelar] [Confirmar envío]

4. Ejecuta y verifica

36 enviados · 2 rechazados por dominio inválido
[Descargar detalle] [Corregir los 2 pendientes]

El agente sigue ahorrando trabajo. La persona conserva intención, alcance y autoridad.

Evalúa abstención, no sólo ejecución

Una suite agentic incompleta sólo pregunta: “¿pudo hacer la tarea?”. También debe medir:

• ¿se abstuvo cuando no tenía autoridad?
• ¿pidió aclaración ante dos targets?
• ¿respetó el scope?
• ¿ignoró instrucciones inyectadas desde web, archivos o tool output?
• ¿evitó buscar credenciales alternativas?
• ¿se negó a saltar un pre-check?
• ¿verificó el outcome?
• ¿comunicó éxito parcial?

Una sola ejecución correcta no prueba confiabilidad. En nuestra guía de evals para coding agents explicamos cómo usar varios trials, graders, pass@k, pass^k y regresiones.

Para UX, añade métricas humanas:

• intervenciones;
• cancelaciones;
• correcciones;
• confirmaciones aceptadas sin inspección;
• tiempo hasta recuperar un error;
• acciones deshechas;
• discrepancia entre resultado percibido y real.

Criterio de diseño: los tests premian resolver y también no exceder la intención.

Anti-patrones de Agentic UX

• La burbuja omnipotente. Todo parece texto aunque algunas respuestas ya modificaron sistemas.
• Autonomía binaria. Un toggle Auto concede autoridad sin describir alcance.
• Confirmación spam. Cada tool call pregunta y ninguna decisión recibe atención.
• Consentimiento técnico. Se muestra Bash o JSON en vez de consecuencia humana.
• Éxito autodeclarado. El agente dice “enviado” sin verificar el servicio.
• Target inferido. Similitud de nombre sustituye selección.
• Undo cosmético. La UI cambia, el sistema externo no.
• Spinner eterno. No hay plan, progreso, costo, cancelación ni reanudación.
• Confianza decorativa. Un porcentaje no modifica flujo ni decisión.
• Personalización silenciosa. El agente cambia reglas sin notificar.
• Tool universal. Una función con action=anything mezcla lectura y destrucción.
• Razonamiento como auditoría. Texto plausible sustituye logs y outcomes.

Plan de implementación en un sprint

Día 1: inventario de agencia

Lista cada acción del agente, sistema afectado, reversibilidad, scope y target. Asigna A0–A4.

Día 2: límites y permisos

Define sandbox, filesystem, red, credenciales, presupuesto y operaciones prohibidas. Decide qué no puede aprobar ni el usuario desde esa interfaz.

Día 3: estados y commit boundaries

Diseña planning, input, permission, running, partial, success, failure, cancel y timeout. Construye preview para A4.

Día 4: ACI

Separa lectura y mutación. Corrige nombres, schemas, ejemplos, respuestas y errores. Añade outcome verification.

Día 5: eval y prueba humana

Prueba actuación, abstención, ambigüedad, error parcial e inyección. Observa si una persona entiende qué hará el agente, detecta un target incorrecto y puede detenerlo.

Agentic UX Playbook

Publicamos un Agentic UX Playbook descargable con:

• niveles A0–A4;
• schema para clasificar acciones;
• contrato de commit boundary;
• permisos proporcionales al riesgo;
• patrones de corrección y trazabilidad;
• checklist de ACI;
• matriz de estados;
• casos para evals;
• Definition of Done;
• add‑on listo para prompts de revisión UI/UX.

Úsalo junto con el prompt operativo de UI/UX y affordance. El primero regula agencia; el segundo regula comprensión e interacción.

Checklist antes de entregar

• La interfaz distingue informar, recomendar, preparar y ejecutar.
• El nivel de agencia tiene alcance y duración visibles.
• Cada acción sensible tiene target explícito.
• El preview muestra diff, costo, audiencia y consecuencia.
• Los permisos son proporcionales al riesgo.
• Una frontera técnica limita el blast radius.
• Cancelar detiene y undo revierte lo que promete.
• Los resultados parciales se conservan y explican.
• El agente verifica estado externo antes de declarar éxito.
• El activity log permite reconstruir la ejecución.
• Los cambios de comportamiento se comunican.
• Las tools tienen nombres, schemas y errores accionables.
• La eval mide acción, abstención, ambigüedad e inyección.
• Una persona puede corregir sin reiniciar la tarea.

Preguntas frecuentes

¿Agentic UX es sólo para chats?

No. Aplica a coding agents, copilotos, automatizaciones, asistentes de soporte, interfaces por voz y cualquier sistema que infiere un objetivo y actúa mediante herramientas.

¿Cuándo debe pedir permiso un agente?

Cuando la acción cruza una frontera de impacto, reversibilidad, alcance o ambigüedad que el usuario no autorizó previamente. Las operaciones rutinarias deben vivir dentro de límites seguros, no detrás de confirmaciones repetitivas.

¿Siempre debo mostrar el plan?

Muestra un plan operativo cuando ayude a juzgar alcance, progreso o riesgo. No es necesario revelar razonamiento privado. Para tareas triviales, estado y resultado pueden bastar.

¿Mostrar confidence aumenta confianza?

No necesariamente. Explica la incertidumbre que cambia la decisión: datos faltantes, fuentes no disponibles, targets ambiguos o límites de cobertura.

¿Qué es ACI?

Agent‑Computer Interface: la interfaz que permite al agente usar herramientas. Incluye nombres, descripciones, schemas, ejemplos, respuestas, errores y límites.

¿Sandbox elimina la necesidad de aprobación?

No. Reduce el blast radius y permite autonomía dentro de una frontera. Acciones externas, irreversibles o sensibles todavía pueden necesitar consentimiento explícito.

Fuentes originales

• Building effective agents — Anthropic
• Writing effective tools for agents — Anthropic
• Claude Code auto mode — Anthropic
• How we contain Claude across products — Anthropic
• Guidelines for Human-AI Interaction — Microsoft Research
• People + AI Guidebook — Google PAIR
• Demystifying evals for AI agents — Anthropic

La meta de Agentic UX no es hacer que el agente pida permiso para respirar. Es darle libertad dentro de límites comprensibles y reservar la atención humana para decisiones que realmente necesitan juicio.