La interfaz del agente es el arnés
OpenAI describe Codex como un agente de ingeniería de software en la nube capaz de leer archivos, editarlos y ejecutar pruebas en un entorno aislado; Anthropic documenta puntos de enlace que pueden inspeccionar y denegar llamadas a herramientas antes de que se ejecuten.43 No son detalles secundarios. Son el producto.
El cuadro de instrucciones se lleva la atención porque se siente como la interfaz. Pero la verdadera interfaz del agente está alrededor de esa entrada: acceso a herramientas, reglas de permisos, carga de memoria, captura de trazas, requisitos de evidencia, controles de recuperación y umbrales de lanzamiento. Esa capa determina cómo se comporta el agente cuando el usuario deja de escribir.
Un producto con agentes no se vuelve confiable porque tenga mejor texto de marcador de posición. Se vuelve confiable cuando la superficie alrededor del modelo convierte la intención en trabajo gobernado.
TL;DR
La interfaz del agente es la capa operativa. El chat puede recoger la intención, pero la superficie que lo rodea decide qué puede ver el agente, qué puede hacer, qué debe demostrar y cuándo debe intervenir una persona. Microsoft planteó la interacción humano-IA como comportamiento a lo largo del tiempo, y NIST entiende la confiabilidad como algo que los equipos incorporan al diseño, el desarrollo, el uso y la evaluación.12
Eso significa que la UX de agentes no puede quedarse en el diseño conversacional. La interfaz tiene que codificar autoridad, memoria, límites de herramientas, evidencia y criterio. Si la interfaz no contiene esas restricciones, el agente las improvisará.
El diseño agéntico es diseño de superficies de control nombra la superficie visible. El marco que sigue nombra la capa operativa que está detrás.
Puntos clave
Para equipos de producto: - Trata el cuadro de instrucciones como la superficie de entrada, no como la superficie operativa. - Diseña los recorridos de permisos, trazas, memoria, evidencia y recuperación del agente antes de pulir el chat.
Para ingenieros de diseño: - Coloca las reglas de calidad donde actúa el agente: antes de las llamadas a herramientas, después de las ediciones, antes del lanzamiento y al cierre del trabajo. - Haz que el estado invisible sea lo bastante inspeccionable como para que una persona siga siendo responsable del resultado.
Para equipos que adoptan agentes: - Pregunta si la interfaz muestra qué vio, cambió, omitió y verificó el agente. - No aceptes una respuesta final fluida como prueba de trabajo gobernado.
La interfaz decide en qué puede convertirse el agente
Toda ejecución de un agente empieza con una intención del usuario, pero la intención no determina por sí sola el comportamiento.
El comportamiento del agente también depende de:
| Capa de la interfaz | Efecto en el comportamiento |
|---|---|
| Herramientas | Define las acciones que puede realizar el agente |
| Permisos | Define cuándo el agente debe detenerse o preguntar |
| Memoria | Define qué contexto previo moldea la ejecución |
| Traza | Define qué puede inspeccionar una revisión posterior |
| Evidencia | Define qué cuenta como terminado |
| Recuperación | Define cómo mantener reversible una falla |
| Criterio | Define qué debería rechazar el sistema |
Esas capas cambian el trabajo tanto como el modelo. El mismo modelo se comporta de otra manera cuando puede ejecutar pruebas, cuando solo puede editar archivos, cuando ve un umbral de lanzamiento, cuando debe citar fuentes o cuando un umbral de detención bloquea un cierre prematuro.
El equipo de producto que trata esas capas como “configuración” no entiende el medio. La configuración queda fuera del trabajo. Las capas de la interfaz del agente se convierten en la forma del trabajo.
Las directrices de Microsoft para la interacción humano-IA recuperan una idea anterior y útil: los sistemas de IA necesitan comunicar estado, admitir correcciones y responder a fallas durante el tiempo de interacción.1 Los agentes vuelven más exigente ese requisito porque el sistema puede actuar entre turnos del usuario. La interfaz ya no puede limitarse a decir: “El modelo respondió”. Tiene que decir: “El sistema actuó bajo estas restricciones”.
El acceso a herramientas es diseño de interfaz
El acceso a herramientas parece técnico. También es UX.
Un agente que solo puede responder desde memoria tiene un tipo de interfaz. Un agente que puede buscar archivos tiene otra. Un agente capaz de ejecutar comandos de shell, editar código, abrir navegadores, llamar APIs y desplegar software necesita un contrato distinto con el usuario.
El Model Context Protocol describe un patrón común: las aplicaciones de IA se conectan con sistemas externos como archivos locales, bases de datos, herramientas y flujos de trabajo.5 Esa conexión amplía la capacidad, pero la capacidad por sí sola no equivale a calidad. Cada herramienta nueva agrega una pregunta que la interfaz debe responder:
| Pregunta sobre la herramienta | Requisito de interfaz |
|---|---|
| ¿Qué puede tocar el agente? | Alcance y límite de permisos |
| ¿Qué envió el agente? | Carga útil inspeccionable de la herramienta |
| ¿Qué recibió de vuelta? | Registro de salida, error y efectos secundarios |
| ¿Qué cambió? | Diferencia, artefacto o resumen de estado |
| ¿Quién lo aprobó? | Registro de permisos |
| ¿Puede revertirse? | Ruta de recuperación |
Una lista de herramientas enterrada en la configuración no puede cargar con ese peso. El usuario necesita una superficie que haga legible la autoridad de las herramientas mientras el trabajo ocurre.
El punto de enlace PreToolUse de Claude Code muestra la pieza básica. Este mecanismo puede recibir el nombre de la herramienta y la entrada antes de la ejecución, y luego permitir, denegar, preguntar, diferir o modificar la llamada.3 Ese mecanismo pertenece al modelo mental del diseño de interfaces para agentes. La interfaz debería exponer el mismo punto de decisión al usuario en el nivel adecuado.
Las lecturas de bajo riesgo pueden pasar en silencio. Los comandos de shell destructivos necesitan mayor fricción. Los lanzamientos públicos requieren un umbral final. Los cambios que afectan a clientes necesitan auditoría. La interfaz correcta no le pide al usuario que apruebe todo. Le da a cada acción el grado de ceremonia que merece.
La memoria es parte del producto
La memoria suele entrar en los productos con agentes como infraestructura: ventanas de contexto, archivos, resúmenes, almacenes vectoriales, cachés, instrucciones de proyecto y sistemas de recuperación. El usuario vive esos sistemas como comportamiento del producto.
Cuando un agente recuerda el estándar de diseño, el producto se siente coherente. Cuando olvida una restricción de hace 40 minutos, el producto se siente descuidado. Cuando recupera una guía obsoleta, el producto parece arrastrar una decisión vieja.
La memoria necesita una interfaz porque cambia la responsabilidad. El usuario no puede supervisar lo que no puede inspeccionar.
La interfaz debería distinguir al menos cuatro estados de memoria:
| Estado de memoria | Significado para el usuario |
|---|---|
| Activa | El agente puede usarla ahora |
| Disponible | El agente puede recuperarla si la necesita |
| Compactada | El sistema la resumió y tal vez perdió detalle |
| Obsoleta | El sistema tiene un registro, pero la confianza debe bajar |
Sin esa distinción, el usuario tiene que inferir la calidad de la memoria a partir del comportamiento del agente. Eso está al revés. La interfaz debería revelar suficiente estado de memoria para que el usuario pueda intervenir antes de que el agente construya sobre una premisa equivocada.
Lo mismo aplica a una filosofía personal o de equipo. Una doctrina de calidad escondida en instrucciones de entrada puede sobrevivir o no a una ejecución larga. Una doctrina codificada en habilidades, puntos de enlace, plantillas, verificaciones y umbrales de cierre tiene más superficie. El modelo todavía puede fallar. La capa operativa puede detectar más fallas porque la regla vive donde ocurre el trabajo.
La evidencia convierte la salida en trabajo
La respuesta final es la unidad de prueba más débil en una ejecución de agente.
Una respuesta final puede decir que las pruebas pasaron cuando ninguna prueba se ejecutó. Puede decir que las citas fueron verificadas cuando la fuente no respalda la afirmación. Puede decir que el despliegue funcionó mientras la ruta pública devuelve un 404 desde caché. La prosa fluida puede ocultar fallas.
La evidencia tiene que convertirse en una superficie. El usuario debería ver la afirmación, el respaldo y la brecha:
| Tipo de afirmación | Evidencia requerida |
|---|---|
| Código cambiado | Rutas de archivos y diferencias |
| Pruebas aprobadas | Comando, estado de salida y resultado relevante |
| Contenido preciso | Enlaces a fuentes y alineación entre afirmación y fuente |
| Ruta SEO funciona | Metadatos renderizados, schema y archivos de descubrimiento |
| Lanzamiento exitoso | Estado de la ruta en vivo y estado de caché |
| Traducción lista | Umbral local, filas D1, páginas en vivo y estado de revisión |
Esa superficie de evidencia cambia el comportamiento del agente. Cuando el sistema sabe que el cierre exige evidencia, el agente busca pruebas durante la tarea en lugar de escribir un resumen confiado al final.
El umbral de evidencia existe por esa razón. Obliga al agente a conectar afirmaciones con comportamiento observado. Las trazas de ejecución de agentes son el contrato del entorno de ejecución lleva el mismo argumento más lejos: la traza contiene más verdad que la respuesta final porque conserva el recorrido.
El AI Risk Management Framework de NIST importa aquí porque la confiabilidad entra en el diseño, el desarrollo, el uso y la evaluación, no solo en la elección del modelo.2 La evidencia es el punto donde esas fases llegan a la pantalla del usuario.
La recuperación pertenece al flujo principal
Las interfaces de agentes suelen tratar la falla como una excepción. El trabajo con agentes convierte la falla en algo rutinario.
Una consulta de búsqueda no encuentra nada. Una prueba falla. Un umbral de permisos bloquea la acción. Una verificación de traducción detecta un desajuste de formato. Un despliegue funciona, pero una CDN sirve HTML obsoleto. Una buena interfaz no entra en pánico ante esos estados. Hace obvia la recuperación.
La recuperación requiere cinco controles:
| Control | Propósito |
|---|---|
| Pausar | Detener el avance sin perder estado |
| Reanudar | Continuar después de una revisión o arreglo externo |
| Reintentar | Repetir un paso fallido con entradas modificadas |
| Bifurcar | Explorar una ruta alternativa sin sobrescribir la primera |
| Revertir | Deshacer trabajo reversible o marcar trabajo irreversible para reparación |
La ruta de recuperación debería estar cerca de las superficies de traza y evidencia. El usuario no debería tener que copiar un comando fallido desde una transcripción, inferir el directorio de trabajo y reconstruir manualmente el estado del agente. La interfaz ya conoce el paso fallido. La interfaz debería ofrecer la siguiente acción responsable.
Ese principio también aplica al trabajo de contenido. Cuando un umbral de calidad de traducción falla, la interfaz debería mostrar el idioma fallido, el segmento fallido, la razón y la ruta de reparación. Cuando una página pública falla en la verificación en vivo, la interfaz debería mostrar si falló la aplicación, la base de datos o la caché perimetral. El agente no debería dar por terminado un lanzamiento hasta que la ruta visible para el usuario funcione.
El criterio no es una instrucción de entrada
La IA para programar abarata la implementación. Una implementación más barata eleva el valor del juicio.
La pregunta importante deja de ser “¿puede el agente hacer algo?” y pasa a ser “¿debería existir esta versión?”. Esa pregunta pertenece tanto a la interfaz como a la revisión humana.
El criterio aparece como restricciones:
- eliminar el paso innecesario;
- rechazar el camino ingenioso que debilita el producto;
- preservar la coherencia entre artefactos;
- verificar la ruta pública en lugar de celebrar el éxito local;
- proteger los mecanismos privados del texto público;
- elegir la solución más pequeña y precisa por encima de la más cargada.
Un agente puede recibir esos valores como prosa. La prosa ayuda. La prosa sola no garantiza el comportamiento. Los valores necesitan formas operativas: una habilidad de blog que bloquee frases perezosas, un verificador de citas que rechace afirmaciones sin respaldo, un verificador de lanzamiento que revise páginas en vivo, un umbral de detención que rechace el cierre sin evidencia y reglas de diseño que eviten la deriva visual.
La interfaz es donde el criterio se vuelve inspeccionable. El usuario ve qué rechazó el sistema, qué simplificó, qué verificó y qué dejó sin probar. Ese registro importa porque la salida de los agentes será cada vez más barata. Lo escaso será el estándar que decide qué sobrevive.
Un mapa práctico para interfaces de agentes
Los equipos pueden empezar con un mapa sencillo. No hace falta un panel futurista.
| Superficie | Versión mínima viable |
|---|---|
| Entrada de intención | Instrucción, tipo de tarea, alcance del repo o workspace |
| Plan | Supuestos, herramientas previstas, criterios de aceptación |
| Permisos | Cola por nivel de riesgo con cargas útiles completas |
| Memoria | Instrucciones activas, archivos cargados, advertencias de obsolescencia |
| Traza | Línea de tiempo de llamadas a herramientas, salidas y efectos secundarios |
| Evidencia | Afirmaciones asignadas a comandos, archivos, fuentes o brechas |
| Recuperación | Pausar, reintentar, bifurcar, revertir, cancelar |
| Lanzamiento | Ruta visible para el usuario, schema, descubrimiento, traducción, caché |
| Criterio | Rechazos, simplificaciones, estándares y mérito final |
El mapa funciona porque cada superficie responde a una responsabilidad del usuario. El usuario no necesita cada evento bruto. Necesita suficiente visibilidad y control para seguir siendo responsable del resultado.
Esa distinción evita dos errores comunes. Uno oculta todo detrás del chat y llama mágico al resultado. El otro expone cada evento interno y llama transparente al resultado. Un buen diseño de interfaz para agentes no hace ninguna de las dos cosas. Le da al operador el control correcto en el momento correcto.
Resumen rápido
La interfaz del agente es la capa operativa. La entrada recoge la intención, pero las herramientas, los permisos, la memoria, las trazas, la evidencia, la recuperación y el criterio determinan lo que realmente ocurre. Codex de OpenAI y los puntos de enlace de Claude Code muestran la dirección: los productos con agentes ya incluyen entornos de ejecución, llamadas a herramientas y puntos de decisión de políticas.43 MCP amplía la conexión entre agentes y sistemas externos.5 NIST y Microsoft aportan el marco previo de confianza y diseño humano-IA.21
La pregunta de producto ya no es si el agente puede responder. La pregunta de producto es si la superficie que lo rodea gobierna el trabajo autónomo lo bastante bien como para que una persona pueda confiar en el resultado, inspeccionarlo, interrumpirlo, repararlo y firmarlo.
FAQ
¿Qué significa “la interfaz es el arnés”?
La frase significa que la interfaz hace más que mostrar la salida del agente. Define la capa operativa alrededor del modelo: herramientas, permisos, memoria, trazas, evidencia, recuperación y estándares. Esas partes moldean el comportamiento antes de que aparezca la respuesta final.
¿Una interfaz de chat todavía puede servir para agentes?
El chat puede servir como superficie de entrada y como carril ligero de revisión. Falla cuando se convierte en la única superficie operativa. El trabajo con agentes necesita acceso no lineal, revisión de permisos, inspección de trazas, visibilidad de memoria y controles de recuperación.
¿En qué se diferencia esto de la ingeniería de instrucciones?
La ingeniería de instrucciones moldea la instrucción. El diseño de interfaz moldea autoridad, estado y rendición de cuentas. Una instrucción puede pedirle a un agente que verifique el trabajo. Una superficie de lanzamiento puede exigir evidencia de la ruta en vivo antes de cerrar la tarea.
¿Qué debería construir primero un equipo?
Construye primero las superficies de traza y evidencia. La traza muestra qué ocurrió. La superficie de evidencia muestra qué prueba el resultado. Los permisos, la recuperación y la memoria se vuelven más fáciles de diseñar cuando el equipo puede inspeccionar el recorrido del trabajo.
Referencias
-
Saleema Amershi et al., “Guidelines for Human-AI Interaction,” Microsoft Research, CHI 2019. Fuente primaria de 18 directrices de interacción humano-IA validadas con 49 profesionales del diseño. ↩↩↩
-
National Institute of Standards and Technology, “AI Risk Management Framework,” NIST. Fuente sobre el propósito voluntario de gestión de riesgos del marco y su encuadre de diseño, desarrollo, uso y evaluación. ↩↩↩
-
Anthropic, “Hooks reference,” Claude Code Docs. Fuente sobre eventos de puntos de enlace, campos de entrada de
PreToolUsey control de decisiones que puede permitir, denegar, preguntar, diferir o modificar llamadas a herramientas antes de la ejecución. ↩↩↩ -
OpenAI, “Introducing Codex,” OpenAI, mayo de 2025. Fuente sobre Codex como agente de ingeniería de software en la nube, sus tareas independientes en sandbox y su capacidad para leer archivos, editar archivos y ejecutar comandos. ↩↩
-
Model Context Protocol, “What is the Model Context Protocol?” Fuente sobre MCP como estándar abierto que conecta aplicaciones de IA con sistemas externos como fuentes de datos, herramientas y flujos de trabajo. ↩↩