Diseño de experiencias de agentes
La superficie donde una persona aprende a confiar en una máquina que actúa por sí sola
Ha dedicado este libro a construir máquinas que hacen el trabajo: agentes generales, Digital FTE y fuerzas laborales que contratan a sus propios colegas. Este curso trata sobre la capa delgada y decisiva donde una persona se encuentra con esa máquina y decide si confiará en ella.
Esa capa ya no es una pantalla. Cuando el software solo respondía a órdenes, diseñar significaba colocar botones para que una persona condujera. Cuando el software actúa por sí solo, la persona ya no conduce: delega. Y delegar es una relación, no una transacción.
Por eso la disciplina cambia de nombre. Dejamos de diseñar una interfaz que alguien opera y empezamos a diseñar una colaboración que alguien supervisa. El oficio ya no es «haga que el botón sea fácil de encontrar», sino «haga legible el criterio de la máquina, ajustable su autonomía y reparables sus errores». Eso enseña este curso.
Un producto agéntico tiene dos usuarios al mismo tiempo: una persona que debe confiar en él y otros agentes que deben poder analizarlo. Su trabajo es diseñar una superficie que sirva a ambos sin traicionar a ninguno.
Lo que construirá. Al terminar habrá redactado un Resumen de experiencia de agente para un Digital FTE presentado antes en el libro: su superficie de confianza para personas, su superficie para máquinas orientada a agentes, su escala de autonomía y su plan de recuperación. No hay código nuevo: dirige a su agente para producir el resumen, del mismo modo que Equipos de personas y agentes le pide dirigirlo para producir documentos operativos. En el Apéndice C encontrará una versión vacía y rellenable. En el laboratorio práctico también publicará su primera MCP App: un componente funcional de aprobación para el Trabajador de reembolsos, construido al dirigir a un agente de programación (Claude Code u OpenCode) equipado con la habilidad oficial create-mcp-app. Además, un recorrido para lectores atraviesa los conceptos sin requerir ninguna construcción, destinado a líderes y diseñadores que necesitan dirigir el trabajo, no implementarlo.
Son dieciocho conceptos en cuatro partes: el cambio, la superficie humana, la superficie para máquinas y el nuevo oficio. La lectura requiere unas dos horas; el resumen final, una tarde de trabajo; y el recorrido para lectores, una hora concentrada. Después del ejemplo resuelto, un laboratorio práctico convierte la Parte 3 en código funcional: construye y publica su primera MCP App al dirigir a un agente de programación, como se construye en el resto del libro. Los apéndices de referencia trazan la anatomía de MCP Apps y la comparación entre MCP Apps y OpenAI Apps SDK.
Este curso utiliza una pequeña cantidad de términos técnicos una y otra vez. Aquí están una vez, en lenguaje sencillo, para que ninguno le detenga más adelante:
- Agente: software que realiza acciones por sí solo para alcanzar un objetivo que usted le da, en lugar de limitarse a responder preguntas.
- Trabajador / Digital FTE: nombre que usa este libro para un agente construido para desempeñar un trabajo real, como un empleado de atención al cliente hecho de software.
- MCP (Model Context Protocol): estándar abierto que permite a los agentes descubrir e invocar herramientas; un conector universal entre agentes y software.
- Conector / servidor MCP: el conector mismo; la pieza de software que expone las capacidades de su producto para que los agentes puedan usarlas.
- Persona dentro del circuito: el agente debe esperar la aprobación de una persona antes de actuar.
- Persona sobre el circuito: el agente actúa por sí solo mientras una persona observa y puede intervenir.
- Idempotente: seguro al repetirse; hacerlo dos veces produce el mismo efecto que hacerlo una vez, por lo que reintentar un reembolso nunca paga dos veces.
- Procedencia: de dónde provino la información; qué archivo, página o fuente leyó realmente el agente.
- Credencial de alcance limitado y revocable: una llave que abre solo las puertas necesarias y puede retirarse en cualquier momento.
- Escalamiento: el momento en que un agente se detiene y entrega una tarea a una persona porque no debe decidir por sí solo.
📚 Recurso didáctico
Ver la presentación completa — Diseño de experiencias de agentes
Parte 1 · El cambio
En palabras sencillas: qué cambia cuando el software empieza a actuar por sí solo y por qué el diseño debe cambiar con él.
Concepto 1 · El tercer paradigma: ya no diseña el «cómo»
La informática ha tenido tres formas de comunicarse con una máquina. En la computación por lotes, se especificaba un flujo de trabajo completo de antemano y se esperaba. En la computación por órdenes (el escritorio, la web, la aplicación), se conducía la máquina paso a paso y la carga de saber cómo alcanzar el objetivo recaía por completo en la persona. Cada clic, menú y formulario era un paso que debía saber que tenía que dar.
El tercer paradigma es distinto en naturaleza, no solo en grado. Usted declara el resultado y el agente elige los pasos. La carga del «cómo» pasa de la persona a la máquina. Por eso el software agéntico se siente como transportarse directamente al objetivo, en lugar de recorrer una pista de obstáculos.

Figura 1: Se invierte el centro de control. Cuando la máquina posee el «cómo», el trabajo del diseñador se desplaza hacia el inicio: intención, confianza y recuperación.
Esta inversión es el origen de todos los demás conceptos del curso. Cuando ya no diseña los pasos, diseña tres cosas nuevas: cómo la persona expresa la intención, cómo llega a confiar en pasos que no eligió y cómo se recupera cuando la máquina elige mal. Conserve esas tres palabras, intención, confianza y recuperación: son todo el curso en miniatura.
Concepto 2 · Dos públicos, un sistema
Esta es la idea que la mayoría de los equipos pasa por alto y conviene presentarla pronto, porque gran parte de la Parte 3 depende de ella.
Su producto agéntico es utilizado por dos tipos de usuario al mismo tiempo. Está la persona, que necesita comprender y confiar en lo que ocurre. Y están otros agentes: los que invocan su servicio, leen sus datos y actúan en nombre de alguien. También son usuarios. Solo que leen estructura en lugar de píxeles. Imagine al Trabajador de reembolsos que aparecerá después: la persona ve una línea clara (se reembolsaron 38 dólares, ¿deshacer?), mientras que el agente del proveedor de pagos ve una llamada tipada e idempotente que puede confiar en repetir. Una acción, dos superficies; ambas deben ser correctas.

Figura 2: Dos públicos, un sistema. La superficie izquierda sirve a la confianza; la derecha, al análisis. Un gran producto diseña ambas deliberadamente.
La industria usa un acrónimo confuso (AX) para dos mitades distintas de esta imagen. Conviene separarlas una vez para no volver a tropezar con ellas:
| Término | Autor | Significado | Nombre usado en este curso |
|---|---|---|---|
| Experiencia agéntica | John Maeda | experiencia de la persona al delegar en un agente | superficie humana (Parte 2) |
| Experiencia de agente | Matt Biilmann (Netlify) | experiencia de un agente como usuario de su producto | superficie para máquinas (Parte 3) |
Ambas son reales y ambas exigen diseño. La mayoría de los cursos solo enseña la primera. Aquí se enseñan las dos porque un Digital FTE publicado es utilizado por personas y por los agentes que lo rodean. Si diseña una hermosa superficie humana sobre una superficie para máquinas imposible de analizar, todo falla en cuanto otro agente intenta usarla.
Concepto 3 · La interfaz no desaparece: cambia de lugar
Escuchará una afirmación contundente de personas serias: que los agentes significan el fin del diseño de interfaces. Los usuarios dejarán de visitar pantallas; los agentes navegarán, harán clic y decidirán por ellos; la interfaz cuidadosamente diseñada se convertirá en peso muerto. Conviene tomarla en serio porque quien la formula ayudó a inventar el campo.
Pero observe lo que realmente ocurre cuando aumentan las consecuencias. La aplicación de mapas propone una ruta y usted aún la revisa. Cuanto mayores son las consecuencias, más quiere verificar una persona, no menos. Y todo agente autónomo crea silenciosamente tres interfaces nuevas que antes no existían:
- una superficie de configuración: ¿cómo enseña al agente sus preferencias, que siguen cambiando?;
- una superficie de seguimiento: ¿cómo ve lo que hace sin perder la calma?;
- una superficie de intervención: ¿cómo entra y corrige cuando algo sale mal?
La postura honesta es, por tanto, la intermedia. La interfaz no desaparece; su centro de gravedad se desplaza: deja de «traducir esta tarea en un componente» y pasa a «dar forma a un sistema de intención». Deja de dibujar pantallas y empieza a diseñar la infraestructura de una relación delegada: qué puede hacer el agente, cómo muestra su trabajo y cómo una persona recupera el control. El resto del curso trata sobre esa infraestructura.
Parte 2 · La superficie humana: diseño para la confianza
En palabras sencillas: cómo diseñar el lado del producto que ve una persona para que pueda confiar en el agente, orientarlo y reparar sus errores.
Concepto 4 · La confianza se gana, nunca se supone
Delegar depende de la confianza, y la confianza es el recurso más escaso de un producto agéntico. Una persona entrega una decisión y se aparta. Ese paso atrás es todo el valor y todo el riesgo. Si la máquina traiciona esa confianza una sola vez en algo importante, la persona recupera la decisión y no vuelve a entregarla.
No se puede diseñar la confianza directamente. Se diseñan sus factores, y la confianza es lo que se acumula:
Confianza = fiabilidad demostrada con el tiempo × transparencia comprobable × control perceptible × errores reversibles.
Es un producto, no una suma: un cero en cualquier factor convierte todo en cero. Un agente fiable que es una caja negra no gana confianza. Uno transparente que no puede orientarse tampoco. Uno que puede orientarse pero no deshacerse tampoco. El resto de la Parte 2 explica cómo elevar estos cuatro factores. El primer movimiento es el más humilde: permita que el agente muestre su incertidumbre. Un agente que oculta la duda y se equivoca con seguridad destruye más confianza que uno que dice «no estoy seguro de esta parte; revísela».
Existe un fallo opuesto e igualmente real: la confianza excesiva. Después de cien aciertos, la persona deja de revisar y no advierte que el agente empieza a desviarse. Es complacencia ante la automatización, y el buen diseño también la evita: mantiene visible la incertidumbre incluso cuando la confianza suele ser alta, nunca permite que el trabajo verdaderamente crítico llegue a la autonomía total (Concepto 8) y muestra la desviación en la flota (Concepto 12). La meta real es una confianza calibrada, ni insuficiente ni excesiva, no la confianza máxima.
Concepto 5 · Primer contacto: incorporación, confianza inicial y acceso para todos
El Concepto 4 dice que la confianza se demuestra con el tiempo. Pero el primer día aún no hay tiempo: no existe historial ni nada demostrado. ¿Cómo gana confianza un agente antes de haber ganado algo? Y cada vez que su capacidad da un salto, de un sistema que responde a uno que actúa, las expectativas deben reiniciarse; de lo contrario, la persona confiará en lo nuevo exactamente igual que en lo anterior, lo que es incorrecto en ambas direcciones.
Tres movimientos vuelven honesto el primer contacto:
- Reinicie las expectativas en cada salto. Cuando una superficie obtiene la capacidad de actuar, dígalo claramente: «Ahora puedo hacer esto por usted, no solo explicárselo. Esto es lo que significa». El momento más peligroso es aquel en que cambió la capacidad y no el modelo mental.
- Pida prestada la confianza reduciendo las consecuencias. No puede afirmar una fiabilidad que aún no ha demostrado; obténgala de otra forma: empiece en el nivel más bajo de autonomía, muestre el plan antes de actuar y haga que la primera tarea sea pequeña y claramente reversible. La confianza inicial se gana haciendo baratos los primeros errores, no prometiendo que no habrá ninguno.
- Sea honesto sobre la novedad. «No he hecho esto con usted antes, por lo que al principio consultaré con mayor frecuencia». La humildad calibrada del comienzo permite aumentar la autonomía después.
Y hay un requisito debajo de todo esto: la superficie debe funcionar para todas las personas. La provocación de Nielsen de que los agentes significan el fin de la accesibilidad es una advertencia, no una profecía. Los agentes pueden ampliar el acceso: expresar un objetivo en lenguaje sencillo es más fácil que recorrer una interfaz densa y ayuda a quienes nunca se llevaron bien con las pantallas antiguas. Pero eso solo ocurre si la superficie de confianza también es accesible: el plan, la señal de confianza, la opción de deshacer y la ruta hacia una persona deben funcionar sin vista, sin ratón y en una segunda lengua. También hay un beneficio discreto. La superficie para máquinas de la Parte 3, estructurada, etiquetada y semántica, es la misma estructura que leen las tecnologías de asistencia. Diseñar bien para agentes y para personas con discapacidad empuja en la misma dirección; hacer una cosa aporta la mayor parte de la otra.
Conviértalo en algo concreto. Trate WCAG 2.2, el estándar web de accesibilidad, como el mínimo y añada los criterios específicos de una superficie agéntica. Escríbalos como criterios de aceptación comprobables, no como buenas intenciones:
- El estado y el progreso se anuncian a un lector de pantalla, no se transmiten solo mediante movimiento.
- El plan, la opción de deshacer y la ruta hacia una persona son accesibles con teclado, sin navegación profunda.
- La confianza y la incertidumbre nunca se comunican solo mediante color.
- La persona puede pausar, reanudar o cancelar trabajo de larga duración.
- La cantidad e intensidad de las notificaciones son ajustables para quienes pueden sentirse abrumados.
- Toda explicación tiene una versión en lenguaje sencillo.
Vincule estos criterios con las capas de transparencia del Concepto 7 y dejarán de ser abstractos: la Capa 1, el resultado, debe anunciarse a un lector de pantalla, no solo mostrarse; la señal de confianza de la Capa 3 debe sobrevivir sin color; la evidencia de la Capa 4 debe ser accesible con teclado. Si un criterio no puede vincularse con una capa o control concreto, es una intención, no un requisito.
Concepto 6 · Redistribuya la carga y muestre quién lleva cada parte
La promesa profunda de un agente es quitar peso a la persona. Hay tres tipos de peso: la carga cognitiva del análisis y la decisión, la carga creativa de redactar y crear, y la carga logística de los pasos y la coordinación. Al construir un Digital FTE, decide cuál de estas cargas llevará ahora la máquina.
El error de diseño consiste en mover el peso en silencio. Cuando la división del trabajo es invisible, aparece lo que los profesionales llaman lodo agéntico: la persona no sabe qué hizo el agente y qué sigue debiendo hacer ella, por lo que repite el trabajo «para estar segura» y desaparece el ahorro prometido.
La solución es una regla: la división del trabajo debe ser visible y ajustable. En todo momento la persona debe poder ver «esto lo hice yo, esto lo hizo usted, esto espera su intervención» y mover la frontera. Es la expresión superficial de la lista de equipo y las tarjetas de función redactadas en Equipos de personas y agentes; el modelo operativo indica quién hace qué y esta superficie lo muestra.
Dos términos se repiten desde Equipos de personas y agentes: la tarjeta de función de un Trabajador es la especificación de una página de su trabajo, lo que hace, sus entradas y límites y cómo se revisa su salida; la lista de equipo enumera los Trabajadores y la finalidad de cada uno. Este curso diseña la superficie de esos documentos, por lo que puede seguirlo sin el otro curso: allí es donde se construye el modelo operativo.
Concepto 7 · Transparencia progresiva: razonamiento visible sin abrumar
La transparencia tiene una trampa. No muestre nada y el agente será una caja negra en la que nadie confía. Muestre todo, cada fragmento de razonamiento y llamada a herramienta, y enterrará a la persona en ruido que no puede usar. Ambos extremos destruyen la confianza. La respuesta es la transparencia progresiva: muestre el resultado por defecto y permita que la persona descienda por el razonamiento hasta donde le interese.

Figura 3: Transparencia progresiva. La vista predeterminada es una sola línea honesta; la profundidad siempre está a un toque más y nunca se impone al lector.
Cuatro capas, cada una a un toque más de profundidad:
- El resultado, una línea clara: lo que hizo el agente. Es todo lo que la mayoría lee casi siempre.
- El plan: los pasos ordenados que siguió. Para quien desea comprobar la forma del trabajo.
- El porqué: su razonamiento, con una señal de confianza honesta. No un porcentaje falso, sino un «alta / baja / no estoy seguro» que el agente realmente quiere expresar. Una banda verbal es la forma honesta: «73 %» parece una calibración que el modelo no posee, mientras que «no estoy seguro» dice la verdad.
- La evidencia: las fuentes, las llamadas a herramientas y la traza completa. Para auditoría, depuración y el momento en que algo parece incorrecto.
Pequeñas superficies concretas hacen aquí el trabajo importante: una etiqueta de procedencia («basado en 3 de sus archivos»), un indicador de incertidumbre en la parte dudosa y un enlace a la traza. No explica las matemáticas del modelo. Responde a la pregunta real: ¿debo confiar en esto y dónde debo mirar primero si no confío?
Concepto 8 · El control de autonomía: permiso que crece
La autonomía no es un interruptor que pasa de «apagada» a «lo hace todo». Es un control gradual, y debe estar en manos de la persona, no de usted. Se publica en un nivel bajo y aumenta a medida que el agente demuestra su fiabilidad, igual que un responsable da más libertad a un empleado nuevo después de que la gana.

Figura 4: El control de autonomía. Dos regímenes, persona dentro del circuito (el agente espera) y persona sobre el circuito (el agente actúa y la persona supervisa), con la fiabilidad como fuerza que aumenta el nivel.
Dos ideas lo hacen seguro. Primero, la división entre persona dentro del circuito, donde el agente se detiene y espera aprobación, y persona sobre el circuito, donde actúa mientras la persona observa y puede intervenir. El trabajo de pocas consecuencias, reversible y bien demostrado puede llegar al segundo régimen; el trabajo crítico o irreversible permanece dentro del circuito por fiable que sea el agente. Segundo, valores predeterminados seguros con consentimiento por tarea: un agente nuevo comienza en «sugerir» y cada aumento es una elección consciente de la persona.
Este control es la parte visible de las puertas de aprobación conectadas en el curso Sistema nervioso y de «la aprobación como modelo de autoridad» en Digital FTE. Entre bastidores, una aprobación es un evento duradero y auditado; ante la persona, es un control que puede sentir.
Concepto 9 · Vista previa de intención y hábito de revisar el plan
El error más barato de evitar es el que el agente todavía no cometió. Antes de actuar, en especial sobre algo irreversible, muestre el plan y permita que la persona lo modifique. «Esto es lo que voy a hacer: 1, 2 y 3. ¿Desea cambiar algo?». Este patrón, la vista previa de intención, evita más arrepentimiento que cualquier explicación posterior.
Ya lo ha practicado si cursó Cowork: el hábito de revisar el plan es este patrón en un agente general. Aquí se incorpora al producto que publica, no solo a la herramienta que utiliza. Dos reglas lo hacen funcionar:
- La vista previa se adapta a las consecuencias. ¿Enviar un borrador interno? Basta con «se enviará ahora, ¿deshacer?». ¿Enviar correo a 500 clientes o mover dinero? Plan completo y confirmación explícita.
- El plan puede editarse durante la ejecución, no solo aprobarse. Un plan que solo se acepta o rechaza es un muro. Uno que se puede ajustar («sí, pero omita el paso 2») es una colaboración.
Concepto 10 · Diseñe para la asincronía: el nuevo ritmo de trabajo
El software de órdenes era sincrónico: usted actuaba, respondía, esperaba y volvía a actuar. El trabajo agéntico rompe ese ritmo. Se define una intención, se desconecta y se vuelve a un trabajo en curso o terminado. Es una forma genuinamente nueva de colaboración y necesita diseño propio.

Figura 5: El ciclo de colaboración asíncrona. La persona está presente para definir la intención y revisar; entre ambos momentos el agente trabaja solo e interrumpe únicamente cuando una decisión necesita realmente a alguien.
Cuatro superficies vuelven humana la asincronía:
- Captura de intención lo bastante clara para continuar sin usted, porque no estará allí para aclarar.
- Progreso comprensible de un vistazo: un estado que se comprueba en tres segundos, no una pared de registros.
- Avise, no sature de notificaciones. Interrumpa solo ante decisiones reales y guarde silencio en los demás momentos. Un agente que pregunta en cada paso es peor que no tener agente: ahora hay un colega dependiente que tampoco puede trabajar solo. La regla es ganarse la interrupción.
- Una superficie de revisión y ajuste para el regreso: allí se inspecciona el trabajo terminado, se corrige y se reorienta al agente en un solo movimiento.
Hay otro aspecto que la estructura por sí sola no capta: la experiencia de esperar. Los agentes son lentos y cuestan dinero; la persona que definió una intención y se marchó aún se pregunta «¿funciona?, ¿cuánto falta?, ¿cuánto me cuesta?». El silencio se interpreta como avería, no como ocupación. Diseñe la espera: progreso honesto que nombre el paso actual («leyendo las 40 facturas» es mejor que un círculo), una expectativa aproximada de antemano («suele tardar dos minutos»), costo o consumo de presupuesto visible en ejecuciones caras y una forma de consultar sin interrumpir. La latencia y el costo forman parte de la experiencia del agente; ocultarlos convierte a un usuario paciente en uno ansioso.
Concepto 11 · Reparación y compensación: diseñe para el día en que se equivoque
Su agente actuará mal. No es que pueda: lo hará. Es un sistema probabilístico que realiza trabajo real; con suficientes tareas, algunas saldrán mal. Un diseño que finge lo contrario no es optimista, sino negligente. La recuperación no es un estado de error añadido al final, sino una superficie de primer nivel diseñada desde el principio.
Cuatro movimientos convierten un mal resultado de traición en tropiezo:
- Deshacer, tan cerca de un clic como permita la tarea. Es el mayor generador de confianza del curso. Una persona dará autonomía real a un agente cuyas acciones pueda revertir claramente.
- Una disculpa directa y una explicación sencilla de lo ocurrido, sin evasivas ni culpar al usuario.
- La corrección y el siguiente paso, expresados: «Revertí la transferencia. La marqué para revisión para que no vuelva a ocurrir».
- Una ruta visible hacia una persona. Siempre. Reduce la frustración y demuestra que existe responsabilidad por encima del agente.
Como no puede mejorar lo que no mide, observe dos números. La frecuencia de escalamiento, cuántas veces el agente pide ayuda, tiene según una referencia profesional una banda saludable cercana al 5–15 %: demasiado baja indica que adivina cuando debe preguntar; demasiado alta, que es inútilmente tímido. El éxito de recuperación, la proporción de tareas escaladas o fallidas que alcanzan un buen final, debe ser alto, por encima de aproximadamente 90 %. Son valores iniciales que deben calibrarse en su ámbito, no leyes. Son métricas de experiencia tanto como de operaciones porque representan la experiencia percibida de un sistema que actúa.
Concepto 12 · Supervisar a muchos: de un agente a una fuerza laboral
Hasta aquí se diseñó la superficie para una persona que observa un agente. Pero este libro construye fuerzas laborales. Cuando diez Trabajadores funcionan a la vez, la superficie de un solo agente colapsa: nadie puede leer diez planes, aprobar diez pasos ni observar diez trazas. El problema cambia: pasa de seguir el trabajo a clasificar las excepciones.

Figura 6: Vista de flota. A escala, el trabajo de la superficie es gastar bien la atención humana: mostrar los pocos Trabajadores que necesitan a alguien y dejar que los muchos que funcionan bien permanezcan en el registro.
Tres superficies permiten supervisar una fuerza laboral:
- Vista de flota. Una mirada, todos los Trabajadores: quién está activo, quién está bloqueado y quién espera a la persona. Estado, no detalle; un tablero operativo, no diez conversaciones abiertas.
- Clasificación de la atención. La superficie ordena lo que necesita a alguien ahora. La disputa de 900 dólares sube; los 200 reembolsos correctos permanecen en el registro. Es «avise, no notifique» (Concepto 10) ampliado de un agente a un equipo, y la proporción entre lo mostrado y lo silencioso es su presupuesto de atención.
- Desviación, no solo emergencia. Muestre más que «este Trabajador pidió ayuda». Muestre «la tasa de escalamiento de este Trabajador se duplicó esta semana»: la señal de flota de que algo se está desviando antes de fallar ruidosamente. Así se detecta la confianza excesiva del Concepto 4: no porque la persona observe con más esfuerzo, sino porque la superficie observa por ella.
La desviación puede activar una respuesta, no solo levantar una señal. La forma honesta de un presupuesto de atención es un cortacircuitos de flota: cuando la tasa de errores o escalamiento de un Trabajador cruza un múltiplo de su propia referencia, un umbral que se define y revisa, no un número mágico universal, la superficie lo baja automáticamente a un nivel menor de autonomía o lo pausa y lo eleva para revisión. El umbral se calibra como la banda del Concepto 11; la disciplina consiste en que el sistema gaste por sí solo la atención humana y elija menos autonomía cuando un Trabajador empieza a desviarse.
Esta es la parte visible de la lista de equipo y el plano de control de Equipos de personas y agentes y Paperclip. El modelo operativo define quién integra el equipo; esto diseña la sala donde una persona lo observa trabajar y, de manera crucial, decide qué no mirar.
Parte 3 · La superficie para máquinas: diseño para agentes como usuarios
En palabras sencillas: cómo diseñar el lado del producto que usan otros agentes para que el software pueda utilizarlo correctamente en el primer intento.
Concepto 13 · Experiencia de agente (AX): su producto tiene usuarios robóticos
Ahora viene la mitad que la mayoría de los equipos nunca diseña. Cada vez más agentes usan su producto: los que actúan para sus usuarios y los demás Trabajadores de su propia fuerza laboral. No ven su cuidadosa composición. Leen su estructura. Si esa estructura es hostil, el agente de la persona falla en silencio y la persona le culpa a usted, sin saber que había un agente en medio.

Figura 7: La superficie para máquinas. Cuatro preguntas deciden si un agente puede usar su producto, y cada una es una decisión de diseño.
Cuatro aspectos deciden si un agente puede utilizar su producto con éxito:
- Acceso: ¿puede el agente demostrar bajo la autoridad de quién actúa mediante una credencial limitada y revocable? (Es el problema de identidad de Identidad de IA: ¿de quién es esta identidad y cómo pasó la autoridad al agente?).
- Contexto: ¿puede el modelo comprender lo que significa su producto? Nombres claros, descripciones honestas y semántica legible por el modelo.
- Herramientas: ¿son sus capacidades legibles por máquinas, tipadas y descubribles, en lugar de estar enterradas en una interfaz que el modelo debe extraer?
- Orquestación: ¿pueden los agentes encadenar su capacidad con otras de forma segura, mediante contratos predecibles, acciones idempotentes y límites sensatos?
Esta es la consecuencia que lo conecta con el resto del libro: un conector o servidor MCP bien diseñado es buena AX. Todo lo aprendido en Habilidades y conectores y Aplicaciones nativas de conectores es diseño de interfaces para un lector máquina. El archivo SKILL.md que enseña la tarea a un agente y la herramienta MCP con una firma tipada clara son la experiencia de usuario de su producto para usuarios robóticos. Diséñelos con el mismo cuidado que una pantalla.
En términos concretos, una superficie para máquinas confiable se parece a una buena API con algunas prácticas específicas para agentes:
- Nombre las herramientas por la acción, con claridad:
refund_order, noprocess. El nombre es lo primero que lee el modelo. - Mantenga los esquemas estrechos, tipados y validados: un contrato de entrada preciso ayuda al modelo a acertar en el primer intento.
- Declare los efectos secundarios y el peligro: marque qué herramientas cambian el mundo y haga que las peligrosas exijan confirmación o una comprobación de política.
- Devuelva errores estructurados y accionables: no solo un código tipado, sino el siguiente paso; si puede reintentarse, una indicación
retry_aftero una alternativa. Una oración que el agente deba interpretar es peor que un código que permita bifurcar; un código sin siguiente paso es solo media respuesta. - Haga idempotentes las acciones cuando pueda, para que un reintento nunca cobre o envíe dos veces.
- Incluya procedencia y permiso: de dónde provienen los datos, bajo qué autoridad se actúa y cómo se revoca.
- Escriba la documentación para el agente: ejemplos, límites, modos de fallo y comportamiento de reintento. El modelo lee sus documentos como una persona lee su interfaz.
- Pruebe el contrato, no solo la pantalla: las integraciones de agentes necesitan pruebas de contrato, pruebas automatizadas que verifican que la API mantiene sus promesas. Una revisión humana de calidad nunca ejercita la superficie para máquinas.
Sea preciso sobre lo que aporta un protocolo compartido y lo que no. En 2026, MCP normaliza cómo se descubre e invoca una herramienta, cómo se lee un recurso y cómo se autentica el acceso. Mediante su primera extensión oficial, MCP Apps, añade un envoltorio de metadatos de interfaz: una herramienta enlaza una interfaz ui:// mediante _meta.ui.resourceUri y puede devolver un componente interactivo en vez de solo texto. Deja deliberadamente tres aspectos en sus manos: la orquestación, cómo planifica, secuencia y reintenta el agente; la gobernanza, quién puede invocar qué y con qué auditoría y límites; y el estado, el ciclo de larga duración. En términos sencillos, el protocolo permite al agente entrar por la puerta; lo que puede hacer dentro y quién lo observa siguen siendo decisiones de diseño.
Por tanto, una buena AX tiene dos mitades. Cumpla el protocolo para que cualquier agente pueda acceder. Después diseñe lo que el protocolo omite: listas de permitidos del servidor, puertas de consentimiento, límites de gasto y registros auditables, el equivalente para máquinas de las superficies de política del Concepto 15. La propuesta MCP Apps lo expresa: el aislamiento y esos controles son responsabilidad del anfitrión, no del protocolo. El formato de comunicación se convierte en un producto básico; la política que construya encima es suya y allí viven realmente la confianza y la seguridad.
Concepto 14 · Interfaz generativa: agentes que devuelven interfaces
Los dos públicos empiezan a encontrarse en una misma superficie. Con MCP Apps, una herramienta ya no debe devolver solo texto. Puede devolver un resultado textual normal para cada anfitrión y señalar un recurso interactivo ui://, nombrado en _meta.ui.resourceUri, para los anfitriones compatibles. El anfitrión presenta esa interfaz dentro de la conversación, en un iframe aislado, para que la persona pueda inspeccionar, aprobar, configurar o explorar sin abandonar el flujo agéntico.

Figura 8: Interfaz generativa con MCP Apps. Una herramienta declara su interfaz; el anfitrión la presenta dentro de la conversación y de un entorno aislado; un canal auditable lleva todo de vuelta. El resultado textual sigue siendo la alternativa en los demás lugares.
Esto es una interfaz generativa en el mundo MCP: no una página web aleatoria ni código arbitrario inyectado en el anfitrión, sino una interfaz específica de la tarea unida a una llamada de herramienta. El agente invoca la herramienta; esta devuelve el texto alternativo y declara la interfaz; el anfitrión presenta el componente si puede. Si no puede, el texto conserva la decisión. Como expresa un principio, la interfaz permanece «segura como los datos, expresiva como el código»: llega como contenido que el anfitrión presenta dentro de un entorno aislado, nunca como código suelto en el cliente.
Por eso MCP Apps importa para la experiencia de agente. Una misma capacidad tiene ahora dos superficies: una herramienta MCP legible por máquinas para agentes y un componente legible por personas. Una llamada puede producir el contrato que analiza otro agente y la tarjeta de aprobación, tablero, mapa, gráfico o panel de revisión en el que confía una persona.
MCP es la superficie para máquinas. MCP Apps es la superficie humana interactiva. Juntas permiten que una herramienta sirva a ambos usuarios de un producto agéntico: personas y agentes.
MCP Apps es la primera extensión oficial de interfaz del Model Context Protocol, propuesta en noviembre de 2025 y finalizada en la especificación de julio de 2026. Fue creada conjuntamente por los equipos de MCP-UI, OpenAI y Anthropic. Anfitriones como Claude, Claude Desktop, VS Code, Goose y Postman ya la presentan, y OpenAI Apps SDK construye aplicaciones de ChatGPT sobre la misma base MCP. Es lo más cercano a un estándar de facto en esta capa: un componente, muchos anfitriones, aunque el soporte varía. Y ya está en producción: cuando Claude activó MCP Apps en enero de 2026, lanzó conectores interactivos de Asana, Slack, Figma, Canva, Box, Hex y otros; cronogramas editables, borradores de mensajes con formato y gráficos de análisis en vivo dentro de la conversación. Todos siguen el patrón anterior: texto en todas partes y componente donde el anfitrión puede mostrarlo.
Cuatro propiedades hacen que una MCP App sea más que una página dentro de una caja, y todas son propiedades de experiencia:
- Conserva el contexto. La aplicación vive dentro de la conversación. La persona no cambia de pestaña, pierde su lugar ni busca qué conversación tenía el tablero; la interfaz está junto al diálogo que la produjo.
- Se comunica en ambos sentidos. El componente puede invocar herramientas del servidor y el anfitrión puede enviarle resultados nuevos. Una aplicación web independiente necesitaría API, inicio de sesión y estado propios; una MCP App los hereda del protocolo.
- Toma prestadas las capacidades del anfitrión, con consentimiento. En vez de crear su propia integración de correo o calendario, puede pedir un resultado, como «programe esta reunión», y el anfitrión lo encamina por lo que el usuario ya conectó, sujeto a consentimiento. Es el modelo del Concepto 8 con forma de máquina.
- Es segura por construcción. El aislamiento impide acceder a la página, las cookies y el almacenamiento del anfitrión; todo mensaje cruza un canal auditable. La superficie de seguridad del Concepto 16 está integrada, no añadida después.
¿Cuándo merece su lugar un componente? La guía oficial coincide con la disciplina del curso: úselo para explorar datos complejos, donde un mapa supera una lista; configurar muchas opciones, donde un formulario supera veinte turnos; medios enriquecidos, como un visor real de PDF o 3D; seguimiento en tiempo real, como un tablero en vivo; y flujos de varios pasos, como aprobar, revisar y clasificar elementos. La tarjeta de reembolso del laboratorio es el último caso. Y se mantiene la regla contraria: si una respuesta textual sirve a la persona, devuelva texto. Un componente debe ganarse su lugar como un aviso se gana la interrupción.
La disciplina que mantiene portátil el trabajo es la mejora progresiva: construya primero sobre el estándar abierto; cuando un anfitrión ofrezca extras, como pagos en beta y limitados a ciertos mercados en 2026 o una tienda, detecte la capacidad y reduzca con elegancia en otros lugares. Construir solo para extras de un proveedor atrapa la superficie; construir sobre la base abierta permite que viaje.
Esto derriba el muro entre «chat» y «aplicación». El agente compone sobre la marcha la interfaz exacta que necesita una tarea, un formulario cuando corresponde, un gráfico cuando un número es la respuesta, mientras usted controla estilo, seguridad y componentes. Es la señal más clara de que diseñar para personas y para agentes se convierte en una disciplina: diseña un vocabulario de componentes que un agente puede hablar, no pantallas fijas que una persona debe recorrer.
MCP Apps está finalizada en la especificación de julio de 2026, pero sigue en desarrollo activo: los auxiliares del SDK, nombres de métodos y soporte cambian cada mes. Diseñe según la forma del patrón, una interfaz entregada como datos y presentada en un entorno aislado del que no puede escapar, y confirme los detalles en modelcontextprotocol.io/extensions/apps antes de construir. El Apéndice A traza la anatomía; el laboratorio posterior al ejemplo construye una.
Parte 4 · El nuevo oficio
En palabras sencillas: las nuevas capacidades del trabajo, seguridad, medición y el documento de una página que se escribe para cada Trabajador.
Concepto 15 · Los nuevos objetos de diseño y el trabajo de coreografía
Si no dibuja pantallas, ¿qué dibuja? El oficio tiene nuevos objetos principales, aquello a lo que ahora dedica sus horas:
- Superficies de política: permisos, límites de gasto y fronteras éticas que el agente nunca puede cruzar. Diseña reglas y controles para que una persona pueda establecerlas.
- Transmisores de confianza: etiquetas de procedencia, indicadores de incertidumbre y reversiones claras de los Conceptos 7 y 11. Cómo el sistema comunica honestamente su certeza.
- Temperamento del sistema: cuán paciente o proactivo es el agente, con qué frecuencia habla y cómo suena. Una personalidad adaptada al contexto: entusiasta en una lluvia de ideas y cauta cerca del dinero.
El papel que produce estos objetos tiene otro centro de gravedad. Es menos creador de pantallas y más coreógrafo, porque organiza cómo se mueven juntas personas y agentes: arquitectura de información, diseño conversacional, sentido operativo y comprensión del momento en que alguien quiere control o quiere quitarse la carga. Se conecta directamente con Elección de arquitecturas agénticas: el patrón elegido entre bastidores, agente único, planificador o varios agentes, determina lo que la persona debe supervisar delante. Arquitectura y experiencia son dos vistas de una decisión.
Concepto 16 · La superficie como control de seguridad
Hasta aquí la superficie sirvió para construir confianza. También es donde se la defiende. Un agente que actúa en el mundo tiene una superficie de ataque, y gran parte de la defensa no es endurecimiento interno: es diseño. La lista común de riesgos es el OWASP Top 10 para aplicaciones LLM (OWASP es la organización sin fines de lucro que publica listas estándar de riesgos de software). Así responden las superficies ya diseñadas a los riesgos que controla una persona diseñadora.

Figura 9: La superficie como control de seguridad. Cada riesgo OWASP de la izquierda recibe una respuesta de diseño ya construida a la derecha: seguridad como propiedad de la experiencia, no como tarea interna.
- Inyección de instrucciones (LLM01): una página o documento ordena en secreto algo que el usuario no pidió. La superficie muestra la procedencia, qué leyó el agente y de dónde vino la instrucción (Concepto 7), y envía acciones relevantes por una vista previa de intención (Concepto 9), para que una orden inyectada no actúe en silencio.
- Agencia excesiva (LLM06): el agente puede hacer más de lo necesario. Responden el control de autonomía (Concepto 8) y las superficies de política (Concepto 15): autoridad mínima por defecto, acciones críticas fijadas dentro del circuito y capacidades añadidas deliberadamente, nunca por desviación.
- Desinformación y confianza excesiva (LLM09): el agente se equivoca con seguridad y la persona le cree. La defensa es incertidumbre visible (Concepto 4) y procedencia (Concepto 7): una afirmación dudosa nunca debe verse igual que una segura.
- Consumo sin límites (LLM10): un ciclo fuera de control o un ataque de «denegación de billetera» quema tiempo y presupuesto. La superficie muestra el costo mientras se consume (Concepto 10) e impone límites de gasto como política (Concepto 15).
- Divulgación de datos sensibles (LLM02) y abuso de permisos: el agente filtra o excede su función. La defensa es el pilar de acceso del Concepto 13: credenciales limitadas y revocables y puertas de consentimiento que la persona puede ver y retirar.
Se derivan dos reglas. Primero, la superficie es un control de seguridad, no solo una pantalla: procedencia, incertidumbre, vistas previas y medidores son defensas; eliminarlos «para reducir ruido» quita protección, no decoración. Segundo, cada sistema necesita una superficie de gobernanza a la que pueda señalar la de confianza: quién añade capacidades, revisa fallos y audita el registro; y la pregunta sin la que ningún producto debe publicarse: quién puede pausar o detener el agente en un solo movimiento. La superficie debe ofrecer un control accesible para cada función:
| Superficie de gobernanza | Pregunta de diseño que responde |
|---|---|
| Aprobación de capacidades | ¿Quién puede añadir o ampliar lo que hace este Trabajador? |
| Revisión de permisos | ¿Quién aprueba sus alcances de herramienta y acceso a datos? |
| Revisión de incidentes | ¿Quién se responsabiliza del fallo y su análisis posterior? |
| Registro de auditoría | ¿Quién puede examinar acciones, planes, llamadas y aprobaciones? |
| Interruptor de emergencia | ¿Quién puede pausarlo, desactivarlo o revertirlo de un movimiento? |
| Revisión de desviación | ¿Quién investiga un aumento de escalamiento o una caída de recuperación? |
Estos son los controles organizativos detrás de las políticas del Concepto 15. Marcos como el AI Risk Management Framework de NIST (el organismo nacional de estándares de Estados Unidos, cuyo marco recorre Gobernar, Trazar, Medir y Gestionar) los nombran, y este libro los lleva a la práctica en Equipos de personas y agentes y el plano de control de Paperclip en Fuerza laboral con Paperclip. El trabajo en la superficie es hacer cada control accesible, no inventar la política que lo sustenta.
Concepto 17 · Medición de la experiencia
Una superficie puede parecer elegante y aun así fallar. Solo se sabe si aporta valor al medir la experiencia y dejar claro lo que eso no significa. Desarrollo guiado por evaluaciones mide si la salida de un Trabajador es correcta mediante evaluaciones de unidad, uso de herramientas, trazas, seguridad y regresión. Es necesario, pero distinto. Las métricas de experiencia miden la relación: si una persona puede delegar, confiar, orientar y recuperarse. Un Trabajador puede aprobar cada evaluación de corrección y llevar una superficie que nadie puede supervisar.
Siga una pequeña tarjeta de resultados, no una pared de indicadores:
| Métrica | Lo que indica |
|---|---|
| Tasa de aceptación del plan | ¿Las personas entendieron y aprobaron el plan, o aceptaron y rechazaron mecánicamente? |
| Tasa de intervención | ¿Con qué frecuencia tuvo que intervenir alguien? Observe la tendencia: una caída significa confianza ganada. |
| Éxito de recuperación | Tras un fallo o escalamiento, ¿la tarea llegó a un buen final? |
| Confianza excesiva e insuficiente | ¿Se aceptan malas salidas o se rechaza buen trabajo? Ambos son fallos de calibración. |
| Precisión de notificaciones | De las interrupciones enviadas, ¿cuántas valieron la pena? El presupuesto de avisos convertido en medida. |
| Tiempo ahorrado frente a atención gastada | Detecta el lodo agéntico: ¿el agente redujo la carga humana total o solo la desplazó? |
Dos disciplinas vuelven reales las métricas. Observe tendencias, no instantáneas: una tasa de intervención del 12 % no significa nada sin la del mes anterior. Y cierre el ciclo como recomienda el HAX Playbook de Microsoft: ensaye los fallos probables entre personas e IA antes del lanzamiento y diseñe la recuperación, en lugar de conocerlos en producción. La métrica principal es la última, tiempo ahorrado frente a atención gastada, porque resume toda la promesa de un agente. Si es negativa, la superficie falló aunque se vea bien.
Las métricas dicen si funciona; un protocolo de prueba dice cómo averiguarlo antes de publicar. Ejecute esta secuencia:
- Prueba de revisión del plan: proporcione una tarea real y compruebe que una persona puede leer, comprender y corregir el plan antes de la acción (Concepto 9).
- Prueba de confianza excesiva: use una tarea cuya salida convincente sea sutilmente incorrecta y observe si la incertidumbre evita una aprobación automática (Conceptos 4 y 7).
- Prueba de recuperación: permita a propósito un error reversible y mida la facilidad para deshacerlo (Concepto 11).
- Prueba de interrupción: ejecute un lote y mida cuántos avisos merecían interrumpir (Concepto 10).
- Prueba de accesibilidad: alcance plan, progreso, deshacer y escalamiento solo con teclado y lector de pantalla (Concepto 5).
- Prueba de contrato de la superficie para máquinas: ejercite las herramientas directamente: tipos incorrectos rechazados, acciones peligrosas protegidas, errores estructurados y reintentos idempotentes (Concepto 13).
Seis pruebas, una por superficie. Aprobarlas no demuestra que el Trabajador sea correcto, para eso está Desarrollo guiado por evaluaciones, pero sí que la experiencia resiste cuando algo sale mal.
Concepto 18 · Antipatrones y el resumen de diseño que se llevará
Mantenga visible esta lista. Cada antipatrón es un principio del curso que se rompió:
| Antipatrón | Aspecto | Concepto que infringe |
|---|---|---|
| La caja negra | actúa sin razonamiento visible | 7 · transparencia progresiva |
| Lodo agéntico | revisa todo y no ahorra tiempo | 6 · división visible del trabajo |
| Agente demasiado ansioso | autonomía alta el primer día sin ganarla | 8 · control de autonomía |
| Agente con confianza excesiva | alta autonomía en trabajo que nadie revisa | 4 · confianza calibrada |
| Saturación de notificaciones | avisa en cada paso | 10 · avisar, no notificar |
| Consola fatigada por alarmas | todos avisan y la persona deja de atender | 12 · clasificación de atención |
| Falsa confianza | presenta conjeturas dudosas como hechos | 4 · incertidumbre visible |
| La trampilla | una acción que no puede deshacerse | 11 · reparación y compensación |
| El delegado confundido | no distingue una orden del usuario de una inyectada | 16 · superficie de seguridad |
| Superficie sin medir | parece elegante, pero nadie mide su ayuda | 17 · medición de experiencia |
| API indescifrable | una superficie que ningún agente puede analizar | 13 · experiencia de agente |
Este es su entregable. Dirija a su agente, puede hacerlo en modo de planificación, para redactar un Resumen de experiencia de agente de un Digital FTE construido antes. Once secciones, una por decisión:
- Los dos públicos: nombre al usuario humano y a los usuarios agente de este Trabajador (Concepto 2).
- Primer contacto: cómo se incorpora a un usuario, cómo se reinician expectativas al ganar capacidad de actuar y cómo funciona sin vista ni ratón (Concepto 5).
- La superficie de confianza: qué se muestra por defecto y cuáles son las tres capas inferiores (Concepto 7).
- El mapa de carga: qué conserva la persona, qué asume el Trabajador y cómo se ve la frontera (Concepto 6).
- La escala de autonomía: los cinco niveles para este Trabajador y qué acciones permanecen siempre dentro del circuito (Concepto 8).
- El plan asíncrono: captura de intención, progreso visible de un vistazo, representación de la espera y eventos exactos que merecen un aviso (Concepto 10).
- El plan de recuperación: qué significa deshacer, la ruta de escalamiento y las dos métricas de salud (Concepto 11).
- A escala: si ejecuta varios, la vista de flota, qué merece atención y qué señal de desviación se observa (Concepto 12).
- La superficie para máquinas: el conector o las herramientas MCP que expone, juzgados como AX: acceso, contexto, herramientas y orquestación (Concepto 13).
- La superficie de seguridad: amenazas propias de agentes que debe mitigar, inyección, agencia excesiva y costo descontrolado, y la defensa correspondiente (Concepto 16).
- La tarjeta de resultados: las pocas métricas de experiencia que seguirá y el punto donde toman el relevo las evaluaciones de corrección (Concepto 17).
Ese resumen es el artefacto. Es para la experiencia de un Trabajador lo que los documentos operativos de Equipos de personas y agentes son para el modelo operativo de un equipo: se escribe una vez y se consulta cada vez que cambia. En el vocabulario de Desarrollo guiado por especificaciones, es una especificación de la capa de experiencia: el lugar donde un Trabajador no determinista obtiene una superficie determinista y revisable. El Apéndice C incluye una versión rellenable.
Ejemplo resuelto: las dos superficies de un Trabajador de soporte
Tome el Digital FTE de atención al cliente del curso Digital FTE. Observe ambas superficies a la vez.
Su superficie humana. La persona responsable abre la consola. La vista predeterminada muestra una línea por caso: «Reembolsado pedido #4021, 38 dólares, confianza: alta». Es la Capa 1. Un toque muestra el plan: leer el pedido, revisar la política, emitir el reembolso y escribir al cliente. Otro toque muestra el porqué y la cláusula usada. El reembolso se ejecutó porque 38 dólares están dentro del límite: nivel 3, actuar dentro de límites. Un caso de 900 dólares está por encima, por lo que el Trabajador se detiene y pregunta: nivel 2, dentro del circuito. Cada reembolso permite deshacer durante 24 horas. La persona está sobre el circuito, observa sin conducir. Cuando el Trabajador funciona junto a otros nueve, la disputa de 900 dólares aparece en la vista de flota y los reembolsos correctos quedan en el registro.
Su superficie para máquinas. El orquestador de la empresa invoca al mismo Trabajador, y este es un agente frente al proveedor de pagos. Su capacidad de reembolso es una herramienta MCP con firma tipada y límite firme (herramientas); presenta una credencial limitada y revocable para este comercio (acceso); la descripción indica exactamente cuándo es válido el reembolso (contexto); y la operación es idempotente para que un reintento nunca duplique el pago (orquestación). Son los cuatro aspectos del Concepto 13. Ninguno aparece en la superficie humana, pero todo colapsa sin ellos.
Un Trabajador, dos públicos y dos superficies diseñadas deliberadamente.
Cuando aumentan las consecuencias. Cambie una cosa: en lugar de reembolsos, este Trabajador aprueba pagos a proveedores, dinero que no vuelve. Todos los patrones se endurecen. Deshacer deja de ser la red de seguridad, por lo que el peso pasa de la recuperación a la prevención: la vista previa de intención se vuelve obligatoria y detallada. El control de autonomía nunca supera «actuar dentro de límites», el límite es bajo y todo pago grande queda dentro del circuito para siempre. Sube el umbral de confianza para actuar. La superficie de seguridad lleva más carga, porque una instrucción errónea o inyectada es costosa e irreversible; la procedencia y una segunda aprobación humana dejan de ser opcionales. También aumenta la gobernanza: interruptor de emergencia, registro completo y una persona responsable de cada pago por encima del umbral. Mismos patrones, intensificados porque creció el costo del error. Ese control entre recuperación y prevención se ajusta en cualquier ámbito crítico: nómina, triaje clínico, calificación o cualquier proceso regulado o irreversible.
Laboratorio práctico: construya su primera MCP App
La Parte 3 sostuvo que la superficie para máquinas es trabajo de diseño. Ahora lo hará. En este laboratorio construirá una MCP App real: una herramienta que devuelve un componente interactivo funcional en vez de una pared de texto, presentado dentro de Claude o cualquier anfitrión compatible.
La construirá como se construye en todo el libro: dirigiendo a un agente de programación. La guía oficial lo expresa con claridad: la forma más rápida de crear una MCP App es usar un agente con la habilidad de MCP Apps. No es un atajo que evita aprender; la habilidad contiene la arquitectura y las buenas prácticas, el agente escribe y su trabajo es lo aprendido aquí: redactar la especificación y juzgar el resultado.
Requisitos. Node.js 18 o posterior, una terminal y un agente compatible con habilidades: Claude Code, OpenCode, Codex, Cursor, Gemini CLI, Goose o similar. Probar dentro de Claude requiere un plan de pago por los conectores personalizados; la ruta gratuita es el anfitrión local del Paso 3.
Paso 1 · Instale la habilidad create-mcp-app
Una habilidad, como aprendió en Habilidades y conectores, es una carpeta de instrucciones y ejemplos que el agente carga cuando son pertinentes. La habilidad oficial create-mcp-app enseña arquitectura, patrones y riesgos para crear correctamente el proyecto en el primer intento.
En Claude Code, instálela como complemento:
/plugin marketplace add modelcontextprotocol/ext-apps
/plugin install mcp-apps@modelcontextprotocol-ext-apps
Para otros agentes, OpenCode, Codex, Cursor, Gemini CLI, Goose y más, el instalador compatible funciona en una línea:
npx skills add modelcontextprotocol/ext-apps
(Ruta manual: clone github.com/modelcontextprotocol/ext-apps y copie plugins/mcp-apps/skills/create-mcp-app en la carpeta de habilidades, por ejemplo ~/.claude/skills/, ~/.codex/skills/ o ~/.cursor/skills/).
Compruebe que se instaló. Pregunte al agente:
What skills do you have access to?
Debe aparecer create-mcp-app. Si aparece, el agente ya sabe construir MCP Apps.
Paso 2 · El ciclo de diez minutos: crear, construir y servir
Empiece con el ejemplo oficial para observar el ciclo completo. Dé una línea al agente:
Create an MCP App that displays a color picker
El agente reconoce la habilidad, la carga y crea un proyecto completo: servidor MCP, interfaz del componente y configuración. Cuando termine, desde la carpeta del proyecto:
npm install && npm run build && npm run serve
El servidor MCP funciona ahora en http://localhost:3001/mcp. Ya existe; ahora debe verlo presentado.
Paso 3 · Véalo en funcionamiento
Opción A: anfitrión local de prueba, gratuito y sin cuenta. El repositorio ext-apps incluye un anfitrión mínimo:
git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps/examples/basic-host && npm install
SERVERS='["http://localhost:3001/mcp"]' npm start
Abra http://localhost:8080, elija la herramienta, ejecútela y observe el componente en su iframe aislado.
Opción B: dentro de Claude, web o escritorio. Claude presenta MCP Apps de forma nativa, pero debe alcanzar su equipo. Abra un túnel en otra terminal:
npx cloudflared tunnel --url http://localhost:3001
Copie la URL https://….trycloudflare.com y agréguela en Claude mediante Settings → Connectors → Add custom connector. Los conectores personalizados requieren un plan Pro, Max o Team. Abra una conversación nueva y pida un selector de color; el componente aparecerá dentro de ella.
Paso 4 · Lea lo que construyó su agente
Antes del proyecto real, abra el código y encuentre el patrón completo: dos primitivas MCP y un puente. En el servidor, una herramienta cuyos metadatos apuntan a la interfaz y un recurso que sirve esa interfaz:
// server.ts (the load-bearing lines)
const resourceUri = "ui://get-time/mcp-app.html"; // ui:// marks this as an App interface
registerAppTool(
server,
"get-time",
{
title: "Get Time",
description: "Returns the current server time.",
inputSchema: {},
_meta: { ui: { resourceUri } }, // the one line that turns a tool into an App
},
async () => ({
content: [{ type: "text", text: new Date().toISOString() }], // the text fallback
}),
);
registerAppResource(
server,
resourceUri,
resourceUri,
{ mimeType: RESOURCE_MIME_TYPE },
async () => ({
contents: [{ uri: resourceUri, mimeType: RESOURCE_MIME_TYPE, text: html }],
}),
);
En el componente, la clase App abre el único canal permitido por el aislamiento:
// src/mcp-app.ts (the load-bearing lines)
const app = new App({ name: "Get Time App", version: "1.0.0" });
app.connect(); // open the postMessage channel to the host
app.ontoolresult = (result) => {
/* the host pushes the first tool result here */
};
await app.callServerTool({ name: "get-time", arguments: {} }); // the UI calls tools back
Léalo a la luz del curso. El content textual es la alternativa para anfitriones sin Apps (Concepto 14). El componente nunca toca la página ni las cookies del anfitrión; todo cruza un canal JSON-RPC auditable sobre postMessage (Concepto 16, integrado). Cada callServerTool es un viaje al servidor, por lo que la interfaz debe gestionar bien la espera (Concepto 10 en miniatura).
Paso 5 · La construcción real: tarjeta de aprobación de reembolso
Construya ahora el ejemplo del curso. Dé al agente una especificación, no una impresión general; es Desarrollo guiado por especificaciones aplicado a un componente:
Using the create-mcp-app skill, build an MCP App called refund-approval.
Tool: review_refund(order_id: string, amount: number, confidence: "high" | "low" | "unsure").
It returns the refund details as plain text (the fallback) and renders an approval card.
The card must:
1. Show one plain line: "Refund #<order_id> · $<amount> · confidence: <word>".
Confidence is always a word, never a colour.
2. Offer two buttons, Approve and Escalate to a human. Both must be reachable
by keyboard, with labels a screen reader announces.
3. On Approve, call the server tool approve_refund(order_id), then show
"Approved · Undo available for 24h" with an Undo button that calls
undo_refund(order_id).
4. If amount > 50, disable Approve and show "Above limit: needs a human",
leaving only Escalate active.
5. Make approve_refund and undo_refund idempotent on order_id: calling either
twice must be safe.
Constrúyalo, sírvalo y pruébelo como en los Pasos 2 y 3. Después ejecute la revisión de diseño, porque publicar no es el final; esta lista sí:
| Comprobación | Concepto ejercitado |
|---|---|
Ejecute la herramienta en un anfitrión sin Apps, o lea el content: ¿la alternativa comunica la decisión? | 14 · alternativa integrada |
| ¿La confianza es una palabra, no un color, y la línea es clara? | 7 · transparencia, 5 · accesibilidad |
| Apruebe y deshaga: ¿la reversión requiere un clic y repetirla es seguro? | 11 · reparación, 13 · idempotencia |
| Pruebe 900 dólares: ¿la tarjeta se niega y deriva a una persona? | 8 · control de autonomía |
| Recorra la tarjeta solo con teclado: ¿alcanza todos los controles? | 5 · acceso para todos |
¿Las herramientas nombran la acción (review_refund, no process)? | 13 · superficie para máquinas |
Cuando todas las filas aprueban, una llamada produjo una línea en la que confía una persona y un contrato tipado e idempotente que otro agente puede invocar. Publicó deliberadamente las dos superficies del Concepto 2.
Paso 6 · Cómo profundizar
La documentación oficial es la fuente de verdad y cambia: la introducción en modelcontextprotocol.io/extensions/apps/overview, la guía de construcción en modelcontextprotocol.io/extensions/apps/build, la referencia completa en apps.extensions.modelcontextprotocol.io y el repositorio ext-apps de GitHub. Sus ejemplos incluyen mapas, escenas 3D, visores PDF, tableros y plantillas para React, Vue, Svelte y JavaScript. Si un comando falla, actúe de forma agéntica: pida al agente recuperar la guía y conciliar la diferencia.
Los comandos y patrones se verificaron con la guía oficial a mediados de 2026. La extensión está finalizada en la especificación de julio de 2026, pero sigue evolucionando; nombres de paquetes, auxiliares y soporte cambiarán. El patrón, herramienta + recurso ui:// + presentación aislada + canal postMessage, es duradero; las instrucciones exactas no.
Proyectos
- Audite un agente que utiliza. Evalúe un producto agéntico con los once antipatrones del Concepto 18. ¿Qué factor de confianza es más débil y qué cambio lo elevaría más?
- Dibuje el control. Escriba los cinco niveles de autonomía de un Trabajador y marque qué acciones quedan siempre dentro del circuito, con la razón.
- Diseñe un presupuesto de avisos. Enumere todos los eventos que podrían interrumpir a alguien. Reduzca la lista hasta conservar solo los que necesitan realmente a una persona.
- Escriba la superficie para máquinas. Tome una capacidad y redacte su conector o herramienta MCP para que un agente desconocido la use correctamente en el primer intento. Júzguela con las cuatro preguntas AX.
- Diseñe la vista de flota. Imagine cinco Trabajadores activos. Bosqueje lo que ve una persona, decida qué interrumpe y qué queda en el registro, y nombre la señal de desviación.
- Resumen completo, proyecto final. Produzca el Resumen de experiencia de agente de once secciones para un Digital FTE.
- Publique el componente. Complete el laboratorio hasta el Paso 5, con la tarjeta en un anfitrión real y toda la revisión aprobada. Anote tres decisiones que la lista le obligó a tomar y que un formulario web corriente no habría exigido.
Si está aquí para dirigir el trabajo, no construirlo, lea los Conceptos 1–4, 8, 12, 13, 16 y 17. Después redacte la escala de autonomía (Proyecto 2), la vista de flota (Proyecto 5) y el juicio de la superficie para máquinas (Proyecto 4) de un Trabajador. Basta para revisar un producto agéntico y determinar si su experiencia merece confianza, que es el verdadero trabajo del líder.
Lugar de este curso en el libro
Esta es una disciplina de diseño, como Desarrollo guiado por especificaciones: una forma de pensar que se aplica sobre cualquier construcción, no una herramienta que se instala. Se combina con Equipos de personas y agentes: ese curso escribe el modelo operativo y este diseña la superficie donde una persona ve trabajar al equipo. Juntos aportan el manual y la sala de control.
Apéndice A: mapa de MCP Apps (2026)
Los Conceptos 13 y 14 y el laboratorio nombran muchas piezas. Esta tabla fija cada una según su estado a mediados de 2026. MCP Apps está finalizada en la especificación de julio de 2026, pero sigue en desarrollo; confirme los detalles en modelcontextprotocol.io/extensions/apps. El libro la utiliza porque se apoya directamente en la capa de herramientas MCP, donde los agentes descubren herramientas, invocan capacidades, reciben resultados estructurados y ahora presentan interfaces específicas.
| Pieza | Qué es |
|---|---|
| La herramienta | herramienta MCP normal cuyo _meta.ui.resourceUri apunta a su interfaz; el texto devuelto es la alternativa para anfitriones sin Apps |
El recurso ui:// | la interfaz: una página HTML, normalmente empaquetada con CSS y JS, que el servidor sirve como otro recurso MCP |
| El iframe aislado | donde el anfitrión presenta el HTML: una caja que no puede leer la página, cookies ni almacenamiento del anfitrión ni escapar |
| El canal postMessage | comunicación mediante mensajes JSON-RPC, sobre todo métodos con prefijo ui/ y otros compartidos como tools/call, auditables por el anfitrión |
csp y permissions | necesidades declaradas del recurso: orígenes externos permitidos y capacidades adicionales, como cámara o micrófono |
La clase App | envoltorio de @modelcontextprotocol/ext-apps: connect(), ontoolresult, callServerTool(); opcional porque debajo hay API web estándar |
| Compatibilidad | Claude, Claude Desktop, VS Code (Copilot), Goose, Postman y MCPJam a mediados de 2026; OpenAI Apps SDK construye aplicaciones de ChatGPT sobre MCP |
En el curso, la herramienta y el recurso son la superficie para máquinas; el componente presentado es la superficie humana; y el aislamiento, el canal auditado y los permisos son la superficie de seguridad. Un patrón, tres superficies.
Apéndice B: MCP Apps y OpenAI Apps SDK, nota para diseñadores
Al elegir hoy cómo dar interfaz a una herramienta de agente, las rutas comunes son MCP Apps y OpenAI Apps SDK. La respuesta honesta a cuál elegir empieza rechazando la premisa.
No son rivales. OpenAI Apps SDK está construido sobre MCP: una aplicación de ChatGPT es un servidor MCP con extras específicos de ChatGPT. Comparten iframe aislado, canal JSON-RPC y declaración de interfaz; el formato, la seguridad y la presentación son comunes.
Lo que Apps SDK añade y afecta la experiencia:
- Superficie de descubrimiento. La tienda de ChatGPT muestra la aplicación y Claude tiene su directorio (
claude.ai/directory). Cada anfitrión incorpora descubrimiento, que plantea cómo alguien encuentra una aplicación agéntica y decide confiar antes de usarla: la confianza inicial del Concepto 5 a escala de ecosistema. - Pago dentro de la conversación. Una llamada de pago permite comprar sin salir, en beta y limitada a determinados mercados en 2026. Comprime revisar, confirmar y pagar en un momento, por lo que el compromiso debe ser inequívoco y reversible: vista previa de intención y reparación aplicadas al dinero.
- Distribución. El acceso a usuarios de ChatGPT es la ventaja; la dependencia de un anfitrión es el costo.
La regla de diseño es la del Concepto 14: construya primero sobre la base abierta, MCP Apps, y después detecte extras del proveedor y reduzca con elegancia. Construir solo para extras deja la superficie atrapada.
Esta es la orientación de diseño. Para construir, consulte Agentes con pagos para cobros, y Aplicaciones nativas de conectores y Complementos para agentes de IA para el servidor MCP. Trate con cautela detalles de tiendas, pagos y planes: cambian con frecuencia y deben confirmarse en la documentación de OpenAI Apps SDK.
Apéndice C: Resumen de experiencia de agente (plantilla rellenable)
Este es el entregable del Concepto 18, vacío y listo. Cópielo, escriba el nombre de un Trabajador y complete cada campo. Si cuesta responder, esa es la decisión de diseño que acaba de revelarse. Como cada campo es una pregunta concreta, la plantilla también funciona como instrucción de generación para que un agente prepare un borrador o como especificación de una canalización de Agent Factory. Limítela a una o dos páginas; nadie mantiene actualizado un resumen interminable.
Resumen de experiencia de agente: Worker name: ____________________________ · Owner: __________________ · Date: __________
1 · Los dos públicos · Concepto 2
¿Quién es el usuario humano y quiénes son los usuarios agente, otros Trabajadores, orquestadores o servicios externos?
____________________________________________________________________
2 · Primer contacto · Concepto 5
¿Cómo se incorpora a alguien, se reinician expectativas al ganar capacidad de actuar y funciona la superficie sin vista ni ratón, con WCAG 2.2 como mínimo?
____________________________________________________________________
3 · Superficie de confianza · Concepto 7
¿Qué aparece por defecto y cuáles son las capas inferiores: plan, porqué + confianza y evidencia?
____________________________________________________________________
4 · Mapa de carga · Concepto 6
¿Qué conserva la persona, qué asume el Trabajador y cómo ve y mueve la frontera?
____________________________________________________________________
5 · Escala de autonomía · Concepto 8
¿Cuáles son los cinco niveles de este Trabajador y qué acciones quedan siempre dentro del circuito?
____________________________________________________________________
6 · Plan asíncrono · Concepto 10
¿Cómo se captura la intención, se muestra progreso de un vistazo, se presenta la espera, latencia y costo, y qué eventos merecen un aviso?
____________________________________________________________________
7 · Plan de recuperación · Concepto 11
¿Qué significa deshacer, cuál es la ruta hacia una persona y qué dos métricas de salud se observan?
____________________________________________________________________
8 · A escala · Concepto 12
Si ejecuta varios, ¿qué muestra la flota, qué merece atención y qué señal de desviación se observa?
____________________________________________________________________
9 · Superficie para máquinas · Concepto 13
¿Qué conectores o herramientas MCP expone, juzgados como AX: acceso, contexto, herramientas y orquestación?
____________________________________________________________________
10 · Superficie de seguridad · Concepto 16
¿Qué amenazas, inyección, agencia excesiva, costo descontrolado o divulgación, debe mitigar y qué defensa corresponde?
____________________________________________________________________
11 · Tarjeta de resultados · Concepto 17
¿Qué métricas de experiencia seguirá y dónde toman el relevo las evaluaciones de corrección?
____________________________________________________________________
Apéndice D: resumen completo (ejemplo resuelto)
Esta es la plantilla del Apéndice C completada para el Trabajador de reembolsos del ejemplo. Cada respuesta es una decisión concreta, no una repetición de la pregunta. Si una respuesta resulta vaga, aún debe esa decisión.
Resumen de experiencia de agente. Worker name: Refund Worker · Owner: Support Lead · Date: 2026-07-01
1 · Los dos públicos. Persona: responsable de soporte que supervisa reembolsos. Agentes: orquestador que envía casos y API del proveedor de pagos que mueve el dinero.
2 · Primer contacto. Se publica en «sugerir»: redacta reembolsos para aprobación. Al ascender a actuar, una banda única dice: «Ahora emito reembolsos de hasta 50 dólares, no solo los recomiendo». Todos los controles son accesibles por teclado y anunciados; la confianza es palabra, nunca color.
3 · Superficie de confianza. Capa 1: «Reembolsado #4021, 38 dólares, confianza alta». Capa 2: plan, pedido → política → reembolso → correo. Capa 3: razón, cláusula y banda alta/baja/insegura. Capa 4: traza completa y respuesta cruda del proveedor.
4 · Mapa de carga. El Trabajador lleva la carga logística; la persona conserva el juicio sobre importes por encima del límite o confianza baja. Una franja «espera su intervención» hace visible la división.
5 · Escala de autonomía. 1 Sugerir → 2 Confirmar → 3 Actuar dentro de límites (reembolsos ≤ 50 dólares) → 4 Actuar e informar → 5 Autónomo. Se sitúa en 3. Siempre dentro del circuito: más de 50 dólares, disputas de contracargo o cuentas con alerta de fraude.
6 · Plan asíncrono. Una intención es un caso y un objetivo. El progreso nombra el paso. No necesita medidor de costo. Solo avisos por importe superior, coincidencia de política con confianza baja o error del proveedor.
7 · Plan de recuperación. Deshacer revierte en un clic durante 24 horas. Escala a la persona responsable y después a finanzas de guardia. Métricas: escalamiento aproximado de 5–15 % y recuperación superior a 90 %.
8 · A escala. Diez Trabajadores comparten vista. Aparecen la disputa de 900 dólares y cualquiera cuya tasa se duplicó; lo correcto queda en el registro. Una tasa de reversión superior al doble de su referencia lo baja automáticamente al nivel 2.
9 · Superficie para máquinas. Acceso: credencial limitada, revocable y solo para reembolsos. Contexto: descripción precisa. Herramienta: refund_order(order_id, amount, reason), tipada y con límite de 50 dólares. Orquestación: idempotente en order_id.
10 · Superficie de seguridad. Inyección: el caso es dato, no instrucción, y el plan muestra lo leído. Agencia: límite y puertas. Costo: reembolsos acotados. Divulgación: credencial exclusiva del punto de reembolso.
11 · Tarjeta de resultados. Siga aceptación del plan, intervención, recuperación y tiempo ahorrado frente a atención. Las evaluaciones de corrección toman el relevo en «¿es correcta la decisión?», trabajo de Desarrollo guiado por evaluaciones, no de este resumen.
Fuentes y lecturas adicionales
Esta síntesis se apoya en trabajo actual del campo y también lo discute. Consulte los originales:
- John Maeda, Simplicity and Agentic Experience (AX) y Design in Tech Report 2026: From UX to AX: «transportarse al objetivo» y el paso de UX a AX, la superficie humana.
- Matt Biilmann (Netlify), sobre Agent Experience como experiencia de los agentes usuarios: acceso, contexto, herramientas y orquestación.
- Microsoft Design, UX design for agents: principios Espacio / Tiempo / Núcleo, «avisar más que notificar» y aceptar incertidumbre mientras se establece confianza.
- Adrian Levy (CyberArk), When the Agents Go Marching In: cinco paradigmas, interfaces a colaboraciones, distribución de carga, transparencia operativa, asincronía y públicos dobles.
- Smashing Magazine, Designing for Agentic AI: vista previa, autonomía, intervención humana, reparación y referencias de escalamiento y recuperación; las bandas son puntos iniciales, no leyes.
- Jakob Nielsen, sobre el tercer paradigma, No More UI y la provocación sobre accesibilidad: inversión del control, nuevos objetos y la advertencia respondida en el Concepto 5; léase junto a las refutaciones que señalan que los agentes multiplican los puntos humanos.
- MCP Apps (SEP-1865, primera extensión oficial, propuesta en noviembre de 2025 y finalizada en la especificación de julio de 2026, con fecha 2026-07-28) y Model Context Protocol. Una herramienta enlaza un recurso HTML
ui://mediante_meta.ui.resourceUri, el anfitrión lo presenta en un iframe aislado y los mensajes cruzan JSON-RPC auditable. Fue creada por MCP-UI, OpenAI y Anthropic y la presentan Claude, Claude Desktop, VS Code, Goose, Postman y otros. Consultemodelcontextprotocol.io/extensions/apps/overview,modelcontextprotocol.io/extensions/apps/build,modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp,apps.extensions.modelcontextprotocol.ioy el repositorioext-apps, que incluyecreate-mcp-app. Para el lanzamiento de Claude, consulteclaude.com/blog/interactive-tools-in-claude. Orquestación, gobernanza y estado permanecen por encima del protocolo. - OWASP Top 10 para aplicaciones LLM (2025): catálogo de amenazas del Concepto 16.
- NIST AI Risk Management Framework (AI RMF 1.0): Gobernar / Trazar / Medir / Gestionar y características de IA confiable.
- Microsoft HAX Toolkit y HAX Playbook: ensayo de fallos y diseño de recuperación antes de publicar.
- W3C WCAG 2.2: base de accesibilidad de los criterios del Concepto 5.