Microsoft 365 kombiniert native Copilot-Funktionen, integrierte Agenten und Erweiterungen über Agenten, Connectoren und APIs. Diese Vielfalt verführt zum Sprung vom ersten enttäuschenden Versuch direkt in eine Spezialentwicklung.

Ein eigener Agent kann eine echte Lücke schließen. Er erzeugt zugleich Anweisungen, Berechtigungen, Evaluation, Deployment, Support und Stilllegung. Deshalb wird die Architektur stufenweise und anhand realer Aufgaben gewählt.

Die fünfstufige Entscheidungsleiter

Stufe 1 ist die aktuelle native Funktion. Sie wird mit realen Aufgaben geprüft und nicht aufgrund einer alten Demo verworfen. Integration, Oberfläche und Betriebsaufwand sind häufig hier am günstigsten.

Stufe 2 verbessert Konfiguration und Prozess: Quellenqualität, Rechte, Vorlagen, Nutzerpraxis und Einstellungen. Viele vermeintliche KI-Lücken sind Informations- oder Prozessprobleme.

Stufe 3 ergänzt eine leichte Erweiterung, etwa Connector, deklarative Anweisung, Skill oder begrenzte Aktion. Die native Oberfläche bleibt bestehen, während eine stabile Einzelfähigkeit ergänzt wird.

Stufe 4 ist ein Spezialagent mit eigenem Ziel, kuratiertem Wissen, Werkzeugen, Routing, Evaluation und Eigentümer. Er braucht eine klare Service-Grenze und darf nicht nur “besserer Copilot” heißen.

Stufe 5 ist Anwendung oder individuelles System. Sie passt zu persistenten Datensätzen, strukturierten Oberflächen, komplexen Transaktionen und deterministischen Kontrollen. Ein Agent kann Teil davon sein, ohne System of Record zu werden.

Der Wechsel zur nächsten Stufe erfolgt nur, wenn die vorherige ein dokumentiertes Abnahmekriterium verfehlt.

Den Spezialisierungsaufschlag berechnen

Zum Aufschlag gehören Entwicklung, Integration, Lizenz und Verbrauch, Datenpflege, Security Review, Regressionsevaluation, Monitoring, Support, Adoption und spätere Migration oder Stilllegung. Verglichen wird nicht nur Lizenzpreis gegen Projektkosten, sondern Kosten je akzeptiertem Geschäftsergebnis über die Nutzungsdauer.

Datiertes Beispiel: Projektplanung

Ein Project Office möchte Arbeitspläne erzeugen, Terminrisiken erkennen, Statusberichte formulieren und Aktionen in Fremdsystemen anlegen. Microsoft listet aktuell Copilot in Planner und Planner Agent, doch Funktions- und Lizenzgrenzen können sich ändern.

Zwanzig repräsentative Projekte werden zuerst nativ getestet. Arbeitsstruktur und einfache Updates funktionieren ausreichend. Die organisationseigene Stage-Gate-Taxonomie wird jedoch nicht konsistent angewendet, und aktuelles Lieferantenrisiko aus Procurement fehlt.

Das Team baut Planner nicht nach. Es standardisiert zunächst Vorlage und Taxonomie und testet dann eine leichte Erweiterung für die Risikodaten. Schließt sie die Lücke, bleibt Planner die Arbeitsoberfläche.

Erst wenn systemübergreifende Ausnahmen, spezielles Stage-Gate-Reasoning und ein eigenes Evaluationsset erforderlich sind, verdient ein Projekt-Assurance-Agent die zusätzliche Komplexität. Planner bleibt führendes System; große Terminänderungen benötigen menschliche Freigabe. Die Entscheidung wird datiert, weil eine spätere native Funktion die Lücke schließen kann.

Einen fairen Vergleich durchführen

Vor der Architekturwahl entsteht ein Aufgabenset aus Normalfällen, schwierigen Fällen, Rollenunterschieden und Fehlerbedingungen. Je Stufe werden akzeptierte Ergebnisse, Korrekturaufwand, Durchlaufzeit, Nutzerfriktion, Betriebskosten und Kontrolllücken gemessen.

Ein polierter Custom-Prototyp darf nicht gegen ein unkonfiguriertes natives Produkt antreten. Quellen, Nutzeranleitung und Erfolgsdefinition müssen vergleichbar sein. Die Restlücke wird als Produktgrenze, Datenproblem, Prozessunklarheit oder Adoptionsthema klassifiziert.

Stop-Bedingungen erkennen

Native Nutzung ist richtig, wenn Restkorrekturen gering sind, der Prozess nicht differenziert oder die Produktentwicklung die Lücke voraussichtlich schließt. Konfiguration passt bei schlechten Quellen und unklarer Arbeit. Ein Spezialagent lohnt sich bei variablen Fällen, mehreren Werkzeugen und belastbarem Eigentum.

Nicht gebaut wird ohne stabilen Owner, ausreichendes Volumen, begrenzbare Rechte oder messbaren Erfolg. Anpassung ohne Evaluation erzeugt dauerhafte Exploration.

Konvergenz einplanen

Native Produkte entwickeln sich weiter. Eigene Komponenten bleiben modular und dokumentieren ihren Existenzgrund. Mindestens jährlich werden sie gegen die aktuelle Plattform geprüft. Erfüllt eine native Funktion später die Kriterien, werden doppelte Wissensquellen, Werkzeuge und Einstiege konsequent stillgelegt.

Amplified Pi nutzt die Leiter, um die kleinste tragfähige Architektur zu finden. Spezialisierung ist nur dann eine Investition, wenn ihr betrieblicher Wert die dauerhafte Eigentumspflicht übersteigt.