Willkommen alle beim M365FM Podcast. Heute gehen wir über eines der häufigsten Gesprächsthemen rund um Microsoft 365 Co-Pilot Prompt Engineering hinaus. Denn, sobald Unternehmen anfangen, Co-Pilot ernsthaft zu nutzen, ändert sich die Frage schnell von, wie schreiben wir bessere Prompts zu, wie verbinden wir Co-Pilot mit den Anwendungen, Daten, Apps, Geschäftsprozessen und dem Wissen, die tatsächlich in unserer Firma laufen. Ähm, und genau da wird die Co-Pilot Erweiterbarkeit interessant. Mein Gast heute ist Evers Harvest, Microsoft MVP Business Application Consultant bei der AI Word Group in der Schweiz. Evers arbeitet mit Microsoft 365, Azure Dynamics 365 und der Power Plattform mit besonderem Fokus auf die Erweiterung von Microsoft 365 Co-Pilot durch Agents und individuelle Entwicklungen. Wir werden die Microsoft 365 Co-Pilot Erweiterbarkeit, Co-Pilot Studio, Microsoft Azure AI Foundry, ich weiß auch nicht, Sie erinnern ja ständig die Namen, MUI, Microsoft Graph, Custom Development, MCPS und so weiter erkunden.

Also ja, Evers, willkommen im M365 Podcast. Ja, hallo zusammen, danke, dass ich hier sein darf. Es ist wirklich eine tolle Gelegenheit für mich, hier zu sein. Also danke für die Einladung. Ja, ich danke dir. Bevor wir technisch werden, kannst du uns ein wenig von deinem Weg erzählen, wie du in das Microsoft-Ökosystem gekommen bist. Ja, ja, natürlich. Denn um ehrlich zu sein, habe ich meine Karriere nicht in der Microsoft-Welt begonnen. Ich habe meine Karriere in der Apple-Welt gestartet. Ich war Softwareentwickler auf der Mac-Plattform und bin danach zu iOS und solchen Dingen gewechselt. Und, oh, das ist schon eine lange Zeit her, vielleicht vor 15 oder 20 Jahren, da bin ich in die Microsoft-Welt gewechselt. Um ehrlich zu sein, habe ich meine Karriere mit SharePoint begonnen.

Und danach bin ich zur Cloud gewechselt, zu Azure und M365.

Ich habe mit SharePoint On-Premises angefangen, so fing es an. Und danach bin ich zu allen Cloud-Diensten übergegangen, am Ende zur Power-Plattform und zuletzt zu all den KI-Themen. Ehrlich gesagt, weil das jetzt ein großer Teil von M365 ist, da wir jetzt diesen agentenbasierten Wandel haben. Und das ist im Grunde, kurz gefasst, meine Reise.

Aber ich habe meine Karriere in der Softwareentwicklung begonnen. Ein Begriff, den heute vielleicht viele vergessen, weil wir, du weißt schon, all diese KI-Sachen haben. Und im Grunde haben sich diese Art von Aktivitäten oder Jobs zur KI hin verlagert. Daher ist es heute ganz anders als noch vor 20 Jahren.

Ja, du arbeitest mit SharePoint und ich sehe, du arbeitest auch mit GraphSpeak, Dynamics und der Power-Plattform. Wie hat dich dieser Hintergrund auf die aktuelle Generation der KI-Entwicklung vorbereitet? Also im Grunde ist mein Profil wirklich sehr transversal, weil ich in meiner Laufbahn mit sehr vielen verschiedenen Produkten gearbeitet habe. Das können Microsoft- oder nicht Microsoft-Produkte gewesen sein. Daher verfüge ich über ein breites Spektrum an Fähigkeiten in vielen verschiedenen Technologien und Tools. Diese ganzen Jobs bieten mir eine gute Grundlage. Denn bei der KI ist es heute ein weites Feld, da es verschiedene Ansätze und Technologien gibt, um KI umzusetzen. Kann agentenbasiert sein, es kann eher workflow-orientiert sein, solche Dinge. Im Grunde haben mir alle meine bisherigen Jobs viele Fähigkeiten gegeben, um ehrlich zu sein, um für diesen KI-Wandel bereit zu sein. Ich habe mich also hin zu Low-Code und auch zu Pro-Code-Tools bewegt.

Ja, all diese Möglichkeiten und Aktivitäten in meinen Jobs haben mir wirklich gute Fähigkeiten verliehen, um in der KI-Welt Fuß zu fassen, um ehrlich zu sein.

Und jetzt bist du AI-Test-Lead. Was genau macht ein AI-Test-Lead?

Das ist eine wirklich gute Frage, denn es fragen mich viele Leute... Meine Aufgabe ist es, die funktionalen Spezifikationen mit dem technischen Stack abzugleichen.

Ich übernehme die Führung, sobald die Geschäftsanalyse abgeschlossen ist. Wir haben Anwendungsfälle für die KI-Sachen definiert. Wir haben Szenarien und Use-Cases festgelegt. Wir haben die vollständige Geschäftsanalyse durchgeführt. Und meine Aufgabe ist es, diese Anforderungen zu nehmen und sie mit der technischen Infrastruktur im Hintergrund abzugleichen. Warne. Und danach leite ich die gesamte Implementierung der Tools und der Lösung, sobald wir bereit sind, mit der Entwicklung zu beginnen. Ja, interessant. Eigentlich kaufen viele Unternehmen Schulungen für ihre Mitarbeiter, besonders für Prompt Engineering. Äh, äh, warum würdest du sagen, dass das nicht ausreicht?

Nur Prompt Engineering, meinst du heute, äh? Warum, warum, warum, warum sie, warum es nur, weißt du, warum reicht es für, für die Unternehmen, äh, nicht, nicht aus den Leuten nur das Prompt Engineering beizubringen? Ah ja, okay. Ich verstehe, ich verstehe. Ja, ja, äh, im Grunde, um ehrlich zu sein, hast du heutzutage, wie ich schon sagte, eine Menge verschiedener Tools und Technologien. Also, und im Grunde kann die KI irgendwann verstehen, was zu tun ist und dich, äh, vielleicht ein wenig anleiten.

Aber für mich, äh, bei der Rolle eines Architekten oder Software Designers beispielsweise, äh, brauchst du einen Menschen hinter den Kulissen, weil du den Kunden verstehen musst.

Im Grunde kann die KI manchmal den Kontext des Kunden nicht verstehen, mich verstehen. Äh, man sieht dort das ganze Netz, aber hinter den Kulissen, äh, sich nur auf das Prompt Engineering zu konzentrieren, mag zwar bis zu einem gewissen Punkt gut sein, aber man braucht mehr, weil man hinter den Kulissen, äh, einige Leute braucht, die, äh, Architekten, Softwareentwickler, äh, hinter den Kulissen sind. Und im Grunde eine Menge Leute, die Fähigkeiten in Technologien, äh, Informationstechnologien wie SharePoint, wie OneDrive, wie, ich weiß nicht, oder Salesforce, diese Art von Dingen haben. Du brauchst Spezialisten für diese Technologien, weil die KI eine Menge Dinge verstehen kann. Sie kann, äh, sie kann dich anleiten, sie kann großartige technische oder funktionale Dokumente erstellen, aber du, du musst Menschen hinter den Kulissen haben, die sich darum kümmern, okay, ist das gut? Beantwortet das, äh, die Kundenbedürfnisse, diese Art von Dingen, weißt du, um alles zu validieren und sich nur auf das Prompt Engineering zu konzentrieren?

Für mich ist das jetzt, ja, es könnte, es könnte eine Option sein, wenn du, wenn du nicht die, äh, Zeit hast, um, um zu trainieren oder zu investieren, äh, in, äh, in, äh, den Erwerb von, von Fähigkeiten. Fähigkeiten, aber für mich musst du, äh, gute Fähigkeiten in den grundlegenden Technologien haben, wo du deine Lösungen aufbauen willst, um ehrlich zu sein. Und du bist ein Experte für Copilot-Erweiterbarkeit. Äh, wo hört um? Der Standard-Copilot Microsoft 365 Copilot. Auf und wo fängt Copilot-Erweiterbarkeit an? Ha, ja, das ist eine gute Frage, denn, um ehrlich zu sein, vor zwei Jahren, als, äh, Copilot, äh, veröffentlicht wurde und, äh, vielleicht die erste Version, äh, war der Chat im Grunde, äh, um ehrlich zu sein, wirklich, äh, wirklich minimalistisch. Im Grunde kann man, okay, es war wie ein Chat-GPT, aber Microsoft hat Microsoft 300er von Bodo, von Fon60 Copilot stark weiterentwickelt.

Jetzt hat man verschiedene Funktionen, also ist die Erweiterbarkeit geringer als früher, denn früher habe ich, äh, äh, Plugins und dergleichen entwickelt, aber, heutzutage, um ehrlich zu sein, beginnt die Erweiterbarkeit dort, wo man etwas bauen und den Orchestrator anpassen will. Oder, wenn man etwas mehr personalisieren möchte, etwa die Benutzeroberfläche, oder wenn man seinen Agenten nicht nur in den Microsoft 300er von Fon50 Chat, sondern beispielsweise auch auf die eigene Website integrieren will, die Erweiterbarkeit beginnt, also da, wo man im Hintergrund mehr anpassen möchte. Äh, ähm, das könnte der Orchestrator sein, wenn man ihn anpassen will, oder die Benutzeroberfläche oder verschiedene andere Aspekte, bei denen, äh, Co-Pilot-Chat im Grunde nicht weiterhelfen oder antworten kann. Ähm, und, und, ich glaube, viele Leute sprechen über Agenten, äh, sind, ähm, sind, warum, warum denken wir jetzt so viel über Co-Pilot-Agenten nach und warum bauen wir nicht, ich weiß es nicht, einen großen Co-Pilot für alles, alles?

Ja, das ist wirklich interessant, denn, um ehrlich zu sein, Microsoft hat sich, wie ich schon sagte, stark weiterentwickelt und vielleicht vor sechs Monaten war ein Agent noch ein wichtiges Thema. Ja, jetzt hat Microsoft Co-Pilot-Co-Worker eingeführt und ehrlich gesagt können Co-Pilot-Co-Worker heute viele Agenten ersetzen und wenn wir über Agenten nachdenken, dann nur, um Dinge zu trennen. Denn wir befinden uns jetzt eher in einem Multi-Agenten-Modell, in dem jeder Agent seinen eigenen Bereich und seine eigenen Verantwortlichkeiten hat. Und wir machen keinen großen Co-Pilot ganz einfach wegen der Performance, ne. Erstens, weil es bei einer großen Menge an Anweisungen und Tools in Sachen Performance ein ziemliches Durcheinander gäbe. Und die Architektur ist heute eher Multi-Agent, das kann ein Co-Pilot-Studio sein. Oder durch individuell entwickelte Agenten via Code oder kundenspezifische Entwicklungen.

Aber heutzutage ist es besser, einen Multi-Agenten-Ansatz zu verfolgen, bei dem jeder Agent seinen eigenen Bereich und seine eigene Verantwortung hat, einfach im Hinblick auf die Leistung und um eine klare Architektur für die Agenten zu haben.

Und wenn wir uns das ansehen, okay, ich denke, bei einer grundlegenden KI-Agenten-Architektur haben wir, sage ich mal, einige Schlagworte. Wir, wir Schlagworte. Aber wir müssen über Schlussfolgerungen, Tools, Wissen und Anweisungen nachdenken. Wie passt das in eine KI-Agenten-Architektur? Das Erste, worüber man nachdenken muss, eine der ersten Fragen, die man beantworten muss, ist, okay, was ist das Ziel? Das Erste Ziel dieses Agenten. Im Grunde hängt die Architektur eines Agenten wirklich davon ab, ob man einen Low-Code-Ansatz oder einen Ansatz mit individueller Entwicklung verfolgt. Denn der Ansatz ist völlig anders, da man bei der individuellen Entwicklung alles selbst verwaltet. Man verwaltet also die Sicherheit, das Hosting und man verwaltet viele verschiedene Dinge. Beim Low-Code-Ansatz ist es ganz anders, denn man überlegt, okay, man gibt die Anweisungen und wählt einige Tools aus.

Im Grunde ist die Architektur bei einem Low-Code-Ansatz nicht so einfach, wie ich es gerade gesagt habe. Aber es könnte sehr schnell gehen, da man definieren kann, okay, man hat die Anweisungen, man kann seine Tools auswählen, man kann verschiedene andere Agenten auswählen, wenn man sie verbinden möchte. Aber es ist wirklich einfach, wenn man sich mit individueller Entwicklung befasst oder wenn man seinen eigenen Agenten entwickelt, wickelt. Das könnte zum Beispiel Semantic Kernel, Agent Framework oder ähnliche Dinge sein. Die Architektur könnte wirklich komplexer sein, weil man sich mit wirklich fortgeschrittenen Konzepten auseinandersetzen muss, wie ich schon sagte, der Sicherheit. Was die Authentifizierung betrifft, wenn man zum Beispiel mehrere Tools hat und einige Endpunkte integrieren möchte, wenn man sich mit internen Tools verbinden will, die durch Reverse Proxies geschützt sind, solche Dinge.

Man muss also im Grunde mehr über die Architektur nachdenken, wenn man es mit benutzerdefinierten Agenten zu tun hat, zum Beispiel in Co-Pilot Studio. Was die Architektur betrifft, ist es wirklich schnell, die Architektur bei einem individuellen Entwicklungsansatz zu definieren, man muss sich mit fortgeschrittenen Konzepten auseinandersetzen und für viele Leute könnte das schwierig sein, weil es sich um wirklich grundlegende Aspekte handelt. Und in meinem Job habe ich es ehrlich gesagt mit einer Vielzahl verschiedener Anforderungen zu tun. Das kann eine kundenspezifische Entwicklung sein, Co-Pilot Studio oder ein einfacher Agent im Agent Builder für eine sehr simple Aufgabe, für eine simple Aufgabe. Die Definition einer Architektur hängt also grundlegend davon ab, welchen Ansatz man verfolgen möchte. Im Grunde gibt es eine allgemeine Architektur, die man erstellen kann, aber danach hängt es wirklich vom Ansatz ab, Low-Code oder Full-Code, verstehen Sie?

Aber können Sie die Anatomie eines typischen KI-Unternehmens Agenten beschreiben?

Oh ja, das kann ich. Im Grunde, wenn man es so einfach wie möglich ausdrücken will, wenn man einen Bedarf hat, zum Beispiel IIT-Support-Agenten, dann hat man im Grunde eine Reihe von Anforderungen. Aber heutzutage gibt es, wie ich schon sagte, diesen Multi-Agenten-Ansatz und ich setze den ersten Agenten als Frontend ein, sozusagen als Fassade.

Das ist also ein Front-Agent, der alle Anfragen an die verschiedenen anderen Agenten weiterleitet. Wenn der Benutzer zum Beispiel eine Frage zu Salesforce hat, leitet er die gesamte Anfrage an den Salesforce-IT-Support-Agenten weiter. Alter. Sehen Sie, wir haben für einige Kunden diese Art von Architektur erstellt, weil jeder Agent seinen eigenen Zuständigkeitsbereich hat. Das könnte für Produkte wie Salesforce sein. Es könnte für M365 oder ähnliche Dinge sein. Und im Hintergrund hat jeder Agent eine Reihe von Anweisungen, Werkzeugen.

Heutzutage ist es besser, MCP-Server zu verwenden, da MCP-Server mittlerweile eine universelle Schnittstelle zur Integration verschiedener Dienste mit KI sind. Ich habe also eine Reihe von MCP-Servern und verfüge zudem über einige interne Wissensquellen. Das könnte Jira sein, eine ServiceNow, Wissensdatenbank oder ähnliche Dinge. Wir haben also einen Satz von Anweisungen pro Agent. Und diese Anweisungen definieren den Aufgabenbereich und die Rolle jedes Agenten. Und dazu kommen dann die MCP-Server und vielleicht Wissensquellen wie PDF-Dateien. Es können also ganz verschiedene Arten von Datenquellen sein.

Und nach der... Entschuldigung, wenn ein Nutzer zum Beispiel eine Anfrage an den Hauptagenten stellt, wird dieser definieren, okay, ich muss diese Aufgabe an den entsprechenden Agenten delegieren. Lassen Sie uns ein wenig die Möglichkeiten betrachten. Oder... Wie fügt sich Co-Pilot Studio in die Gesamtarchitektur ein?

Co-Pilot Studio ist, um ehrlich zu sein, ein Low-Code-Tool von Microsoft. Zunächst einmal in Bezug auf die Architektur ist Co-Pilot Studio wirklich für Maker konzipiert, im Grunde für Leute, die nicht in erster Linie Entwickler sind. Und was die Architektur angeht, wenn wir zum Beispiel das Beispiel nehmen, das ich vorhin genannt habe, den IT-Support, dann passt Co-Pilot Studio, weil es architektonisch gesehen seinen Zweck erfüllt. Man kann es definieren. Man kann einen Co-Pilot-Server festlegen und man kann problemlos externe oder interne Wissensquellen integrieren, wenn man möchte.

Wie ich bereits sagte, falls Sie einen Anwendungsfall haben, bei dem Sie den Orchestrator ein wenig anpassen, im Hintergrund von Co-Pilot Studio können Sie den Orchestrator nicht anpassen, man aktiviert den KI-Orchestrator und das war's.

Man kann zum Beispiel nicht die Priorität der Aufgaben anpassen, die man erledigen möchte, da Co-Pilot Studio im Hintergrund den Plan festlegt, den es dann ausführt.

Wenn Sie jedoch etwas mehr Anpassungsmöglichkeiten benötigen, müssen Sie auf eine eigene Entwicklung zurückgreifen, zum Beispiel mit Semantic-Kernel oder Langchain einem Framework, das Microsoft kürzlich veröffentlicht hat. In dieser Phase können Sie die Orchestrierung einfach anpassen, Workflows definieren und alles nach Wunsch konfigurieren. Das ist Co-Pilot Studio als Architektur, die wirklich für Erbauer und Maker definiert ist, weil es sehr einfach ist, einen Agenten zum Laufen zu bringen. Das einzige Problem bei Co-Pilot Studio und darauf müssen Sie achten, wenn Sie Ihren Pfad wählen und Ihre Architektur definieren ist, dass Sie die Lizenzierung im Blick behalten müssen, da sie mittlerweile ein großer Teil jeder Lösung ist.

Heutzutage hat sich Co-Pilot Studio etwas in Richtung eines Pay-as-you-go-Modells entwickelt und man muss bei der Kostenschätzung aufpassen, denn je nachdem, was man erreichen will, ist es manchmal besser, eine eigene Entwicklung zu machen, da man dann selbst hostet, wo man will, sich um alle Kosten kümmert und diese leichter abschätzen kann als jetzt.

Denn mit dem Co-Pilot-Credit-Ansatz ist es manchmal schwierig, vorherzusagen, wie viel es für einen Monat, zwei Monate und dergleichen kosten wird. Und was sind die Einschränkungen von Co-Pilot Studio? Studio, wann sollte ich mich entscheiden? Dann denke ich, ja, Microsoft Foundry, Azure Foundry, weiß nicht, wie das wirklich heißt. Und wann ich sagen muss, okay, ich muss eine komplett eigene Entwicklung machen. Die erste Frage, die es zu beantworten gilt, lautet, okay, muss ich die Orchestrierung anpassen? Das ist für mich die erste Frage, denn diese Frage sagt dir, okay, wenn du die Orchestrierung nicht anpassen willst, um tief in die Details zu gehen, wie die Orchestrierung gemacht wird oder wie der Plan generiert wird, kannst du einen Low-Code-Ansatz mit Co-Pilot Studio verwenden, zum Beispiel einen Bilder, zum Beispiel einen Bilder. Außerdem kann man solche Tools manchmal verwenden, wenn man einfache Anwendungsfälle hat.

Aber wenn man die Orchestrierung anpassen will, okay, dann muss man auf eine spezifische Entwicklung setzen und in diesem Fall muss man, okay, man muss Foundry für das Modell nutzen oder seine eigene Plattform, denn der Vorteil einer individuellen Entwicklung ist, du kannst Modelle integrieren, die nicht bei Microsoft Foundry gehostet werden. Wenn du willst, kannst du Foundry-Modelle nutzen, aber wenn du auch eine AWS- oder Google-Plattform hast, Entschuldigung, Google-Plattform, und du zum Beispiel Gemini hast oder Modelle extern bereitgestellt hast, hast du die Möglichkeit, diese Modelle direkt in deinen Agenten zu integrieren, wenn du einen individuellen Ansatz wählst.

Das ist auch ein Vorteil. Und danach kannst du die Orchestrierung anpassen, wie der Plan generiert wird. All diese Dinge fließen dann in den Agenten Foundry ein. Das Problem mit Foundry heutzutage ist, dass Foundry am Anfang nur eine Plattform zum Hosten von Modellen war. Wenn man ein paar Jahre zurückblickt, war es nur ein einfacher Modellkatalog, den man bereitgestellt hat, heutzutage hat Microsoft dieses Produkt so weiterentwickelt, dass man Agenten mit einer Benutzeroberfläche wie bei Copilot Studio erstellen kann. Im Grunde ganz ohne Code. Man kann die Governance verwalten und eine ganze Menge andere Dinge steuern. Es ist wirklich zu einer Agenten-basierten Plattform geworden wie Copilot Studio für Low-Code und ähnliche Dinge. Und heutzutage ist es wirklich schwierig, Foundry im Ökosystem einzuordnen, weil sich Foundry so schnell weiterentwickelt.

Microsoft hat im Grunde einige Funktionen eingeführt, die, ich weiß nicht, nicht direkt anders aber doch ähnlich wie bei Copilot Studio sind. Etwa bei der MCP-Integration und solchen Dingen. Aber die Haupteinschränkung von Copilot Studio liegt bei den Modellen. Man hat also die Möglichkeit, Code zu integrieren oder Dinge zu visualisieren. Wenn man aber zum Beispiel sein eigenes Modell integrieren möchte, weil man eine spezifische Version hat, geht das nicht. Man braucht im Grunde eine individuelle Entwicklung, um beispielsweise seine eigene LLM-Plattform anzubinden, falls vorhanden. Ich habe Kunden, die ihre eigene AWS-Plattform nutzen. In diesem Fall kann man dieses Modell mit einer extern verwalteten Preisgestaltung integrieren.

Und ich denke, wenn wir einen Agenten bauen, ist ein Thema auch immer wichtig.

Ja, Schopenhauer.

Die meisten Leute sprechen vom MCP, dem Model Context Protocol. Warum wird das zu einem der größten Themen bei der Entwicklung von Agenten? Und für jemanden, der noch nicht damit gearbeitet hat, was ist das Model Context Protocol? Ja, das ist ein großes Wort. Im Grunde sprechen viele Leute darüber, weil es ein großes Problem löste. Es geht darum, wie man die Integration von Tools, Fähigkeiten oder vielleicht externen Werkzeugen in die KI vereinheitlicht. Es löst dieses Problem, denn früher war es ohne MCP ein ziemliches Chaos, weil viele Dienste auf unterschiedliche Weise kommunizierten.

Man hatte verschiedene Technologieprotokolle und unterschiedliche Architekturansätze. Im Grunde vereinheitlicht MCP die Art und Weise, wie man Dienste in seinen KI-Agenten oder seine KI-Lösung integriert. Wenn ich es allgemein ausdrücke, MCP ist heute der Standard, um externe oder interne Tools zu integrieren. Das kann beides sein. Aber MCP ist mittlerweile ein wichtiger Bestandteil der KI-Architektur, weil man diese technologische Einheitlichkeit hatte. Und heutzutage ist es ein bedeutender Punkt. Denn früher war es die API-Integration und jetzt ist es MCP.

Das ist nicht die Evolution. Aber in der Vergangenheit hat man seinen Agenten mit APIs integriert. Man musste verwalten, wie man sich authentifiziert oder das verwaltet oder das Tool aufruft. Jetzt kann die KI sagen, okay, ich habe dieses Tool verfügbar. Ich kann auswählen, was ich brauche, um das Ziel zu erreichen.

Und was hat sich wirklich geändert von MCP zu API-Verbindungen?

Im Grunde genommen waren APIs in der Vergangenheit, was die Integration angeht, nicht intelligent. Und wenn ich das so sagen darf, APIs sind einfach, okay, du rufst ein Tool auf und es gibt dir Daten. Der Unterschied bei MCP ist, MCP ist architektonisch intelligenter, denn hinter den Kulissen hast du nicht nur Tools, die dir Daten oder Informationen liefern, sondern du hast auch Fähigkeiten, Anweisungen und verschiedene andere Dinge, die MCP wirklich intelligent machen.

Und im Grunde kann MCP der KI sagen, okay, du möchtest das erreichen? Ich kann dir die genauen Tools geben, die zu deiner Anfrage passen. Und du kannst nicht nur ein Tool aufrufen, sondern musst diese Tools aufrufen, um das zu erreichen, was du willst. Das ist die Rolle von MCP. Es gibt der KI vor, okay, ich habe diese Tools und danach kannst du dieses oder jenes oder mehrere Tools aufrufen, um deine Ziele zu erreichen und holen sie. Es gibt der KI den Kontext, den echten Kontext von allem und eine API ist nur, okay, du hast Tools, du hast eine Beschreibung und das war es eigentlich schon.

Also ist es das Model-Kontext-Protokoll, ich denke, ähnlich wie Metadaten oder wie funktioniert das?

Nein, MCP hinter den Kulissen, es ist einfach, es ist ein Protokoll.

Im Grunde ist es ein Technologie-Protokoll und hinter den Kulissen hast du, ja, du hast Metadaten, du hast Beschreibungen, du hast KI-Fähigkeiten, die mehr beschreiben. Es ist wirklich auf KI fokussiert. Im Grunde hast du Fähigkeiten, du hast Anweisungen und die KI kann besser verstehen, okay, diese Tools machen das, dieses Tool macht jenes, okay, ich kann diese Fähigkeiten abrufen, ich kann diese Informationen vom MCP-Server anfordern, um meine Aufgabe zu erfüllen. Aber man hat, ja, man hat einen Teil Metadaten, denn man muss definieren, okay, den Namen des Tools, was es im Hintergrund tut.

Schau, können wir sagen, die Zukunft ist MCP. Also müssen wir anfangen, darüber nachzudenken, ich weiß nicht, Firmen haben hunderte von REST-APIs in der Organisation, sollten sie anfangen, MCP-Server da rumzubauen. Ja, ja, im Grunde, im Grunde, MCP-Server, wir arbeiten mit APIs im Hintergrund. Das ist im Grunde kein Ersatz. Wenn ich das zusammenfasse, weil der MCP-Server ist einfach okay. Er liefert den Kontext und im Hintergrund kann der MCP-APIs aufrufen, im Hintergrund, aber der MCP-Server ist ein Frontend. Das ist das Front-Tool, das man aufrufen muss, weil man im Hintergrund seine Anfrage weiterleitet, basierend auf okay. Im Hintergrund könnte es eine API sein, eine Datenbank, es könnten mehrere Tools sein, aber man muss, wenn man seinen eigenen MCP-Server haben möchte, zum Beispiel, wenn man intern in seiner Firma APIs und verschiedene Arten von Diensten hat, es könnte, ich weiß nicht, ein Finanzdienst sein, es könnte ein HR-Dienst sein, wenn man seinen eigenen MCP bauen will, muss man im Hintergrund mit all diesen APIs umgehen und der MCP-Server muss all diese APIs offenlegen, was sind die, was sind die Dienste, welche Tools sind verfügbar, was sind die Fähigkeiten und diese Art von Dingen.

Danach muss man sich um die Authentifizierung im Hintergrund kümmern, weil die APIs nicht gleich funktionieren. Denn man kann eine Authentifizierung per Schlüssel haben, per Eingabe, diese Art von Dingen. Man muss sich also darum kümmern. Aber der MCP wird die verfügbaren Tools offenlegen und im Hintergrund können all diese Tools mehrere APIs abfragen. Eine API könnte sein, man hat verschiedene Arten von Architekturen im Hintergrund.

Und wie macht das MCP die Auswahl des richtigen Tools, wenn ich, ich weiß nicht, 100, 500 KI-Agenten habe? Das wird auf ersten Dingen basieren. Im Grunde, wenn man eine Anfrage an einen Agenten hat, entdeckt man alle verfügbaren Tools. Der MCP-Server wird, man wird prüfen, okay, ich habe all diese Tools zur Verfügung. Und im Grunde versteht der Orchestrator des Agenten, okay, ich habe dies, ich habe ein LLM zur Verfügung. Danach erstellen Sie den Plan, wenn ich es kurz zusammenfasse. Sie erstellen einen Plan mit einigen auszuführenden Aktionen und in dieser Aktion, die Sie ausführen möchten, können Sie ein, zwei, drei oder mehr Tools aufrufen, um die vom Benutzer angeforderte Aufgabe zu erledigen. Im Grunde versteht der Orchestrator des Agenten, also MCP-Tools und wählt das Beste für die Anfrage aus, äh, stehen Sie? Und das ist wirklich die Rolle des Orchestrators, Tools und ähnliches auszuwählen.

Natürlich mit Hilfe des LLM, denn das LLM ist Teil des Gehirns und der Orchestrator kommuniziert mit dem LLM und auch mit den Tools, um die beste Wahl zu treffen und den besten Plan zur Erledigung der Aufgabe zu erstellen. Ja, ich denke, eine ganze Weile haben viele Unternehmen mit PowerShell begonnen. Und jetzt nutzen Sie die Microsoft Graph API.

Gab es eine Verbindung zwischen Graph und MCP oder wie? Ja, ich denke tatsächlich, ehrlich gesagt, nein, es gibt kein MCP für Graph, wenn man es so nennt. Wissen Sie, gibt es jetzt in der Microsoft 365 Welt viele von Microsoft eingeführte MCP-Server. Und diese MCP-Server basieren im Hintergrund auf Microsoft Graph.

Wenn Sie zum Beispiel, ich weiß nicht, den Teams, ähm, MCP-Server verwenden möchten, wird im Hintergrund die Graph API aufgerufen, wenn Sie den MCP-Server nutzen. Ähm, Graph API ist also in der Microsoft 365 Welt zentral, da der MCP im Hintergrund mit Graph kommuniziert, damit die Anfrage gut funktioniert.

Aber ja, heutzutage ist Graph auch in Copilot allgemein zentral, da der semantische Index von Copilot auf Rohdaten basiert. Aber eigentlich konsumiert man Graph über MCP-Server. Heutzutage ist das einfach so.

Microsoft 365 enthält einen unglaublichen Mehrwert organisatorische Kontexte, Dokumente, Besprechungen, E-Mails, Personen, Teams, Unterhaltungen und, wie ich sage, freigegebene Inhalte.

Wie legen wir diesen Kontext? Offen? Ohne ja. Einen Albtraum in Sachen Sicherheit zu schaffen? Sie meinen im Sinne von Governance und solchen Dingen? Ja, das ist immer ein Problem, weil viele Leute Agenten bauen, ohne im Hintergrund eine angemessene Governance zu etablieren. Also ich möchte einen Agenten bauen? Okay, legen wir los. Wir bauen und implementieren ihn und danach, ach, okay, dieser Agent wird mit einer Menge Daten arbeiten. Wie manage ich das? Die erste Frage ist, okay, wie setze ich die Governance für den Agenten um? Vorher könnte es, wie du schon sagtest, ein Chaos werden, denn viele Leute wollen, okay, ich will einen Agenten bauen, Agent, Agent, oder ich will etwas aufbauen, ich will eine KI-Lösung bauen. Aber im Hintergrund, wenn man zum Beispiel im Microsoft 365-Kontext arbeitet, ist eines der ersten Dinge, die man tun muss, okay, seine Daten zu verstehen. Denn ohne ein Verständnis der Daten ist man aufgeschmissen.

Man muss seine Daten verstehen, denn es ist wichtig zu wissen, okay, habe ich es mit vertraulichen Daten zu tun oder nicht? Habe ich es mit hochvertraulichen Daten zu tun? Okay, du musst deine Daten verstehen. Danach, wenn du in einem Microsoft-Umfeld bist, musst du zum Beispiel die LP-Funktion oder Sensitivitätslabeling und solche Dinge implementieren, denn ohne das könnte es ein Problem geben. Und danach musst du auch deine Daten ein wenig bereinigen, denn KI mit schlechten Daten, dein Agent wird nicht so arbeiten, wie du es willst. Denn wenn du ein Durcheinander in deinem, ich weiß nicht, SharePoint-Teamkanal oder Ähnlichem hast, wenn es ein Durcheinander ist, wird es im Grunde schwierig, korrekt zu arbeiten bei einem agentenbasierten Ansatz. Aber ja, du musst deine Daten verstehen, du musst einige grundlegende Sicherheitsmaßnahmen ergreifen, wie Authentifizierung, wie ich sagte, Purview-Funktionen und Purview ist zu einer zentralen Lösung geworden, um all diese Sicherheits- und Governance-Sachen umzusetzen.

Und nachdem sie ihre Daten bereinigt und grundlegende Sicherheitsmaßnahmen implementiert haben, müssen sie sich auch mit der Lizenzierung befassen, bevor sie mit der Entwicklung von Agenten beginnen, müssen sie verstehen, ob die Entwickler dafür geschult sind und ob wir die richtigen Lizenzen für den Start haben oder ob wir Abonnements benötigen.

Ein großes Problem ist die Tooling-Frage. Wie integriere ich alle Werkzeuge ordnungsgemäß in meine Entwicklung und meine Agenten? Muss ich etwas einschränken? Um ehrlich zu sein, ist das eine komplexe Frage mit vielen verschiedenen Aspekten, die man berücksichtigen muss. Aber für mich ist das Wichtigste, ihre Daten zu verstehen. Wenn ein Unternehmen seine Daten nicht versteht, wird das von Anfang an ein Problem sein. Und wenn wir wie, haben wir okay gefragt. Das Thema Sicherheit. Da gibt es glaube ich zwei Arten von Leuten. Die einen sagt, sie benötigen Benutzerberechtigungen und die anderen sagen, sie benötigen Anwendungsberechtigungen. Generell ist meine Empfehlung, wenn sie mit agentischen Lösungen arbeiten, immer delegierte Benutzerberechtigungen zu verwenden. Das ist aus Sicherheitssicht. Ehrlicherweise besser, da der Benutzer nur mit Daten und Tools arbeitet, auf die er auch Zugriff hat. Das ist das wichtigste Prinzip.

Wenn sie später Anwendungsberechtigungen für eine spezifische API oder einen bestimmten Kontext benötigen, können sie das tun. Aber verwenden sie diese nicht direkt. Nutzen sie sie im Kontext eines Wrappers.

Sie erstellen also, ich weiß nicht, vielleicht einen MCP-Server und integrieren diesen MCP-Server im Hintergrund mit Anwendungsberechtigungen. Wenn der MCP-Server ruft dann zum Beispiel ihre API im Hintergrund mit Anwendungsberechtigungen auf und liefert ihnen die benötigten Informationen, ohne dass der Benutzer direkt mit den Anwendungsberechtigungen in Berührung kommt. Wir rufen zum Beispiel den MCP-Server mit Benutzerberechtigungen auf und dieser Server ruft im Hintergrund Anwendungen oder Dienste mit dedizierten Anwendungsberechtigungen auf. E. Verstehen Sie den Unterschied?

Okay. Interessant. Ich denke, wenn wir über Architektur nachdenken, sollten wir auch etwas tiefer blicken. Ich glaube, es gibt drei große Themen in der Architektur. Wir haben die Retrieval Augmented Generation, wir haben das Thema Wissen und wir haben das, was ich die Backdoor-Unternehmen suche, nenne. Ähm, lass uns mit RAG beginnen. Wo passt RAG in die Architektur? Äh, A. A. A. G. Um ehrlich zu sein, ist RAG leistungstechnisch am wichtigsten, denn die KI muss verschiedene Arten von Daten verstehen. Und im Grunde ist RAG dazu da, eine Frage zu beantworten. Äh, denn früher, als wir kein RAG hatten, musste man sich im Grunde mit anderen Ansätzen befassen. Nicht unbedingt altmodisch, aber es war kompliziert. Aber RAG ist zentral, weil RAG verschiedene Arten von Daten versteht und man im Grunde die benötigten Informationen aus Dokumenten abruft, was viele verschiedene Datentypen sein können.

Äh, also ja, RAG ist heutzutage zentral in der KI-Architektur. Aber es stimmt, dass viele Nutzer nicht wissen, was RAG ist, wenn man hinter den Kulissen davon spricht, weil Microsoft oder viele andere Softwareunternehmen heutzutage nicht darüber reden, da hinter den Kulissen zwar RAG arbeitet, aber beispielsweise in Co-Pilot-Studio der Nutzer nicht versteht, dass es RAG ist. Man kann zwar tief in diese Konzepte eintauchen, aber für viele Nutzer ist RAG völlig unbekannt, weil sie nur das Tool verwenden, während dahinter diese Konzepte stehen. Und dann haben wir das nächste Thema, Wissen. Wie erhalten die KI-Systeme ihr Wissen? Sammle ich das selbst? Oder wie funktioniert das?

Eigentlich muss man ehrlich sein. Das Wissen könnte in vielen verschiedenen Systemen gehostet sein. Es könnte eine einfache Textdatei sein, eine Markdown-Datei in der Wissensdatenbank. Es könnte alles Mögliche sein. Aber tatsächlich, wenn man einen MCP-Server hat, kann man auf dieses Wissen zugreifen. Oder wenn man zum Beispiel Konnektoren zu SharePoint oder vielen anderen Diensten hat, dann ist der Zugriff auf Wissen heutzutage einfacher als früher. Seien wir ehrlich. Denn früher musste man seine eigenen Plugins bauen und alles selbst anbinden. Heutzutage haben sie direkte Konnektoren zu beliebigen Systemen und können ihr Wissen integrieren, ohne sich mit großem Entwicklungsaufwand herumschlagen zu müssen.

Ich denke, oft haben wir, ich weiß nicht, ich sammle das für meine, ich sage meinen, ich weiß nicht, meinen Leuten. Und wie versteht die KI, was keine fertigen Dokumente sind? Oder veraltet oder, ich weiß nicht, dupliziert.

Wie kann das ein KI-System verstehen? Was sollten wir wofür verwenden? Im Grunde nutzen sie RAG, weil sie hinter den Kulissen verstehen müssen, okay, was ihre Daten sind. Aber um ehrlich zu sein, wenn ich es ein wenig zusammenfasse, fangen sie mit dem Prompt an, okay? Der Benutzer möchte zum Beispiel eine Suche in einer Wissensdatenbank und zum Beispiel OneDrive durchführen. Hinter den Kulissen, wenn der Orchestrator mit Hilfe eines LM den Prompt und die Benutzerabsicht versteht, haben sie im Grunde den Index. Jetzt haben sie im Grunde den Index. Denn zum Beispiel haben sie in Co-Pilot den semantischen Index. Und dieser semantische Index gibt ihnen im Grunde zu verstehen, okay, ich habe all dieses Wissen. Und sie können mit einer semantischen Indexabfrage, kann die KI den semantischen Index direkt abfragen, um zum Beispiel RAG durchzuführen und sie können direkt, okay, die richtigen Dokumente basierend auf den Bedürfnissen auswählen.

Aber in Co-Pilot haben sie diesen semantischen Index und die KI kann diesen Index hinter den Kulissen direkt mit natürlicher Sprache abfragen. Ich werde also fragen, okay, ich möchte verstehen, ich weiß nicht, wie ich meinen Firmen VPN einrichte. Und hinter den Kulissen führen sie RAG auf dem semantischen Index durch und rufen im Grunde das Dokument ab, das zum Beispiel die gesamte Einrichtung des Firmen VPNs enthält. Zum Beispiel im Microsoft 365 Co-Pilot Chat, hinter den Kulissen ist es die Graph API, weil sie, wie ich bereits sagte, den semantischen Index auf der Graph API aufgebaut haben. Es ist hinter den Kulissen eine Graph-Funktion. Aber bei kundenspezifischen Entwicklungen haben sie zum Beispiel Foundry AI hinter den Kulissen. Es war ein Azure-Dienst mit einem anderen Namen. Aber jetzt können sie ihr eigenes RAG-System haben, wenn sie möchten. Und im Grunde können sie, wenn sie einen benutzerdefinierten Agenten haben, diesen direkt für eine Foundry IQ Instanz anfragen.

Ich möchte die Einrichtung meines VPN-Unternehmens abrufen. Und die KI kann abrufen, was sie an Dokumenten benötigen. Es könnten PDFs, Word, Excel oder ähnliche Dinge sein.

Und so funktioniert die Suche, oder?

Hinter den Kulissen, meinen Sie? Ah, hinter den Kulissen. Sie haben die Suche. Aber im Grunde haben sie heutzutage hinter den Kulissen von Copilot Chat drei Funktionen. Sie haben die Standardsuche. Das ist im Grunde eine Suche, bei der sie einfach ein paar Schlüsselwörter eingeben und sie durchsuchen ihre Dokumente und diese Art von Dingen. Das ist eine einfache Suche. Wir alle kennen die Stichwortsuche wie bei Google. Danach haben sie zwei verschiedene Funktionen. Sie haben zuerst RAG hinter den Kulissen. Sie haben die RAG-Funktion in Graph und sie haben auch die semantische Index-Suche von Copilot, die ein wenig anders ist, da RAG wirklich fortgeschrittener ist als die semantische Index-Suche von Copilot. Aber sie haben alle diese drei Funktionen hinter den Kulissen, damit ihre, äh, es sind nicht sie, aber hinter den Kulissen, kann die KI diese drei verschiedenen Funktionen aufrufen, um die Daten über OneDrive Teams M3565 im Allgemeinen abzurufen.

Er kann, der semantische Index von Copilot beinhaltet auch die Copilot-Konnektoren. Wenn sie also zum Beispiel Salesforce mit dem Copilot-Connector verbunden haben, kann er auch ihre gesamten Daten in Salesforce, in ServiceNow, in mehreren Tools durchsuchen. Und da alles, äh, mit dem Copilot-Connector, sie alle Daten in den Graph, äh, index, semantischen Index integriert haben, können sie ihre externen Systeme direkt abfragen, e.g. abfragen.

Und, ähm, ich denke, der, wenn wir Agenten bauen, haben wir den, äh, Governance-Teil und, ähm, ein Teil davon ist für mich auch, sage ich mal, das Agenten-Lebenszyklus-Management, ähm, ähm, wie sieht das eigentlich aus? Wie sieht das eigentlich aus? Äh, ehrlich gesagt ist das im Microsoft-Ökosystem ziemlich einfach, wenn ich das so sagen darf, äh, denn, wenn sie, wenn sie mit Low-Code arbeiten, zum Beispiel Copilot-Studio, haben sie es mit der Power-Plattform zu tun, Konzept-IM. Und, äh, daran hat sich nichts geändert. Sie haben also Lösungen, sie haben ALM vor Ort, sie haben Pipelines, äh, wenn man sich mit Copilot-Studio beschäftigt, ist es ehrlich gesagt wie vorher, weil man alles hat, worin man im Bereich Power-Plattform-Governance, Lebenszyklus und ALM investiert hat. Äh, es ist exakt dasselbe. Das ist eine gute Sache, denn viele Leute fragen mich, oh, Copilot-Studio, wie verwaltet man das?

Ist es anders? Nein, es ist genauso einfach wie das Application-Lifecycle-Management für Power-Apps oder Power-Automate. In diesem Fall ist es ein Agent-Lifecycle-Management, aber im Hintergrund gilt das gleiche Konzept wie bei der Power-Plattform.

Und wenn man es beispielsweise mit individueller Entwicklung zu tun hat, ist es im Grunde so, als würde man Anwendungen oder Doc-Net-Anwendungen bauen, weil man alles wie Code verwaltet.

Man hat also Frameworks, man hat Sicherheitsaspekte und solche Dinge. Ehrlich gesagt ist alles, was das Application- oder Agent-Lifecycle-Management betrifft, wirklich das gleiche Konzept wie vorher. Und das ist für mich ein guter Punkt, weil man nicht viel in Lebenszyklus-Prozesse oder ähnliches investieren muss.

Es gibt zwar einige Änderungen, aber eine der großen Änderungen ist, okay, man muss sich um LLM-Bereitstellung und solche Dinge kümmern. Aber im Hintergrund sieht es aus wie beim früheren DevOps-Ansatz mit Pipelines und dergleichen. Meiner Meinung nach hat sich also nichts geändert, weil wir Agenten verwalten, walten.

Könnte eine individuelle Entwicklung oder Co-Pilot sein, man nutzt heutzutage ehrlich gesagt den gleichen Ansatz wie vorher.

Und das bedeutet, wenn ein Unternehmen vorher keine KI eingesetzt hat, ist aber das perfekte Setup für Purview, Defender und all die anderen Tools. Muss da noch etwas geändert werden? Oder bedeutet das bereits KI-Bereitschaft?

Das ist eine große Frage, denn KI-Bereitschaft ist für Microsoft zwar in Ordnung. Berechtigungen schärfen und solche Dinge verwalten, aber KI-Bereitschaft ist für mich nicht nur ein technischer Ansatz, denn technisch gesehen wissen wir, was zu tun ist. Okay, wir müssen die Berechtigungen über viele Dienste hinweg verwalten. Wissen Sie? Für mich muss KI-Bereitschaft auch die Daten beinhalten. Die Daten, verstehen Sie? Ähm, wenn Sie. Weil, wenn man seine Daten nicht versteht, wie ich vorhin sagte, kann man nicht, man kann den technischen Teil nicht verwalten, weil, wenn man nicht weiß, was vertraulich ist oder nicht zum Beispiel, ist es schwierig, einige Sicherheitsvorkehrungen zu treffen.

Aber wenn wir Microsoft folgen, ist KI-Bereitschaft. Okay, man muss Berechtigungen verwalten, man möchte Vertraulichkeitsbezeichnungen einführen, man muss GLP umsetzen, diese Art von Dingen.

Aber es gibt auch einen übergeordneten Aspekt und für mich ist KI-Bereitschaft nicht nur technisch, man muss heutzutage ehrlich gesagt auch einen funktionalen oder übergeordneten Aspekt berücksichtigen.

Äh, ja, das ist wirklich interessant.

Ich denke, viele Unternehmen, bei denen das mit der KI angefangen hat, sagen jetzt mit den Agenten, Oh, sie hat alle meine, ich weiß nicht, E-Mails gelöscht oder irgendwelche bösen, bösen Dinge getan.

Was denken Sie, warum sagen Unternehmen, dass sie Angst vor KI haben? Ah, das ist eine gute Frage, denn ich lebe in der Schweiz und im Grunde haben wir, wir haben viele Privatbanken und wir haben viele, um ehrlich zu sein, wirklich sensible Kunden und im Grunde ist der der kritischste Teil. Okay, wo werden die Daten verarbeitet? Grundsätzlich. Und, ja, auch okay, durchsucht die KI meine E-Mails. Diese Art von Dingen. Also hinter, hinter den Kulissen fragen Sie das immer. Aber wissen Sie, der kritischste Teil für Sie ist, okay, ich muss verstehen, okay, wo werden die Daten verarbeitet? Und, äh, und auch, okay, äh, ich bin der, der, der, der, äh, Eigentümer der KI. Also ich, ich gebe der KI die Anweisung und die KI erledigt im Hintergrund die Arbeit und Sie haben zum Beispiel Angst vor dem autonomen, äh, Aspekt, weil man heutzutage, okay, das tun kann und hinter den Kulissen sucht die KI nach etwas, äh, fragt, äh, etwas im Hintergrund ab.

Und Sie haben Angst, okay, äh, wenn ich die bitte etwas zu tun, was wird da im Hintergrund ausgeführt? Und, äh, ja, es gibt viele Fragen dieser Art, okay. Wie benehme ich die Kontrolle über den gesamten Prozess hinter einer Sache, sei es ein KI-Agent oder ein KI-Dienst? Ja, es gibt solche Fragen, aber es ist wirklich eine Frage der Akzeptanz und auch der Schulung, um Schulungen anzubieten, okay, wie man KI versteht, wie man versteht, was genau hinter den Kulissen passiert.

Und Transparenz ist auch ein wichtiger Punkt, denn Transparenz muss bei jeder KI-Lösung umgesetzt werden, da Transparenz für mich ein großes Thema ist, weil man alles implementieren muss. Denn die KI-Lösung muss transparent sein.

Man muss verstehen, was hinter den Kulissen passiert, welche Daten abgefragt werden, man muss nachverfolgen und alles protokollieren können. Alles muss heute transparent sein, wenn man eine Lösung hat. Denn man muss genau verstehen, was im Hintergrund abläuft, welche Daten verarbeitet werden und was die Überlegungen dahinter sind. Wie haben Sie diesen Plan erstellt, auf welchen Fakten basierend und dergleichen dergleichen? Großartig. Oh, ich sehe, wir laufen ein wenig aus der Zeit. Entschuldigung. Wissen Sie, das war wirklich fantastisch, aber ich habe in jedem Podcast eine Schnellfragerunde. Also, ich gebe einen kurzen Satz vor und Sie geben eine kurze Antwort. Also, sind Sie bereit?

Co-Pilot Studio oder benutzerdefinierter Code? Co-Pilot Studio. Microsoft Foundry oder Co-Pilot Studio? Co-Pilot Studio. Typescript oder C-ShirtScript?

GitHub oder Azure DevOps? GitHub. RAG oder Feintuning?

Alles klar. Was ist die am meisten unterschätzte Microsoft 365 API? Zinn.

Ragapi.

Eine Technologie, die jeder Microsoft-Entwickler 2026 lernen sollte.

GitHub Co-Pilot.

Wenn Satya Nadella zu Ihnen kommt und sagt, Sie bekommen alles Geld und alle Ressourcen, die Sie wollen, um unsere KI-Plattform zu verbessern, Sie können eine Funktion entwickeln. Welche wäre das? All die Governance-Sachen, die wir brauchen.

Und um? Wen soll ich als nächstes in den Podcast einladen und welche Frage soll ich stellen?

Oh, gute Frage. Ich habe viele Freunde. Aber, äh, ja, vielleicht können Sie meine Co-Speakerin von vielen Konferenzen fragen. Sie könnten zum Beispiel Chloe Moro fragen. Sie war früher funktionale Beraterin, bevor sie jetzt zur technischen Seite gewechselt ist.

Und sie hat eine wirklich gute Geschichte über funktionale, weniger technische Dinge in der Dynamics-Welt. Vielleicht kannst du sie ja einladen und sie fragen, Sag mal, wie geht man heutzutage eigentlich mit dem Spagat zwischen funktionaler und technischer Arbeit um? Denn da gibt es ja einige sehr große Herausforderungen.

Und meine abschließende Frage ist, was sollten die Leute, wenn sie eine einzige Erkenntnis aus dieser Sitzung mitnehmen können, was sollten sie aus dieser Sitzung mitnehmen? So meinst du.

Im Grunde entwickelt sich KI schnell weiter.

Und wenn man heute auf dem Laufenden bleiben will, muss man alles verfolgen. Denn ehrlich gesagt durchzieht KI heutzutage wirklich den gesamten Microsoft-Stack.

Und heutzutage ist eine der Dinge, die man verstehen muss, dass die Entwicklung rasant ist. Und man muss wirklich, wirklich jederzeit auf dem neuesten Stand sein. Denn man wird irgendwann etwas verpassen, wenn man nicht lernt. Wenn man die Entwicklung in dieser Art nicht versteht.

Ja, also danke, dass du bei mir warst. Ich denke, die wichtige Erkenntnis aus unserem Gespräch ist, dass es bei der Erweiterbarkeit von Microsoft 365 Co-Pilot nicht einfach nur darum geht, immer ausgefeiltere Prompts zu schreiben. Ich denke, wir bewegen uns aber eine Architektur zu, bei der Co-Pilot und Agenten eine Verbindung zu Unternehmenswissen, Microsoft Graph, Geschäftsanwendungen, APIs und so weiter herstellen können.

Um, ja, ich denke Co-Pilot Studio, Microsoft Foundry, individuelle Entwicklungen und Technologien wie MCP geben Entwicklern einen, ja, einen erstaunlich mächtigen Werkzeugkasten an die Hand. Und, ja, aber je fähiger die Agenten werden, desto wichtiger werden auch die Grundlagen Identität, Berechtigungen, Sicherheit, Governance, Tests, Beobachtbarkeit, Anwendungslebenszyklusmanagement und so weiter. Also, ja, ich denke, du hast einen wirklich, wirklich guten Überblick über all diese Themen gegeben. Also, danke, dass du bei mir warst und für die Zuhörer alle Informationen dazu findet ihr in den Shownotes auf der M365FM-Podcast-Seite und, ja, wo ihr euch vernetzen und die Arbeit von EES sehen könnt. Und, ja, danke, dass du hier warst. Danke, dass ich hier sein durfte. Es war eine wirklich gute Zeit mit dir.