IA: la experiencia y la tecnología no se diseñan por separado

Cuando diseñábamos experiencias de usuario en aplicaciones antes de la era IA, hace dos o tres años hacia atrás, las posibilidades siempre eran pocas y limitadas: un formulario se enviaba correctamente o contenía un error, un proceso se ejecutaba exitosamente, se reintentaba o se daba por fallido, una transacción se revertía o se confirmaba.

Hoy en día las aplicaciones que incorporan funcionalidades con IA son mucho más complejas de diseñar en su experiencia. No basta diseñar sólo cuando todo sale bien o cuando el resultado final es el esperado. Hay que diseñar además todos los posibles resultados intermedios. Y eso ya no es una tarea que se pueda resolver desde un solo lado: la experiencia y la tecnología dejan de ser dos etapas separadas, primero se piensa el diseño, después se resuelve el sistema, y pasan a diseñarse juntas, decisión por decisión.

Por qué cambió en la era IA

Hoy en día uno de los requerimientos de features para cualquier aplicación es incorporar de un modo u otro algún tipo de funcionalidad con inteligencia artificial. La IA nos permite diseñar experiencias más humanas. Permite además automatizar muchos procesos, incluso los muy complejos, dándonos más tiempo a las personas para otro tipo de tareas.

Pero todos los beneficios que trae la IA también tienen algunas cuestiones que, sin ser contras, hay que manejar correctamente.

La primera es que la IA es no determinística. A diferencia del software sin IA, donde las condiciones se programaban explícitamente, la IA nos puede devolver diferentes resultados incluso ante exactamente los mismos datos ingresados. Tenemos que pensar siempre que el resultado de determinado proceso ejecutado por IA puede ser muy diferente en cada una de sus ejecuciones.

Y lo segundo, que las ejecuciones pueden durar minutos, horas, incluso días. Los agentes IA necesitan conocer cuál es el punto final donde pueden devolver una respuesta. Pero para llegar a él, pueden ejecutar, si así lo consideran, decenas, incluso cientos, de pasos antes de lograrlo. Siempre dependerá de la tarea a ejecutar, pero puede ser desde consultar una base de datos, hasta crear subagentes especializados, crearles un entorno seguro para ejecutar código, consultar portales web en busca de información y más.

Y no es sólo a nivel código, la experiencia de usuario es lo más importante

En procesos con agentes IA que duran mucho, el usuario incluso puede cerrar el navegador o la aplicación, y volver al otro día. Todo tiene que quedar funcionando y brindando la experiencia al usuario, incluso en estas circunstancias.

Muchas de las operaciones con IA, además, requieren que el usuario decida ante ciertos puntos que son más críticos y que dejarlos a criterio del agente podría ser riesgoso.

Y cómo se logra dar una buena experiencia en sistemas con agentes IA

Lo mejor es pensar primero qué tiene que lograr el usuario. Definir bien lo que se llama el "job-to-be-done" o las tareas a realizar es fundamental. Esto no cambia con respecto al diseño de hace 2 o 3 años hacia atrás.

Lo que sí cambia es lo no determinístico de la IA. Por más que intentemos disminuir su aleatoriedad, siempre existe margen para que ante un mismo ingreso de información devuelva respuestas diferentes.

Hay que contemplarlo desde el lado técnico y también el lado de la experiencia

Lo mejor entonces es pensar toda la experiencia y lo técnico en conjunto.

Desde el lado técnico

Estado persistido: si el proceso se corta a mitad de camino, ¿desde dónde se retoma? Cada step necesita un checkpoint, no solo el resultado final.
Idempotencia: si un step se reintenta, ¿genera un efecto duplicado (un cobro, un email, un registro) o es seguro repetirlo?
Timeouts y reintentos: cada llamada a un modelo o a una herramienta externa necesita un límite de tiempo y una política clara de reintento, no un "que siga esperando".
Fallos parciales: un agente que ejecuta cinco herramientas y la tercera falla no debería perder el trabajo de las dos anteriores. El diseño de datos tiene que permitir guardar progreso parcial.
Observabilidad: cada step necesita quedar loggeado con su input, su output y su razonamiento intermedio, porque cuando algo sale mal, la pregunta no es "qué falló" sino "en qué paso, con qué contexto".
Control de costo: una ejecución larga que se cuelga en loop consume tokens y llamadas a herramientas. Necesita límites duros, no solo buenas intenciones.
Desacople de la sesión: la ejecución no puede vivir en el navegador ni depender de que el usuario mantenga una pestaña abierta. Un job que dura horas o días tiene que correr en el servidor, sobrevivir a que el usuario cierre sesión, y quedar recuperable desde cualquier dispositivo cuando vuelva a entrar.

Desde el lado experiencia

Visibilidad del progreso: el usuario necesita saber que el sistema sigue trabajando y, en lo posible, en qué está trabajando. Silencio total durante una ejecución larga se lee como que el sistema se rompió.
Sync vs. async según la duración: un step de segundos se puede mostrar en vivo, con un spinner o un log que se va llenando. Un proceso de horas o días necesita el patrón inverso: el usuario se va, y el sistema lo trae de vuelta, por email, push o una notificación in-app, cuando hay algo que requiere su atención o cuando el resultado está listo. Diseñar solo el modo "en vivo" para una ejecución que puede durar un día es diseñar para que nadie lo use así.
Interrumpibilidad: si una ejecución dura minutos, horas o días, el usuario tiene que poder cancelarla o pausarla en cualquier momento, sin que eso deje datos en un estado inconsistente.
Estado consultable de forma independiente: el usuario tiene que poder preguntar "¿cómo va esto?" desde cualquier lugar, un dashboard, un link, un comando, sin depender de la sesión donde arrancó el proceso.
Puntos de intervención humana: no todo agent flow debe correr de punta a punta sin supervisión. Hay que decidir dónde el sistema pide confirmación antes de un paso irreversible.
Comunicación de fallos, no de errores técnicos: cuando un step falla, el usuario no necesita un stack trace. Necesita saber qué pasó, qué impacto tiene y qué puede hacer ahora.
Expectativas de tiempo: un proceso de tres minutos sin ninguna señal de progreso se siente más lento que uno de diez minutos con feedback constante. Y un proceso que puede tardar entre veinte minutos y dos días, según el caso, necesita comunicar ese rango por adelantado, no dejar al usuario adivinando si algo se colgó.
Degradación elegante: si un step secundario falla pero el resultado principal se puede entregar igual, el sistema debería completarlo con una advertencia, no cancelar todo el proceso.

El verdadero trabajo de diseño

Las herramientas actuales resuelven la parte de escribir el código de un agente con una velocidad que hace unos años era impensada. Lo que no resuelven es esta capa: decidir qué pasa en cada paso, tanto en los datos como en la experiencia, cuando la ejecución no es instantánea y no es determinística. Ese diagnóstico, mapear cada step, su contrato de sistema y su contrato de experiencia, es el trabajo que efectivamente define si un producto con agentes es confiable o es una demo con suerte.

Pensar primero la experiencia y después la tecnología, o al revés, es el error. En un sistema con agentes IA, ambas disciplinas se diseñan juntas, paso por paso, o el sistema no funciona en producción.