So routen Sie Aufgaben von KI-Agenten mit der Gemini Decisions API

TL;DR

Um KI-Agenten-Tasks mit der Gemini Decisions API zuzuweisen, sendet man Titel und Beschreibung des Tasks an gemini-decision-1 – zusammen mit drei Fragen: einer choice-Frage, welcher Agent den Task übernimmt, einem score für den Schwierigkeitsgrad und einem noul-Wert für die Frage, ob zuerst eine menschliche Entscheidung erforderlich ist. Liegt das Konfidenzniveau über dem festgelegten Schwellenwert, erfolgt die Zuweisung automatisch. Alle anderen Tasks werden zur manuellen Prüfung zurückgehalten.

Einleitung

Jedes Team, das mehrere Coding-Agenten parallel betreibt, steht vor derselben lästigen Routineaufgabe: Jemand muss jeden neuen Task durchsehen und entscheiden, wer ihn übernimmt. Der Backend-Agent oder der Frontend-Agent? Das kostengünstige Modell oder die High-End-Variante? Ist der Task schon startklar oder fehlt noch eine grundlegende Vorgabe?

Google hat am 11. November 2026 ein maßgeschneidertes Werkzeug für genau dieses Problem veröffentlicht. Die Gemini Decisions API beantwortet geschlossene Fragestellungen mit kalibrierten Wahrscheinlichkeiten statt mit generiertem Text. Google nutzt diesen Dienst innerhalb von Gemini Notebook, um jede Anfrage an die passende Modell-Leistungsstufe und Thinking-Tiefe weiterzuleiten, und konnte damit nach eigenen Angaben die Latenz bei Standardanfragen um bis zu 40 % senken.

In diesem Beitrag bauen wir genau diesen Router für ein Agent-Board auf: ein API-Aufruf pro Task, drei Fragen, ein Schwellenwert und eine saubere Übergabe an ein Teammitglied, sobald der Router unsicher ist. Wenn Sie ein Board zum Testen suchen: Sharkly lässt sich kostenlos ausprobieren. Für die Routing-Logik selbst (welche Aufgaben das leistungsstärkere Modell erfordern) empfehlen wir vorab unseren Leitfaden zum Thema Agenten-Tasks nach Schwierigkeit zuweisen. In diesem Artikel geht es um den konkreten API-Aufruf, der diese Logik anwendet.

Funktionsweise der Gemini Decisions API

Die Gemini Decisions API ist ein Endpunkt, der typisierte Fragen anhand eines gemeinsamen Inputs auswertet und für jede Frage eine Wahrscheinlichkeit sowie einen Konfidenzwert zurückliefert. Da kein Freitext erzeugt wird, liegt die Anzahl der Output-Tokens immer bei null. Der Code kann direkt anhand der gelieferten Zahlen verzweigen, ganz ohne Parsing-Logik.

Drei Fragetypen decken das Routing vollständig ab:

Ein einziger Request kann bis zu 1.000 Fragen zum selben Input enthalten. Laut der Dokumentation zur Decisions API werden alle Fragen in einem einzigen Forward Pass verarbeitet und sind voneinander isoliert. Das Hinzufügen weiterer Fragen beeinflusst die übrigen Antworten daher nicht. Google beziffert die End-to-End-Latenz auf 150 bis 250 ms – nahezu unabhängig davon, ob 1 oder 100 Fragen gestellt werden.

Wer unseren Beitrag über Jev und Entscheidungsmodelle für Coding-Agenten kennt, wird das Konzept wiedererkennen. Der Unterschied liegt hier in der praktischen Umsetzung: ein von Google gehostetes Modell, drei präzise formulierte Fragen und die direkte Anbindung an ein Projektboard.

Der Routing-Call: Drei Fragen pro Task

Hier ist die Implementierung des Routers. Er setzt google-genai Version 3.2 oder neuer sowie einen GEMINI_API_KEY aus dem Google AI Studio voraus.

import json
from google import genai

client = genai.Client(http_options={"api_version": "v1beta"})

AGENTS = {
    "backend": "Server code, APIs, database migrations, and backend tests.",
    "frontend": "UI components, styling, client state, and frontend tests.",
    "docs": "README files, docs pages, and changelogs. No code changes.",
    "other": "Work that fits none of the options above.",
}

DIFFICULTY = [
    "Trivial: one file, obvious change, no design decision.",
    "Routine: a few files, follows a pattern already in the repo.",
    "Involved: several modules or a new pattern, needs new tests.",
    "Hard: cross-cutting, touches auth or data migrations, or the spec is thin.",
]

def ask(task):
    state = json.dumps({
        "title": task["title"],
        "description": task["description"][:8000],
    })
    result = client.decisions.create(
        model="gemini-decision-1",
        input=state,
        questions={
            "agent": {
                "type": "choice",
                "instructions": "Which agent should take the task in `title` and `description`?",
                "criteria": AGENTS,
            },
            "difficulty": {
                "type": "score",
                "instructions": "How hard is this task for a coding agent working alone?",
                "criteria": DIFFICULTY,
            },
            "needs_human": {
                "type": "noul",
                "instructions": "Does a person need to make a decision before any agent starts?",
                "criteria": {
                    "true_description": "The spec is ambiguous, contradicts itself, or asks for a product, security, or pricing call.",
                    "false_description": "The spec is clear enough to implement as written.",
                },
            },
        },
    )
    return result.answers

Vier wichtige Details aus der Dokumentation werden bei diesem Code leicht übersehen:

Das Modell sieht die Keys nicht. Es liest ausschließlich instructions und criteria. Formulieren Sie die Fragestellung daher vollständig in instructions und beschreiben Sie jede Option verständlich.

Option-Keys werden alphabetisch sortiert. Die API sortiert Choice-Keys vor der Bewertung nach ihrer UTF-8-Bytereihenfolge. Aus diesem Grund heißt die Fallback-Option other und nicht none_of_the_above – letzteres würde vor regulären Optionen einsortiert.

Score-Stufen müssen linear sein. Der zurückgegebene score ist ein wahrscheinlichkeitsgewichteter Mittelwert der Stufen-Indizes (hier 0 bis 3). Benachbarte Stufen sollten sich daher eindeutig voneinander abgrenzen.

Nur relevante Inhalte übergeben. Laut Dokumentation verschlechtern themenfremde Details die Treffsicherheit. Titel und Beschreibung liefern in der Regel verlässlichere Ergebnisse als der gesamte Kommentarverlauf eines Tickets.

Den passenden Konfidenz-Schwellenwert ermitteln

Der Antwortwert bestimmt, was zu tun ist. Der Konfidenzwert zeigt an, ob der Schritt ohne Rückfrage ausgeführt werden kann. Bei einer choice-Antwort entspricht die Konfidenz der Wahrscheinlichkeit der führenden Option. Bei einem noul-Wert errechnet sie sich über max(noul, 1 - noul).

So sieht der Entscheidungslayer aus:

AUTO = 0.75      # assign without a person above this
HARD = 2.4       # difficulty score that earns the strong-model Agent

def decide(a):
    if a["needs_human"].noul >= 0.5:
        return ("human", "needs a decision first")
    if a["agent"].choice == "other" or a["agent"].confidence < AUTO:
        return ("human", f"router unsure ({a['agent'].confidence:.2f})")
    tier = "strong" if a["difficulty"].score >= HARD else "default"
    return (f"{a['agent'].choice}-{tier}", "auto")

Übernehmen Sie den Wert 0.75 nicht ungeprüft. Google empfiehlt, Schwellenwerte anhand gelabelter Beispiele aus den eigenen Arbeitsabläufen zu bestimmen. Nehmen Sie die letzten 50 bis 100 abgeschlossenen Tasks, prüfen Sie, welcher Agent sie jeweils erledigt hat, und lassen Sie sie durch ask() laufen. Wählen Sie den niedrigsten Schwellenwert, bei dem die automatisierten Zuweisungen mit den tatsächlichen Teamentscheidungen übereinstimmen. Eine Fehlzuweisung führt zu einem abgebrochenen Run und einer manuellen Neuzuweisung; eine unnötige manuelle Warteschleife kostet nur wenige Minuten. Wägen Sie diese beiden Faktoren gegeneinander ab, statt sich an willkürlichen Zahlen zu orientieren.

Zwei typische Fallstricke: Ein noul-Wert übersteigt niemals 0.99 – eine Bedingung wie > 0.99 greift daher nie. Zudem kann ein score von 1.5 bedeuten, dass die Entscheidung zwischen den Stufen 1 und 2 liegt, oder dass das Modell über alle vier Stufen hinweg unsicher ist. In kritischen Fällen sollten Sie deshalb zusätzlich das Feld probabilities auswerten.

Den Router in ein Sharkly-Board einbinden

Da der Router in Standard-Python geschrieben ist, kann er in beliebigen Umgebungen laufen. Auf einem Sharkly-Board bietet sich als Trigger der Moment an, in dem ein Task in den bearbeitungsbereiten Status wechselt.

1. Einen Agenten pro Bereich und Leistungsstufe anlegen. Beispielsweise backend-default, backend-strong oder frontend-default. Gemäß der Dokumentation zu Sharkly Agents übernimmt jeder Agent standardmäßig das Modell seiner Runtime. Über das Feld „Model“ lässt sich jedoch ein anderes Modell aus dem Katalog der Runtime auswählen. Genau hier wird aus dem Schwierigkeitsgrad eine gezielte Modellentscheidung.

2. Die Entscheidung per sharkly-CLI zuweisen.

import subprocess

def apply(task_id, target, reason, a):
    note = (f"Router: agent={a['agent'].choice} ({a['agent'].confidence:.2f}), "
            f"difficulty={a['difficulty'].score:.1f}, "
            f"needs_human={a['needs_human'].noul:.2f}")
    if target == "human":
        subprocess.run(["sharkly", "task", "comment", task_id,
                        "--body", f"{note}. Held for a person: {reason}."], check=True)
        return
    subprocess.run(["sharkly", "task", "edit", task_id,
                    "--delegate-agent", target], check=True)
    subprocess.run(["sharkly", "task", "comment", task_id, "--body", note], check=True)

Sobald der Task bereit ist, startet die Agenten-Zuweisung den entsprechenden Durchlauf. Das Protokollieren der Wahrscheinlichkeiten als Kommentar ist wertvoller als es zunächst scheint: So lässt sich das Verhalten des Routers auch Wochen später noch transparent nachvollziehen.

3. Per Statuswechsel triggern. Eine Sharkly-Automation bündelt Instruktionen, zugewiesene Agenten und Trigger. Versehen Sie einen kompakten Router-Agenten mit der Anweisung „Führe route.py für den auslösenden Task aus“ und konfigurieren Sie einen Task-Status-Trigger für den Status, den Ihr Team als „Ready“ definiert hat. Läufe, die durch einen Task-Status-Trigger gestartet werden, bleiben direkt mit dem Task verknüpft – damit bleibt das Routing-Protokoll immer beim Vorgang. Über die CLI genügt:

sharkly automation trigger create <automation-id> --kind task_event --to-status "Ready"

Kosten eines Routing-Aufrufs

Gemini Decision 1 wird laut Googles Ankündigung mit 0,10 $ pro 1 Million Input-Tokens abgerechnet; für Output-Tokens fallen 0 $ an. Der geteilte Input wird pro Request nur einmal berechnet – unabhängig von der Anzahl der Fragen.

Damit kostet das Routing weniger als ein einziger Agenten-Lauf auf einer typischen Aufgabe. Im AI Studio stellt Google zudem ein kostenloses Kontingent für Prototypen bereit.

Wichtige Einschränkungen im Vorfeld

Die API befindet sich als v1beta in der Gemini Developer API; die Unterstützung für Gemini in Google Cloud ist als „demnächst verfügbar“ angekündigt. Laut Dokumentation werden Context Caching, die Batch API sowie Flex- und Priority-Inference bisher nicht unterstützt. Wiederholte Eingaben werden somit jedes Mal voll angerechnet. Die Rate-Limits nach Kontostufe finden sich auf Googles Übersichtsseite zu Rate-Limits – prüfen Sie diese Limits, bevor Sie Ihren gesamten Task-Verkehr über einen einzelnen API-Key leiten.

Task-Beschreibungen sollten grundsätzlich als nicht vertrauenswürdiger Input behandelt werden. Die Dokumentation weist darauf hin, dass von Nutzern verfasste Texte gezielt Argumente für eine bestimmte Klassifizierung enthalten können. Wenn Personen außerhalb Ihres Teams Tasks erstellen können, sollten Aufgaben mit Bezug zu Authentifizierung, Bezahlsystemen oder Produktivdaten immer zur manuellen Prüfung vorgelegt werden – unabhängig vom Urteil des Routers.

Googles Benchmark-Ergebnisse (geringster Kalibrierungsfehler in der gesamten Suite, fast fünfmal günstiger als Gemini 3.5 Flash-Lite über die Interactions API) spiegeln die Messungen des Herstellers wider. Der entscheidende Maßstab für den Praxiseinsatz bleiben die eigenen, fundiert geprüften Tasks.

Wann ein Routing-Aufruf nicht das richtige Werkzeug ist

Ein Decisions-Aufruf empfiehlt sich, wenn mehr Tasks eingehen, als ein Mensch zeitnah sichten kann, und wenn die Auswahlmöglichkeiten feststehen: eine feste Gruppe von Agenten, definierte Leistungsstufen, eine Ja/Nein-Entscheidung. Greifen Sie auf einfache Regeln zurück, wenn bereits ein Label den Zielagenten festlegt. Geht jeder Task mit dem Label docs ohnehin an den Dokumentations-Agenten, ist eine einfache if-Bedingung günstiger und fehlerfrei.

Setzen Sie auf ein generatives Modell, wenn der Router seine Entscheidung in Textform begründen, Anforderungen umschreiben oder komplexe Aufgaben in Teilaufgaben zerlegen soll. Die Decisions API liefert Zahlen, keinen Text. Für die Arbeitsaufteilung über verschiedene Rollen hinweg eignet sich eine Crew besser, deren Führungskraft das Ziel strukturiert aufteilt; siehe hierzu Modell-Routing für Agent-Crews.

Fazit

Routing ist eine Entscheidung aus einem geschlossenen Set an Optionen – und genau darauf ist die Gemini Decisions API ausgelegt: ein einziger Call, typisierte Antworten, ein klar abgrenzbarer Konfidenzwert und Kosten im Bereich von Bruchteilen eines Cents. Der verbleibende Aufwand liegt auf Ihrer Seite: Formulieren Sie eindeutige Beschreibungen für jede Option, kalibrieren Sie die Schwellenwerte anhand realer, abgeschlossener Aufgaben und übergeben Sie Fälle mit geringer Konfidenz an Ihr Team.

Starten Sie mit einem einzelnen Bereich. Routen Sie neue Backend-Tasks eine Woche lang testweise, vergleichen Sie die Vorschläge mit den Teamentscheidungen und rollen Sie das System anschließend breiter aus. Um den Router direkt auf einem echten Board mit Agenten, Automatisierungen und manuellem Review zu betreiben, können Sie direkt mit Sharkly durchstarten.

FAQ

Was ist die Gemini Decisions API?

Dabei handelt es sich um einen am 11. November 2026 eingeführten Endpunkt der Gemini API, der Ja/Nein-, Auswahl- und Bewertungsfragen zu Texten, Bildern, Audio, Video oder PDFs beantwortet. Statt generiertem Text liefert er kalibrierte Wahrscheinlichkeiten und Konfidenzwerte über das Modell gemini-decision-1 zurück.

Was kostet Gemini Decision 1?

Google gibt die Kosten mit 0,10 $ pro 1 Million Input-Tokens und 0 $ für Output-Tokens an, wobei gemeinsam genutzter Input pro Request nur einmal berechnet wird. Für Prototypen steht im Google AI Studio eine kostenlose Nutzungsstufe zur Verfügung.

Wie viele Fragen können pro Request gestellt werden?

Möglich sind zwischen 1 und 1.000 Fragen, begrenzt durch ein Kontextfenster von 262.144 Tokens für den gemeinsamen Input und alle Fragen zusammen. Choice-Fragen unterstützen 2 bis 255 Optionen.

Welcher Konfidenz-Schwellenwert eignet sich für das Routing?

Es gibt keinen universellen Richtwert. Google empfiehlt, Schwellenwerte anhand gelabelter Beispiele aus den eigenen Daten festzulegen. Testen Sie 50 bis 100 abgeschlossene Aufgaben und wählen Sie die Schwelle so, dass automatisierte Entscheidungen mit denen Ihres Teams übereinstimmen.

Kann die Decisions API steuern, welches Modell ein Agent verwendet?

Indirekt ja. Sie können eine score-Frage zur Komplexität stellen und hohe Werte einem Agenten zuweisen, der für ein leistungsfähigeres Modell konfiguriert ist. In Sharkly lässt sich jeder Agent gezielt auf ein Modell aus dem Katalog seiner Runtime einstellen.

Ist die Gemini Decisions API auf Vertex AI verfügbar?

Noch nicht. Laut Googles Ankündigung ist die Unterstützung für Gemini in Google Cloud in Vorbereitung. Aktuell läuft die API als v1beta über die Gemini Developer API.