Verbindungen für KI-Agenten: Plattformvergleich 2026

Verbindungen für KI-Agenten sind konfigurierte Integrationen zwischen einer Agenten-Runtime und einer externen Ereignisquelle oder einem Zielsystem. Für Teams, die KI-Features in bestehende Software integrieren, können sie individuellen Webhook-, Consumer-, Listener- oder Delivery-Code ersetzen. Unterstützte Modi und Garantien bei Fehlern unterscheiden sich je nach Verbindung.

Welche Plattformen bieten Verbindungen für KI-Agenten?

Eine Verbindung kann ein Ereignis zustellen, das einen Agenten-Run startet, oder eine App-Aktion darstellen, die der Agent in einem Workflow aufruft. Nach Auswertung der jeweiligen Dokumentation ist connic die einzige Plattform, die Inbound, Sync und Outbound als eigenständige Verbindungsmodi direkt an bereitgestellten Agenten definiert. Die anderen Plattformen lösen Teile desselben Problems mit Workflow-Nodes, Anwendungsrouten, Durable Functions, Channels oder separat zusammengestellten Cloud-Diensten.

„Dokumentierte Garantien“ bezeichnet das in der verlinkten Produktdokumentation beschriebene Verhalten und kein pauschales SLA. Keine dieser Zeilen ist als universelle Exactly-once-Garantie zu verstehen.

Der Vergleich der Anbieter für KI-Agenten-Deployments beschreibt die Trade-offs der Runtimes. Im connic-Verbindungskatalog stehen die unterstützten Modi und Konfigurationen. Das Rechnungsbeispiel mit Webhook zeigt weiter unten einen vollständigen Request samt Ergebnis mit einer bestehenden Agentenvorlage.

Was individueller Integrationscode umfasst

Ein produktiver Agent braucht einen Eingangs- und häufig auch einen Ausgangspfad. Je nach Quelle erfordert eine selbst entwickelte Integration einen signierten Webhook-Handler, die Behandlung von Queue Visibility Timeouts oder einen dauerhaft laufenden Datenbank-Listener. Das Anwendungsteam verantwortet diesen Code, sofern die Plattform ihn nicht ausdrücklich als Verbindungsverhalten dokumentiert. Das betrifft auch KI-Funktionen in bestehender Software.

Checkliste zur Bewertung einer Verbindung

Vor dem Einsatz als verwaltete Infrastruktur muss die Dokumentation jeder Verbindung geprüft werden. Für jede Quelle sind folgende Fragen zu klären:

• Welche Modi unterstützt sie und läuft eine konfigurierte Instanz nur in einem Modus?
• Wer authentifiziert die Quelle oder signiert den Outbound Request?
• Was passiert bei einem Fehler: Retry, Visibility Timeout, erneute Zustellung oder optionale DLQ des Providers?
• Welche Payload- und Ergebnis-Schemas, Größenlimits und Garantien zur Reihenfolge sind dokumentiert?

Ausgewählte Beispiele für connic-Verbindungen

connic unterstützt Verbindungen für Webhooks, Queues, Datenbanken, E-Mail, Sprachanrufe und Nachrichten. Diese Beispiele zeigen, wie verschiedene Quellen und Ziele die Integrationsarbeit rund um einen Agenten verändern. Im aktuellen Verbindungskatalog stehen alle verfügbaren Verbindungen, Modi und Konfigurationsoptionen.

Die Einführung in connic Voice beschreibt die Einrichtung eines Sprachagenten und ein Kundensupport-Beispiel. Telnyx Voice und Messaging können denselben gespeicherten Kontozugang nutzen.

Verbindungen im connic marketplace

Unsere Verbindungen stehen im connic marketplace, dem Katalog für Bausteine von connic-Projekten. Daneben gibt es Agentenvorlagen, die funktionsfähige Agenten-Setups im Projekt-Repository anlegen, und Retrieval-Quellen, die Inhalte in das Retrieval des Agenten synchronisieren. Der Verbindungskatalog zeigt Modi, Konfiguration und Ereignisübergabe jeder Verbindung.

Seiten für Agentenvorlagen können auf die benötigten Verbindungen verlinken. So lassen sich erforderliche Ereignisquellen vor der Konfiguration der Vorlage prüfen. Alle Details zur Einführung stehen in der Ankündigung des Marketplace. Bei der Auswahl des Inbound-Pfads hilft der Vergleich von Webhook, Kafka, SQS und Postgres als Trigger.

Inbound, Outbound und Sync

connic unterscheidet drei Modi. Inbound startet einen Agenten durch ein externes Ereignis. Outbound sendet das Agentenergebnis an ein externes System. Sync hält die Interaktion offen, um die Agentenantwort zurückzugeben oder zu streamen. Ein Verbindungstyp kann mehrere Modi unterstützen, eine konfigurierte Verbindungsinstanz hat jedoch genau einen. Ein Flow mit Inbound und Outbound verwendet deshalb zwei konfigurierte Instanzen, auch bei Kafka oder E-Mail.

Eine Rechnung über einen synchronen Webhook verarbeiten

Eine Anwendung kann Rechnungstext an einen HTTP-Webhook senden und die extrahierten Felder in derselben Antwort erhalten. Die Vorlage Invoice Processor enthält den Agenten, Rechen-Tools, Ausgabeschema, Middleware und Tests. In diesem Beispiel ist der Webhook mit invoice-extractor verknüpft, der die Rechnungsfelder zurückgibt. Die separate invoice-pipeline der Vorlage ergänzt eine deterministische Prüfung und gibt deren Prüfergebnis zurück.

1. 1

   Die Rechnungsvorlage bereitstellen

   Erstelle ein connic-Projekt ohne verknüpftes Git-Repository und anschließend einen Projekt-API-Schlüssel. Dieses Beispiel nutzt das CLI-Deployment aus dem Schnellstart. Lege dann mit der Vorlage ein neues lokales Verzeichnis an. Füge bei der Abfrage durch connic login den Login-Token ein, der beim Erstellen des Schlüssels angezeigt wird. Das Deployment führt die enthaltene Testsuite aus, bevor es die Agenten aktiviert.

   terminal

   Copy

   pip install connic-composer-sdk
   connic init invoice-webhook --templates=invoice
   cd invoice-webhook
   pip install -r requirements.txt
   connic login
   connic deploy

2. 2

   Den HTTP-Webhook verknüpfen

   Öffne invoice-extractor in der Umgebung mit dem aktiven Deployment. Wähle im Verbindungsdiagramm Add inbound connector, dann Create New Connector und HTTP Webhook. Wähle den Modus Sync (Request-Response) und lasse die Authentifizierung aktiviert. Verknüpfe nur diesen Agenten, damit die Antwort wie unten beschrieben ein einzelnes Ergebnis enthält. Kopiere die generierte Webhook-URL und das Secret aus den Verbindungsdetails. Die Webhook-Dokumentation erläutert die Einstellungen und Authentifizierungsoptionen.

3. 3

   Eine Beispielrechnung senden

   Ersetze die Platzhalter für URL und Secret durch die kopierten Werte. Der Request übermittelt einen fiktiven Rechnungstext als JSON; das Secret steht im Request-Header.

   terminal

   Copy

   curl --fail-with-body --max-time 310 '<webhook-url>' \
     -H 'Content-Type: application/json' \
     -H 'X-Connic-Secret: <webhook-secret>' \
     --data '{
       "message": "Extract the fields and check the arithmetic in this invoice.",
       "text": "Example Supplier, invoice INV-001. Issued 2026-09-11, due 2026-09-25. Consulting: 2 hours at EUR 100, line total EUR 200. Subtotal EUR 200. Tax 19%: EUR 38. Total EUR 238."
     }'

4. 4

   Das Ergebnis lesen und den Run prüfen

   Bei einem verknüpften Agenten enthält die Antwort result.run_id, result.status, result.output und result.error. Prüfe, ob result.status den Wert completed hat, und dekodiere dann den String in result.output als JSON. Das äußere Feld status: "ok" bestätigt noch keine erfolgreiche Extraktion. Vergleiche bei diesem Beispiel die extrahierte Währung und Gesamtsumme mit EUR und 238. Der Extraktor verwendet Rechen-Tools und das Rechnungsschema der Vorlage. Im Trace des Runs lassen sich die Tool-Aufrufe und mögliche Fehler prüfen.

   Sync wartet bis zu fünf Minuten auf den Run; die Vorlage legt für den Agenten einen kürzeren Timeout fest. Eine HTTP-Antwort mit Status 401 weist auf eine fehlgeschlagene Webhook-Authentifizierung hin. Für die Verarbeitung im Hintergrund eignet sich der Inbound-Modus mit einer separaten Outbound-Verbindung für das Ergebnis. Der Leitfaden zu Verbindungsmustern erläutert diese Wahl. Die Dokumentation zu Runs und Traces beschreibt die Untersuchung einzelner Runs.

Die Rolle von MCP

MCP, das Model Context Protocol, ist als Verbindung verfügbar. Die Details zur MCP-Verbindung erklären, wie die Verbindung einen Agenten als aufrufbares Tool für einen MCP-Client veröffentlicht. Event-Verbindungen lösen Runs aus oder stellen Ergebnisse über externe Systeme zu. Der Leitfaden zu MCP-Verbindungen erklärt den Unterschied zwischen dem Veröffentlichen eines Agenten und dessen Zugriff auf externe MCP-Tools.

Wann eigener Integrationscode weiterhin notwendig ist

Für ein internes oder spezialisiertes System ohne Verbindung ist ein eigenes Tool nötig, das der Agent aufrufen kann. Ist das System nur in einem privaten Netzwerk erreichbar, routet connic Bridge die Verbindung, ohne den Dienst öffentlich freizugeben.