El estándar de los agentes de IA acaba de cambiar de raíz

El 28 de julio, el estándar que permite a los agentes de IA conectarse con los sistemas de una empresa publicó una nueva versión. Y no ha sido una actualización menor: es la mayor revisión desde que existe MCP y buena parte de lo que hasta ahora formaba parte del protocolo ha desaparecido.

Se llama MCP y es posible que todavía no te suene. Pero si tu empresa ha comprado, encargado o desarrollado algo con agentes de IA durante el último año, hay bastantes posibilidades de que esté apoyado en él.

Por eso merece la pena entender qué ha cambiado. La reacción más lógica podría ser esperar a que el estándar se estabilice. Y, precisamente, esa puede ser la decisión equivocada.

Qué es MCP, en dos frases

Un agente de IA, por sí solo, tiene una limitación bastante evidente: puede razonar, pero no conoce tu empresa.

No puede consultar tu ERP, revisar el calendario, crear un cliente o comprobar el estado de una factura si no tiene alguna forma de acceder a esos sistemas.

MCP es ese puente.

Es un estándar abierto que define cómo un agente puede descubrir qué puede hacer un sistema y cómo puede pedirle que lo haga. La ventaja de tener un estándar común es sencilla: no hay que construir una integración diferente desde cero para cada agente y para cada herramienta.

Qué se ha eliminado

Hay dos cambios que destacan especialmente.

El agente ya no mantiene una conversación abierta con el sistema

Hasta ahora, el funcionamiento se parecía bastante a una llamada telefónica.

El agente iniciaba la conversación, ambas partes se identificaban y, mientras la conexión siguiera abierta, podían mantener ese contexto. Si la comunicación se interrumpía, había que volver a establecerla.

Ahora el modelo se parece más a enviar una carta.

Cada petición contiene la información necesaria para entenderla por sí misma: quién la realiza, qué quiere hacer y con qué permisos. No es necesario mantener una conversación abierta ni confiar en que ambos sistemas recuerden lo que ocurrió en la petición anterior.

Puede parecer un cambio puramente técnico, pero tiene una consecuencia importante: reduce la cantidad de estado que la propia infraestructura tiene que mantener.

MCP deja de intentar decidir cómo se comporta el agente

El segundo cambio es todavía más interesante.

El protocolo tenía mecanismos que permitían al sistema conectado tomar cierta iniciativa y pedir cosas al agente, influyendo en el desarrollo de la interacción.

Eso desaparece.

Queda un periodo de transición de un año para quienes ya tienen esas capacidades en producción, pero la dirección es clara: MCP deja de intentar dirigir la conversación.

Su función pasa a ser mucho más concreta.

Decir qué puede hacer un sistema y cómo puede utilizarse.

Quién decide qué hacer, en qué orden y con qué criterio queda fuera del protocolo.

Y creo que ahí está la parte realmente importante de todo este cambio.

Lo que esto debería cambiar en una empresa

Un estándar que elimina una parte importante de lo que había definido apenas veinte meses después de su aparición va a seguir evolucionando.

Probablemente más de una vez.

Por eso conviene separar dos cosas que en muchos proyectos terminan mezclándose.

Por un lado está el conocimiento de tu empresa.

Cómo decides si dos clientes son realmente el mismo. Qué importe necesita revisión humana. Qué haces cuando un pedido llega incompleto. Qué excepciones existen en un proceso y qué ocurre cuando algo se sale del camino habitual.

Eso no debería depender de ningún proveedor.

Es parte de cómo funciona tu negocio.

Por otro lado está la fontanería.

Cómo se envían los mensajes, en qué formato, cómo se autentican las peticiones o cómo se establece la comunicación entre sistemas.

Eso sí depende del estándar.

Y el estándar puede cambiar.

El problema aparece cuando ambas cosas están mezcladas. Una actualización técnica puede obligarte entonces a revisar reglas de negocio que nadie documentó fuera del código.

Y una actualización del protocolo acaba convirtiéndose en seis meses de trabajo del equipo.

Si las dos capas están separadas, la situación cambia bastante.

El estándar puede cambiar dos, tres o cinco veces sin que tengas que volver a definir cómo funciona tu negocio.

Tres preguntas que puedes hacer sin ser técnico

Si tienes un proyecto de agentes en marcha, o estás pensando en empezar uno, hay tres preguntas que pueden darte más información que cualquier presentación sobre IA.

¿Qué parte de lo que hemos construido depende del protocolo y qué parte es conocimiento nuestro?

Debería existir una frontera bastante clara entre ambas cosas.

Si nadie sabe señalarla, probablemente esa separación no existe.

Si el estándar cambia otra vez, ¿qué tendríamos que rehacer y cuánto nos costaría?

No hace falta que la respuesta sea cero.

Lo importante es que exista una respuesta.

Si nadie puede decir qué partes habría que tocar ni cuánto esfuerzo supondría, tienes una dependencia técnica que probablemente no estás viendo.

¿Está escrito, fuera del código, qué decide el agente y con qué criterio?

Esta es probablemente la pregunta más incómoda de las tres.

Y también la más importante.

Si la respuesta es que ese conocimiento está dentro del código, entonces una parte del conocimiento de tu empresa está atada a la implementación concreta que alguien construyó.

Y eso significa que cambiar de proveedor, de arquitectura o incluso de estándar puede resultar mucho más caro de lo que parecía al principio.

Lo que no ha cambiado

En una revisión de este tamaño es fácil sacar la conclusión de que todo está todavía en el aire.

No es así.

Lo que sigue siendo importante es precisamente lo que debería haber importado desde el principio: que la unidad útil con la que trabaja un agente sea una capacidad expresada en términos de negocio.

Dar de alta un cliente.

Comprobar si una factura está conciliada.

Consultar el estado de un pedido.

Reservar una cita.

No debería ser necesario que el agente entienda primero una maraña de operaciones técnicas para poder hacer algo que para una persona de la empresa tiene un significado muy claro.

Eso es lo que permanece.

Todo el andamiaje que rodeaba esa idea puede cambiar. Y, de hecho, ya ha cambiado.

La idea central, en cambio, sigue ahí.

Si quieres profundizar en esta forma de plantear las integraciones, puedes leer MCP-Led: integración semántica para sistemas empresariales.

Por eso creo que esperar a que MCP se estabilice antes de empezar a trabajar con agentes puede ser una mala interpretación de lo que realmente estamos aprendiendo.

Lo importante no es memorizar el protocolo.

Va a cambiar.

Lo importante es aprovechar estos proyectos para entender cómo funcionan de verdad tus propios procesos cuando intentas automatizarlos.

Qué excepciones aparecen.

Qué reglas nadie había documentado.

Qué información necesita realmente el agente.

Y, sobre todo, en qué momentos sigue siendo necesario que decida una persona.

Eso no lo deprecia ninguna especificación.