Lass deinen Agenten fragen, bevor er Geld ausgibt: Freigaben per Link

Agenten sollten ihre eigenen Erstattungen nicht freigeben

Sobald ein Agent Erstattungen veranlassen, Dinge kaufen oder Zugriff gewähren kann, wird jemand fragen: „Wer hat Ja gesagt?“. Die Antwort kann nicht lauten: „Das Modell hat entschieden“. Du willst, dass ein Mensch freigibt, du willst wissen, welcher, und du willst, dass der Agent wartet, statt zu raten, wenn niemand antwortet.

Die Leute, die freigeben sollten, sind oft nicht in deinem Chat-Tool: eine Finanzleiterin auf dem Handy, der Vorgesetzte eines Kunden, der Inhaber eines kleinen Betriebs. Sie brauchen einen Link, den sie überall öffnen können, keinen Seat in deiner Software.

Eine Anfrage, mehrere Freigebende

Eine Freigabe ist ein createRequest mit mode: "approval", einer Begründung und den Leuten, die entscheiden. Jede Person bekommt ihren eigenen Link, sodass jede Entscheidung ihr zugeordnet ist:

{
  "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",
    "detail": "Customer reported a damaged item. Photos in ticket T-1042.",
    "policy": "majority",
    "showOthers": "names",
    "verify": "email"
  },
  "expiresIn": "24h",
  "webhookUrl": "https://example.com/hooks/runitby",
  "metadata": { "orderId": "4821" }
}

Die Optionen, auf die es ankommt

• policy bestimmt, wie viele Freigaben nötig sind: "any", "all", "majority" oder eine Zahl. Die Entscheidung kommt, sobald sie gefallen ist, ohne auf alle zu warten.
• verify: "email" lässt jede Person einen 6-stelligen Code bestätigen, der an ihre eigene Adresse geschickt wurde, bevor die Buttons funktionieren. Ein weitergeleiteter Link kann nicht für sie entscheiden. Nutze es bei Geld, Zugriff oder Löschung.
• showOthers lässt jede freigebende Person sehen, wie die anderen stehen, namentlich oder als Zahlen.
• options ersetzt Freigeben und Ablehnen durch bis zu vier Bezeichnungen, etwa „Mit Änderungen freigeben“. Die erste zählt als Freigabe.
• allowComment lässt Leute ihre Entscheidung begründen; Kommentare kommen mit ihr zurück.

Handle nach der Entscheidung, nie nach Schweigen

Wenn die Regel erfüllt ist, erhält dein Webhook request.completed mit einer Entscheidung: "approved", "declined" oder "expired" (getStatus liefert dasselbe). Wenn niemand entscheidet, bevor die Anfrage abläuft, lautet die Entscheidung expired. Es gibt keinen Weg, auf dem keine Antwort zu einem Ja wird. Bei Builder und Pro braucht ein über MCP verbundener Agent den Webhook nicht: Er abonniert die Anfrage, erfährt, wann die Entscheidung eintrifft, und veranlasst die Erstattung in derselben Sitzung.

// Your webhook handler, after checking the X-Runitby-Signature header
if (event.event === 'request.completed') {
  if (event.verdict === 'approved') await refund(event.metadata.orderId)
  else await tellCustomer(event.metadata.orderId, event.verdict)
}

Prüfe immer die Webhook-Signatur, bevor du handelst: Sie ist ein HMAC-SHA256 des rohen Bodys mit dem Signaturgeheimnis deines Kontos. In der Doku findest du eine fertige Prüfung.

Gute Gewohnheiten

• Schreib den Betrag und die Bestellung in reason. Das lesen die Leute zuerst, auf einem kleinen Bildschirm.
• Setze ein expiresIn, das zur Entscheidung passt. Eine Erstattung kann einen Tag warten; eine Deploy-Freigabe wahrscheinlich nicht.
• Nutze metadata, um eigene IDs mitzugeben, damit der Webhook-Handler ohne Nachschlagen weiß, was zu tun ist.
• Ruf remind auf, wenn eine Frist näher rückt. Es schreibt ausstehenden Personen erneut, höchstens einmal am Tag pro Person.

Du vergleichst das mit Slack-Freigaben oder Review-Postfächern? Siehe Run it by im Vergleich zu Freigabe-Tools.