Estuve trabajando en un flujo de validación de diseño con agentes de IA, que incluye revisiones de contenido, usabilidad, accesibilidad, voz y tono y consistencia con el sistema de diseño.
No es una revisión exhaustiva de todo el proceso de diseño, sino un ejemplo que forma parte de las actividades y el material para mi curso Agentes y Skills para Diseño.
El flujo se descompone en varios validadores o subagentes con tareas específicas, cada uno con su propio criterio y su propia evidencia. Cuando terminan su trabajo, un agente principal reúne los resultados, detecta relaciones y devuelve al diseñador las decisiones que debe tomar.
Desde fuera, el flujo podría resumirse como “varios agentes auditan una interfaz”.
El desafío real aparece al repartir responsabilidades sin mezclar criterios ni delegar decisiones que corresponden al diseñador.
Algunas verificaciones se resuelven con reglas; otras necesitan interpretación. El reporte final puede reunirlas, pero debe dejar claro qué criterio produjo cada hallazgo y con qué evidencia. Y las decisiones sobre qué problema importa, qué severidad aceptar o qué recomendación tiene sentido para el producto vuelven a una persona (Human In The Loop).
El propósito del flujo es convertir una actividad conocida en un sistema de trabajo más explícito, revisable y reusable, con el diseñador a cargo de las decisiones que requieren su criterio.
Hace poco publiqué el artículo Un producto con IA no es un modelo con una interfaz encima. Allí explicaba el producto en el sistema que le da contexto, reglas y una experiencia concreta. Este artículo continúa desde ese punto y mira dos lugares que los agentes empiezan a ocupar en Diseño.
En el flujo de validación, los agentes son herramientas para diseñar un proceso. La otra relación aparece cuando el comportamiento de un producto utiliza patrones agénticos.
En ese segundo ámbito, lo agéntico forma parte del material con que se está diseñando.
Ésa es la distinción que me interesa desarrollar: usar agentes para diseñar no es lo mismo que diseñar con patrones agénticos.
Cuando el proceso de diseño también se diseña
El flujo de validación parte de una actividad que ya existe en el trabajo de diseño: revisar una interfaz desde distintos criterios, consolidar hallazgos y decidir qué hacer con ellos.
Esta actividad puede ocurrir mediante una crítica de diseño, varias revisiones especializadas, comentarios en archivos y conversaciones entre personas. Al distribuir parte del trabajo entre agentes que leen evidencia, aplican reglas, interpretan situaciones y producen salidas estructuradas, el proceso mismo se vuelve un objeto explícito de diseño.
Cada evaluador necesita un contrato —o una definición— distinto. El de accesibilidad separa lo que puede comprobar automáticamente de lo que requiere revisión manual. El evaluador de voz y tono compara contra una referencia explícita, no contra una impresión genérica de que el texto “suena bien”. Para revisar el sistema de diseño hacen falta tokens, componentes, estados y reglas de uso. El agente principal recibe esas salidas, pero necesita saber qué puede normalizar y qué no debería aplanar en un promedio falso.
Diseñar este flujo implica definir intención, criterio, evidencia, herramientas, responsabilidades, contratos de salida, handoffs y puntos de intervención humana.
El diseñador aporta en otro punto: define el sistema de evaluación, revisa excepciones, interpreta consecuencias y decide qué recomendaciones tienen sentido para el producto, en vez de repetir instrucciones o comprobar manualmente todo lo que una regla puede detectar.
Aquí el objeto diseñado es el proceso de trabajo. Los agentes participan en él como herramientas.
El agente no es el modelo
Para entender esto hace falta separar conceptos que suelen aparecer mezclados.
Un modelo de lenguaje recibe contexto y produce una respuesta. Por sí mismo no conserva memoria entre llamadas, no decide qué herramientas tiene disponibles ni conduce un proceso completo. El comportamiento que identificamos como agéntico lo produce el sistema que construye contexto alrededor del modelo, interpreta sus respuestas, ejecuta acciones, observa resultados y vuelve a llamarlo.
A ese sistema que rodea y coordina al modelo se le suele llamar harness.
El diagrama es un modelo conceptual, no una arquitectura de referencia ni un inventario de componentes obligatorios. Sirve para observar relaciones que suelen desaparecer cuando reducimos el agente a “un LLM con un prompt”.
En el centro está el harness. Construye el contexto que recibe el modelo, coordina herramientas, mantiene estado y ejecuta el ciclo de decidir, actuar, observar y volver a decidir. Puede delegar una tarea a un subagente con su propio contexto, herramientas y responsabilidad acotada. Y puede suspender el proceso cuando necesita una decisión humana.
Visto desde Diseño, el diagrama permite reconocer tres propiedades que cambian lo que un sistema puede hacer.
Puede dar continuidad: conservar el estado relevante de una tarea y retomarla después de cada acción.
Puede actuar: consultar una base de datos, modificar un archivo, ejecutar una operación o coordinar otro sistema, en lugar de limitarse a producir una respuesta.
Puede distribuir autoridad: decidir qué tarea asume cada agente, qué acción está permitida, qué resultado requiere revisión y en qué momento la decisión vuelve a una persona.
En el flujo de validación, estas propiedades pertenecen a las herramientas, al agente. Cuando se incorporan al comportamiento de un producto, pasan a ser parte del material con que el equipo diseña.
Cuando lo agéntico se vuelve material de producto
En un producto con patrones agénticos, Diseño trabaja sobre un sistema que puede mantener una intención en el tiempo, actuar sobre otros sistemas y coordinar responsabilidades para alcanzar un resultado. La interfaz es apenas una parte de ese comportamiento.
Un producto puede usar IA sin comportarse de forma agéntica, y un producto agéntico puede prescindir de una interfaz conversacional. El chat es una modalidad posible, no la propiedad que define el comportamiento.
La diferencia aparece con más claridad cuando el producto deja de limitarse a responder y empieza a hacerse cargo de una tarea.
Imaginemos un retail en línea que entrega productos a domicilio. Algunos pedidos no llegan; otros aparecen como entregados cuando el cliente no los recibió; a veces la dirección está incompleta, el transportista no encuentra a la persona o el producto llega dañado.
Un chat con IA puede conversar con el cliente, interpretar el reclamo, recopilar datos y crear un ticket para backoffice. Puede hacer esa primera parte con mucha fluidez y aun así no resolver el problema. Para el cliente, la derivación marca el final de la conversación aunque el reclamo siga abierto.
Un flujo agéntico podría ir más lejos. Podría consultar el estado de la orden, recuperar información del operador logístico, comprobar qué evidencia existe, pedir un dato faltante, revisar disponibilidad de inventario, aplicar políticas del comercio y coordinar la acción siguiente con las áreas necesarias.
Según las condiciones del caso, el sistema podrá ejecutar una acción, preparar una propuesta o detenerse y escalar. El hilo que une esas posibilidades es la capacidad de llevar el caso hasta que exista una resolución o una transferencia de responsabilidad comprensible.
El producto conserva el estado del reclamo más allá de una conversación, opera sobre sistemas de pedidos, logística, inventario o pagos y distribuye autoridad entre el agente, el cliente, las áreas internas y las personas con atribuciones específicas.
En este caso, el patrón agéntico forma parte del comportamiento del servicio que el equipo está diseñando.
La autonomía no es una configuración única
El ejemplo abre una pregunta evidente: cuánto debería resolver el agente de manera autónoma.
La pregunta es válida, pero no tiene una respuesta universal.
Consultar el estado de un pedido, corregir una dirección, reprogramar una entrega, enviar un reemplazo, realizar un reembolso o resolver información contradictoria producen consecuencias diferentes. Su nivel de riesgo cambia según el tipo de industria, la regulación, los estándares de calidad, los costos, el valor de la transacción, la reversibilidad de la acción y las políticas de cada organización.
Por eso la intervención humana no debería definirse una sola vez para todo el agente.
La distribución de autoridad puede cambiar durante un mismo caso. El sistema puede avanzar de forma autónoma mientras consulta información, pedir confirmación al cliente antes de modificar la entrega, requerir aprobación interna para una excepción y transferir el caso cuando la evidencia no alcanza.
Diseñar la autonomía exige definir bajo qué condiciones actúa cada parte, cómo se hace visible la transición y qué ocurre cuando el sistema no puede continuar de forma segura o confiable.
El riesgo, la operación, el negocio, la regulación y la responsabilidad condicionan estas decisiones. Por esa vía terminan definiendo la experiencia: qué promete el producto, cuánto control percibe la persona, quién responde ante un error y si el servicio realmente resuelve el problema o sólo lo mueve a otra cola.
El producto agéntico se diseña antes de la interfaz
En un proceso convencional, muchas decisiones de experiencia pueden discutirse cuando el equipo ya conoce el flujo general del producto. En un sistema agéntico, esperar hasta la interfaz puede ser demasiado tarde.
Antes de decidir cómo se verá la conversación, el equipo necesita responder otras preguntas:
- qué significa completar la tarea;
- qué información necesita el sistema para avanzar;
- qué herramientas y áreas puede involucrar;
- qué acciones puede ejecutar y cuáles sólo puede proponer;
- cómo mantiene el estado de un proceso que puede durar más que una sesión;
- qué señales cambian el nivel de intervención humana;
- cómo recupera el control una persona;
- qué experimenta el cliente mientras el sistema sigue trabajando;
- qué ocurre cuando una integración falla o la evidencia es insuficiente.
Son preguntas de producto, tecnología, operación y experiencia al mismo tiempo.
Por eso deberían entrar temprano en product discovery y en la conversación del equipo que construye la visión del producto. Diseño, Producto e Ingeniería aportan perspectivas distintas; en el ejemplo del retail también necesitarán participar Operaciones, Atención al Cliente, Logística, Riesgo u otras áreas según el caso.
El punto es incorporar estas preguntas a la conversación de diseño antes de que la orquestación se cierre como una solución técnica y a Diseño sólo le corresponda decidir cómo presentarla.
Diseño puede sostener el hilo entre la intención del producto, la forma en que el sistema actúa y la experiencia que produce. Para que eso ocurra, Ingeniería traduce esa intención a una implementación viable y confiable, Producto la conecta con el problema, las prioridades y los resultados esperados, y las áreas operativas aportan reglas, excepciones y consecuencias que el sistema no puede inventar.
Cuando esta colaboración ocurre temprano, las tensiones entre roles pueden tratarse mientras el comportamiento todavía admite decisiones de diseño.
Trabajar con agentes y diseñar comportamientos agénticos
Los agentes ocupan dos lugares diferentes en Diseño. En el flujo de validación funcionan como herramientas dentro de un proceso de trabajo: distribuyen tareas, evidencia y decisiones, mientras el diseñador define cómo se revisa una interfaz y dónde debe intervenir su criterio.
En el caso del retail, el equipo usa patrones agénticos para definir cómo el producto se hace cargo de una tarea y qué relación mantiene con personas, sistemas y áreas internas mientras intenta resolverla. El objeto diseñado es el comportamiento del servicio.
Ambos lugares pueden compartir modelos, herramientas, loops, memoria o subagentes, pero exigen capacidades y decisiones diferentes. Trabajar con agentes obliga a diseñar el proceso propio; diseñar un producto agéntico obliga a definir cómo actúa un sistema frente a otras personas y sistemas, con qué autoridad y bajo qué condiciones.
En los dos conviene comprender lo agéntico más allá del modelo y del prompt. Hacer visible el sistema que administra contexto, ejecuta acciones y distribuye responsabilidades amplía el espacio de Diseño: permite intervenir tanto en las herramientas con las que trabajamos como en el comportamiento de los productos que ayudamos a construir.
La distinción tiene una consecuencia práctica: ante un proyecto con agentes, conviene aclarar si estamos diseñando el proceso con el que trabajamos o el comportamiento de un producto que actuará sobre otros sistemas y personas. Esa respuesta cambia las responsabilidades, los riesgos y las decisiones que Diseño necesita poner sobre la mesa.
