Fai agire il tuo agente appena qualcuno risponde

L’attesa dopo la domanda

Fare la domanda a una persona è solo metà del lavoro. Risponde dopo minuti o ore, e a quel punto l’agente di solito è già passato ad altro. Finora aveva tre modi per scoprirlo: fare polling in un ciclo, tenere un server webhook che lo risvegli, oppure fermarsi e aspettare che l’utente torni a chiedere «hanno già risposto?». La maggior parte degli agenti in un’app di chat fa l’ultima, ed è lì che i compiti si bloccano.

MCP push: la risposta trova l’agente

Ogni richiesta che il tuo agente crea è anche una risorsa MCP, runitby://requests/{requestId}, collegata dal risultato di createRequest. Un client sul protocollo 2026-07-28 vi si iscrive con subscriptions/listen. Quando qualcuno risponde o lo stato cambia, Run it by invia notifications/resources/updated; l’agente legge la risorsa, che restituisce lo stesso di getStatus, e prosegue con il compito.

→ 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

Da parte tua non gira nulla: nessun endpoint da ospitare, nessun segreto da verificare, nessun ciclo da regolare. L’agente chiede, porta avanti altro lavoro e riprende il compito quando la persona risponde.

Esempio: un rimborso che si completa da solo

Un agente di assistenza ha bisogno che due responsabili su tre approvino un rimborso di $1.200. Crea l’approvazione con sendEmail: true, così ogni responsabile riceve il proprio link per email, e si iscrive alla richiesta:

{
  "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 approva. L’agente viene avvisato, legge la richiesta (1 approvazione su 3) e continua ad aspettare.
2. 10:21. Emily approva. L’esito è "approved"; l’agente emette il rimborso e avvisa il cliente, nella stessa sessione.
3. Martin non deve nemmeno rispondere: la regola è soddisfatta e il suo link smette di accettare risposte.

Se i responsabili avessero rifiutato, o avessero lasciato scadere la richiesta, l’esito lo direbbe e l’agente si fermerebbe. Nessuna risposta non diventa mai un sì.

Push, webhook, attesa o email?

• MCP push quando il tuo agente è un client MCP che resta attivo e deve reagire da solo.
• Un webhook quando il flusso è gestito dal tuo backend: ogni risposta è un POST firmato, ritentato per ore se il tuo server è irraggiungibile.
• getStatus con wait per risposte rapide mentre la conversazione è ancora aperta: resta in attesa fino a 25 secondi e risponde appena qualcuno risponde.
• notifyEmail quando anche una persona deve saperlo, o quando la sessione potrebbe essere finita da un pezzo prima che le persone rispondano.

Si combinano liberamente: push per l’agente e un’email per chi lo gestisce sono una buona coppia.

Da sapere

• Il push è incluso nei piani Builder e Pro, con un’iscrizione aperta alla volta per account su Builder e fino a tre su Pro.
• Serve un client MCP sul protocollo 2026-07-28. La risorsa in sé si può leggere su ogni piano.
• Su Free e Builder, subscriptions/listen restituisce un errore che indica gli altri modi per ricevere la risposta, così l’agente può cambiare senza tirare a indovinare.