KI-Agenten-Routing: Agenten auslösen und Ergebnisse zurückgeben

KI-Agenten-Routing ist die Integrationsebene, die ein externes Event an einen Agenten weiterleitet und das Ergebnis an das System ausliefert, das es benötigt. Unsere Plattform übernimmt diesen Ablauf mit Inbound-Verbindungen, synchronen Routen und Outbound-Verbindungen. So kann der Agent zwischen den bereits genutzten Unternehmenssystemen arbeiten.

Was ist KI-Agenten-Routing?

KI-Agenten-Routing verbindet Ereignisquelle, Agenten-Run und Zielsystem. Es beantwortet praktische Fragen: Welches Event startet den Agenten? Wartet der Aufrufer? Wohin geht das fertige Ergebnis? Welche Komponente verwaltet Zugangsdaten, Payload-Formatierung und Wiederholungsversuche?

Dieser Artikel meint mit Routing den Traffic über Systemgrenzen hinweg. Ein KI-Modell auszuwählen, eine Aufgabe an einen anderen Agenten zu delegieren oder eine feste Multi-Agent-Sequenz aufzubauen, gehört zur Agenten-Orchestrierung. Agentenaufrufe über Orchestrierungs-Tools beschreiben diese Form der Orchestrierung.

Warum das Triggern eines KI-Agenten nur die halbe Integration ist

Ein Webhook-Handler oder Queue-Consumer kann einen Agenten starten. Die Arbeit bleibt unvollständig, wenn die Betrugsbewertung nie das Alert-Topic erreicht, das klassifizierte Ticket nicht ins Support-System zurückkehrt oder der Antwortentwurf nie beim Kunden ankommt. Jeder asynchrone Run braucht ein Zielsystem für das Ergebnis.

Eine Eingangsbestätigung ist noch kein Ergebnis. Webhook- und Inbound-MCP-Anfragen liefern nach der Übergabe die IDs der erstellten Runs zurück. So bleibt die ursprüngliche Anfrage kurz, doch der Aufrufer erhält in dieser Antwort nicht die fertige Ausgabe. Soll der Aufrufer warten, eignet sich eine Sync-Verbindung. Andernfalls kann eine Outbound-Verbindung das Ergebnis später ausliefern.

Die Wahl des Auslösers bringt eigene Kompromisse bei Zustellung und erneuter Verarbeitung mit sich. Vor der Auswahl der Eingangsseite einer Route lohnt sich ein Vergleich der Auslösemuster für Webhook, Kafka, SQS und Postgres.

So routet Connic Inputs und Ergebnisse

Die Verbindungsrichtung definiert, was an der Systemgrenze geschieht. Eine konfigurierte Verbindungsinstanz hat genau eine Richtung; ein Kafka-Roundtrip nutzt daher einen Inbound-Consumer und einen Outbound-Producer. Input- und Output-Transport können sich ebenfalls unterscheiden: Ein Stripe-Ereignis kann einen Run starten, dessen Ergebnis an SQS oder einen HTTP-Callback geht.

Ein synchroner Webhook passt zu einer interaktiven Produktfunktion, die die Antwort sofort benötigt. Ein eingehender Webhook mit ausgehendem Callback eignet sich für längere Verarbeitung. Kafka, SQS, E-Mail und Telegram verwenden separate Inbound- und Outbound-Verbindungsinstanzen. Verbindungsrichtungen und Einrichtung.

Wie unterscheiden sich Connics Outbound-Verbindungsmodi?

Die Verbindungsrichtung legt fest, dass eine Verbindung Daten nach außen sendet. Der Verknüpfungsmodus entscheidet, wer den jeweiligen Versand steuert. Diese Auswahl gehört zur Verknüpfung zwischen Outbound-Verbindung und Agenten. Derselbe Verbindungstyp kann so in verschiedenen Abläufen unterschiedliche Routing-Regeln unterstützen.

Automatic-Outbound-Verbindungen

Der Automatic-Modus eignet sich, wenn die Ergebnisse aller passenden abgeschlossenen Runs zur Zustellung in die Queue gestellt werden sollen. Er kann alle Runs einschließlich manueller, geplanter und von Agenten getriggerter Runs oder nur Runs abdecken, die ausgewählte Inbound- oder Sync-Verbindungen gestartet haben. Fehlgeschlagene und abgebrochene Runs werden übersprungen.

Das ausgehende Format hängt vom Transport ab. Automatic-Verbindungen für Webhook, Kafka und SQS liefern eine strukturierte Nachricht zum abgeschlossenen Run. E-Mail- und Telegram-Verbindungen interpretieren den finalen Output als Nachricht für den jeweiligen Kanal. Die Verbindung enthält diese transportspezifischen Regeln. Der Agenten-Prompt kann auf die Aufgabe fokussiert bleiben.

Agent-Tool-Outbound-Verbindungen

Der Agent-Tool-Modus ergänzt einen LLM-Agenten um ein benanntes Verbindungs-Tool. Das KI-Modell entscheidet, ob und wann es das Tool aufruft und welche gültigen Nutzdaten es übergibt. Dieser Modus eignet sich, wenn die Entscheidung von der Bedeutung innerhalb einer Unterhaltung oder eines Ereignisses abhängt, etwa um nur vom Agenten als dringend klassifizierte Fälle zu eskalieren.

Die Verbindung validiert die Tool-Nutzdaten und hält gespeicherte URL, Zugangsdaten und Routing-Standardwerte vom KI-Modell fern. Der Agent erhält eine zweckspezifische Aktion. Connic erstellt die Transportanfrage und verwaltet die Secrets.

Middleware-Outbound-Verbindungen

Der Middleware-Modus hält die Routing-Entscheidung in Python. Code kann die Verbindung vor oder nach der Agentenausführung mit send_connector(action_name, payload) aufrufen. Das KI-Modell kann nicht auf eine Middleware-Outbound-Verbindung zugreifen. Middleware eignet sich für feste Richtlinienprüfungen, deterministischen Fan-out oder explizite Duplikatunterdrückung je Ausführung mit einem Idempotenzschlüssel.

from connic.tools import send_connector

async def after(response: str, context: dict) -> str:
    if context["payload"].get("priority") == "urgent":
        await send_connector(
            "send_to_results_webhook",
            {
                "payload": {
                    "run_id": context["run_id"],
                    "result": response,
                }
            },
            idempotency_key=context["run_id"],
        )

    return response

Dieses Beispiel routet dringende Ergebnisse an einen konfigurierten HTTP-Webhook und nutzt die Run-ID als Idempotenzschlüssel. Connic löst die Verbindung auf und stellt die Zustellung in die Queue. Der Leitfaden zu Middleware-Outbound-Verbindungen beschreibt die Schnittstelle zur Runtime.

Wie gelangt das Ergebnis zum jeweiligen Zielsystem?

Ein Browser, der auf eine HTTP-Antwort wartet, und ein Kafka-Consumer benötigen unterschiedliche Wege für die Ergebniszustellung. Unsere Plattform lässt die Agentenlogik unverändert, während die Verbindungsebene den jeweiligen Transport übernimmt.

Ein Agent kann mehrere ausgehende Verknüpfungen besitzen. Im Automatic-Modus kann das abgeschlossene Ergebnis an mehrere Ziele gehen; Quellenfilter begrenzen dabei, welche Runs eine Route verwenden. Ein Outbound-Callback kann nur Runs aus dem Webhook der Produktivumgebung annehmen, während ein Link für alle Runs zusätzlich manuelle, geplante und von Agenten ausgelöste Arbeit abdeckt.

Connic-Verbindungskatalog mit unterstützten Richtungen und Konfigurationen je Transport.

Welche Routing-Aufgaben Connic übernimmt

Ohne Verbindungsebene verantwortet die Anwendung die Endpunkte und Consumer, die Arbeit annehmen, sowie die Callback-Worker, die Ergebnisse zurückgeben. Sie speichert außerdem die Zugangsdaten der Zielsysteme, validiert Nutzdaten, verfolgt Wiederholungsversuche und protokolliert die Zustellung. In Connic übernimmt die Verbindung im jeweiligen Environment diese Aufgaben. Der Agent bleibt YAML, Python und Git; der Verbindungsablauf steuert, wie externe Systeme ihn erreichen und wohin sein Output geht.

Private Infrastruktur benötigt keinen öffentlichen eingehenden Port. Bridge läuft im privaten Netzwerk und baut einen ausschließlich ausgehenden Tunnel auf, den unterstützte Verbindungen für bidirektionalen Traffic nutzen können. Zugriff auf private Systeme mit Connic Bridge.