Der GitHub Copilot Harness in Microsoft Copilot Studio ist für anspruchsvolle, mehrstufige Aufgaben ausgelegt. Er kann ein Ziel in Schritte zerlegen, mit Dateien und Werkzeugen arbeiten und bei einem Fehler einen anderen Weg wählen. Für Prozesse mit variablen Fällen ist das ein erheblicher Fortschritt.

Diese Flexibilität besitzt jedoch eine andere Kostenlogik als ein fester Ablauf. Laut Microsofts Dokumentation zur verbrauchsbasierten Abrechnung können Modell-Tokens, Werkzeuge, Wissen, MCP-Verbindungen und der Harness selbst in den Verbrauch eingehen. Kosten entstehen bereits beim Erstellen, in Vorschauen, Tests und Evaluationen. Die Administrationsdokumentation stellt klar, dass eine Microsoft-365-Copilot-Lizenz die Nutzung dieses Harness nicht abdeckt.

Das zentrale Risiko ist deshalb nicht nur ein hoher Tokenverbrauch. Es ist die falsche Bezugsgröße. Nutzerzahl und sichtbare Anfragen erklären nicht, wie viel Arbeit der Agent tatsächlich ausführt. Steuerbar wird die Wirtschaftlichkeit erst pro erfolgreich abgeschlossenem Geschäftsergebnis.

Zuerst die Harness-Wahl prüfen

Der GitHub Copilot Harness passt, wenn ein Prozess adaptive Planung, Dateibearbeitung, mehrere Werkzeuge oder Erholung von wechselnden Fehlern benötigt. Dazu können komplexe Fallakten, Dokumentenabgleiche mit Ausnahmebehandlung oder mehrstufige Onboarding-Pakete gehören.

Ein stabiles FAQ, eine deterministische Freigaberoute oder eine klar definierte Systemintegration kann im Standard Harness, in einem klassischen Flow oder in einer Anwendung günstiger und vorhersagbarer sein. Die leistungsfähigste Laufzeit pauschal einzusetzen erzeugt unnötige Varianz. Die erste Kostenkontrolle ist daher eine bewusste Architekturentscheidung.

Auch der Name darf nicht zu falschen Lizenzannahmen führen. Microsoft beschreibt den GitHub Copilot Harness als Copilot-Studio-Laufzeit und grenzt ihn vom GitHub-Copilot-Dienst ab. Entwicklerlizenzen oder Microsoft-365-Copilot-Lizenzen sind keine automatische Kostenabdeckung.

Das Sechs-Treiber-Modell

Ein belastbares Modell zerlegt den Verbrauch in sechs Treiber.

1. Nachfrage

Wie viele Aufgaben werden gestartet, von welchen Nutzergruppen und mit welchen Lastspitzen? Automatische Auslöser und wiederholte Eingaben gehören zur Menge.

2. Reasoning-Tiefe

Wie viel Planung und Iteration erfordert ein Fall? Unklare Ziele, großer Kontext und umfangreiche Ergebnisse können mehr Modellarbeit erzeugen als ein eng begrenzter Auftrag.

3. Werkzeug- und Wissensfächerung

Wie viele Suchen, Connectoren, MCP-Aufrufe, Dateien und verbundene Agenten werden verwendet? Eine sichtbare Aufgabe kann zahlreiche Operationen auslösen.

4. Wiederholungs- und Ausnahmequote

Wie oft scheitert ein Werkzeug, liefert unvollständige Daten oder zwingt zu einem Alternativweg? Automatische Erholung ist fachlich wertvoll, verbraucht aber Kapazität, bevor ein Ergebnis erscheint.

5. Entwicklung und Qualitätssicherung

Natürlichsprachliche Erstellung, Vorschauen, Testläufe und generierte Evaluationen kosten Credits. Ein seriöser Pilot budgetiert Lernen und Absicherung ausdrücklich.

6. Erfolgsquote

Welcher Anteil der Läufe beendet den vorgesehenen Geschäftsfall ohne manuelle Wiederholung? Günstige Fehlversuche können ein erfolgreiches Ergebnis teuer machen.

Als Planungslogik gilt:

Monatsverbrauch = Nachfrage x durchschnittliche Arbeit je Lauf + Entwicklung, Tests und Evaluation

Für die Geschäftsentscheidung zählt:

Kosten je Erfolg = zurechenbare Gesamtkosten / akzeptierte abgeschlossene Ergebnisse

Diese Gleichungen ersetzen weder den aktuellen Microsoft-Kalkulator noch reale Tenant-Berichte. Sie zeigen, welche Betriebsdaten erhoben werden müssen.

Beispiel: Lieferanten-Onboarding

Ein Agent nimmt Lieferantenunterlagen entgegen, extrahiert Stammdaten, prüft Dokumente gegen Richtlinien, fragt eine Risikodatenquelle ab, fordert fehlende Nachweise an und bereitet die Freigabe vor.

Eine Hochrechnung mit 2.000 monatlichen Anfragen verschleiert die entscheidenden Unterschiede. Ein vollständiges Paket benötigt vielleicht einen Dokumentdurchlauf und zwei Werkzeuge. Ein unvollständiges Paket löst mehrere Lesevorgänge, Suchen, Rückfragen und Wiederholungen aus. Ein fehlerhafter Connector kann den Verbrauch erhöhen, ohne einen akzeptierten Fall zu liefern.

Der Pilot trennt deshalb mindestens vollständige Fälle, unvollständige Fälle und Ausnahmen. Er erfasst Credits, Laufzeit, Werkzeugaufrufe, Wiederholungen, Ergebnisstatus und verbleibende manuelle Minuten. Werden aus 2.000 Versuchen nur 1.400 akzeptierte Onboardings, wäre eine Division durch alle Versuche wirtschaftlich irreführend.

Möglicherweise sollten deterministische Prüfungen bereits vor dem Agenten in einem normalen Flow stattfinden. Vielleicht lässt sich der Dokumentkontext begrenzen, eine breite Suche durch ein gezieltes Werkzeug ersetzen oder eine Ausnahme direkt an Menschen routen. Gute Kostenoptimierung verbessert den Lösungsentwurf, statt lediglich Transparenz zu erzeugen.

Drei Ausgabengrenzen kombinieren

Ein Dashboard zeigt Verbrauch, stoppt ihn aber nicht automatisch. Drei Grenzen gehören zusammen.

Agentengrenze

Für kostenrelevante Agenten wird ein Monatslimit mit Benachrichtigung eingerichtet. Falls der Betrieb am Limit stoppen soll, braucht der Prozess zusätzlich einen Ausnahme- und Kontinuitätsweg.

Umgebungsgrenze

Prepaid Credits werden einer Umgebung bewusst zugeteilt. Außerdem wird entschieden, ob sie nach Ausschöpfung aus dem freien Tenant-Pool ziehen darf. Ist Pay-as-you-go verknüpft, kann Nutzung laut Microsoft trotz deaktiviertem Tenant-Zugriff weiterlaufen. Beide Quellen müssen geprüft werden.

Finanzielle Grenze

Azure Budgets und Warnungen schaffen Sichtbarkeit für Pay-as-you-go, sind aber keine technische Sperre für Copilot Studio. Sie werden mit Agentenlimits und einem verantwortlichen Eigentümer kombiniert.

Kapazität kann darüber hinaus von verschiedenen Copilot-Studio-Workloads und unterstützten Microsoft-365-Erlebnissen genutzt werden. Deshalb müssen Agenten-, Umgebungs- und Tenant-Sicht gemeinsam betrachtet werden.

Entwicklung als bewusste Investition behandeln

Kosten während der Entwicklung sind nicht automatisch problematisch. Tests und Evaluationen sind Voraussetzung für einen zuverlässigen Agenten. Gefährlich ist unbegrenztes Experimentieren ohne Hypothese, Budget und Abbruchentscheidung.

Jeder Pilot erhält ein Lernbudget und konkrete Fragen: Welche Pfade erzeugen Wert? Wie hoch ist die Erfolgsquote? Welche Werkzeuge dominieren den Verbrauch? Welche Qualität rechtfertigt die Produktion? Am Budgetpunkt wird skaliert, neu entworfen oder beendet. Tests zu reduzieren, um Credits zu sparen, verschiebt Kosten lediglich in spätere Fehler.

Fünf Bedingungen für die Produktionsentscheidung

Eine Freigabe ist tragfähig, wenn fünf Aussagen gelten:

  1. Der Anwendungsfall benötigt tatsächlich die Fähigkeiten dieses Harness.
  2. Die Prognose umfasst Entwicklung, Absicherung und Betrieb.
  3. Gemessen werden Kosten je akzeptiertem Ergebnis.
  4. Agenten-, Umgebungs- und Finanzgrenzen sind konfiguriert und besitzen Eigentümer.
  5. Auch bei ungünstiger Nachfrage, Wiederholungsquote und Erfolgsrate bleibt ein positiver Geschäftswert.

Der GitHub Copilot Harness kann anspruchsvolle Automatisierung ermöglichen, die zuvor kaum realisierbar war. Beherrschbar wird sein Kostenrisiko, wenn Lösungsarchitektur, FinOps und Prozessverantwortung gemeinsam entworfen werden. Amplified Pi unterstützt bei Harness-Wahl, Messmodell, Pilotierung und Kapazitätssteuerung, bevor aus einer starken Demonstration eine unvorhersehbare Produktionsverpflichtung entsteht.