Let your agent act the moment someone answers

The wait after the question

Asking a person is half the job. They answer minutes or hours later, and by then the agent has usually moved on. So far it had three ways to find out: poll in a loop, run a webhook server that wakes it up, or stop and wait for the user to come back and ask “did they answer yet?”. Most agents in a chat app do the last one, and that’s where tasks stall.

MCP push: the answer finds the agent

Every request your agent creates is also an MCP resource, runitby://requests/{requestId}, linked from the createRequest result. A client on the 2026-07-28 protocol subscribes to it with subscriptions/listen. When someone answers or the status changes, Run it by sends notifications/resources/updated; the agent reads the resource, which returns the same as getStatus, and carries on with the task.

→ 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

Nothing runs on your side: no endpoint to host, no secret to verify, no loop to tune. The agent asks, gets on with other work, and picks the task back up when the person replies.

Example: a refund that finishes itself

A support agent needs two of three managers to approve a $1,200 refund. It creates the approval with sendEmail: true, so each manager gets their own link by email, and subscribes to the request:

{
  "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 approves. The agent is notified, reads the request (1 of 3 approved) and keeps waiting.
2. 10:21. Emily approves. The verdict is "approved"; the agent issues the refund and tells the customer, in the same session.
3. Martin never has to answer: the policy is met, and his link stops taking answers.

Had the managers declined, or let the request expire, the verdict would say so and the agent would stop. No answer never turns into a yes.

Push, webhook, wait or email?

• MCP push when your agent is an MCP client that keeps running and should react on its own.
• A webhook when your backend owns the workflow: every answer is a signed POST, retried for hours if your server is down.
• getStatus with wait for quick answers while the conversation is still open: it holds for up to 25 seconds and returns as soon as someone answers.
• notifyEmail when a person should know too, or the session may be long over by the time people answer.

They combine freely: push for the agent and an email for its owner is a good pair.

Good to know

• Push is on the Builder and Pro plans, with one subscription open at a time per account on Builder and up to three on Pro.
• It needs an MCP client on the 2026-07-28 protocol. The resource itself can be read on every plan.
• On Free and Builder, subscriptions/listen returns an error that names the other ways to hear back, so the agent can switch without guessing.