Lass deinen Agenten handeln, sobald jemand antwortet

Das Warten nach der Frage

Einen Menschen zu fragen ist nur die halbe Arbeit. Er antwortet Minuten oder Stunden später, und bis dahin ist der Agent meist weitergezogen. Bisher gab es drei Wege, das mitzubekommen: in einer Schleife pollen, einen Webhook-Server betreiben, der ihn weckt, oder anhalten und warten, bis der Nutzer zurückkommt und fragt: „Hat schon jemand geantwortet?“. Die meisten Agenten in einer Chat-App machen Letzteres, und genau da bleiben Aufgaben hängen.

MCP-Push: Die Antwort findet den Agenten

Jede Anfrage, die dein Agent erstellt, ist auch eine MCP-Ressource, runitby://requests/{requestId}, verlinkt im Ergebnis von createRequest. Ein Client mit dem Protokoll vom 2026-07-28 abonniert sie mit subscriptions/listen. Wenn jemand antwortet oder sich der Status ändert, sendet Run it by notifications/resources/updated; der Agent liest die Ressource, die dasselbe liefert wie getStatus, und macht mit der Aufgabe weiter.

→ 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

Auf deiner Seite läuft nichts: kein Endpunkt zu hosten, kein Geheimnis zu prüfen, keine Schleife zu justieren. Der Agent fragt, macht mit anderen Aufgaben weiter und nimmt die Aufgabe wieder auf, sobald die Person antwortet.

Beispiel: eine Erstattung, die sich selbst abschließt

Ein Support-Agent braucht die Freigabe von zwei von drei Managern für eine Erstattung über $1,200. Er erstellt die Freigabe mit sendEmail: true, sodass jeder Manager seinen eigenen Link per E-Mail bekommt, und abonniert die Anfrage:

{
  "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 Uhr. John gibt frei. Der Agent wird benachrichtigt, liest die Anfrage (1 von 3 freigegeben) und wartet weiter.
2. 10:21 Uhr. Emily gibt frei. Die Entscheidung lautet "approved"; der Agent veranlasst die Erstattung und informiert den Kunden, in derselben Sitzung.
3. Martin muss gar nicht mehr antworten: Die Regel ist erfüllt, und sein Link nimmt keine Antworten mehr an.

Hätten die Manager abgelehnt oder die Anfrage ablaufen lassen, würde die Entscheidung das sagen, und der Agent würde aufhören. Keine Antwort wird nie zu einem Ja.

Push, Webhook, Warten oder E-Mail?

• MCP-Push, wenn dein Agent ein MCP-Client ist, der weiterläuft und von selbst reagieren soll.
• Ein Webhook, wenn dein Backend den Workflow besitzt: Jede Antwort ist ein signierter POST, stundenlang wiederholt, falls dein Server nicht erreichbar ist.
• getStatus mit wait für schnelle Antworten, solange das Gespräch noch offen ist: Es hält bis zu 25 Sekunden und antwortet, sobald jemand antwortet.
• notifyEmail, wenn auch ein Mensch Bescheid wissen soll oder die Sitzung längst vorbei sein könnte, bis die Leute antworten.

Sie lassen sich frei kombinieren: Push für den Agenten und eine E-Mail für seinen Besitzer sind ein gutes Paar.

Gut zu wissen

• Push gibt es in den Tarifen Builder und Pro, mit einem gleichzeitig offenen Abonnement pro Konto bei Builder und bis zu drei bei Pro.
• Dafür braucht es einen MCP-Client mit dem Protokoll vom 2026-07-28. Die Ressource selbst lässt sich in jedem Tarif lesen.
• Bei Free und Builder liefert subscriptions/listen einen Fehler, der die anderen Wege nennt, Antworten zu erhalten, sodass der Agent umschalten kann, ohne zu raten.