Wie ein Agent Zugang zu einem Zielsystem bekommt

Ein KI-Agent, der nur reden kann, hilft niemandem. Nützlich wird er erst, wenn er in den Systemen arbeitet, in denen die Arbeit tatsächlich liegt: im Ticketsystem, in der Quellcodeverwaltung, im Postfach. Wir nennen diese Systeme Zielsysteme, und wie ein Agent Zugang zu ihnen bekommt, ist eine der Fragen, die wir am gründlichsten durchdacht haben.

Dieser Beitrag beschreibt den Weg von der Anbindung bis zum ersten Aufruf.

Ein Zielsystem ist ein Plugin

Wir hätten für jedes System einen festen Anschluss ins Programm bauen können. Dann wäre jede neue Anbindung eine neue Version von Covey gewesen, und wer etwas anderes braucht, hätte auf uns warten müssen.

Stattdessen ist jedes Zielsystem ein Plugin, und jedes Plugin bringt drei Dinge mit:

Aktionen. Die Liste dessen, was ein Agent hier tun kann: ein Ticket beantworten, einen Status setzen, einen Branch anlegen. Jede Aktion hat benannte Parameter, und die Plattform prüft sie, bevor irgendetwas passiert.

Die Verarbeitung eingehender Ereignisse. Wenn das Zielsystem von sich aus meldet, dass etwas passiert ist — ein Kunde hat geantwortet, eine Pipeline ist rot —, entscheidet das Plugin, ob daraus ein Weckruf für einen Agenten wird.

Eine Beschreibung für das Modell. Jedes Plugin erklärt in eigenen Worten, wofür seine Aktionen da sind. Dieser Text landet im Prompt des Agenten. Das Plugin bringt also nicht nur die Technik mit, sondern auch die Anleitung.

Vier Wege zu einer neuen Anbindung

Ein Plugin kann auf vier Arten in eine Installation kommen, und alle vier sind gleichwertig.

Manche Plugins sind fest eingebaut, weil sie etwas brauchen, das sich anders nicht ausdrücken lässt. Andere liegen in einem Katalog hinter einer Internetadresse und werden zur Laufzeit installiert. Ein Katalogeintrag verweist auf eine Datei mit ihrer Prüfsumme, sodass immer genau die Fassung geladen wird, die geprüft wurde.

Wer ein System anbinden will, das eine gewöhnliche Programmierschnittstelle hat, schreibt ein Manifest: eine JSON-Datei, in der Anmeldung, Aktionen und Ereignisfelder beschrieben werden. Hochladen, aktivieren, zuweisen — ohne eine einzige Zeile Programmcode.

Und schließlich lässt sich jeder MCP-Server eintragen. Model Context Protocol ist ein verbreiteter Standard für Werkzeuge, die Sprachmodellen zur Verfügung stehen. Covey erkennt selbst, welche Werkzeuge ein solcher Server anbietet, und Sie geben pro Agent frei, welche davon er benutzen darf.

Uns war dabei eines wichtig: Unsere eigenen Plugins haben keinen besseren Stand als die von anderen. Drei Anbindungen, die früher fest eingebaut waren, sind inzwischen in den Katalog gewandert — genau deshalb. Eine Erweiterbarkeit, die man selbst umgeht, ist keine.

Die Zugangsdaten sieht der Agent nie

Jetzt der Teil, der uns am wichtigsten ist.

Der naheliegende Weg wäre, dem Agenten einen API-Schlüssel in seine Arbeitsumgebung zu legen. Damit wäre der Schlüssel aber dauerhaft an einem Ort, den ein Sprachmodell liest und beschreibt. Er stünde in Logdateien, er ließe sich in eine Datei kopieren, und er wäre in jeder Sicherungskopie dieser Umgebung enthalten.

Bei uns bleiben Zugangsdaten deshalb in der Control Plane — dem zentralen Teil der Plattform, in dem auch die Planung liegt. Sie werden dort verschlüsselt gespeichert und verlassen ihn nicht.

Will ein Agent eine Aktion ausführen, geht der Aufruf über die Control Plane. Sie prüft, ob dieser Agent diese Aktion auf diesem System ausführen darf, setzt die Zugangsdaten erst dort ein und schreibt den Vorgang ins Protokoll. Der Agent bekommt das Ergebnis. Den Schlüssel bekommt er nicht.

Das hat einen angenehmen Nebeneffekt: Weil jeder Zugriff ohnehin durch diese Stelle läuft, ist die Aufzeichnung vollständig, ohne dass man sie extra bauen müsste. Was ein Agent in einem Zielsystem getan hat, steht hinterher lückenlos da.

Und es zieht eine Grenze an der richtigen Stelle. Was ein Agent darf, steht nicht in seinem Prompt, sondern in der Konfiguration der Plattform. Ein Prompt ist Text, den das Modell interpretiert. Eine Regel in der Control Plane ist eine Regel.

Wie das Einrichten abläuft

Früher war das Anbinden eines Zielsystems ein Schalter und ein längerer Erklärtext — fünf Schritte über drei Seiten hinweg, teils in einem fremden System. Heute führt ein Assistent durch die Reihenfolge:

1. Das Zielsystem aktivieren.
2. Die Zugangsdaten hinterlegen.
3. Den Agenten zuweisen, der damit arbeiten soll.
4. Die Adresse für eingehende Ereignisse kopieren — bereits mit der richtigen Kennung darin.
5. Die Verbindung testen.

Welche Schritte überhaupt erscheinen, entscheidet das Plugin. Ein System ohne eingehende Ereignisse zeigt Schritt vier nicht. Und jeder Schritt fragt seinen Zustand beim Server ab, statt sich zu merken, was man vorhin angeklickt hat — wer den Assistenten zwischendurch verlässt, findet ihn beim nächsten Mal dort wieder, wo er wirklich steht.

Was der Agent davon merkt

Aus Sicht des Agenten ist das alles unsichtbar. Er sieht eine Liste von Aktionen, die er ausführen kann, mit der Beschreibung, die das Plugin mitgebracht hat. Er ruft eine davon mit Parametern auf und bekommt ein Ergebnis.

Dass dazwischen eine Rechteprüfung liegt, ein Protokolleintrag entsteht und Zugangsdaten eingesetzt werden, die er nie zu sehen bekommt, ist nicht seine Angelegenheit. Genau so soll es sein: Die Grenzen zieht die Plattform, nicht die Selbstbeschränkung des Modells.