Faça seu agente agir assim que alguém responder

A espera depois da pergunta

Perguntar a uma pessoa é só metade do trabalho. Ela responde minutos ou horas depois, e a essa altura o agente geralmente já seguiu em frente. Até agora ele tinha três formas de descobrir: consultar em loop, rodar um servidor de webhook que o acorde ou parar e esperar o usuário voltar e perguntar “já responderam?”. A maioria dos agentes em um app de chat faz a última, e é aí que as tarefas empacam.

MCP push: a resposta encontra o agente

Toda solicitação que seu agente cria também é um recurso MCP, runitby://requests/{requestId}, referenciado no resultado de createRequest. Um cliente no protocolo 2026-07-28 o assina com subscriptions/listen. Quando alguém responde ou o status muda, o Run it by envia notifications/resources/updated; o agente lê o recurso, que devolve o mesmo que getStatus, e segue com a tarefa.

→ subscriptions/listen
  { "resourceSubscriptions": ["runitby://requests/req_8fK2…"] }

← notifications/resources/updated
  { "uri": "runitby://requests/req_8fK2…" }

→ resources/read
  { "uri": "runitby://requests/req_8fK2…" }   // status, verdict and every answer so far

Nada roda do seu lado: nenhum endpoint para hospedar, nenhum segredo para verificar, nenhum loop para ajustar. O agente pergunta, segue com outras tarefas e retoma a tarefa quando a pessoa responde.

Exemplo: um reembolso que se conclui sozinho

Um agente de suporte precisa que dois de três gestores aprovem um reembolso de $1,200. Ele cria a aprovação com sendEmail: true, para que cada gestor receba o próprio link por e-mail, e assina a solicitação:

{
  "mode": "approval",
  "title": "Refund #4821",
  "requester": "Ava (the Acme refunds agent)",
  "audience": { "kind": "named", "recipients": [{ "name": "John Smith", "email": "john@acme.com" }, { "name": "Martin Carpenter", "email": "martin@acme.com" }, { "name": "Emily Lee", "email": "emily@acme.com" }] },
  "approval": { "reason": "Refund order #4821, $1,200", "policy": "majority", "verify": "email" },
  "sendEmail": true
}

1. 10:14. John aprova. O agente é notificado, lê a solicitação (1 de 3 aprovaram) e continua esperando.
2. 10:21. Emily aprova. O veredito é "approved"; o agente faz o reembolso e avisa o cliente, na mesma sessão.
3. Martin nem precisa responder: a regra foi cumprida, e o link dele deixa de aceitar respostas.

Se os gestores tivessem recusado, ou deixado a solicitação expirar, o veredito diria isso e o agente pararia. A falta de resposta nunca vira um sim.

Push, webhook, espera ou e-mail?

• MCP push quando seu agente é um cliente MCP que continua rodando e deve reagir por conta própria.
• Um webhook quando seu backend é o dono do fluxo: cada resposta é um POST assinado, com novas tentativas por horas se o seu servidor estiver fora do ar.
• getStatus com wait para respostas rápidas enquanto a conversa ainda está aberta: segura a chamada por até 25 segundos e responde assim que alguém responde.
• notifyEmail quando uma pessoa também deve ficar sabendo, ou quando a sessão já pode ter acabado há muito tempo quando as pessoas responderem.

Eles se combinam à vontade: push para o agente e um e-mail para o dono dele é uma boa dupla.

Bom saber

• O push está nos planos Builder e Pro, com uma assinatura aberta por vez por conta no Builder e até três no Pro.
• Exige um cliente MCP no protocolo 2026-07-28. O recurso em si pode ser lido em todos os planos.
• No Free e no Builder, subscriptions/listen devolve um erro que indica as outras formas de receber a resposta, para o agente trocar sem adivinhar.