Que tu agente actúe en cuanto alguien responde

La espera tras la pregunta

Preguntar a una persona es la mitad del trabajo. Responde minutos u horas después, y para entonces el agente suele haber pasado a otra cosa. Hasta ahora tenía tres maneras de enterarse: consultar en bucle, ejecutar un servidor de webhooks que lo despierte, o parar y esperar a que el usuario vuelva y pregunte “¿ya respondieron?”. La mayoría de los agentes en una app de chat hacen lo último, y ahí es donde las tareas se estancan.

MCP push: la respuesta encuentra al agente

Cada solicitud que crea tu agente es también un recurso MCP, runitby://requests/{requestId}, enlazado desde el resultado de createRequest. Un cliente del protocolo 2026-07-28 se suscribe a él con subscriptions/listen. Cuando alguien responde o cambia el estado, Run it by envía notifications/resources/updated; el agente lee el recurso, que devuelve lo mismo que getStatus, y sigue con la tarea.

→ 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

No se ejecuta nada de tu lado: ni un endpoint que alojar, ni un secreto que verificar, ni un bucle que ajustar. El agente pregunta, sigue con otras tareas y retoma la tarea cuando la persona contesta.

Ejemplo: un reembolso que se termina solo

Un agente de soporte necesita que dos de tres gerentes aprueben un reembolso de $1,200. Crea la aprobación con sendEmail: true, así que cada gerente recibe su propio enlace por correo, y se suscribe a la solicitud:

{
  "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 aprueba. El agente recibe el aviso, lee la solicitud (1 de 3 aprobadas) y sigue esperando.
2. 10:21. Emily aprueba. El veredicto es "approved"; el agente emite el reembolso y avisa al cliente, en la misma sesión.
3. Martin no tiene que responder: la regla se cumple y su enlace deja de aceptar respuestas.

Si los gerentes hubieran rechazado, o hubieran dejado caducar la solicitud, el veredicto lo diría y el agente se detendría. La falta de respuesta nunca se convierte en un sí.

¿Push, webhook, espera o correo?

• MCP push cuando tu agente es un cliente MCP que sigue en marcha y debe reaccionar por su cuenta.
• Un webhook cuando tu backend es el dueño del flujo: cada respuesta es un POST firmado, con reintentos durante horas si tu servidor está caído.
• getStatus con wait para respuestas rápidas mientras la conversación sigue abierta: mantiene la llamada hasta 25 segundos y responde en cuanto alguien contesta.
• notifyEmail cuando una persona también debe enterarse, o cuando la sesión puede haber terminado hace rato para cuando la gente responda.

Se combinan libremente: push para el agente y un correo para su dueño es una buena pareja.

Conviene saber

• Push está en los planes Builder y Pro, con una suscripción abierta a la vez por cuenta en Builder y hasta tres en Pro.
• Necesita un cliente MCP del protocolo 2026-07-28. El recurso en sí se puede leer en todos los planes.
• En Free y Builder, subscriptions/listen devuelve un error que indica las otras maneras de recibir la respuesta, para que el agente cambie sin adivinar.