Decisions API für Request-Routing

Warum Routing natürlich passt

Routing stellt eine endliche Frage — welche meiner Queues ist dafür zuständig — und genau das beantwortet ein Decision-Endpoint nativ. Kein Queue-Namen aus generiertem Text parsen, kein Prompt-Engineering gegen eine erfundene fünfte Queue.

Derselbe Call kann mehrere Fragen zum selben Ticket tragen: Queue, Dringlichkeit und ein Review-Flag lösen sich in einem Roundtrip für 1 Credit.

• Queue-Zuweisung: billing, platform, account, other
• Priorität: ein geordneter Score von niedrig bis blockierend
• Eskalation: ein noul-Check, ob ein Mensch zuerst schauen muss

Criteria als Queue-Beschreibungen schreiben

Jede Option einer choice-Frage trägt eine kurze Beschreibung, was dorthin gehört. Schreiben Sie sie wie ein Briefing für eine neue Triage-Kraft — diese Beschreibungen sind Ihre Routing-Policy.

Immer eine 'other'- oder 'unclear'-Option einbauen. Ein ehrlicher Ausweg verhindert, dass mehrdeutige Tickets mit scheinbarer Sicherheit falsch geroutet werden.

Ein Call: Queue plus Dringlichkeit

Senden Sie den Ticket-Text als state und stellen Sie zwei Fragen: ein choice für das zuständige Team und ein score für die Dringlichkeit. Die Antwort enthält answers.team.choice, answers.urgency.score und eine Wahrscheinlichkeit pro Option für beide.

// Route a ticket: ask for team + urgency in one call,
// then gate the automation on confidence.
const res = await fetch("https://decisions-api.net/api/v1/decisions", {
  method: "POST",
  headers: {
    Authorization: "Bearer YOUR_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "decisions-1",
    state: "Payments fail with a 500 since your last deploy. Enterprise plan customer.",
    questions: {
      team: {
        type: "choice",
        instructions: "Which queue should handle this request?",
        criteria: {
          payments: "Billing, charges, or payment failures.",
          platform: "Deploys, infrastructure, or API errors.",
          account: "Login, SSO, or permissions.",
          other: "Unclear or out of scope.",
        },
      },
      urgency: {
        type: "score",
        instructions: "How urgent is this for the customer?",
        criteria: ["can wait", "normal queue", "needs attention today", "blocking revenue"],
      },
    },
  }),
});
const { answers } = await res.json();

// Illustrative response: answers.team -> { choice: "payments", confidence: 0.84 }
//                        answers.urgency -> { score: 3, confidence: 0.79 } (0 = lowest level)
if (answers.team.confidence >= 0.8 && answers.team.choice !== "other") {
  assignToQueue(answers.team.choice, { priority: answers.urgency.score });
} else {
  assignToQueue("human_triage", { note: "low confidence" });
}

Auto-Zuweisung an die Confidence koppeln

Die Wahrscheinlichkeitsverteilung macht Routing sicher automatisierbar. Ein brauchbarer Startwert: ab Confidence 0,8 automatisch routen, alles darunter in eine menschliche Triage-Queue.

Den Schwellwert auf der eigenen Ticket-Historie tunen — der richtige Wert hängt davon ab, was ein falsch geroutetes Ticket gegenüber einem verzögerten kostet.

Anfragen zwischen Modellen routen

Dasselbe Muster entscheidet, welches Modell antworten soll. Stellen Sie eine choice-Frage mit Optionen wie fast_model (kurze Fakten- oder Formatierungsanfragen), strong_model (mehrstufiges Reasoning, Code, langer Kontext) und human (Rechtliches, Erstattungen oder alles, was ein Modell nicht allein beantworten sollte). Jede Option kommt mit einer Wahrscheinlichkeit zurück — Sie sehen, wie umstritten die Zuordnung war.

Genauso gaten: Bei niedriger Konfidenz routen Sie die Anfrage an einen Menschen oder einen sichereren Pfad, statt der Top-Option zu vertrauen — die Wahrscheinlichkeit der Zweitoption zeigt, wie knapp die Entscheidung war.

Kosten und Volumen

Ein erfolgreicher Call kostet 1 Credit, egal ob 1 oder 6 Fragen. Für einen Backlog historischer Tickets führt das Batch-Tool im Dashboard dieselbe Request-Form über eine CSV- oder JSONL-Datei aus.

FAQ