Hay una idea que, formulada de forma extrema, suena casi absurda:

no quiero usar tu producto; quiero que mi agente pueda usarlo por mí.

Pero cuanto más se mira el ecosistema actual de agentes, menos absurda parece.

Un comentario alrededor de la discusión sobre WebMCP utilizaba Jira como ejemplo. El punto no era que Jira hubiera dejado de ser útil. Era justamente lo contrario: Jira podía volverse todavía más importante aunque el usuario abriera menos veces su interfaz.

¿Por qué?

Porque el agente puede convertir Jira en infraestructura.

En lugar de hacer esto:

abrir Jira
   ↓
buscar proyecto
   ↓
crear issue
   ↓
rellenar campos
   ↓
asignar prioridad
   ↓
enlazar epic
   ↓
publicar comentario

el usuario podría decir simplemente:

"Convierte los hallazgos del code review en tres issues,
priorízalos, enlázalos al epic y asígnalos al developer."

Y por debajo ocurriría algo como:

Usuario
   ↓
Agente
   ↓
MCP / API / WebMCP
   ↓
Jira

El usuario no dejó de utilizar Jira en el sentido económico o funcional.

Lo que dejó de hacer fue operar manualmente la interfaz de Jira.

Ésa es una diferencia enorme.

La aplicación sigue ahí; cambia quién la opera

Durante décadas, el modelo dominante del software fue relativamente estable:

persona
   ↓
interfaz gráfica
   ↓
aplicación
   ↓
backend

El frontend era la puerta de entrada obligatoria.

Si querías crear un ticket, entrabas a Jira.

Si querías revisar mensajes, entrabas a Slack.

Si querías administrar pagos, entrabas a Stripe.

Si querías modificar un repositorio, entrabas a GitHub.

Las APIs existían, pero estaban principalmente pensadas para integraciones, scripts y desarrolladores.

Con agentes capaces de utilizar tools, la topología empieza a cambiar:

                 ┌── GitHub
                 ├── Jira
Usuario → Agente ├── Slack
                 ├── Stripe
                 └── otras herramientas

Ahora la interfaz que el usuario percibe puede ser una conversación, un IDE, una voz o incluso una automatización que corre en segundo plano.

Las aplicaciones siguen aportando lo más valioso:

  • datos;
  • reglas de negocio;
  • permisos;
  • historial;
  • identidad;
  • almacenamiento;
  • workflows;
  • integración con otros sistemas.

Pero su UI ya no tiene por qué ser el punto principal de interacción.

En ese sentido, la aplicación empieza a parecerse a un backend especializado para agentes.

El ejemplo de Jira ya no es solamente teórico

Atlassian ofrece hoy el Rovo MCP Server, generalmente disponible, para permitir que clientes de IA externos trabajen con Jira y Confluence mediante Model Context Protocol.

La propia compañía presenta la idea en términos muy cercanos a este cambio de paradigma: reducir cambios de contexto y permitir que el trabajo de Atlassian llegue al entorno donde ya está trabajando el usuario.

Eso permite imaginar flujos como:

Codex revisa un PR
        ↓
detecta tres problemas
        ↓
consulta el epic en Jira
        ↓
crea tres issues
        ↓
enlaza evidencia del repositorio
        ↓
asigna prioridad
        ↓
continúa trabajando

El desarrollador puede terminar usando Jira mucho más intensamente que antes.

Pero quizá no abrió jira.com ni una sola vez.

Ésa es la paradoja.

El uso del producto sube mientras el uso de su interfaz baja.

De “time spent in app” a “capabilities consumed”

Este cambio puede ser incómodo para muchas compañías SaaS porque durante años una parte importante del éxito de producto se midió con métricas como:

DAU
MAU
tiempo en la aplicación
sesiones por usuario
pantallas visitadas
clicks

Pero esas métricas parten de una suposición:

el humano es quien opera directamente la aplicación.

En un mundo agent-first, una métrica más importante podría ser otra:

acciones completadas
capabilities consumidas
tool calls exitosas
workflows finalizados
valor producido

Un usuario podría pasar de abrir Jira veinte veces al día a abrirlo dos veces por semana y, al mismo tiempo, multiplicar por cinco la cantidad de trabajo que procesa Jira.

Eso obliga a distinguir entre dos cosas que antes estaban muy correlacionadas:

uso del producto ≠ uso de la interfaz

Y probablemente cambie también cómo se diseñan pricing, analytics y growth.

La interfaz principal puede convertirse en tu agente

Éste es quizá el cambio conceptual más profundo.

Hoy pensamos en nuestras herramientas como destinos:

"voy a GitHub"
"voy a Jira"
"voy a Slack"
"voy a Stripe"

En un entorno realmente agent-first, el usuario puede pensar de otra forma:

"Agente, resuelve esto."

Después, el agente decide qué sistemas necesita.

Por ejemplo:

"Investiga por qué falló el deploy,
abre los issues necesarios,
avisa al equipo y prepara el rollback."

El agente podría entonces:

GitHub → inspeccionar commit y CI
Jira   → crear incident issue
Slack  → publicar resumen
Cloud  → consultar estado del deployment

La persona deja de funcionar como el bus de integración humano entre aplicaciones.

Eso es importante porque una enorme cantidad de trabajo digital actual consiste precisamente en transportar contexto manualmente:

copiar de A
pegar en B
interpretar B
volver a A
abrir C
actualizar D

Los agentes son especialmente valiosos cuando pueden eliminar esa capa de coordinación mecánica.

“Bring your own agent” cambia la relación con el SaaS

Aquí aparece una segunda idea fuerte de la conversación original.

Muchas compañías están construyendo su propio agente dentro de su producto:

Producto A → Agent A
Producto B → Agent B
Producto C → Agent C

Pero el usuario termina con un problema nuevo: ahora tiene que gestionar diez agentes diferentes, cada uno con su propia memoria, interfaz, permisos y contexto.

La alternativa es casi la inversa:

                 ┌── Producto A
                 ├── Producto B
Mi agente ───────┼── Producto C
                 └── Producto D

Es el modelo bring your own agent.

El usuario escoge el agente que ya conoce su contexto y sus preferencias —ChatGPT, Claude, Codex, Cursor u otro— y los productos compiten por exponerle capacidades de alta calidad.

Eso no significa que los agentes integrados desaparezcan.

Pueden seguir siendo excelentes para onboarding, soporte y usuarios que no desean configurar nada.

Pero dejan de ser necesariamente el único canal.

Un buen producto agent-first podría ofrecer simultáneamente:

UI humana
+ agente propio
+ API
+ MCP
+ WebMCP
+ handoff hacia agentes externos

La pregunta deja de ser solamente:

¿qué tan buena es mi interfaz?

Y empieza a incluir:

¿qué tan fácil es para un agente externo descubrir y utilizar mis capacidades?

WebMCP empuja esta idea hasta la propia página web

En nuestro análisis anterior de WebMCP vimos una pieza especialmente interesante de este futuro.

WebMCP propone que una página pueda exponer tools estructuradas directamente a agentes del navegador.

En lugar de obligar al agente a mirar la pantalla y deducir:

"ese rectángulo azul probablemente sea el botón Crear ticket"

la página podría publicar algo conceptualmente parecido a:

create_issue({
  title,
  description,
  priority,
  assignee
})

Chrome describe WebMCP precisamente como una forma de hacer que los sitios participen activamente en la interacción con agentes mediante tools estructuradas, reduciendo la ambigüedad de operar una interfaz mediante clicks y texto.

Eso cambia el papel del frontend.

Antes era exclusivamente la representación visual del producto.

Ahora también puede convertirse en una superficie semántica de capacidades para agentes.

MCP y WebMCP no hacen exactamente lo mismo

Conviene separar las dos capas.

Con MCP podemos tener algo así:

Agente
   ↓
MCP client
   ↓
MCP server
   ↓
Jira / GitHub / filesystem / database

Con WebMCP:

Browser Agent
   ↓
Browser
   ↓
WebMCP tools
   ↓
Aplicación web y su sesión actual

La documentación de Chrome insiste en que WebMCP y MCP son complementarios, no sustitutos.

Eso permite una arquitectura interesante:

                 ┌── MCP → backend e integraciones
Agente ──────────┤
                 └── WebMCP → capacidades ligadas a la sesión web

Para el usuario la distinción puede terminar siendo invisible.

Sólo pide una tarea.

El agente escoge el canal más fiable.

La UI no desaparece

Es tentador llevar la idea demasiado lejos y concluir que las interfaces gráficas van a desaparecer.

Probablemente no.

Hay muchas situaciones donde una UI sigue siendo mejor:

  • explorar información visual;
  • comparar opciones;
  • descubrir capacidades nuevas;
  • revisar resultados;
  • comprender estados complejos;
  • confirmar acciones irreversibles;
  • corregir decisiones del agente.

Una arquitectura más plausible es híbrida:

Agente hace el trabajo mecánico
            ↓
UI muestra el estado y resultado
            ↓
Humano revisa / confirma cuando importa

Por ejemplo:

Agente prepara una compra
        ↓
UI muestra precio, producto y dirección
        ↓
Usuario confirma
        ↓
Sistema ejecuta el pago

La interfaz deja de ser un requisito para cada operación, pero sigue siendo una superficie poderosa de supervisión.

El verdadero moat puede moverse

Si el usuario interactúa cada vez menos con la UI, una pregunta estratégica aparece inmediatamente:

¿qué diferencia a un producto cuando el agente está en medio?

Algunas ventajas tradicionales pierden peso relativo:

navegación bonita
microinteracciones
menús memorables

Mientras otras pueden ganar muchísimo:

calidad de los datos
fiabilidad de las acciones
latencia
permisos claros
schemas estables
autenticación
observabilidad
audit logs
reversibilidad
precio

Para un agente, una tool que funciona el 99,99 % del tiempo puede ser más valiosa que una interfaz espectacular.

Esto puede crear una nueva disciplina de diseño de producto:

Agent Experience, o AX.

De la misma forma que durante años optimizamos Developer Experience para APIs y SDKs, ahora habrá que optimizar la experiencia que tienen los agentes cuando descubren y ejecutan capacidades.

El pricing también puede cambiar

El modelo por asiento fue diseñado alrededor de humanos.

Pero imaginemos una empresa con:

20 empleados
100 agentes especializados
1.000.000 tool calls al mes

¿Qué es exactamente un “usuario” en ese sistema?

Es probable que veamos combinaciones nuevas:

seats humanos
+ consumo de agentes
+ volumen de acciones
+ límites por tool
+ capacidad reservada

Esto ya empieza a parecer menos a vender acceso a una aplicación y más a vender acceso a una infraestructura de capacidades.

Y esa transición afecta directamente al modelo de negocio SaaS.

La seguridad se vuelve parte del producto

Permitir que agentes externos operen sistemas reales no es solamente un problema de conectividad.

Es un problema de autoridad.

Si un agente descubre tools como:

create_issue
send_message
approve_invoice
refund_payment
delete_project

necesitamos responder preguntas muy concretas:

¿quién autorizó al agente?
¿qué scopes tiene?
¿qué operaciones requieren confirmación?
¿qué límites existen?
¿cómo se audita cada acción?
¿cómo se revoca acceso?
¿qué puede deshacerse?

Por eso la infraestructura agent-first no será simplemente “añadir un endpoint para LLMs”.

Necesitará modelos serios de permisos, identidad, logging y human-in-the-loop.

Las compañías que resuelvan bien esa capa tendrán una ventaja importante.

El tweet que cristaliza la idea

La discusión que inspiró este análisis aparece condensada en este tweet de Dillon Mulroy.

La tesis puede resumirse así:

no quiero estar obligado a utilizar el agente de cada producto; quiero que mis propios agentes estén habilitados para utilizar esos productos eficientemente.

Es una diferencia pequeña en palabras y enorme en arquitectura.

El primer modelo intenta llevar al usuario hacia el agente del proveedor.

El segundo intenta llevar las capacidades del proveedor hacia el agente del usuario.

Modelo A
Usuario → agente del producto → producto

Modelo B
Usuario → su agente → muchos productos

Si el segundo modelo gana terreno, la competencia entre aplicaciones cambia.

Ya no basta con ser un destino atractivo.

También hay que ser un buen componente dentro del workflow de otro agente.

De aplicaciones a infraestructura cognitiva

La web y el SaaS crecieron alrededor de interfaces diseñadas para humanos.

Los agentes no eliminan esas interfaces, pero introducen otra capa de abstracción.

Podemos verlo como una evolución:

Era 1
Humano → UI → aplicación

Era 2
Humano → scripts / APIs → aplicación

Era 3
Humano → agente → tools → aplicaciones

En la tercera era, el agente se convierte en el coordinador.

GitHub puede convertirse en el backend del código.

Jira, en el backend de issues.

Slack, en el backend de comunicación.

Stripe, en el backend de pagos.

Y una enorme cantidad de aplicaciones pueden empezar a competir menos por “ser el lugar donde trabajas” y más por ser la infraestructura que tu agente elige cuando necesita hacer algo.

Ése es el cambio de paradigma.

No dejamos necesariamente de utilizar software.

Puede ocurrir justo lo contrario.

Utilizamos muchísimo más software, pero cada vez vemos menos de él.

Fuentes y lecturas relacionadas