Bestehende Agenten einbinden (A2A, MCP) und Middleware

Eine Reederei, mit der die Nordlicht Reisen GmbH Fähren für Gruppen anfragt, betreibt einen eigenen Agenten, der Anfragen per A2A annimmt. Lektion 1.2 hat den Fall angedeutet (Übung 1) und gesagt: Dieser Agent wäre die erste A2A-Verbindung des Teams, denn er liegt jenseits einer Organisationsgrenze. Diese Lektion bindet ihn ein. Sie fragt nach dem Weg (im Code, im Dienst oder über MCP), nach der Sicherheit (was verlässt das Haus, wem vertrauen wir die Antwort) und nach Middleware, mit der solche Anschlüsse ihre Schutzfunktionen nicht jedes Mal neu bauen.

Vorwissen. „Lektion 1.2“ hat die Protokolle gewählt, den Stand von A2A in Foundry gelesen (Protokoll 1.0 allgemein verfügbar, das ältere a2a_preview Vorschau, .NET-Pakete Vorabversion, Pfad der Agent-Karte offen) und den Kanalplan als Daten geprüft. „KI-Track, Lektion T8.2“ zeigt den Agenten als MCP-Client, „T2.4“ Middleware um den Chat-Client, „AI-103, Lektion 2.5“ die Freigabe für MCP-Werkzeuge, „Lektion 2.8“ den Ablauf in Stufen und „Lektion 2.9“ Freigaben und Randfälle. Hier beginnt, was darüber hinausgeht: Middleware um einen Agenten, nicht um einen Chat-Client, und die Anbindung eines fremden Agenten.

Neu in dieser Lektion. Der Partner heißt reederei (kein Agent des Teams, also steht der Name nicht in der Menge agenten der Prüfung aus 1.2). Der Kanalplan bekommt einen zwölften Kanal, transport -> reederei, Protokoll a2a. Er ist nur Anfrage (A0): Eine verbindliche Buchung wäre eine Zahlung und bleibt ein Mensch (A3, M-05). Annahmen der Aufgabe: Der Partner spricht A2A in der Fassung 1.0; die Frist für eine Antwort ist 30 Sekunden; zum Partner gehen nur Ziel, Zeitraum und Personenzahl, nie Teilnehmerlisten (M-07).

Die Anforderung

Alle Zahlen sind Annahmen der Aufgabe.