MCP Events y agentes siempre activos: cómo preparar tu plataforma

OpenAI lanzó agentes siempre activos y llevó MCP Events a ChatGPT. Qué cambia para una plataforma con API y webhooks, y cómo diseñar identidad, permisos y eventos para agentes.

Lectura de 8 minActualizado: 22 de octubre de 2026

El 29 de septiembre de 2026, en su DevDay, OpenAI presentó dots: agentes “siempre activos”, basados en GPT-6 Astra, que trabajan desde su propia computadora en la nube y se conectan a más de 4,000 aplicaciones a través de los plugins de ChatGPT. Ese mismo día amplió esos plugins, que están construidos sobre servidores MCP (Model Context Protocol), con soporte para MCP Events: un mecanismo para que un servicio externo avise al agente cuando algo ocurre, en lugar de que el agente tenga que preguntar una y otra vez.

Parece una noticia de producto de consumo, pero desde la operación de una plataforma es la señal más clara de que parte de quienes usen tu API, tu portal y tus notificaciones serán agentes que trabajan en nombre de personas, a toda hora. Veamos qué se anunció, qué dice el protocolo y cómo diseñarlo.

Qué se anunció exactamente

  • Dots. Cada dot tiene computadora y navegador propios en la nube. Se le escribe o llama desde ChatGPT, Slack y Teams, con mensajería de texto “próximamente”. En empresas, cada dot recibe su propia identidad, credenciales y accesos. Arrancó con usuarios Pro y Business Premium; en Enterprise está en beta.
  • Plugins sobre MCP. Según la documentación de OpenAI, las extensiones se montan sobre servidores MCP: para aparecer como capacidad nativa en ChatGPT, la vía es exponer uno.
  • MCP Events. ChatGPT ya entrega eventos a plugins en los chats de Work, sobre la versión del protocolo 2026-07-28. Matiz: el grupo de trabajo de MCP aún marca la propuesta como borrador exploratorio, no como especificación oficial.

MCP está en la Agentic AI Foundation de la Linux Foundation desde diciembre de 2025, y A2A se sumó en agosto de 2026: no es una integración propietaria, sino un estándar abierto.

Tu siguiente usuario puede ser un agente

Un agente con navegador propio puede usar tu portal como una persona. Funciona, pero es la peor integración posible: frágil ante cambios de interfaz, difícil de auditar y sin distinguir qué hizo el humano y qué el agente. Si no ofreces una interfaz estructurada, los agentes usarán la que encuentren.

La alternativa es publicar un servidor MCP delante de tu API existente, con herramientas pensadas para tareas concretas: consultar el estado de un envío, descargar un reporte, revisar el saldo de una cuenta de servicio, programar una campaña. Es una capa delgada sobre los mismos servicios REST de siempre.

En su documento de seguridad, OpenAI explica que los dots deben devolver al usuario los pasos sensibles, como cambiar una contraseña o transferir dinero entre cuentas. Buen patrón para copiar del lado del servidor: clasifica tus herramientas en lectura, escritura y acciones críticas. Las de lectura pueden ser autónomas; las de escritura deberían tener alcances (scopes) explícitos; y las críticas, como rotar credenciales, cambiar destinatarios de alertas o enviar una campaña masiva, deberían exigir confirmación humana en tu propio sistema, no solo en el agente.

MCP Events: los webhooks que ya tienes, con un contrato estándar

Para una plataforma de comunicaciones, esto es lo que más cambia. Casi todo lo valioso que tienes para un agente es asíncrono: el estado de entrega de un mensaje, una respuesta entrante de un cliente final, el cierre de una campaña, una alerta de cuota. Hoy eso viaja por webhooks propietarios, cada uno con su formato. Si ya trabajas con canales bidireccionales, vas a reconocer el problema de inmediato.

El borrador de diseño de MCP Events propone que el servidor declare sus tipos de evento con events/list, cada uno con un esquema para los argumentos de suscripción y otro para el contenido. Define tres modos de entrega: poll (el cliente pregunta con un cursor), push (un flujo abierto) y webhook (el servidor hace POST a una URL registrada). ChatGPT, por ahora, solo soporta webhook.

La documentación de OpenAI fija requisitos concretos:

  • Las entregas se firman con HMAC-SHA256 según Standard Webhooks, con los encabezados webhook-id, webhook-timestamp, webhook-signature y X-MCP-Subscription-Id. El secreto lo proporciona el cliente y debe medir entre 24 y 64 bytes.
  • Un evento por solicitud, con un máximo de 256 KiB de contenido.
  • Antes de activar la entrega, tu servidor debe verificar la URL de destino con un desafío de un solo uso, exigir HTTPS y bloquear direcciones privadas, locales y no públicas.
  • Las suscripciones caducan: llevan un refreshBefore y el cliente debe renovarlas antes de esa fecha.
  • Tu servidor debe volver a comprobar el acceso del usuario durante la vida de la suscripción y dejar de entregar si ese acceso se revoca.

El borrador agrega dos reglas que, en mi experiencia con plataformas de mensajería críticas, separan una integración que aguanta de una que no: las entregas concurrentes y los reintentos pueden llegar desordenados, así que el receptor deduplica por eventId y ordena por timestamp si lo necesita; y el cursor permite retomar desde donde se quedó, con un maxAgeMs que acota cuánta historia se reenvía.

Cómo lo implementaría

No como un camino aparte, sino como un adaptador más sobre el mismo bus de tus webhooks: un outbox transaccional, una cola por suscripción para que un destino lento no frene a los demás, reintentos con espera exponencial y un registro de suscripciones con principal, URL, vencimiento y estado de autorización. La revalidación de acceso conviene hacerla en el momento de la entrega, no solo al suscribir: una suscripción es, en la práctica, un permiso vivo.

Lo que la especificación 2026-07-28 simplifica en tu infraestructura

MCP Events se apoya en la versión del protocolo publicada el 28 de julio de 2026, que trae cambios muy favorables para quien opera servicios a escala:

  • Núcleo sin estado. Se elimina el saludo initialize y los identificadores de sesión; cada solicitud lleva su versión, identidad del cliente y capacidades. El propio anuncio lo resume: se puede desplegar detrás de un balanceador round-robin sin almacenamiento compartido.
  • Enrutamiento por encabezados. Las solicitudes incluyen Mcp-Method y Mcp-Name, así que tu API gateway puede autorizar, limitar tasa y medir por herramienta sin abrir el cuerpo JSON.
  • Listas cacheables. Las listas de herramientas y recursos traen ttlMs y cacheScope, lo que reduce consultas repetidas.
  • Solicitudes de varias vueltas. En vez de mantener un flujo abierto para pedirle algo al cliente, el servidor responde input_required y el cliente reintenta con la información adjunta. Es un buen punto de apoyo para pedir datos o confirmaciones antes de una acción crítica.
  • Autorización más estricta. Validación del emisor según RFC 9207, migración del registro dinámico de clientes hacia Client ID Metadata Documents y credenciales ligadas al servidor de autorización que las emitió.

El contenido de un evento es dato, no instrucción

El borrador lo dice sin rodeos: el contenido de los eventos es información no confiable, con las mismas consideraciones de inyección que los resultados de herramientas. Si un agente recibe el texto de una respuesta de un cliente final, es contenido de terceros, no una orden.

El esquema ayuda:

  • Separa los metadatos estructurados (estado, identificadores, marcas de tiempo, códigos) del texto libre, y etiqueta el texto libre como contenido de usuario.
  • Que el límite sea de 256 KiB no significa que debas llenarlo. Envía referencias y deja que el agente consulte el detalle con su propia autorización, que tú vuelves a validar.
  • Minimiza datos personales en el evento: números enmascarados, sin contenido de mensajes cuando el caso de uso solo necesita el estado.

Desde la óptica de un auditor de ISO/IEC 27001, es minimización de datos, control de acceso y trazabilidad aplicados a un consumidor que actúa solo y a cualquier hora.

Por dónde empezar con MCP Events y agentes

No hace falta lanzar un plugin mañana, pero sí que la arquitectura de este trimestre no cierre la puerta:

  • Inventario de eventos. Lista los eventos que ya emites hacia webhooks y define para cada uno un esquema estable y versionado.
  • Clasificación de acciones. Marca qué operaciones de tu API son de lectura, de escritura y críticas, y decide cuáles exigen confirmación humana en tu sistema.
  • Identidad de agentes. Prepara cuentas de servicio por agente, con scopes mínimos y auditoría separada de la del usuario.
  • Webhooks firmados. Si tus webhooks actuales no usan firma HMAC, idempotencia por identificador de evento y verificación del destino, ese es el primer trabajo, sirva o no para agentes.
  • Gateway preparado. Aprovecha los encabezados Mcp-Method y Mcp-Name para límites de tasa y métricas por herramienta.
  • Prueba acotada. Empieza con un servidor MCP de solo lectura sobre reportes o estados de envío y mide cómo lo usan los agentes antes de abrir escritura.

Ya escribí sobre por qué los agentes de IA en producción son, ante todo, un problema de arquitectura. Lo nuevo es el lado opuesto: los agentes que otros van a conectar a tu plataforma. Y el estándar ya está sobre la mesa.

Sobre las APIs de red que ya exponen los operadores, ver también Network APIs de GSMA Open Gateway.

Fuentes

¿Estás evaluando esto ahora? Si tu equipo está decidiendo cómo exponer su API y sus eventos a agentes sin perder control sobre identidad, permisos y trazabilidad, escríbeme: es una conversación que estoy teniendo bastante seguido.

Seguir leyendo

¿Te sirvió? Compártelo con tu equipo:Compartir en LinkedIn

Sigue leyendo