Diseñar para agentes, no para humanos

Durante décadas, el diseño de producto tuvo un destinatario claro: una persona con ojos, memoria limitada y prisa. Hoy una parte creciente del tráfico de muchos productos proviene de agentes que actúan en nombre de esa persona. Diseñar para ellos no es "hacer una API y ya está".

El agente es un usuario, con necesidades propias

Un agente no se frustra con un formulario feo, pero sí falla con una interfaz ambigua. Sus necesidades:

• Estados explícitos. "Cargando", "listo", "error con motivo". Nada de spinners infinitos sin señal semántica.
• Affordances legibles. Si una acción existe, debe ser descubrible sin leer la mente del diseñador.
• Idempotencia. Reintentar no debe duplicar un pedido ni cobrar dos veces.
• Errores accionables. "Campo inválido" no sirve; "el campo fecha espera formato ISO 8601" sí.

La documentación es la interfaz

Para un agente, tu documentación no es material de apoyo: es la interfaz. Un endpoint mal documentado es, para un agente, un botón sin etiqueta.

Tensiones nuevas de producto

1. Diseñas para dos audiencias a la vez. La persona quiere una pantalla clara; el agente quiere contratos estables. A veces compiten.
2. La capa de presentación deja de ser el producto. El valor se mueve a los datos, las acciones y las garantías.
3. La confianza se negocia con permisos. ¿Qué puede hacer el agente sin preguntar? ¿Dónde exige confirmación humana?
4. El soporte cambia. Un agente no abre un ticket con captura de pantalla; deja un log. Tu observabilidad es tu servicio de atención.

Si tu producto solo se puede usar bien mirándolo, acabas de excluir a tu segmento de usuarios de mayor crecimiento.

Un patrón útil: acciones autodescriptivas

En lugar de esconder la lógica en el frontend, expón lo que el sistema puede hacer de forma que un agente lo entienda:

type Action = {
  name: "cancel_order";
  description: "Cancela un pedido si aún no ha sido enviado";
  params: { orderId: string };
  reversible: false;
  requiresConfirmation: true;
};

Ese mismo contrato puede alimentar tanto un menú para humanos como una lista de herramientas para un agente. Una fuente de verdad, dos consumidores.

Cómo empezar

• Audita tus tres flujos principales y pregunta: ¿un agente podría completarlos sin adivinar?
• Convierte los mensajes de error en instrucciones.
• Publica un catálogo de acciones con permisos y reversibilidad explícitos.
• Mide el éxito por tarea completada, no por clics ni por tiempo en pantalla.

No abandones a la persona

Diseñar para agentes no es una excusa para descuidar la interfaz visible. La mayoría de las decisiones importantes seguirán pasando por una persona que confirma, corrige o rechaza lo que el agente propone. Esa pantalla de confirmación es ahora uno de los momentos de diseño más críticos del producto.

Conclusión

Diseñar para agentes no significa abandonar a las personas; significa separar la intención de la presentación. Cuando el producto expone acciones claras, estados honestos y errores útiles, mejora para todos: la persona apurada y el agente que trabaja por ella. El buen diseño para máquinas casi siempre resulta ser buen diseño, a secas.