El resumen del DevDay de OpenAI del 29 de septiembre lo explicó con un ejemplo muy claro: «puedes pedirle a ChatGPT que monitorice las nuevas tareas en un tablero de proyectos. Cuando entra una, ChatGPT puede leer los documentos vinculados y redactar un plan, incluso mientras estás fuera». Detrás de esto se encuentra la compatibilidad de ChatGPT con la propuesta de especificación de MCP Events, disponible en todos los planes y lanzada junto con dos funciones orientadas a equipos: tareas de equipo que se ejecutan de forma programada o basadas en eventos, y @ChatGPT en Slack y Teams.
Para un equipo que ya trabaja con agentes de programación, contar con un tablero que los agentes supervisan redefine por completo lo que significa una nueva tarea. Antes, una tarea esperaba la intervención de una persona; ahora puede activar a un agente, o a varios. Si dos personas piden por separado a ChatGPT que monitorice el mismo tablero, y este ya tiene asignado un agente para nuevas labores, una sola tarea puede generar tres borradores de planes en tres lugares distintos, sin que nadie haya definido cuál es el válido.
TL;DR
MCP Events ofrece a ChatGPT un mecanismo limpio y firmado para recibir notificaciones sobre cambios en aplicaciones conectadas, mientras que las tareas de equipo de ChatGPT incorporan flujos de trabajo programados y dirigidos por eventos a los planes Business y Enterprise. Conseguir que un evento active un agente es la parte sencilla, y OpenAI la ha implementado minuciosamente. Lo verdaderamente complejo es lo que ese evento produce en el tablero: quién asume la responsabilidad del trabajo resultante, dónde se deposita el borrador del plan, cómo se revisa y cómo se evita que dos agentes respondan al mismo evento. La solución pasa por establecer una regla de enrutamiento clara: un tipo de evento, un único responsable, planes que regresan a la tarea y una persona que dé el visto bueno antes de dar nada por terminado.
Novedades presentadas en el DevDay
MCP Events es una propuesta de extensión para el Model Context Protocol que permite a un servidor MCP notificar a ChatGPT cuando ocurre algo en una aplicación conectada, de modo que un plugin pueda iniciar una automatización como respuesta. La guía de MCP Events de OpenAI describe la implementación en el servidor. Este indica que admite eventos e implementa tres métodos: events/list, events/subscribe y events/unsubscribe. ChatGPT solo admite la entrega mediante webhooks, firmados con HMAC de Standard Webhooks tras superar un desafío de verificación HTTPS, a razón de un evento por solicitud de hasta 256 KiB. Cuando llega un evento, tal como indica la guía, «ChatGPT recibe el evento en el chat suscrito y sigue las instrucciones del usuario sobre cómo responder».
Los detalles se han cuidado donde más importa. El servidor debe asignar a cada evento un identificador único que se conserve entre reintentos. Las suscripciones deben ser idempotentes: su identidad depende del principal, la URL de callback, el nombre del evento y los argumentos; de este modo, suscribirse de nuevo actualiza la suscripción existente en lugar de duplicarla. Asimismo, el servidor debe bloquear direcciones de callback locales o privadas y no debe seguir redirecciones.
| Lanzamiento | Qué hace | Planes | Quién define la respuesta |
|---|---|---|---|
| MCP Events | Un servidor MCP envía eventos; ChatGPT ejecuta la automatización configurada | Todos los planes | La persona cuyo chat se ha suscrito |
| Team tasks | Trabajo recurrente, como actualizaciones semanales de proyectos, de forma programada o en respuesta a eventos como un nuevo correo o mensaje de Slack | Business, Enterprise | El equipo define y ajusta las instrucciones de forma colaborativa |
| @ChatGPT en Slack y Teams | Menciónalo en un canal, hilo o mensaje directo; utiliza las herramientas conectadas por el administrador o las tuyas según tus permisos | Business, Enterprise | Cualquier participante de la conversación añade contexto, sin requerir una licencia individual de ChatGPT |
En conjunto, estas novedades convierten a ChatGPT en un entorno donde el trabajo puede iniciarse desde fuera de una conversación. Supone un avance significativo que resultará más que suficiente para gran cantidad de tareas recurrentes.
El disparador es solo la mitad fácil
Traslademos el ejemplo del anuncio a un equipo real. Llega una nueva tarea al tablero. ChatGPT lee los documentos vinculados y redacta un plan de acción. A partir de ahí surgen cuatro preguntas inevitables, y ninguna tiene que ver con la capa de transporte.
¿Quién se hace cargo del trabajo resultante? Un borrador de plan no constituye una asignación. Alguien debe asumir la responsabilidad del trabajo descrito y, en la mayoría de los equipos, esto se gestiona en el tablero: un responsable asignado y un estado que avanza. Un buen borrador no cambia ninguno de estos dos elementos por sí solo.
¿Dónde se entrega el plan? El evento llega al chat que formalizó la suscripción, y el plan irá adonde indiquen las instrucciones de esa persona: como respuesta dentro del chat o mediante una escritura directa en el tablero, siempre que el plugin lo permita y las instrucciones así lo soliciten. El equipo debe tener esto muy claro; de lo contrario, el tablero seguirá mostrando la tarea como «nueva» mientras un plan perfectamente viable aguarda en un lugar que nadie consulta.
¿Cómo se revisa? Un plan representa una decisión de alcance. Alguien distinto a su autor debe revisarlo antes de comenzar a escribir código, y debe quedar documentado en un lugar accesible para quien tome el relevo.
¿Quién responde al evento? La idempotencia evita que una misma suscripción se duplique por sí sola. Sin embargo, no coordina la interacción entre dos personas, ya que el principal forma parte de la identidad de la suscripción y, por lo tanto, cada una es independiente. Si a esto sumamos un agente asignado directamente en el tablero, una misma tarea podría planificarse más de una vez. La deduplicación en la capa de webhooks no resuelve la asignación de responsabilidades en el flujo de trabajo.
Estas cuestiones atañen a la gestión de procesos. Ya existían antes de los agentes —cuando tres personas podían tomar el mismo ticket a la vez— y ahora se intensifican cuando quien toma el trabajo nunca descansa. Para profundizar en la revisión de tareas desatendidas, consulta agentes de programación mientras estás ausente.
Centraliza las reglas de enrutamiento en el tablero
En un tablero donde los agentes figuran como asignados (Assignees), «monitorizar nuevas tareas» equivale prácticamente a «asignar la tarea». En Sharkly, una tarea asignada a un agente inicia su ejecución tan pronto como sale del Backlog y su entorno de computación y runtime están listos. El espacio de asignación de ejecución admite exactamente un Agent o Crew, y Sharkly consolida el trabajo pendiente para evitar que una ráfaga rápida de comentarios genere ejecuciones duplicadas para el mismo agente y tarea. La asignación es un campo estructurado, no una mera convención.
Para los eventos que deben iniciar tareas sin una asignación previa, las automatizaciones de Sharkly son el equivalente integrado en el tablero. Una automatización consiste en una única regla: instrucciones, un Agent o Crew, uno o varios disparadores y un historial de ejecuciones, con estado Activo o En pausa. Sus disparadores abarcan programación temporal (cron con zona horaria), el paso de una tarea a un estado concreto, un comentario con una frase específica o un webhook de un servicio externo, además de la opción «Ejecutar ahora» para pruebas. Cada ejecución comienza de inmediato y registra su historial en la propia automatización, por lo que las instrucciones deben especificar dónde se almacena el resultado. Dado que la coincidencia de estados y comentarios opera hoy a nivel de toda la organización, la documentación de automatizaciones recomienda incluir instrucciones que validen la tarea que originó el disparo antes de proceder.
A continuación se muestra la matriz de eventos y tareas de un Space:
| Evento | Mecanismo | Quién lo ejecuta | Dónde se registra el resultado | Quién decide |
|---|---|---|---|---|
| Solicitud publicada en Slack | Un atajo de Slack crea una Task en estado de triaje | Nadie todavía | La Task, en Triage | Una persona la acepta, la rechaza, la marca como duplicada o la pospone |
| Apertura de un issue en GitHub | Integración con GitHub: los nuevos issues de un repositorio vinculado pasan a ser Tasks | Nadie todavía | La Task | La persona encargada del triaje en el Space |
| La Task pasa a «Needs plan» | Automatización por cambio de estado | Planner Agent | Un comentario en la Task | El asignado humano de la Task |
| Comentario «/replan» en una Task | Automatización por detección de comentario | Planner Agent | Un nuevo comentario en la Task | El asignado humano de la Task |
| Task asignada a un agente de código, sale de Backlog | Ejecución de la Task | Ese agente, en su Computer | Comentarios, Executions, pull request vinculada | Un revisor, y luego una persona la aprueba |
| Webhook por fallo en CI | Automatización activada por webhook | Triage Agent | Historial de ejecuciones de la automatización | La persona de guardia (on-call) |
| Días laborables a las 09:00 | Automatización por programación horaria | Status Agent | Historial de ejecuciones y una entrada en el Inbox de cada destinatario | El responsable del equipo |
Y esta es la regla en la que se fundamenta, expuesta con total claridad para que el equipo pueda debatirla y ajustarla:
Routing rule: new work in the ENG Space
1. One event type, one owner. Each event maps to exactly one
Automation or one Agent Assignee. Personal watchers (a chat
subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
the Backlog category. The "Draft plan" Automation runs the Planner
Agent, which first checks the Task's Space and type and stops if
the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
into a Completed status.
Ubicar «Needs plan» dentro de la categoría Backlog es precisamente lo que garantiza la seguridad del paso 5: una tarea asignada en Backlog permanece a la espera, permitiendo revisar el plan antes de iniciar la ejecución. Especifica con precisión en las instrucciones del Planner dónde debe publicarse el plan y compruébalo mediante «Ejecutar ahora» antes de confiar plenamente en el disparador. Cuando un agente requiere una decisión a mitad de ejecución, la tarea pasa al estado de espera de respuesta humana y se envía al Inbox del responsable; es aquí donde la promesa de «incluso mientras estás fuera» vuelve a necesitar el criterio de una persona. La tarea es el punto exacto donde una petición en un chat grupal se transforma en trabajo rastreable, y lo mismo ocurre con un issue de GitHub asignado a un agente.
Dónde encaja la monitorización de ChatGPT
Recurre a una suscripción de MCP Events cuando una sola persona necesite avisos y un primer borrador en su propio chat: un tablero que supervisas pero no gestionas, el registro de seguimiento de un socio o un resumen de los viernes para uso personal. Utiliza las tareas de equipo cuando el trabajo recurrente consista en informes compartidos dentro de ChatGPT y tu organización cuente con planes Business o Enterprise, ya que los miembros del equipo colaboran afinando un único conjunto de directrices en lugar de escribir cada uno las suyas. En cambio, implementa una regla en el tablero cuando el evento genere trabajo del que el equipo deba responsabilizarse: un plan que alguien ejecutará, una corrección que alguien debe revisar o una tarea que deba contabilizarse en el reporte del lunes.
Los agentes de IA dirigidos por eventos son tan efectivos como la regla que determina cuál de ellos debe responder. El evento es solo la infraestructura de transporte; el enrutamiento, la titularidad y la revisión forman parte de la gestión, y deben residir en el tablero al que reportan todos los agentes, con independencia del proveedor que los desarrolle. Para decidir qué tareas asumen los agentes una vez que la cola se llena, consulta gestión y triaje del backlog de IA. Por su parte, Dots, el primer lanzamiento del resumen de OpenAI, plantea este mismo dilema desde la perspectiva del agente.
Si ya gestionas varios agentes, Sharkly te ofrece un único entorno centralizado para coordinar sus tareas y resultados.
Recursos adicionales
- Sharkly Automations: los cuatro tipos de disparadores, historial de ejecuciones y los límites de la automatización
- De un chat grupal a tareas de código rastreables: cómo convertir un mensaje en trabajo con responsable asignado
- Gestión y triaje del backlog de IA: cómo priorizar el próximo trabajo de los agentes
- Asignar un issue de GitHub a un agente de IA: del problema al pull request listo para revisión
- Agentes de programación mientras estás ausente: ejecuciones desatendidas y la cola de revisión
- OpenAI Dots explicado: agentes personales siempre activos y el soporte complementario que requiere un equipo
