Resumen de la señal
Durante décadas, el software ha obligado a las personas a aprender su estructura.
Abrir la aplicación.
Encontrar la sección correcta.
Navegar por los menús.
Localizar la función.
Introducir la información.
Confirmar la acción.
La inteligencia artificial introduce la posibilidad de invertir esa relación.
En lugar de que la persona navegue hacia la función, el sistema puede interpretar el resultado deseado, localizar la capacidad necesaria y construir una interfaz adecuada en torno a la tarea.
Esto no significa necesariamente que las interfaces gráficas desaparezcan.
La evidencia que emerge en los ecosistemas de IA y de sistemas operativos apunta a algo más sutil:
la interfaz puede dejar de estar permanentemente unida a la aplicación.
Un gráfico puede aparecer cuando un gráfico resulta útil.
Un formulario puede materializarse cuando se requiere una entrada estructurada.
Un mapa puede aparecer cuando la ubicación se vuelve relevante.
Un panel de confirmación puede surgir antes de una acción irreversible.
Un pequeño widget persistente puede permanecer visible mientras un agente sigue trabajando.
Después, la interfaz puede desaparecer.
Varias tecnologías que aparecieron de forma independiente entre 2025 y 2026 empiezan a converger en torno a esta arquitectura:
- Model Context Protocol — MCP
- MCP Apps
- MCP-UI
- OpenAI Apps SDK
- A2UI de Google
- AG-UI
- Agent2Agent — A2A
- Apple App Intents y App Schemas
- Android AppFunctions
- bibliotecas de componentes orientadas a agentes y frameworks de UI generativa
Ninguna de ellas define por sí sola el futuro de las interfaces.
En conjunto, sin embargo, exponen un patrón detectable.
El software empieza a separar la capacidad de la aplicación, y la interfaz de la capacidad.
El cuadro de chat probablemente no es la interfaz definitiva
La primera interfaz ampliamente difundida para la IA generativa era extraordinariamente simple:
┌──────────────────────────────┐ │ Ask anything... │ └──────────────────────────────┘
Esa simplicidad resultó estratégicamente útil.
El lenguaje natural eliminó la necesidad de entender la organización interna de un sistema.
En lugar de localizar un comando, la persona podía describir un objetivo.
Pero la conversación tiene limitaciones importantes como interfaz de usuario.
Pensemos en reservar un hotel enteramente mediante texto.
Show me hotels in Lisbon.
Here are five options.
Only those with a pool.
Here are three.
Which are below €220?
Two meet that requirement.
What dates were available again?
El modelo puede realizar la interacción.
Pero la interfaz es ineficiente.
Un sistema visual convencional puede representar el mismo estado con más eficacia:
LISBON 12–15 OCTOBER Price €120 ───────── €250 Pool ☑ Breakfast ☑ Distance < 3 km ┌──────────────┐ │ Hotel A │ │ €184 │ │ ★★★★ │ └──────────────┘ ┌──────────────┐ │ Hotel B │ │ €206 │ │ ★★★★ │ └──────────────┘
El lenguaje natural es muy eficiente para expresar intención.
Las interfaces gráficas siguen siendo muy eficientes para:
- comparar
- manipular
- información espacial
- revisar información estructurada
- elegir entre alternativas
- ajustar parámetros
- visualizar estado
- confirmar acciones
Por tanto, la arquitectura emergente no parece ser:
Se parece cada vez más a:
- STATIC GUI
- INTENT
- AGENT
- CONTEXTUAL GUI
La conversación se convierte en la capa de orquestación.
La interfaz gráfica se vuelve situacional.
La distinción importante: MCP no es un protocolo de interfaz
Gran parte de la terminología actual genera confusión.
El propio Model Context Protocol se diseñó principalmente para estandarizar cómo las aplicaciones de IA se conectan a capacidades, recursos y herramientas externas.
Conceptualmente:
- MODEL / AGENT
- │ MCP
- TOOLS
- DATA
- SERVICES
- APPLICATIONS
Esto resolvió un problema de integración importante.
Un agente podía descubrir que un sistema expone algo como:
search_customers() create_invoice() check_inventory() send_message()
sin necesidad de una arquitectura de integración a medida para cada modelo y cada aplicación.
Pero saber que una función existe no resuelve el problema de la interfaz de usuario.
Supongamos que el agente llama a:
search_products()
y recibe 40 productos.
El texto es técnicamente capaz de representar el resultado.
No es necesariamente la interfaz correcta.
Esa capa que faltaba produjo otro desarrollo.
MCP Apps: las herramientas ya pueden llevar interfaces
El 26 de enero de 2026, los responsables de MCP anunciaron MCP Apps como la primera extensión oficial de MCP.
Permite que las herramientas MCP proporcionen interfaces de usuario interactivas que pueden renderizarse directamente dentro de hosts compatibles. Entre los ejemplos cubiertos explícitamente por la especificación figuran paneles, formularios, visualizaciones de datos, visores multimedia y flujos de trabajo de varios pasos.
La arquitectura básica es:
MCP
AGENT ─────────────────► SERVER
│
├── TOOL
│
└── UI RESOURCE
│
▼
HOST
│
▼
INTERACTIVE UI
Una herramienta declara que tiene una interfaz asociada mediante metadatos que apuntan a un recurso ui://.
El host recupera ese recurso y lo renderiza dentro de un iframe aislado (sandbox).
La interfaz y el host se comunican después mediante JSON-RPC sobre postMessage.
Esto parece técnico.
Sus implicaciones son arquitectónicas.
La capacidad del backend y la experiencia del frontend ahora pueden viajar juntas.
De MCP-UI a MCP Apps
La distinción entre MCP-UI y MCP Apps merece quedar registrada porque ambos nombres siguen apareciendo en las conversaciones de desarrolladores.
MCP-UI fue un proyecto comunitario temprano que exploraba interfaces interactivas devueltas por herramientas MCP.
Sus experimentos incluían:
- interfaces HTML entregadas por MCP
- renderizado en sandbox
- comunicación entre la interfaz embebida y el host
- resultados de herramientas interactivos
Esos conceptos influyeron posteriormente en la extensión formal MCP Apps.
El proyecto MCP-UI recomienda ahora MCP Apps para aplicaciones nuevas y su SDK actual implementa la especificación oficial de MCP Apps.
La progresión puede simplificarse así:
MCP
│
├── tools
├── resources
└── prompts
↓ community experimentation
MCP-UI
↓ standardization
MCP Apps
Esto importa porque la UI sobre MCP ya no es solo un patrón experimental.
Ha entrado en el ecosistema formal de MCP.
Una herramienta MCP ya puede contener una aplicación
El modelo de MCP Apps es esencialmente:
MCP APP = TOOL + UI RESOURCE
Supongamos que una organización expone:
get_sales_report()
Antes, la respuesta podría haber sido JSON:
{
"revenue": 184932,
"orders": 1847,
"conversion": 3.8
}
El agente podía traducir eso a prosa.
Con MCP Apps, la misma capacidad puede declarar:
ui://sales/dashboard
y el host puede mostrar algo más parecido a:
┌──────────────────────────────────────┐ │ SALES │ │ │ │ Revenue €184,932 │ │ Orders 1,847 │ │ Conversion 3.8% │ │ │ │ ▁▂▃▃▄▅▅▇▆█ │ │ │ │ [Last 7 days ▼] [Region ▼] │ └──────────────────────────────────────┘
La persona puede interactuar con el panel.
La interfaz puede entonces llamar a otras herramientas MCP.
La aplicación existe, en la práctica, dentro del host de IA.
La interfaz es bidireccional
Aquí es donde MCP Apps se vuelve más importante que la mera visualización de resultados enriquecidos.
La interfaz embebida puede comunicarse de vuelta con el host.
Según la especificación actual, una MCP App puede realizar operaciones como:
- llamar a herramientas del servidor
- leer recursos del servidor
- enviar mensajes a la conversación
- actualizar el contexto visible para el modelo
- solicitar enlaces externos
- reaccionar a cambios del entorno del host
Consideremos una interfaz de inventario.
El agente muestra inicialmente:
| WAREHOUSE STATUS | |
|---|---|
| Item | Stock |
| A | 381 |
| B | 12 |
| C | 0 |
La persona hace clic en:
[ Item B ]
La interfaz puede actualizar el contexto del modelo:
User selected Item B. Current stock: 12.
La conversación ahora sabe qué está inspeccionando la persona sin necesidad de:
«Me refiero al segundo elemento.»
La interfaz pasa a formar parte del bucle de contexto.
- MODEL
- CONTEXT
- USER ↔ INTERFACE
Este es un cambio significativo.
El modelo ya no se limita a generar la interfaz.
La propia interfaz puede convertirse en un sensor de la intención del usuario.
Los widgets pueden convertirse en la unidad atómica del software de IA
Las aplicaciones tradicionales se construyen en torno a destinos.
- Open Spotify
- Open Amazon
- Open Excel
- Open Salesforce
- Open Uber
Los sistemas agénticos parten de una premisa distinta:
- Play something
- Buy something
- Analyze something
- Update something
- Travel somewhere
La aplicación pasa a ser secundaria respecto al objetivo.
Esto crea un entorno en el que una aplicación completa puede resultar a menudo innecesaria.
Una pequeña interfaz contextual puede bastar.
Ejemplos:
- FLIGHT SEARCHdate widget
- EXPENSE ANALYSISchart
- DELIVERYlive tracking card
- MUSICpersistent player
- PROJECT APPROVALapprove / reject panel
- HOTELmap + cards
- FINANCIAL SIMULATIONsliders + graph
MCP Apps define formalmente tres modos de visualización:
inline
Embebido directamente en el flujo conversacional.
fullscreen
Adecuado para editores, paneles y aplicaciones más complejas.
picture-in-picture
Una superficie persistente adecuada para elementos como reproductores o temporizadores mientras la conversación continúa.
Esto es notable.
El protocolo ya está reconociendo que las interfaces de agente no tendrán una única forma.
El widget ya existía antes de la IA
Los widgets no son nuevos.
Los sistemas operativos móviles llevan años separando progresivamente las capacidades de las aplicaciones completas.
Lo que cambia la IA es la selección y la composición.
Antes:
chooses widget
places widget
configures widget
Modelo agéntico potencial:
- USER INTENT
- SYSTEM determines required interaction
- correct widget appears
- user completes interaction
- widget disappears or persists if useful
Esto cambia el papel del widget.
Deja de ser una simple aplicación en miniatura.
Se convierte en una primitiva de interfaz temporal.
Apple está sacando las capacidades fuera de las aplicaciones
El framework App Intents de Apple ofrece otra señal importante.
App Intents permite a los desarrolladores exponer acciones y entidades de la aplicación a experiencias a nivel de sistema, como Siri, Spotlight, Shortcuts y widgets.
En la WWDC 2026, Apple amplió esta dirección en torno a Siri AI y los App Schemas.
Las aplicaciones pueden describir:
- ENTITIES
-
- what information exists
- INTENTS
-
- what actions can be performed
- SCHEMAS
-
- how the system should understand them
Siri puede entonces resolver peticiones en lenguaje natural hacia esas acciones.
La documentación de Apple de 2026 describe escenarios en los que Siri puede entender el contexto en pantalla y realizar acciones entre aplicaciones usando entidades e intenciones expuestas.
La dirección arquitectónica se parece a MCP aunque la implementación sea distinta.
- DATA / ENTITIES
- CAPABILITIES / INTENTS
- UI
El sistema ya no necesita abrir la interfaz para acceder a cada capacidad.
Apple hace explícitamente que App Intents esté disponible en superficies del sistema como widgets, Spotlight, Shortcuts y Siri.
La aplicación se está volviendo invocable.
Android se acerca aún más al modelo MCP
La dirección de Android es aún más explícita.
Google describe actualmente AppFunctions como una API experimental de la plataforma Android diseñada para que las aplicaciones expongan capacidades a los agentes.
La documentación de Android caracteriza directamente AppFunctions como el equivalente móvil de las herramientas MCP.
Las aplicaciones pueden aportar acciones a un registro del sistema operativo que los agentes o asistentes pueden invocar.
Conceptualmente:
ANDROID APPLICATION
│
├── Traditional UI
│
└── AppFunctions
│
▼
SYSTEM / AGENT
En julio de 2026, el equipo de desarrolladores de Android describió AppFunctions como un punto de entrada complementario a la interfaz móvil tradicional, que permite a un agente privilegiado en el dispositivo acceder a la funcionalidad de la aplicación en segundo plano.
La palabra complementario es importante.
Google no afirma que las aplicaciones dejen de existir.
En lugar de eso, las aplicaciones ganan otra interfaz:
funcionalidad invocable por máquinas.
A2UI: en vez de enviar una app, enviar intención de interfaz
MCP Apps ofrece una libertad considerable.
Un servidor puede entregar HTML, CSS y JavaScript que el host renderiza dentro de un iframe aislado.
Esto permite experiencias sofisticadas.
Pero crea otro problema.
Supongamos que cinco servicios distintos insertan cinco aplicaciones distintas en el mismo asistente.
Cada una puede incluir:
- tipografías distintas
- estilos de botón distintos
- espaciados distintos
- comportamientos de desplazamiento distintos
- características de accesibilidad distintas
El resultado puede parecerse a cinco sitios web embebidos dentro de otra aplicación.
El Agent-to-User Interface — A2UI de Google explora una arquitectura diferente.
En lugar de transmitir código de interfaz ejecutable, el agente transmite una descripción declarativa de la interfaz deseada.
Por ejemplo:
AGENT
- title
- date selector
- price slider
- three result cards
- confirmation button»
El host determina cómo se ven realmente esos elementos.
Conceptualmente:
- AGENT
- A2UI DESCRIPTION
- HOST COMPONENT CATALOG
- NATIVE INTERFACE
El agente especifica qué debe existir.
El cliente decide cómo debe renderizarse.
El catálogo de componentes puede volverse extremadamente importante
Los clientes A2UI definen catálogos de componentes de confianza.
Por ejemplo:
- COMPONENT CATALOG
-
- Text
- Button
- Card
- Table
- Chart
- Map
- Slider
- DatePicker
- Image
- Video
- Form
- Confirmation
Un agente puede componer estos elementos.
No puede ejecutar arbitrariamente el código de interfaz que quiera.
Esto tiene implicaciones de seguridad importantes.
Google diseñó explícitamente A2UI como datos declarativos en lugar de código ejecutable. Los agentes solicitan componentes de un catálogo predefinido controlado por el cliente.
Esto produce un modelo fundamentalmente distinto del de generar dinámicamente HTML o JavaScript.
- GENERATED CODE
-
- AI → HTML / JS → execute
pasa a ser:
- GENERATED INTENT
-
- AI → component description → trusted renderer
Esa separación podría volverse crítica si las interfaces generativas operan en entornos sensibles.
A2UI 0.9 hace la idea más concreta
Google publicó A2UI 0.9 en abril de 2026.
La versión añadió o amplió:
- renderizado en React
- renderizado en Flutter
- renderizado en Angular
- renderizado en Lit
- catálogos de componentes dinámicos
- negociación de versión
- generación de interfaz en streaming
- funciones definidas por el cliente
- sincronización de estado cliente/servidor
- validación de esquema mejorada
Es importante señalar que A2UI no está atado a un transporte específico.
Google lo describe explícitamente como utilizable sobre mecanismos como:
- MCP
- WebSockets
- REST
- AG-UI
- A2A
Esto significa que A2UI se entiende mejor como un lenguaje para la intención de interfaz, más que como otro transporte de agentes.
MCP Apps y A2UI no son necesariamente competidores
Esta distinción queda más clara con el trabajo publicado por los equipos de A2UI y MCP Apps en junio de 2026.
Los dos enfoques pueden combinarse.
Un servidor MCP puede devolver un payload A2UI en lugar de una aplicación HTML.
Por ejemplo:
- MCP TOOL
- A2UI JSON
- HOST NATIVE COMPONENTS
Google demostró payloads A2UI transportados a través de MCP usando el tipo MIME:
application/a2ui+json
La arquitectura gana por tanto dos caminos posibles.
Experiencia personalizada de alto control
- MCP
- MCP APP
- HTML / JS
- SANDBOXED IFRAME
Experiencia nativa del host
- MCP
- A2UI
- DECLARATIVE UI
- HOST COMPONENTS
Ninguno es universalmente superior.
Una aplicación de diseño especializada puede requerir bastante código a medida.
Un formulario de reserva sencillo puede representarse mejor con controles nativos del host.
Por tanto, es probable que aparezcan modelos híbridos.
AG-UI aborda otra capa
Un tercer proyecto aparece con frecuencia junto a MCP y A2UI: AG-UI.
Resuelve un problema distinto.
AG-UI se describe a sí mismo como un protocolo para la comunicación entre agentes y aplicaciones frontend orientadas al usuario.
El protocolo aborda eventos como:
- respuestas en streaming
- estado del agente
- llamadas a herramientas desde el frontend
- ejecución de herramientas
- intenciones de interfaz
- aprobación humana
- interrupciones
- dirección del usuario
- eventos de UI generativa
Una simplificación útil es:
- MCP
- Agent ↔ Tools
- A2A
- Agent ↔ Agent
- AG-UI
- Agent ↔ Frontend
- A2UI
- AgentUI description
- MCP Apps
- Toolinteractive application UI
Estos límites no son absolutos.
Las tecnologías pueden solaparse e integrarse.
Pero verlas como capas hace más fácil entender la arquitectura emergente.
La pila de interfaces agénticas empieza a ser visible
Una arquitectura de aplicación futura podría parecerse a esto:
USER
│
▼
AI HOST / OS
│
┌───────┴────────┐
│ │
AG-UI UI RENDERER
│ │
│ ┌───────┴────────┐
│ │ │
│ A2UI MCP APP
│ │ │
▼ ▼ ▼
AGENT
│
┌──────────┴───────────┐
│ │
MCP A2A
│ │
▼ ▼
TOOLS / SERVICES OTHER AGENTS
Ningún estándar único controla actualmente esta arquitectura completa.
La observación importante es que las capas se están separando.
A2A completa otra parte del cuadro
Agent2Agent — A2A — aborda la comunicación entre agentes independientes.
Su especificación actual permite a los agentes anunciar capacidades, descubrir otros agentes, intercambiar información y coordinar tareas sin exponer su memoria interna ni su implementación.
En agosto de 2026, A2A se unió a la Agentic AI Foundation como proyecto en fase de crecimiento. Su propia documentación describe la relación de forma concisa:
MCP proporciona integración vertical entre agentes y herramientas.
A2A proporciona integración horizontal entre agentes.
Eso nos da otra estructura posible:
USER
│
▼
AGENT
┌──────┴───────┐
│ │
MCP A2A
│ │
▼ ▼
TOOLS AGENTS
│
▼
UI
La persona podría por tanto interactuar con un único asistente visible mientras varias aplicaciones y agentes remotos operan por debajo.
La aplicación puede convertirse en proveedor de capacidades
Esto lleva a una posibilidad arquitectónica mayor.
La aplicación actual suele empaquetarse así:
- DATA
- BUSINESS LOGIC
- API
- UI
La persona entra a través de la interfaz.
La estructura futura podría parecerse cada vez más a:
- DATA
- BUSINESS LOGIC
- API
- AGENT TOOLS
- CAPABILITY SCHEMAS
- OPTIONAL UI COMPONENTS
- FULL APPLICATION UI
Distintos consumidores seleccionan distintas capas.
Una persona puede usar la aplicación completa.
Un agente puede invocar una herramienta.
Un sistema operativo puede invocar un App Intent.
Otro agente puede comunicarse mediante A2A.
Un asistente puede renderizar solo un widget MCP.
Un cliente A2UI puede construir una interfaz nativa.
La aplicación deja por tanto de tener una única entrada.
De navegar aplicaciones a descubrir capacidades
Esto crea un cambio fundamental en el descubrimiento de software.
Hoy:
- USER
- find application
- learn interface
- locate capability
- perform action
Modelo agéntico:
- USER
- describe objective
- agent discovers capability
- agent invokes capability
- system requests human interaction only where necessary
Pensemos en:
Encuentra tres hoteles cerca del congreso, por debajo de 200 €, compara políticas de cancelación y reserva la mejor opción después de que la apruebe.
Pueden intervenir varias capacidades:
- calendar
- maps
- hotel search
- travel profile
- payment
- expense policy
Un agente suficientemente integrado no obliga a la persona a navegar por seis aplicaciones.
La persona interactúa con la tarea.
La tarea puede sustituir a la app como objeto principal de UX
Actualmente esto es una proyección, no un resultado consolidado del sector.
Pero se deriva directamente de las arquitecturas que ya se están implementando.
El software tradicional se organiza en torno a:
Las interfaces agénticas pueden organizarse en torno a:
Es una inversión notable.
Imaginemos:
Organiza mi viaje a Berlín.
El sistema podría construir temporalmente:
┌─────────────────────────────────────────────┐ │ BERLIN · 14–17 OCT │ │ │ │ ✈ FLIGHT │ │ Iberia 08:20 €184 │ │ │ │ 🏨 HOTEL │ │ Motel One €161/night │ │ │ │ 📅 CALENDAR │ │ Conference starts 14:00 │ │ │ │ 💳 POLICY │ │ Within company allowance │ │ │ │ [ Review booking ] │ └─────────────────────────────────────────────┘
Puede que esa interfaz nunca haya existido antes de la petición.
Puede que nunca vuelva a ser necesaria.
La tarea generó la superficie de aplicación.
Esto es distinto de que la IA genere código frontend
La distinción es importante.
Gran parte de la experimentación actual consiste en pedir a los modelos que generen React, HTML o aplicaciones enteras.
Eso es útil para el desarrollo de software.
No es necesariamente cómo funcionarán las interfaces generativas en tiempo de ejecución.
Permitir que un modelo genere y ejecute continuamente código frontend arbitrario introduce problemas evidentes:
- seguridad
- accesibilidad
- consistencia
- rendimiento
- interacción impredecible
- dificultad de pruebas
- inestabilidad visual
Los enfoques que ahora emergen de MCP Apps y A2UI apuntan hacia una generación restringida.
- MODEL
-
- does not necessarily generate application code
- MODEL
-
- selects or composes approved interaction primitives
Esto se acerca más a una gramática de interfaz que a la generación ilimitada de aplicaciones.
Los sistemas de diseño podrían volverse legibles por máquina
Si las arquitecturas al estilo A2UI crecen, el sistema de diseño de una organización gana otro consumidor.
Hoy:
- DESIGN SYSTEM
- DESIGNERS
- FRONTEND DEVELOPERS
- APPLICATION
Futuro potencial:
DESIGNERS
│
DESIGN SYSTEM ─────────┼──── FRONTEND
│
└──── AI AGENTS
El sistema de diseño puede necesitar describir no solo:
- Button
- Card
- Modal
- Table
sino también restricciones semánticas:
PaymentConfirmation
- amount
- currency
- merchant
- confirm
- cancel
- consequential
El catálogo de componentes se convierte en algo sobre lo que un agente puede razonar.
La arquitectura frontend se vuelve, por tanto, parcialmente semántica.
Los componentes pueden adquirir capacidades, no solo apariencia
Los componentes de interfaz actuales describen principalmente presentación.
<Button /> <Table /> <DatePicker />
Los sistemas agénticos pueden requerir algo más rico.
<PaymentApproval amount recipient policy authenticationRequired />
La diferencia es importante.
El componente representa un contrato de tarea, no solo píxeles.
Sabe:
- qué datos necesita
- qué acciones están disponibles
- qué permisos aplican
- qué cambios de estado son posibles
Esto podría reducir la cantidad de generación arbitraria de interfaz necesaria.
Una nueva división de responsabilidades
Una posible arquitectura frontend futura sería por tanto:
- AI
-
- decides WHAT interaction is required
- DESIGN SYSTEM
-
- decides HOW that interaction appears
- APPLICATION
-
- defines WHAT actions are possible
- POLICY
-
- defines WHAT actions are permitted
- USER
-
- decides WHAT actions to approve
Esta separación es más controlable que dar a un modelo autónomo acceso sin restricciones al código de la aplicación.
La seguridad pasa a formar parte de la arquitectura de interfaz
Las interfaces generadas por agentes crean problemas de seguridad poco habituales.
Una interfaz maliciosa podría intentar:
- imitar controles de confianza
- manipular a las personas para que aprueben acciones
- exfiltrar información
- invocar herramientas no autorizadas
- disfrazar acciones externas
- crear flujos de confirmación engañosos
Por eso los estándares emergentes contienen límites de seguridad explícitos.
MCP Apps ejecuta las aplicaciones dentro de iframes aislados.
Esas aplicaciones no reciben acceso directo al DOM del host, a las cookies ni al almacenamiento.
Los destinos de red externos se declaran mediante metadatos de Content Security Policy, y la comunicación pasa por mecanismos controlados del host.
A2UI elige un modelo aún más restrictivo.
Los agentes remotos envían datos declarativos y solo pueden solicitar componentes de confianza presentes en el catálogo del cliente.
Representan dos enfoques distintos:
- MCP APPS
-
- sandbox the code
frente a:
- A2UI
-
- do not transmit executable code
Ambos pueden seguir siendo útiles.
El host está ganando poder
Hay otra consecuencia.
Si las aplicaciones se ejecutan cada vez más dentro de entornos de IA, el host gana importancia.
Entre los hosts potenciales figuran:
- ChatGPT
- Claude
- Microsoft Copilot
- asistentes de sistemas operativos
- IDE
- entornos de IA empresariales
- aplicaciones de agentes especializadas
MCP Apps se anunció con soporte en clientes como ChatGPT, Claude, Goose y Visual Studio Code, y se esperan más hosts.
Microsoft también documenta ahora widgets interactivos basados en MCP dentro de Microsoft 365 Copilot.
Su guía de UX es reveladora.
Microsoft recomienda explícitamente que las interfaces MCP dentro de Copilot se mantengan centradas en la tarea en lugar de intentar reproducir aplicaciones completas dentro de la conversación.
Eso refuerza el patrón emergente:
superficies contextuales pequeñas en lugar de aplicaciones dentro de aplicaciones.
OpenAI avanza en la misma dirección
OpenAI presentó su Apps SDK en octubre de 2025, permitiendo que aplicaciones con interfaces interactivas funcionen directamente dentro de ChatGPT.
El SDK usa MCP como mecanismo de integración subyacente y permite a los desarrolladores definir tanto la lógica de la aplicación como su interfaz.
La documentación actual de OpenAI recomienda ahora usar el estándar abierto MCP Apps para nueva funcionalidad de interfaz compartida y añadir extensiones específicas de ChatGPT solo cuando sea necesario.
El sistema de interfaz admite conceptos como:
- tarjetas
- carruseles
- interfaces embebidas
- vistas de aplicación más ricas
- widgets con estado
- modales controlados por el host
- interacción con archivos
- llamadas a herramientas desde la interfaz
De nuevo, la conversación evoluciona hacia un entorno de ejecución para otras interfaces.
La infraestructura para desarrolladores sigue el mismo camino
Este patrón no se limita a las grandes plataformas de IA.
El AI SDK de Vercel se ha expandido progresivamente desde la invocación de modelos y el streaming hacia la infraestructura de agentes y la UI generativa.
AI SDK 7, publicado en junio de 2026, añadió soporte de MCP Apps junto a herramientas para agentes, flujos de aprobación, agentes duraderos e integraciones con múltiples harness de agentes.
La biblioteca de componentes AI Elements de Vercel también ofrece componentes diseñados específicamente en torno a patrones de interacción con IA como:
- respuestas en streaming
- llamadas a herramientas
- visualización de razonamiento
- partes de mensaje estructuradas
El ecosistema frontend empieza por tanto a construir componentes para interacciones que no existían en las aplicaciones web tradicionales.
El nuevo elemento de interfaz más importante puede ser la aprobación
El software tradicional asume:
human initiates action
El software agéntico permite cada vez más:
agent proposes action
Eso produce una nueva interfaz crítica:
THE APPROVAL SURFACE
Ejemplo:
┌─────────────────────────────────────────┐ │ PAYMENT READY │ │ │ │ Recipient ACME Ltd │ │ Amount €4,820 │ │ Account Operations │ │ │ │ Agent reason │ │ Invoice INV-4827 matched purchase order │ │ PO-1821. │ │ │ │ [ Reject ] [ Approve ] │ └─────────────────────────────────────────┘
Esto no es chat ni navegación convencional.
Es un momento en el que la ejecución autónoma se cruza con la autoridad humana.
A medida que los agentes acceden a herramientas con consecuencias, las interfaces para:
- inspección
- aprobación
- corrección
- interrupción
- delegación
- reversión
pueden volverse cada vez más importantes.
AG-UI ya trata las interrupciones y las interacciones humano-en-el-bucle como conceptos explícitos de la interfaz de agente.
Las interfaces podrían volverse sensibles a la confianza
Otra extensión lógica es una interfaz dinámica basada en la incertidumbre del modelo.
Esto es una proyección.
Consideremos:
confidence = 0.99
El agente podría actuar automáticamente.
Con:
confidence = 0.78
el sistema podría mostrar:
[ Confirm customer ]
Con:
confidence = 0.42
el sistema podría presentar:
- SELECT CUSTOMER
-
- ○ ACME Europe
- ○ ACME Holdings
- ○ ACME Spain
La interfaz se vuelve por tanto condicional a la incertidumbre.
En lugar de que todos los flujos tengan la misma interfaz, la cantidad de interacción humana podría adaptarse a la confianza con que el sistema entiende la situación.
Esta podría convertirse en una de las diferencias más significativas entre el software tradicional y el software agéntico.
Las interfaces también podrían volverse sensibles a los permisos
La misma tarea podría producir una interfaz distinta según el usuario.
- EMPLOYEE
-
- [ Request refund ]
- MANAGER
-
- [ Approve refund ]
- [ Reject refund ]
- AUDITOR
-
- View only
Una interfaz generativa no tiene por qué significar generación ilimitada.
Puede significar seleccionar la superficie permitida correcta dentro de un sistema restringido.
La interfaz puede vivir cada vez más fuera de la aplicación
Apple expone las acciones de las apps en:
- Siri
- Spotlight
- widgets
- Shortcuts
- controles del sistema
Android está construyendo AppFunctions para el acceso de agentes.
MCP expone las capacidades de las aplicaciones a los hosts de IA.
A2UI permite a los agentes remotos solicitar interfaces nativas del host.
MCP Apps permite a los servicios traer sus propias superficies interactivas.
Estos desarrollos apuntan a un cambio arquitectónico común:
- UI
- FEATURES
- APP UI
- WIDGET
- AI ASSISTANT
- VOICE
- SYSTEM SEARCH
- AUTOMATION
- AGENT
La aplicación completa sigue siendo una superficie entre varias.
Es poco probable que el icono de la app desaparezca pronto
Esto exige un contrapunto.
Actualmente no hay evidencia fiable de que las aplicaciones convencionales estén a punto de desaparecer.
De hecho, los propios proveedores de plataformas describen estas interfaces de agente como complementarias.
Android afirma explícitamente que las interfaces móviles tradicionales siguen siendo eficaces para tareas concretas y manuales, y sitúa AppFunctions como un punto de entrada adicional.
El software complejo sigue beneficiándose de una estructura espacial estable.
Ejemplos:
- editores de vídeo
- aplicaciones CAD
- entornos de desarrollo
- hojas de cálculo
- producción musical
- analítica avanzada
- sistemas de administración complejos
Las personas construyen memoria espacial en torno a estas interfaces.
Sustituirlo todo por controles generados dinámicamente podría reducir la eficiencia en lugar de mejorarla.
La transición probable no es, por tanto:
APPS disappear.
Una proyección más defendible es:
The percentage of tasks requiring users to open the full app decreases.
Es una afirmación significativamente distinta.
La aplicación del futuro puede tener dos públicos
Históricamente, el software se ha diseñado sobre todo para personas.
Cada vez más, las aplicaciones tendrán otro consumidor:
agentes.
Los desarrolladores pueden por tanto necesitar construir dos interfaces paralelas.
- HUMAN INTERFACE
-
- screens
- navigation
- widgets
- visualizations
y:
- AGENT INTERFACE
-
- tools
- schemas
- entities
- permissions
- structured responses
- capability metadata
Una buena aplicación puede requerir ambas.
Esto podría cambiar la ventaja competitiva
Esta sección es una proyección.
Si los agentes eligen cada vez más herramientas por las personas, el descubrimiento de aplicaciones cambia.
La competencia tradicional depende en gran medida de:
- brand
- app-store position
- SEO
- advertising
- user habit
El software mediado por agentes podría introducir otro factor:
machine discoverability
Un agente necesita determinar:
- qué puede hacer un servicio
- qué entradas requiere
- cuánto cuesta
- si está autorizado
- qué garantías ofrece
- cuán fiable es
Eso crea incentivos para metadatos de capacidad altamente estructurados.
Un servicio que los agentes puedan entender e invocar de forma fiable puede ganar ventaja aunque la persona nunca navegue directamente por su interfaz.
El equivalente a la optimización para la búsqueda humana podría por tanto ampliarse gradualmente hacia la optimización para la selección por agentes.
Es demasiado pronto para saber qué modelo económico surgirá en torno a esto.
El requisito arquitectónico ya está apareciendo.
Las aplicaciones pueden volverse componibles entre proveedores
Consideremos un flujo de gastos futuro.
Arrange the trip to Munich and keep it within company policy.
Un agente podría interactuar con:
- CALENDAR AGENT
- TRAVEL SERVICE
- AIRLINE MCP
- HOTEL MCP
- COMPANY POLICY
- EXPENSE SYSTEM
La interfaz resultante podría combinar:
- calendar information
- flight selection
- hotel cards
- policy warnings
- expense estimate
- approval controls
Ningún servicio participante concreto tiene por qué ser dueño de la interfaz final.
Lo es el orquestador.
Esto representa una ruptura significativa con la computación centrada en la aplicación.
Puede que nos acerquemos al software efímero
Esta es una de las implicaciones más especulativas.
El software tradicional asume que una interfaz se diseña antes de que llegue la persona.
- designer
- application
- user
La UI generativa introduce:
- designer
- component system
- agent
- current objective
- temporary interface
- user
La interfaz se convierte en una instancia en lugar de un artefacto permanente.
Existe porque el estado actual la requiere.
Cuando la tarea termina, puede que ya no sea necesaria.
Esto podría describirse como software efímero:
superficies de software ensambladas temporalmente en torno a un objetivo.
Los servicios subyacentes siguen siendo persistentes.
La interfaz no tiene por qué serlo.
La transición probable
A partir de las tecnologías actualmente desplegadas y documentadas, puede construirse una progresión razonable.
Fase 1 — Computación centrada en la aplicación
Fase 2 — Acceso conversacional
Fase 3 — Asistentes que usan herramientas
Fase 4 — Interfaces de agente interactivas
Esta fase ya está emergiendo.
- USER
- AGENT
- TOOL
- CONTEXTUAL WIDGET
Fase 5 — Interfaces de tarea compuestas
Esto sigue siendo una proyección.
- USER INTENT
- ORCHESTRATOR
- MULTIPLE SERVICES
- GENERATED TASK UI
Fase 6 — Capa de capacidades ambiental
Más especulativa:
- USER
- SYSTEM INTENT LAYER
- CAPABILITY NETWORK
- only generates UI
- when human interaction is useful
En esta etapa, las aplicaciones siguen existiendo.
Pero las personas interactúan cada vez más con capacidades en lugar de con los límites de las aplicaciones.
Qué pueden necesitar construir distinto los desarrolladores
Si esta dirección continúa, crear software puede implicar más que construir pantallas y API.
Una aplicación madura podría necesitar:
- HUMAN UI
- MACHINE API
- MCP TOOLS
- CAPABILITY SCHEMAS
- ENTITY MODEL
- AGENT PERMISSIONS
- UI COMPONENT CATALOG
- AGENT-SAFE ACTIONS
- APPROVAL SURFACES
- OBSERVABILITY
El frontend ya no es la única representación del producto.
Qué pueden necesitar diseñar distinto los diseñadores
Los diseñadores podrían pasar de diseñar secuencias fijas de pantallas:
- SCREEN 1
- SCREEN 2
- SCREEN 3
a diseñar primitivas de interacción.
- SELECT
- COMPARE
- CONFIRM
- EDIT
- REVIEW
- APPROVE
- MONITOR
- INTERRUPT
Esas primitivas pueden aparecer después en contextos distintos.
El diseño pasa a consistir, en parte, en definir la gramática a partir de la cual pueden ensamblarse las interfaces.
Qué cambia para las personas
El cambio más significativo puede acabar teniendo que ver con la carga cognitiva.
Las aplicaciones tradicionales obligan a mantener un modelo mental del software:
- Where is the feature?
- Which application does it?
- Which menu contains it?
- What order do I perform these operations?
Las interfaces agénticas pueden transferir parte de ese trabajo organizativo al sistema.
La persona describe el estado deseado.
El sistema determina la ruta operativa.
Pero esto también crea un nuevo requisito.
Las personas necesitan entender:
- What is the agent doing?
- Why is it asking me this?
- What will happen if I approve?
- Which service is performing the action?
- Can I reverse it?
El reto de diseño se desplaza por tanto.
La complejidad de navegación disminuye.
La transparencia en la delegación aumenta.
La señal más fuerte no es el chat
El chat atrajo la atención inicial porque proporcionó la primera interfaz universal a los modelos de lenguaje.
Pero la infraestructura que ahora se desarrolla en torno a la IA apunta más allá del chat.
MCP Apps permite que las herramientas lleven aplicaciones.
A2UI permite que los agentes describan interfaces.
AG-UI conecta agentes con frontends.
A2A conecta agentes con otros agentes.
Apple App Intents hace accesibles las capacidades de las apps en todo el sistema operativo.
Android AppFunctions expone la funcionalidad de las aplicaciones a los agentes.
Los SDK de IA están introduciendo componentes específicamente para la ejecución de herramientas, el estado del agente y la UI generativa.
La arquitectura resultante ya no es simplemente:
CHATBOT
Se mueve hacia:
INTENT
│
▼
ORCHESTRATION
│
├──── CAPABILITY
│
├──── CAPABILITY
│
├──── AGENT
│
└──── DATA
│
▼
APPROPRIATE INTERFACE
A veces esa interfaz será texto.
A veces voz.
A veces un botón.
A veces un formulario.
A veces un mapa.
A veces una aplicación completa.
Y a veces puede que no haya interfaz alguna.
Evaluación de CORE01
La aplicación no está desapareciendo.
Sus límites se están debilitando.
Durante la mayor parte de la historia de la computación personal, funcionalidad e interfaz se distribuyeron juntas.
La persona elegía una aplicación porque esa aplicación contenía la capacidad necesaria.
Las arquitecturas de agentes empiezan a separar esos dos conceptos.
Una capacidad puede ahora exponerse de forma independiente.
Un agente puede descubrirla.
Un protocolo puede transportarla.
Un host puede renderizar su interfaz.
El sistema operativo puede invocarla.
Otro agente puede delegar en ella.
La interfaz puede aparecer solo cuando se requiere juicio humano.
La transición más trascendente puede por tanto no ser la de interfaces gráficas a interfaces conversacionales.
Puede ser:
- APPLICATION-CENTRIC COMPUTING
- CAPABILITY-CENTRIC COMPUTING
En ese modelo, la persona no navega software.
El software se ensambla a sí mismo en torno al objetivo de la persona.
Los estándares necesarios para esa arquitectura están incompletos.
Las implementaciones siguen fragmentadas.
La seguridad, los permisos, los modelos de negocio, el descubrimiento y la confianza de las personas siguen sin resolverse.
Pero los componentes subyacentes ya no son teóricos.
Se están estandarizando ahora.
Patrón detectado.
La interfaz se está volviendo dinámica.
La aplicación se está volviendo invocable.
El agente se está convirtiendo en la capa de orquestación.
La monitorización continúa.