A retrospectiva do DevDay da OpenAI em 29 de setembro resumiu o exemplo em palavras simples: “você pode pedir ao ChatGPT para monitorar novas tarefas em um quadro de projetos. Quando uma surgir, o ChatGPT pode ler os documentos vinculados e elaborar um rascunho de plano, mesmo enquanto você estiver ausente.” Por baixo dos panos, isso funciona graças ao suporte do ChatGPT à especificação proposta de MCP Events, disponível em todos os planos, lançada juntamente com dois recursos voltados para equipes: tarefas de equipe executadas por agendamento ou por eventos, e o @ChatGPT no Slack e no Teams.
Para uma equipe que já utiliza agentes de programação, um quadro monitorado por agentes muda o significado de uma nova tarefa. Antes, ela ficava aguardando uma pessoa. Agora, pode acionar um ou vários agentes. Se duas pessoas pedirem ao ChatGPT para monitorar o mesmo quadro, e o próprio quadro já tiver um agente atribuído a novos trabalhos, uma única tarefa pode gerar três propostas de planos em três lugares diferentes, sem que ninguém tenha definido qual delas é a válida.
TL;DR
O MCP Events oferece ao ChatGPT uma forma limpa e autenticada de ser notificado sobre alterações em um aplicativo conectado, enquanto as tarefas de equipe do ChatGPT trazem fluxos de trabalho agendados e orientados a eventos para os planos Business e Enterprise. Fazer um evento acionar um agente é a parte fácil, e a OpenAI fez isso com muito cuidado. A parte difícil é o que esse evento gera no quadro: quem assume a responsabilidade pelo trabalho resultante, onde o rascunho do plano é registrado, como ele é revisado e como evitar que dois agentes respondam ao mesmo evento. Defina isso em uma regra de roteamento: um tipo de evento, um único responsável, planos que retornam à Task e uma pessoa que aprova antes que qualquer item seja considerado concluído.
O que foi lançado no DevDay
O MCP Events é uma proposta de extensão para o Model Context Protocol que permite a um servidor MCP notificar o ChatGPT quando algo acontece em um aplicativo conectado, possibilitando que um plugin inicie uma automação em resposta. O guia de MCP Events da OpenAI descreve o lado do servidor. O servidor informa que suporta eventos e implementa três métodos: events/list, events/subscribe e events/unsubscribe. O ChatGPT suporta exclusivamente entrega via webhook, assinada com HMAC do Standard Webhooks, após um desafio de verificação via HTTPS, com um evento por requisição de até 256 KiB. Quando um evento chega, nas palavras do guia, “o ChatGPT recebe o evento no chat inscrito e segue as instruções do usuário sobre como responder”.
Os detalhes foram pensados com cautela onde realmente importa. O servidor precisa atribuir a cada evento um ID exclusivo que se mantenha o mesmo em novas tentativas. As inscrições devem ser idempotentes: sua identidade deriva da entidade principal, da URL de callback, do nome do evento e dos argumentos, de modo que inscrever-se novamente atualiza a inscrição existente em vez de criar uma duplicada. O servidor deve bloquear endereços de callback privados e locais e não pode seguir redirecionamentos.
| Lançamento | O que faz | Planos | Quem define a resposta |
|---|---|---|---|
| MCP Events | Um servidor MCP envia eventos; o ChatGPT executa a automação descrita por você | Todos os planos | A pessoa cujo chat realizou a inscrição |
| Tarefas de equipe | Trabalhos recorrentes, como atualizações semanais de projetos, por agendamento ou em resposta a eventos como um novo e-mail ou mensagem no Slack | Business, Enterprise | Os colegas de equipe refinam as instruções em conjunto |
| @ChatGPT no Slack e no Teams | Mencione-o em um canal, thread ou mensagem direta; ele utiliza ferramentas conectadas pelo administrador ou as suas próprias permissões | Business, Enterprise | Qualquer pessoa na conversa pode adicionar contexto, sem precisar de uma licença individual do ChatGPT |
Juntos, esses recursos transformam o ChatGPT em um espaço onde o trabalho pode ter início a partir de fora de uma conversa. Esse é um passo importante e, para muitas demandas recorrentes, será suficiente.
O gatilho é a parte fácil
Aplique o exemplo da retrospectiva a uma equipe real: uma nova tarefa chega ao quadro; o ChatGPT lê os documentos anexados e elabora um rascunho de plano. A partir daí surgem quatro perguntas, e nenhuma delas diz respeito ao transporte de dados.
Quem é o responsável pelo trabalho resultante? Um rascunho de plano não é uma atribuição formal. Alguém precisa se responsabilizar pelo trabalho descrito e, na maioria das equipes, essa responsabilidade fica registrada no quadro: um nome na tarefa e um status que avança. Um bom rascunho não altera nada disso por conta própria.
Onde o plano é registrado? O evento é recebido no chat que realizou a inscrição, e o plano vai para onde as instruções daquela pessoa determinarem: uma resposta no próprio chat ou um registro de volta no quadro, caso o plugin disponibilize essa ação e as instruções a solicitem. A equipe precisa saber para onde ele vai, caso contrário o quadro continuará marcando a tarefa como “nova” enquanto um plano perfeitamente válido fica esquecido em um lugar que ninguém mais lê.
Como ele é revisado? Um plano é uma decisão de escopo. Alguém além do seu autor deve lê-lo antes do início da codificação, e em um local de fácil acesso para o próximo responsável.
Quem responde ao evento? A idempotência impede que uma mesma assinatura se duplique. No entanto, ela não coordena duas pessoas diferentes, pois a entidade principal faz parte da identidade da assinatura, tornando a inscrição de cada pessoa única e independente. Some a isso um Agent atribuído no próprio quadro e a mesma tarefa poderá ser planejada mais de uma vez. A deduplicação na camada de webhook não decide a responsabilidade na camada de trabalho.
Essas são questões de gestão. Elas já existiam antes dos agentes — quando três pessoas podiam pegar o mesmo ticket por engano — e retornam com ainda mais intensidade quando quem assume a tarefa nunca dorme. Para entender melhor a etapa de revisão em execuções não supervisionadas, consulte agentes de programação enquanto você está ausente.
Centralize o roteamento no quadro
Em um quadro onde os agentes atuam como Assignees, “monitorar novas tarefas” se resume praticamente a “atribuir a tarefa”. No Sharkly, uma Task atribuída a um Agent inicia uma execução assim que sai do Backlog e seu Computer e Runtime ficam prontos. O campo de Assignee de execução comporta exatamente um Agent ou Crew, e o Sharkly consolida o trabalho pendente para que comentários sucessivos não gerem execuções duplicadas para o mesmo Agent e Task. A responsabilidade é um campo formal, não uma convenção.
Para eventos que devem iniciar trabalhos sem atribuição prévia, as Automações do Sharkly são o equivalente no lado do quadro. Uma automação é uma regra única: instruções, um Agent ou Crew, um ou mais gatilhos e o histórico de execuções, com status Ativo ou Pausado. Seus gatilhos podem ser um agendamento (cron com fuso horário), uma Task mudando para um status selecionado, um comentário contendo determinada frase e um webhook de um serviço externo, além da opção Run now para testes. Cada execução começa diretamente e mantém seu histórico na própria automação; portanto, as instruções devem especificar onde o resultado será registrado. A correspondência de status e comentários hoje abrange toda a organização, por isso a documentação de Automações recomenda incluir instruções que verifiquem a Task disparadora antes de agir.
Aqui está a tabela de correspondência entre eventos e tarefas de um Space:
| Evento | Mecanismo | Quem executa | Onde o resultado é registrado | Quem decide |
|---|---|---|---|---|
| Solicitação publicada no Slack | Atalho do Slack cria uma Task no status de triagem | Ninguém ainda | A Task, em Triage | Uma pessoa aceita, recusa, marca como duplicada ou adia |
| Issue aberta no GitHub | Integração com GitHub: novas issues em um repositório vinculado tornam-se Tasks | Ninguém ainda | A Task | Quem realiza a triagem do Space |
| Task muda para “Needs plan” | Automação, gatilho de status | Planner Agent | Um comentário na Task | O responsável humano pela Task |
| Comentário “/replan” em uma Task | Automação, gatilho de comentário | Planner Agent | Um novo comentário na Task | O responsável humano pela Task |
| Task atribuída a um Agent de código, sai do Backlog | Execução da Task | Aquele Agent, em seu Computer | Comentários, Executions, pull request vinculado | Um revisor; em seguida, uma pessoa aceita |
| Webhook de falha no CI | Automação, gatilho de webhook | Triage Agent | Histórico de execuções da automação | A pessoa de plantão |
| Dias úteis às 09:00 | Automação, gatilho de agendamento | Status Agent | Histórico de execuções e uma linha na Inbox de cada destinatário | O líder da equipe |
E a regra por trás disso, documentada onde a equipe possa debatê-la:
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.
Colocar o status “Needs plan” na categoria Backlog é o detalhe que torna a etapa 5 segura: uma Task atribuída no Backlog aguarda, garantindo que o plano seja lido antes do início da execução. Especifique nas instruções do Planner exatamente para onde o plano deve ir e teste com a opção Run now antes de confiar plenamente no gatilho. Quando um Agent precisa de uma decisão no meio da execução, a Task indica espera por resposta humana e vai direto para a Inbox da pessoa responsável — que é quando a parte de atuar “mesmo enquanto você estiver ausente” volta a envolver um ser humano. A Task é o ponto onde uma solicitação de chat em grupo se transforma em trabalho rastreável, e o mesmo vale para uma issue do GitHub atribuída a um agente.
Onde o monitoramento do ChatGPT se encaixa
Utilize uma assinatura do MCP Events quando uma única pessoa quiser receber notificações e um primeiro rascunho em seu próprio chat: um quadro que você acompanha mas não gerencia, o controle de um parceiro ou um resumo semanal para consumo próprio. Use tarefas de equipe quando a demanda recorrente for uma atualização coletiva mantida no ChatGPT e sua equipe estiver nos planos Business ou Enterprise, já que os colegas refinam um único conjunto de instruções em vez de cada um redigir o seu. E use uma regra no próprio quadro quando o evento gerar demandas que a equipe precisa assumir: um plano que alguém executará, uma correção que alguém revisará ou uma Task que deve constar no balanço da próxima segunda-feira.
Agentes de IA orientados a eventos são tão eficientes quanto a regra que define qual deles responde. O evento é apenas a estrutura técnica; o roteamento, a responsabilidade e a revisão fazem parte da gestão e pertencem ao quadro ao qual todos os agentes se reportam, independentemente da ferramenta utilizada. Para decidir o que os agentes devem priorizar quando a fila estiver cheia, consulte o artigo sobre gestão e triagem de backlog com IA. O recurso Dots, o primeiro anúncio da retrospectiva da OpenAI, levanta a mesma questão sob a ótica do agente.
Se você já gerencia múltiplos agentes, o Sharkly oferece uma plataforma centralizada para organizar suas tarefas e resultados.
Recursos adicionais
- Automações do Sharkly: os quatro tipos de gatilhos, histórico de execuções e os limites da automação
- Do chat em grupo a tarefas de código rastreáveis: transformando uma mensagem em trabalho com responsável definido
- Gestão e triagem de backlog com IA: decidindo no que os agentes trabalharão a seguir
- Atribua uma issue do GitHub a um agente de IA: da issue a um pull request pronto para revisão
- Agentes de programação enquanto você está ausente: execuções não supervisionadas e a fila de revisão
- OpenAI Dots explicados: agentes pessoais sempre ativos e o que uma equipe ainda precisa construir ao redor deles
