Willkommen zu einem weiteren Wissens-Navid. Stellen Sie sich vor, Sie leiten ein Unternehmen und stellen ein Team brillanter Spezialisten ein, einen erstklassigen Reiseplaner, einen Experten für Mitarbeiter-Onboarding und einen IT-Support-Mitarbeiter. Aber niemand von Ihnen spricht mit dem anderen. Jedes Mal, wenn eine Aufgabe zwei von Ihnen erfordert, müssen Sie zwischen den Schreibtischen hin- und herlaufen und die Information selbst überführen. Genau so funktionieren die meisten KI-Agenten derzeit. Sie arbeiten isoliert, selbst wenn das Problem eindeutig Teamarbeit erfordert. Heute sprechen wir also darüber, wie Agenten kommunizieren, Aufgaben übergeben und wie echte Teams agieren können. Ich bin Mirko Peters. Das ist kein Zukunftskonzept mehr. Multi-Agenten-Orchestrierung findet bereits statt. Und sie wird durch ein Protokoll namens A2A angetrieben. Wir beginnen mit dem Problem, analysieren das Protokoll Stück für Stück und sehen uns an, wie Microsoft es in Copilot Studio und Azure AI einsetzt.

Schnappen Sie sich einen Kaffee und lassen Sie uns ein. Also was ist das eigentliche Problem? KI-Agenten sind heute genau wie diese isolierten Spezialisten. Jeder hat sein eigenes Wissen, seine eigenen Ziele und seine eigenen Ziele. Ein Wetteragent kennt die Vorhersagen. Ein Hotelagent kennt die Zimmerverfügbarkeit, aber Sie tauschen nichts aus. Stellen Sie sich nun einen Benutzer vor, der nach einer Reise nach Seattle nächste Woche fragt mit einem Hotel in Nähe des Berufs. Ein einzelner Agent müsste gleichzeitig Wette-Experte, Reise-Experte und Experte für lokale Unternehmen sein. Das bedeutet gigantische überladene Prompts, die jede erdenkliche Fähigkeit in ein System zwängen. Und diese Prompts stürzen ständig ab. Die alte Lösung war benutzerdefinierter Co. Man schrieb eine Brücke zwischen dem Wetteragenten und dem Hotelagenten, dann eine weitere zwischen Hotel- und Flugagent, sowie eine für den Kalenderagenten.

Anfangs funktioniert das, aber jedes Mal, wenn Sie einen neuen Agent hinzufügen, bauen Sie eine weitere Rente-Aktion. Schon bald haben Sie einen Spaghetti-Albtraum aus Punkt-zu-Punkt-Verbindungen, bei dem eine Änderung alles kaputt macht. Die Produktivitätsgewinne, die Ihre KI eigentlich liefern sollte, werden von Wartungsarbeiten aufgefressen. Betrachten wir den echten geschäftlichen Schmerzpunkt. Ihr Unternehmen hat bereits Prozesse mit Übergaben. Ein Ticket wird erstellt, jemand priorisiert es, jemand löst es, jemand protokolliert es, jeder Schritt ist eine Übergabe. In der alten Welt automatisieren Sie jeden Schritt mit einem separaten Agenten, verbringenden Wochen, damit Sie miteinander zu vernetzen. Aber was wäre, wenn es ein Protokoll gäbe, mit dem Agenten einander entdecken und ohne benutzerdefinierte Brücken zusammenarbeiten könnten? Genau das leistet A2A. Einfach ausgedrückt ist A2A eine Standardmethode für Agenten, um miteinander zu sprechen, Arbeit weiterzureichen und Dinge als Team zu erledigen.

Was ist A2A? Einfache Definition. A2A steht für Agent to Agent. Es ist ein offenes Protokoll, das es KI-Agenten ermöglicht, direkt miteinander zu kommunizieren, unabhängig davon, wer sie entwickelt hat. Man kann es sich wie HTTP für Agenten vorstellen. HTTP ist die Sprache, die Webbrowser und Server für die Kommunikation nutzen und A2A tut dasselbe für Agenten. Ein Agent, den die IT-Team in Microsoft Co-Pilot Studio erstellt hat, kann mit einem Agenten eines anderen Unternehmens auf Google Cloud sprechen, solange beide A2A beherrschen. Dies ist auch kein kleines Projekt. A2A wird von acht großen Unternehmen unterstützt, darunter Google, Microsoft Cisco, Salesforce, SAP und andere und wird von der Linux Foundation gehostet. Version 1.0 ist stabil und bereit für den produktiven Einsatz, was bedeutet, dass kein einzelner Anbieter das Protokoll kontrolliert. Es ist keine reine Google- oder Microsoft-Angelegenheit.

Es ist eine Branche, heute Sache. Das Design ist bewusst einfach gehalten. A2A baut auf bestehenden Webstandards wie HTTP und JSON-RPC auf Dinge, die jeder Entwickler bereits kennt, denn nichts Exotisches oder Populitäres dabei. Das macht es für Unternehmer einfach, es zu übernehmen, ohne ihre bestehende Infrastruktur austauschen zu müssen. Vielleicht haben Sie schon von einem anderen Protokoll namens MCP gehört, dem Model-Context-Protokoll. Das ist der Unterschied. MCP ist Agent-to-Tool, das heißt, es verbindet einen Agenten mit externen Datenquellen und APIs. A2A ist Agent-to-Agent und verbindet Agenten direkt miteinander. Die sind keine Konkurrenten, sondern ergänzen sich gegenseitig. Betrachten Sie MCP als die vertikale Verbindung vom Agenten zu seinen Tools und A2A als die horizontale Verbindung zwischen Agenten untereinander. Noch eine Designentscheidung. A2A behandelt Agenten als Blackboard.

Wenn also ein Agent mit einem anderen kommuniziert, sieht er weder die interne Logik noch die Tools oder privaten Daten des anderen Agenten. Sieht nur die Aufgabe, die er gesendet hat und das er zurückerhält. Das schützt die Privatsphäre und das geistige Eigentum. Ein Wetteragent muss nicht wissen, wie der Hotelagent Zimmer buchte, muss lediglich die Wettervorhersage übermitteln. Schauen wir uns nun das erste Teil des Puzzles an. Die Agentenkarte. Die Agentenkarte der Lebenslauf. Jeder A2A-kompatible Agent veröffentlicht eine sogenannte Agentenkarte. Diese Karte ist ein maschinenlesbares Dokument, das unter einer Standard-URL auf der Domain des Agenten liegt, spezifisch unter dem Pfad wellknown.agent-card.json. Wenn Sie wissen, wo ein Agent lebt, können Sie seine Karte abrufen und alles erfahren, was Sie für die Zusammenarbeit benennen. Betrachten Sie die Agentenkarte wie einen Lebenslauf oder eine Visitenkarte.

Sie sagt anderen Agenten, wer sie sind und was sie tun können. Die Karte enthält den Namen des Agenten, eine einfache Textbeschreibung seiner Fähigkeiten und Skilltext, die bei der Entdeckung her. Es listet zudem die Endpunkt-URL auf, unter der Anfragen entgegengenommen werden, sowie die Authentifizierungsanforderungen und die akzeptierten Eingabe- und Ausgabeformate. Das ist ein konkretes Beispiel. Nehmen wir an, Sie haben einen spezialisierten Wetteragent. Seine Agentenkarte besagt, ich kann das aktuelle Wetter und eine 5-Tage-Vorhersage für jede Stadt liefern. Dort sind die API-Endpunkte aufgelistet, die einen Stadtnamen akzeptieren und Temperatur sowie Bedingungen im JSON-Format zurückgeben. Das ist auch schon alles. Es ist lediglich eine klare Erklärung dessen, was er leisten kann, ohne Geheimnisse oder interne Logik preiszugeben. Die Erkennung funktioniert so. Ein Orchestrator-Agent verfügt über eine Liste bekannter Agenten-URLs oder Sie können ihn entsprechend konfigurieren.

Wenn eine Aufgabe eingeht, ruft der Orchestrator die Agentenkarten ab, liest die Beschreibungen und entscheidet, welcher Agent am besten geeignet ist. Die Wetterkarte sagt Wetter, also gehen Wetteraufgaben dorthin. Die Hotelkarte sagt Hotels, also gehen Hotelaufgaben dorthin. Beachten Sie, dass kein zentrales Register erforderlich ist. Agenten müssen sich nicht bei einem globalen Verzeichnis registrieren. Sie veröffentlichen ihre Karte einfach an einem bekannten Ort. Und jeder andere Agent, der die URL kennt, kann sie finden. Das ist eine bewusste Designentscheidung, die das System dezentral und flexibel hält. Sie können einen neuen Spezialisten zu Ihrem Netzwerk hinzufügen, indem Sie dem Orchestrator dessen URL geben und die Erkennung erfolgt automatisch. Der Orchestrator weiß also, wer verfügbar ist. Aber wie übergeben Sie eigentlich die Arbeit? So funktioniert die A2A-Kommunikation. Der Orchestrator weiß also durch die Agentenkarte, welche Agenten verfügbar sind.

Aber wie übergeben diese Agenten die Arbeit eigentlich aneinander? Die Antwort ist einfach. Die gesamte Kommunikation erfolgt über HTTP unter Verwendung von JSON-APC-Nachrichten, demselben Protokoll, auf dem die meisten heutigen Webdienste basieren. Nichts Spezielles oder Kompliziertes. Einfach nur standardmäßiger Webdatenverkehr zwischen zwei Agenten. Ist der Punkt. Nicht alle Aufgaben sind gleich. A2A unterstützt je nach Bedarf drei verschiedene Interaktionsmuster. Die Sofortantwort verarbeitet schnelle Abfragen, bei denen der entfernte Agent sofort antworten kann. Wir senden eine Anfrage, er antwortet direkt und Sie sind fertig. Einen Wetteragenten nach der heutigen Vorhersage zu fragen, funktioniert genau so, synchrone Antwort, rein und raus. Streaming ist für längere Aufgaben gedacht. Vielleicht muss der spezialisierte Agent mehrere Datenbanken durchsuchen oder eine komplexe Analyse durchführen.

Anstatt Sie auf eine einzige Antwort warten zu lassen, sendet der Agent während der Arbeit Status-Updates per Service-End-Events. Sie erhalten zwischendurch Fortschrittsberichte und am Ende landet das Endergebnis. Die Sendungsverfolgung eines Pakets funktioniert auf die gleiche Welt. Sie sehen jeden Schritt während er geschieht. Asynchrone Benachrichtigung ist für lang andauernde Aufgaben gedacht, bei denen der entfernte Agent Minuten, Stunden, Stunden oder sogar Tage benötigen kann. Die Mitarbeiter-Einarbeitung ist ein gutes Beispiel. Ein Spezialist richtet IT-Konten ein, während ein anderer über mehrere Tage die Leistungsanmeldung übernimmt. Der Client-Agent sendet eine Anfrage, erhält eine Aufgaben-ID zurück und setzt seine Arbeit fort. Später sendet der Remote-Agent das Ergebnis über einen Webhook. Der Client kann den Fortschritt jederzeit durch Abfragen dieser Aufgaben-ID überprüfen.

Jede Interaktion folgt demselben Aufbau, alles organisiert als Aufgabe. Wenn der Client eine Anfrage sendet, erstellt der Remote-Agent eine Aufgabe und gibt eine Aufgaben-ID zurück. Diese ID dient als Nachverfolgungsmerkmal für alles, was folgt. Nachrichten innerhalb dieser Aufgabe haben eine Rolle, die angibt, wer sie gesendet hat, sowie Teile, die Klartext, Binärdaten wie Bilder oder Dokumente, JSON-Nutzdaten oder URLs zu extern gespeicherten Dateien sein können. Zu extern gespeicherten Dateien sein können. Die Authentifizierung folgt den üblichen Webkonventionen, OAuth, API-Schlüssel, Bearer-Tokens. Die üblichen Verdächtigen hier gibt es nichts Neues zu lernen. Die Agentenkarte teilt dem Client mit, welche Authentifizierungsmethode verwendet werden soll und der Client handhabt dies wie bei jedem anderen IP-Aufruf. So sieht es in der Praxis aus. Angenommen, der Orchestrator benötigt Wetterdaten für eine Reise.

Er sendet eine Aufgabe an den Wetterspezialisten. Der Wetterspezialist bestätigt die Anfrage, beginnt mit der Verarbeitung und streamt Fortschrittsaktualisierung zurück. Daten werden abgehoben. Ergebnisse werden analysiert. Dann sendet er die endgültige Vorhersage. Der Orchestrator sieht niemals die internen Tools des Wetteragenten, dessen API-Schlüssel oder dessen Denkprozess oder dessen Denkprozess. Er sieht nur das Ergebnis. Das ist das zentrale Designprinzip. Saubere Grenzen zwischen Agenten und kein Austreten von internem Status. Doch ArtWire allein reicht nicht aus. Man benötigt einen intelligenten Chef, um all diese Spezialisten zu kodieren. Das führt uns zum Orchestrator-Spezialisten-Muster. Das Orchestrator-Spezialisten-Muster. Hier läuft alles zusammen. Das Orchestrator-Spezialisten-Muster ist heute die häufigste Architektur in produktiven Multiagentensystemen. Stellen Sie es sich wie ein Unternehmen mit Abteilungen vor IT, Personalwesen, Finanzen, bei dem jeder seinen eigenen Bereich abdeckt.

Es gibt einen zentralen Entscheider, der die Arbeit an spezialisierte Teams verteilt, und jedes Team konzentriert sich auf das, was es am besten kann. Der Orchestrator behält den Überblick. Er empfängt die Anfrage des Benutzers, bestimmt was zu tun ist und entscheidet, welcher Spezialist welchen Teil übernehmen kann. Wenn ein Benutzer fragt, plähnete Woche eine Reise nach Seattle. Bucht der Orchestrator weder Flüge noch prüft er selbst Hotels. Er weiß, dass es einen Flugspezialisten, einen Hotelspezialisten und einen Wetterspezialisten gibt. Er zerlegt die Anfrage in diese Teile und delegiert jeden davon. Jeder Spezialist hat einen eng gefassten Fokus. Ein Agent übernimmt die Flugbuchung, ein anderer die Hotelsuche und ein dritter die Vorfalltriage. Sie müssen nichts über die Bereiche der jeweils anderen wissen. Der Flugspezialist kennt Fluggesellschaft, Routen und Preise. Er muss nichts über Hotelzimmertypen oder Stornierungsbedingungen wissen.

Dieser enge Fokus hält jeden Agenten einfach, wartungsarm und leicht zu testen. Hier ist der wichtige Teil. Der Orchestrator führt die Aufgaben nicht selbst ab. Er leitet die Arbeit weiter und führt die Ergebnisse zusammen. Das ist seine einzige Aufgabe. Die Rolle des Orchestrators ist ein intelligenter Verteiler, kein Superagent, der alles versucht. Wenn Sie den Orchestrator Spezialisten Aufgaben übernehmen lassen, verlieren Sie den gesamten Nutzen des Musters. Es wird wieder zu einem monolithischen Chaos. Achten Sie auf einen häufigen Fehler. Manche Teams erstellen sich überschneidende Spezialistenbereiche. Zwei Agenten behaupten beide, sie könnten Kundensupport oder Datensuche übernehmen, was zur Routingverwirrung führt. Der Orchestrator weiß nicht, welchen er wählen soll und Nutzer erhalten inkonsistente Ergebnisse. Die Lösung ist unkompliziert. Jeder Spezialist besitzt einen klar abgegrenzten Bereich ohne Überschneidung.

Wenn zwei Agenten dasselbe tun können, führen Sie sie zusammen oder unterteilen Sie den Bereich sauber. Microsofts Co-Pilot Studio verwendet dieses Muster nativ. Ihr Hauptco-Pilot fungiert als Orchestrator, während untergeordnete und verbundene Agenten als Spezialisten agieren. Wenn ein Nutzer eine Frage stellt, die mehrere Bereiche umfasst, delegiert der Hauptco-Pilot über A2A an die richtigen Spezialisten. A. Es ist in die Plattform integriert, Sie müssen die Orchestrierungslogik also nicht von Grund auf neu programmieren. Der große Vorteil hierbei ist die Modularität. Müssen Sie Ihren Hotelbuchungsanbieter austauschen? Ersetzen Sie den Hotelspezialisten, ohne den Orchestrator oder einen anderen Agenten zu berühren. Fügen Sie eine neue Fähigkeit hinzu? Stellen Sie einen neuen Spezialisten, registrieren Sie ihn beim Orchestrator und Sie sind fern. Jeder Agent bleibt klein, überschaubar und unabhängig einsetzbar.

Das ist der ganze Zweck des Wechsels von monolithischen Agenten zu einem Multiagentensystem. Wir haben also das Protokoll, die Agentenkarten und das Muster. Lassen Sie uns das in echten Szenarien in Aktion sehen. Echte Beispiele für A2A in Aktion. Wie sieht R2R also in der realen Welt tatsächlich aus? Beginnen wir mit einem einfachen Beispiel. Sie sagen Ihrem KI-Assistenten, plane eine Reise nach Seattle nächste Woche. Bei der alten Vorgehensweise müsste dieser einzelne Assistent alles wissen. Wetter, Flüge, Hotels, Restaurants, alles auf einmal. Das ist viel für eine einzige Eingabeaufforderung. Mit A2A bricht der Orchestrat dies herunter. Er sendet eine Aufgabe an einen Wetterspezialisten und fragt nach der Vorhersage für diese speziellen Teil. Gleichzeitig bittet es einen Flugspezialisten, Flüge mit Ankunft am Dienstagmorgen und Rückflug am Donnerstagabend zu finden und einen Hotelspezialisten, Unterkünfte in der Nähe der Innenstadt von Seattle für drei Nächte zu suchen.

Jeder Spezialist arbeitet unabhängig und muss nicht mit den anderen Agenten kommunizieren, da jeder über eigene Datenquellen, Tools und Fachkenntnisse verfügt. Der Orchestrator sammelt alle Ergebnisse und führt sie zu einer einzigen Antwort zusammen. Der Benutzer sieht eine einzige Antwort. Hier ist die Vorhersage. Dies sind ihre Flugoptionen und hier sind drei Hotels in der Nähe des Bewusstes. Hinter den Kulissen haben drei separate Agenten zusammengearbeitet, ohne dass benutzerdefinierte Integrationscode erforderlich war. Nun ein Geschäftsszenario. Nehmen wir ein Ticket-Git ein. Mein Laptop verbindet sich nicht mit dem VPN. Der Orchestrator erkennt, dass dies ein Netzwerkproblem ist. Er übergibt das Ticket an einen Runbook-Spezialisten, der die Standardschritte kennt. VPN-Client-Status prüfen, Netzwerkanmeldedaten verifizieren, Dienst neu starten. Dieser Spezialist liefert die Schritte zurück.

Dann leitet der Orchestrator das Ergebnis an einen Ticket-Writer-Spezialisten weiter, der die Lösung im System protokolliert. All dies geschieht in Sekunden, ohne dass ein Mensch eingreifen muss. Und das IT-Team wird nur involviert, wenn die automatisierten Schritte das Problem nicht beheben. Das Onboarding von Mitarbeitern ist ein weiteres Beispiel, aber dieses dauert Tage statt Sekunden. Ein neuer Mitarbeiter kommt mit dem. Der Orchestrator beauftragt einen IT-Spezialisten mit dem Erstellen von Konten und der Zuweisung von Hardware, was einige Stunden dauern kann. Gleichzeitig aktiviert er einen Herrsspezialisten für Sozialleistungen für Anmeldeformulare und später einen Facility-Spezialisten für Schreibtisch- und Zugangskartenzuweisung. Jeder Spezialist führt seine eigene langwierige Aufgabe unabhängig aus und der Orchestrator verfolgt den Fortschritt mithilfe der zuvor erwähnten Aufgaben-IDs.

Wenn also der IT-Spezialist fertig ist, weiß der Orchestrator Bescheid auf Bescheid und wenn der Facility-Spezialist verzögert ist, kann er nachhaken. Der Benutzer sieht einen reibungslosen Onboarding-Prozess, aber hinter den Kulissen arbeitet ein koordiniertes Team über mehrere Tage hinweg. Und das ist nicht nur Theorie. Coca-Cola Beverages Africa nutzt bereits Co-Pilot-Studio-Agenten mit Dynamics 365, um Planungszyklen zu automatisieren. Ihre Plane verbrachten früher jeden Tag bis zu anderthalb Stunden mit repetitiven Aufgaben. Mit Multi-Agenten-Orchestrierung laufen diese Zyklen von selbst. Der Orchestrator delegiert an Spezialisten, die verschiedene Teile des Supply-Chain-Planungsprozesses abwickeln. Das Ergebnis ist eine Ersparnis von über einer Stunde pro Person und Tag, nur indem Agenten miteinander kommunizieren, anstatt Informationen manuell zwischen Systemen übertragen zu lassen.

Das Muster ist also in all diesen Beispielen gleich. Jeder Agent ist ein in sich geschlossener Experte, der sein eigenes Fachgebiet kennt, über eigene Tools verfügt und nichts über die anderen Agenten wissen muss. A2A bietet eine einfache Kommunikationsebene, damit Sie ohne benutzerdefinierten Code zusammenarbeiten können. Sie erhalten ein Standardprotokoll und einen intelligenten Orchestrator, ohne Bridges, ohne Punkt-zu-Punkt-Integrationen und ohne Wartungsaufwand. Microsoft setzt voll und ganz darauf. Sehen wir uns an, wo Co-Pilot-Studio und Azure AI hineinpassen. Das Microsoft-Ökosystem, Co-Pilot-Studio und Azure AI. Wo steht Microsoft also bei all dem? Genau im Zentrum. Co-Pilot-Studio unterstützt A2A jetzt nativ und ist seit April 2096 allgemein verfügbar. Das ist keine Vorschau- oder Beta-Version. Es ist produktionsreif und jeder berechtigte Kunde kann es heute nutzen. Darum geht es.

Sie können externe Agenten mit Ihrem Co-Pilot-Studio-Orchestrator verbinden. Wenn ich extern sage, meine ich wirklich extern. Agenten, die auf Google Cloud, AWS oder einer anderen Plattform erstellt wurden, die das A2A-Protokoll unterstützt. Dem Orchestrator ist es egal, wo der Agent lebt oder mit welchem Framework er erstellt wurde. Solange er A2A spricht, kann er dem Team beitreten. Die Einrichtung ist einfach. In Co-Pilot-Studio erstellen Sie einen sogenannten verbundenen Agenten. Sie fügen die Endpunkt-URL des Agenten ein. Co-Pilot-Studio ruft automatisch die Agentenkarte von dieser URL ab, also die bekannte JSON-Datei, über die wir gesprochen haben. Es liest die Fähigkeiten des Agenten, die Authentifizierungsanforderungen sowie die Ein- und Ausgabeformate aus. Dann erstellt es im Hintergrund einen benutzerdefinierten Connector und die Orchestrator kann sofort mit der Aufgabendelegierung beginnen.

Sie benötigen keine manuelle Integrationsarbeit oder benutzerdefinierten Connector. Einfach die URL einfügen und fertig. Auf der Azure-Seite unterstützt auch der Azure AI Foundry Agent Service A2A. Er verfügt über einen dedizierten A2A-RPE-Inpunkt mit dem Open-Source-Orchestratoren wie Autogen, Langchain und Semantic-Kernel-Foundry-Agenten aufrufen können. Wenn Sie also Agenten mit diesen Frameworks erstellt haben, können Sie diese ohne Umschreiben das Microsoft-Ökosystem einbinden. Das ist eine Einbahnstraße bei der Richtung. Microsoft folgt dem gleichen Orchestrator-Spezialisten-Muster, das wir beschrieben haben. Der Hauptagent in Co-Pilot-Studio fungiert als Orchestrator, während untergeordnete und verbundene Agenten die Spezialisten sind. Jeder kümmert sich um seinen eigenen Bereich und der Orchestrator leitet weiter und führt zusammen. Es ist dieselbe Architektur, nur eben auf der Microsoft-Plattform.

Aber es gibt einige Einschränkungen, die Sie kennen sollten. Erstens fügt jeder zusätzliche Orchestrierungsschritt Latenz hinzu. Wenn Ihr Hauptagent einen verbundenen Agenten aufruft und dieser wiederum einen anderen Spezialisten, erhöht jeder Schritt die Netzwerkzeit. Bei Echtzeit-Konversationen können zu viele Schritte die Erfahrung träge wirken lassen. Zweitens führt eine Überdelegierung zu Routing-Chaos. Wenn Sie zu viele Spezialisten mit sich überschneidenden Bereichen haben, trifft der Orchestrator schlechte Routing-Entscheidungen. Halten Sie also die Anzahl Ihrer Spezialisten überschaubar und Ihre Domänen klar voneinander getrennt. Drittens gibt es eine spezifische Einschränkung bei Fabric-Daten-Agents. Diese funktionieren nicht, wenn der Hauptagent in Microsoft-Rand 65 Co-Pilot bereitgestellt wird. Wenn Ihre Bereitstellung auf M365 abzielt, planen Sie entsprechend. Diese Einschränkungen sind real, aber sie sind beherrschbar.

Die Plattform ist ausgereift genug für den produktiven Einsatz und Microsoft arbeitet aktiv daran, diese Lücken zu schließen. Lassen Sie uns nun die Punkte verbinden und das Gesamtbuch betrachten. Verbindungsabschnitt, wie alles zusammenpasst. Lassen Sie uns einen Schritt zurücktreten und sehen, wie diese Teile zusammen sind. A2A ist das Telefonsystem des Agents nutzen, um sich gegenseitig anzurufen. Die Agentkarten sieht ihr Telefonbuch. Sie zeigen ihnen, wen sie anrufen müssen und was jeder Agent übernimmt. Der Orchestrator ist der Empfangsmitarbeiter, der jeden Anruf an die richtige Abteilung weitergeht. Keines dieser Teile funktioniert allein. Sie benötigen alle drei. Ohne Telefonbuch wissen Sie nicht, wen Sie anrufen sollten. Ohne Empfangsmitarbeiter steuert niemand den Datenverkehr. Und ohne Telefonsystem kann ein Empfangsmitarbeiter niemanden verbinden. Sie funktionieren nur als Team.

Hier kommt Modularität ins Spiel. Wenn Ihre Spezialisten modular aufgebaut sind, können Sie neue Funktionen hinzufügen, ohne das zu unterbrechen, was bereits funktioniert. Nehmen wir an, Sie möchten Ihrem Reiseassistenten einen Mietwagenspezialisten hinzufügen. Sie erstellen ihn, veröffentlichen seine Agentenkarte und geben dem Orchestrator dessen URL. Der Flugspezialist und der Hotelspezialist bleiben exakt gleich. Auch der Orchestrator ändert sich nicht. Sie fügen einfach ein neues Teil hinzu und das System passt sicher. Da das Protokoll offen ist, sind Sie nie an einzigen Anbieter gebunden. Ihr Orchestrator kann auf Copilot Studio laufen, Ihr Wetteragent in der Google Cloud leben, Ihr Hotelagent auf AWS liegen und Ihr internen System auf Azure bleiben. Sie alle sprechen dieselbe Sprache. Das ist das Schöne an einem offenen Standard. Er verhindert Vendor-Login und lässt Sie das beste Werkzeug für jede Aufgabe wählen.

Bei A2A geht es nicht darum, einen superintelligenten Agenten zu bauen, der alles weiß. Es geht darum, eine flexible Belegschaft von Spezialisten aufzubauen, die Sie bei sich ändernden Anforderungen nennen können. Sie ersetzen Ihre Agenten nicht, Sie orten sie neu an. Sie fügen neue hinzu. Sie tauschen alte aus. Das System wächst mit Ihnen, anstatt zu einem Engpass zu werden. Was können Sie also heute mit diesem Wissen anfangen? Umsetzbare Erkenntnis. Fangen Sie klein an. Wählen Sie einen wiederkehrenden Prozess in Ihrem Unternehmen, der mehrere Systeme umfasst. Ticketlösung, Mitarbeiter, Onboarding oder Spesenabrechnung zum Beispiel. Etwas mit klaren Übergaben zwischen den Schritten. Bauen Sie dann einen Prototyp mit einem Orchestrator und zwei Spezialisten. Sie benötigen keine großartige Architektur. Sie benötigen nur ein funktionierendes Beispiel, aus dem Sie lernen können. Nutzen Sie die Tools, die dies bereits unterstützen.

Copilot Studio hat integrierten A2A Support, Azure AI Foundry ebenso. Sie müssen das Protokoll nicht von Grund auf neu erstellen oder benutzerdefinierten Code schreiben. URL einfügen, Agenten konfigurieren und mit der Delegation beginnen. Achten Sie auf häufige Fallstrecken. Vermeiden Sie Überschneidungen bei Ihren Fachgebieten. Wenn zwei Agenten dasselbe tun können, führen Sie sie zusammen oder trennen Sie die Bereiche sauber. Lassen Sie den Orchestrator das Routing übernehmen, nicht die Ausführung. Und achten Sie auf Latenzzeiten durch Orchestrierung. Wenn die Antwortzeiten steigen, haben Sie möglicherweise zu viele Delegationsschichten. Der beste erste Schritt ist ganz einfach. Skizzieren Sie die Übergaben in Ihrem bestehenden Workflow. Wo werden Informationen zwischen Person oder System weitergegeben? Das sind genau die Stellen, an denen Agenten übernehmen können. Jede Übergabe ist eine neue Chance.

Das ist also das A2A System in aller Kürze. Drei einfache Komponenten, die zusammenarbeiten. Agenten sind nicht mehr isoliert, sondern agieren als echtes Team. Wehen Sie ein Workflow mit klaren Übergaben und bauen Sie darauf ab. Abonnieren Sie für weitere einfache Erklärungen und hinterlassen Sie einen Kommentar, falls etwas hilfreich war. Das ist hier interessant.