Microsoft Build 2025: das Jahr des Agenten, der GitHub Copilot Coding Agent und das offene agentische Web

22. Mai 2025

  • Startseite
  • Blog
  • Microsoft Build 2025: das Jahr des Agenten, der GitHub Copilot Coding Agent und das offene agentische Web
Microsoft Build 2025: das Jahr des Agenten, der GitHub Copilot Coding Agent und das offene agentische Web

19.–22. Mai 2025, Seattle (hybrid, vier Tage). Build 2025 war die erste Ausgabe, die Microsoft auf vier volle Tage ausdehnte, und das Framing war griffig genug für einen T-Shirt-Aufdruck: 2024 war das Jahr des Assistenten; 2025 ist das Jahr des Agenten. Wir schicken seit 2012 jedes Jahr jemanden zur Build, und das war die Ausgabe, in der das Wort „Agent" aufhörte, ein Demo auf der Bühne zu sein, und anfing, eine Plattform zu sein – mit der unglamourösen Sanitärtechnik darunter, die eine „Plattform" tatsächlich verlangt.

Skyline von Seattle mit der Space Needle, Austragungsort der Microsoft Build 2025

Ein Jahr zuvor drehte sich jedes Flurgespräch darum, was ein Copilot vorschlagen konnte. 2025 verschob sich das Gespräch dahin, was ein Agent in deinem Auftrag tun konnte – einen Pull Request öffnen, die Tests laufen lassen, eine API aufrufen, über deine Daten hinweg handeln – und, ebenso wichtig, wie man das alles unter Kontrolle behält. Microsoft baute das ganze Event rund um „das Zeitalter der KI-Agenten und den Aufbau des offenen agentischen Web" und lieferte über fünfzig Ankündigungen, um den Slogan zu untermauern. Im Folgenden steht, was wir tatsächlich mitgenommen haben, warum es für einen Microsoft-Stack-Laden wie unseren zählte und die eine Ankündigung, von der wir glauben, dass sie alle anderen überdauern wird.

„Das Jahr des Agenten" war nicht nur ein Slogan

Satya Nadella eröffnete, indem er 2025 fest auf eine Zeitachse stellte, die vom frühen Web bis zu autonomer Software reicht:

"The current shift is building out the open agentic web at scale in 2025. The industry is moving from few apps with vertically integrated stacks to an open, scalable, agentic web platform." — Satya Nadella, Build 2025 Keynote.

Die Wendung, die hängen blieb – und um die Microsoft die ganze Konferenz baute –, war das offene agentische Web: eine Welt, in der Agenten nicht nur innerhalb der App eines Anbieters leben, sondern einander entdecken, einander aufrufen und über das Web hinweg auf einem gemeinsamen Satz offener Protokolle handeln. Das Wort offen leistet hier eine Menge Arbeit, und es ist der Grund, warum eine Firma unserer Größe aufmerksam wird. Ein agentisches Web, das einer einzigen Cloud gehört, ist ein Burggraben. Ein agentisches Web auf Protokollen, die jeder implementieren kann, ist Infrastruktur – und auf Infrastruktur lässt sich ein Geschäft bauen, ohne alles auf eine einzelne Roadmap zu setzen.

Die skeptische Lesart ist berechtigt: „Das Jahr des Agenten" ist genau die Art Zeile, die eine Keynote planmäßig produziert. Wir haben genug davon gesehen, um das Genre zu erkennen. Was 2025 aber vom Assistenten-Hype des Vorjahres unterschied: Die Protokolle und das Produktions-Tooling wurden zeitgleich mit dem Slogan ausgeliefert, nicht ein halbes Jahr später. Man konnte aus der Keynote gehen und in derselben Woche anfangen, Agenten zu verdrahten – und genau das taten wir. Das ist der Test, den wir an jede Build anlegen: nicht, wie gut das Demo aussah, sondern ob es ein echtes dotnet add package oder einen echten Endpunkt gab, als das Licht anging. 2025 gab es das.

Es gibt auch eine leisere Verschiebung, die man benennen sollte. 2024 brachten Entwickler zur Build die Fragen mit kann das überhaupt Code schreiben, und taugt er etwas? Bis 2025 waren die bejaht, und die neuen Fragen waren härter und erwachsener: Wie lasse ich einen Agenten auf meinen Systemen handeln, ohne ihm die Schlüssel zu geben; wie auditiere ich, was er getan hat; wie behalte ich einen Menschen bei den Entscheidungen, die zählen? Die ganze Konferenz war, wohlwollend gelesen, Microsofts Antwort auf diesen zweiten Satz Fragen. Das ist eine interessantere Konferenz als eine Parade von Fähigkeiten, und es ist die, auf die wir gewartet hatten.

Der GitHub Copilot Coding Agent wurde erwachsen

Die Schlagzeile für Entwickler war der GitHub Copilot Coding Agent – ein asynchroner, autonomer Coding-Agent, direkt in die GitHub-Plattform eingebettet und aus VS Code erreichbar, verfügbar am Tag der Keynote. Microsofts eigenes Framing war, dass Copilot sich „von einem In-Editor-Assistenten zu einem agentischen KI-Partner mit einem einzigartigen, in die GitHub-Plattform integrierten asynchronen Coding-Agenten" entwickle. GitHub stellte in derselben Woche außerdem Copilot Chat in VS Code unter Open Source – eine eigene kleine Absichtserklärung darüber, wo der Wert liegen soll.

In der Praxis heißt das: Man übergibt dem Agenten ein GitHub-Issue, und er macht sich an die Arbeit: Er klont das Repo in eine sichere Umgebung, analysiert die gesamte Codebasis, nimmt datei-übergreifende Änderungen vor, generiert und führt Tests aus, fixt Bugs, schlägt Terminal-Befehle vor und kommt mit einem Draft-Pull-Request zurück – samt Session-Log, damit man genau sieht, was er getan hat und warum. Das „Asynchrone" ist der wirklich neue Teil, und man unterschätzt ihn leicht. Der 2024er-Copilot saß im Editor und wartete auf einen; er war eine schnellere Art zu tippen. Der 2025er-Coding-Agent läuft, während man etwas anderes tut, und meldet sich, wenn ein PR zur Prüfung bereitliegt. Das ist eine ganz andere Beziehung zum Werkzeug – weniger „Autocomplete auf Steroiden", mehr „eine Nachwuchskraft, der man ein Ticket delegiert und bei der man später nachschaut".

Code in einem Editor auf einem Entwicklerbildschirm

Wir wollen ehrlich sagen, wie wir das lesen, denn die Lücke zwischen einem guten Demo und etwas, das wir in das Repo eines Kunden legen, ist genau der Ort, an dem unsere Arbeit stattfindet. Das Muster ist echt und nützlich, und wir haben seither eigene Varianten davon übernommen. Aber das tragende Wort ist Draft. Ein Agent, der einen PR öffnet, den man weiterhin prüft, freigibt und mergt, ist ein Kraftverstärker; ein Agent, der sich selbst mergt, ist ein Risiko in der Art von Systemen, die wir bauen, wo ein Bug keine CSS-Regression ist, sondern ein verpasster Export, eine fehlgeschlagene Zahlung oder ein Compliance-Befund, der drei Monate später in einem Audit auftaucht. Das 2025er-Design traf diese Balance richtig: Der Mensch bleibt am Merge-Button, das Session-Log macht das Vorgehen des Agenten nachvollziehbar, und die Arbeit landet im selben Review-Prozess wie jede andere Änderung. Genau dieser Satz Entscheidungen ist der Grund, warum wir dem Ganzen genug vertraut haben, um es überhaupt in unseren Workflow zu übernehmen – nicht, weil das Demo beeindruckend war, sondern weil die Leitplanken ebenso die Schlagzeile waren wie die Fähigkeit.

Es fügt sich auch sauber in unser Denken über Delegation im Unternehmen. Die gute Variante eines Agenten ist nicht die, die am meisten tut, sondern die, die ehrlich darüber ist, was sie getan hat, und den unumkehrbaren Schritt einem Menschen überlässt. Build 2025 war das erste Jahr, in dem die Plattform uns darin wirklich recht gab.

Copilot Agent Mode überall – und Multi-Model mit Absicht

Neben dem Coding-Agenten brachte Microsoft den Copilot Agent Mode über die Editoren, die Entwickler tatsächlich nutzen – Visual Studio, VS Code, JetBrains, Eclipse und Xcode – statt das Gute auf eine einzige hauseigene IDE zu beschränken. Für ein Unternehmen, das jeden kommerziellen Anreiz hat, seinen eigenen Editor zum einzigen Ort der Magie zu machen, ist das Ausliefern des Agent Mode nach JetBrains und Xcode ein bemerkenswerter Akt der Zurückhaltung.

Das Detail, das uns am meisten interessierte, war Multi-Model-Support als First-Class-Option: Modelle von Anthropic, Google und OpenAI, auswählbar innerhalb derselben Agent-Erfahrung. Dass ein Anbieter, der eine der größten Modell-Partnerschaften der Branche besitzt, eine Eingangstür ausliefert, an der man das Modell eines Konkurrenten wählen kann, ist ein bedeutsames Signal. Es sagt einem, dass Microsoft entschieden hatte, der dauerhafte Wert liege in der Agenten-Plattform und dem Tooling drumherum, nicht in der Bindung an ein einzelnes Modell – und genau diese Haltung schützt unsere Kunden davor, ihre Plattform auf die Roadmap eines einzelnen Labors zu setzen. Modelle werden sich auf den Benchmarks weiter gegenseitig überholen; das Team, das auf Austauschbarkeit ausgelegt hat, altert deutlich besser als das Team, das eines fest verdrahtet hat.

Das ist die Art Entscheidung, die kein spektakuläres Demo ergibt, aber jahrelange Kundenarbeit leise entrisikt. Wenn ein Kunde uns fragt „Was passiert, wenn das Modell, auf das wir uns standardisieren, zurückfällt, oder sein Preis sich ändert, oder seine Bedingungen?", lautete die ehrliche Antwort ab 2025: „Du änderst ein Dropdown." Das ist einem Mittelstandskunden, der eine Fünf-Jahres-Plattform plant, mehr wert als ein einzelnes Modell, das ein paar Punkte höher auf einem Leaderboard liegt.

Azure AI Foundry: Modelle als Utility, inklusive Grok 3

Azure AI Foundry setzte seinen Marsch fort, Microsofts vereinheitlichte KI-App- und Agenten-Fabrik zu werden, und 2025 war das Jahr, in dem der Katalog ins „Modell-als-Utility"-Gebiet überging. Microsoft bezifferte den Katalog auf „mehr als 1.900 partner- und Microsoft-gehostete KI-Modelle", aufbauend auf mehr als 10.000 Open-Source-Modellen von Hugging Face, mit Metas Modellen ebenfalls im Mix. Bei dieser Größenordnung hört man auf, über „welches Modell" so nachzudenken wie über „welche Datenbank-Engine", und beginnt, darüber nachzudenken wie über Strom – eine Utility, die man anzapft, steuert und abrechnet, keine Beziehung, die man jedes Mal neu verhandelt.

Die augenfällige Ergänzung war Grok 3 und Grok 3 Mini von xAI, und das wichtige Wort in Microsofts eigener Beschreibung war abgerechnet:

"With Azure AI Foundry Models, we're bringing Grok 3 and Grok 3 mini models from xAI to our ecosystem, hosted and billed directly by Microsoft."

Von Microsoft gehostet und abgerechnet heißt, ein Unternehmen kann ein Frontier-Modell eines Drittanbieters unter Azures Verträgen, Governance und einer einzigen Rechnung nutzen – keine separate Anbieterbeziehung, keine separate Vertrauensbewertung, keine zweite Beschaffungsschlacht. Das klingt kleiner als „ein neues Modell", aber es ist das Feature, das tatsächlich verschiebt, was ein deutscher Mittelstandskunde einsetzen darf. Der Adoptionsblocker ist in unserer Welt selten die Qualität des Modells; es sind die rechtliche, Datenresidenz- und Beschaffungsprüfung, die ein neuer externer Anbieter auslöst. Das Modell unter die Azure-Beziehung zu falten, die der Kunde ohnehin schon hat, lässt den schweren Teil verschwinden.

Die andere Foundry-Neuigkeit, die direkt in unsere Arbeit fällt, war die allgemeine Verfügbarkeit des Azure AI Foundry Agent Service, der Semantic Kernel und AutoGen in ein einziges, entwicklerorientiertes SDK zusammenführte und Agent-to-Agent (A2A)- sowie Model-Context-Protocol-Unterstützung für die Orchestrierung mehrerer spezialisierter Agenten bei einer komplexen Aufgabe ergänzte. Die Konsolidierung „aus zwei Frameworks wird ein unterstütztes SDK" zählt mehr, als sie klingt. Wir hatten Teams beobachtet, die über Semantic Kernel versus AutoGen grübelten, wie man früher über Framework-Entscheidungen grübelte, die sich als Einbahnstraßen entpuppten. Beide in ein einziges unterstütztes SDK zu kollabieren, ist der Unterschied zwischen einem Experiment, das wir zögernd empfehlen würden, und etwas, für das wir in Produktion mit unserem Namen einstehen.

NLWeb: „HTML für das agentische Web"

Die leiseste, aber ambitionierteste Ankündigung war NLWeb, ein Open-Source-Projekt, um jeder Website mit sehr wenig Code eine natürlichsprachliche KI-Schnittstelle hinzuzufügen. Microsofts Pitch war bewusst groß: Es stellte NLWeb als etwas vor, von dem es glaubt, dass es „eine ähnliche Rolle wie HTML für das agentische Web spielen kann".

Die Analogie ist der ganze Punkt, und sie lohnt sich auszupacken, statt vorbeizuwinken. HTML löste das Publizieren – wie man Inhalte in einer Form ins Web stellt, die alles rendern kann. NLWeb versucht das nächste Problem zu lösen: wie Menschen und Agenten diese Inhalte abfragen, sobald sie da sind. Es liest Formate, die bereits im Umlauf sind – Schema.org, RSS –, und legt eine natürlichsprachliche Schnittstelle darüber, mit einem Modell der Wahl des Entwicklers; man beschreibt seinen Katalog also nicht in einer neuen proprietären Form neu, sondern legt offen, was man ohnehin schon publiziert hat. Und das Detail, das es für uns einrasten ließ: Jeder NLWeb-Endpunkt läuft zugleich als Model-Context-Protocol-Server. Legt man seine Inhalte über NLWeb offen, hat man sie zugleich für jeden MCP-fähigen Agenten aufrufbar gemacht – das Konversations-Widget für Menschen und die Maschinenschnittstelle für Agenten sind derselbe Endpunkt.

Wir behalten unsere Skepsis auf dem Tisch, denn die Vergleichung leistet eine Menge Marketingarbeit. Ob NLWeb tatsächlich das HTML dieser Ära wird, ist heute nicht wissbar; die meisten Projekte, die sich selbst zum „HTML von X" taufen, sind binnen zwei Jahren vergessen. Aber es direkt auf MCP statt auf ein eigenes Protokoll zu bauen, ist der Zug, der ihm eine echte Chance gibt, denn er bedeutet, dass NLWeb nicht allein gewinnen muss – es reitet auf dem Schwung, den MCP hat. Auf die Sanitärtechnik statt auf die Marke zu setzen, ist meist die kluge Wette, und es ist der Teil von NLWeb, den wir heute tatsächlich für einen Kunden verdrahten würden.

Abstraktes Netzwerk verbundener Knoten als Sinnbild eines offenen Web aus Agenten

Das Model Context Protocol wurde zum Standard unter allem

Wenn wir eine einzige Sache von Build 2025 behalten müssten, dann diese. Das Model Context Protocol (MCP) wurde von einer interessanten, von Anthropic stammenden Spezifikation zum Bindegewebe, auf das Microsoft sich über seinen gesamten Stack festlegte. Microsoft kündigte breite First-Party-MCP-Unterstützung an, die GitHub, Copilot Studio, Dynamics 365, Azure AI Foundry, Semantic Kernel und Windows 11 umspannt – und Windows wurde ein First-Class-MCP-Host, mit eingebauten MCP-Servern, die Kernsystemfunktionen wie Dateisystemzugriff, Fensterverwaltung und die Integration mit dem Windows Subsystem für Linux offenlegen, sodass Agenten native OS-Fähigkeiten über dasselbe Protokoll aufrufen können, das sie für alles andere nutzen.

Dann kam das Governance-Signal, das einen vielversprechenden Standard zu einer sicheren Wette macht: Microsoft und GitHub traten dem MCP Steering Committee bei, um die sichere Adoption des Protokolls im großen Maßstab voranzutreiben, und steuerten eine aktualisierte Autorisierungsspezifikation sowie das Design eines MCP-Server-Registry-Dienstes bei. Gerade dieses letzte Detail zählt mehr, als es sich liest. Ein Protokoll, das eine Firma kontrolliert, ist ein Produkt; ein Protokoll, das von einem Komitee mit mehreren großen Akteuren getragen wird – und mit einer ernsthaften Antwort auf Autorisierung, genau dort, wo ein naives Agentenprotokoll gefährlich wird –, ist Infrastruktur, um die herum man jahrelang planen kann. Besonders die Autorisierungsarbeit ist das, was uns erlaubt, MCP mit ruhigem Gewissen in eine regulierte Kundenumgebung zu bringen.

Abgerundet wird die On-Device-Geschichte durch Windows AI Foundry, das als vereinheitlichte Plattform für den KI-Entwicklungslebenszyklus auf Windows ankam – Training und Inferenz –, sodass dieselben agentischen Ambitionen auch für Apps gelten, die lokal laufen statt nur in der Cloud. Für Kunden, die nicht alles an einen Cloud-Endpunkt schicken können oder wollen, ist dieser lokale Pfad kein Nice-to-have, sondern der Unterschied zwischen einem möglichen und einem unmöglichen Projekt.

Warum es für uns zählte

Schält man das Keynote-Theater weg, war Build 2025 fast maßgeschneidert für einen Laden wie ThreeBIT:

  • Dass MCP ein echter, governter Standard wurde, ist das Einzelhilfreichste für unsere Kundenarbeit. Bis 2025 war jede Agent-Integration ein Einzelfall, und Einzelfälle sind genau die Art Sache, die in einem Wartungsvertrag leise vor sich hin rottet. Jetzt können wir Microsoft 365 Copilot, GitHub Copilot und unsere eigenen Kunden-Agenten über dasselbe Protokoll mit demselben Auth-Modell verdrahten. Das kollabiert eine ganze Kategorie maßgeschneiderten Glue-Codes – des teuersten Codes überhaupt, weil sich zwei Jahre später niemand mehr erinnert, wie er funktioniert.
  • Der Coding-Agent ist gerade deshalb ein Kraftverstärker, weil der Mensch den Merge-Button behält. Wir haben das Muster „Agent öffnet einen Draft-PR, ein Mensch prüft und mergt" übernommen, weil es Tempo bringt, ohne Kontrolle wegzunehmen. In unseren Branchen ist diese Reihenfolge nicht verhandelbar, und Build 2025 war das Jahr, in dem die Plattform sie als Standard auslieferte, statt dass wir sie selbst anbauen mussten.
  • Modell-Optionalität schützt unsere Kunden. Multi-Model-Agent-Mode, ein Foundry-Katalog in Tausenden gemessen und Drittanbieter-Frontier-Modelle wie Grok 3, über Azure abgerechnet, bedeuten, dass wir die Plattform eines Kunden nie auf die Roadmap eines einzelnen Anbieters setzen müssen. Das ist derselbe Grund, aus dem uns die offenen, von einer Foundation getragenen Teile der .NET-Welt immer gefallen haben.
  • NLWeb und Windows AI Foundry runden das Bild an beiden Enden ab – das öffentliche, agentenlesbare Web am einen, vollständig lokale On-Device-Agenten am anderen Ende –, beide sprechen dasselbe Protokoll wie alles dazwischen.

Nichts davon änderte unseren Leitstern: Dinge ausliefern, die beim ersten Mal funktionieren müssen, für Branchen, in denen ein Fehler nicht kosmetisch ist. Build 2025 gab uns nur ein Standardprotokoll, ein vertrauenswürdiges Agentenmuster und einen Modellmarktplatz, um es zu tun. Wir verließen Seattle mit einer Wette auf die These vom offenen agentischen Web. Ein Jahr später, mit allem, was danach kam, halten wir sie weiter.

Die Zeile „Jahr des Assistenten / Jahr des Agenten" ist ein weit verbreitetes Framing der Keynote, kein einzelnes wörtliches Nadella-Zitat; die oben direkt zitierten Sätze sind so wiedergegeben, wie Microsoft und Satya Nadella sie formuliert haben. Englische Originalzitate sind bewusst auf Englisch belassen.

Bildnachweise

Alle Fotos werden unter ihren jeweiligen Creative-Commons-Lizenzen verwendet; wir danken den Fotografen.

  • Seattle Skyline — © Maëlick, CC BY-SA 2.0, via Flickr (source).
  • PROJECT BOOT Dev Mode codes Preview — © Deliveramable, CC BY-SA 4.0, via Wikimedia Commons (source).
  • 20101210-NodeXL-Twitter-pdfleaks — © Marc_Smith, CC BY 2.0, via Flickr (source).
Microsoft Build KI-Agenten GitHub Copilot Azure AI Foundry MCP NLWeb Windows AI Foundry .NET
ZUM BLOG