Ich habe Copilot nicht mehr durch die Arbeit geführt. Ich habe Cowork den Job gegeben.
Was passiert, wenn aus mehreren Einzelprompts ein komplettes delegiertes Arbeitspaket wird?
Experiment Ticket
- TESTOBJEKT
- MakerBox Mini
- VERSUCH
- M365 Copilot Chat → Cowork
- FRAGE
- Task Assistance oder delegiertes Arbeitspaket?
Es gibt einen Punkt, an dem ein guter Prompt nicht mehr das eigentliche Problem löst.
Nicht weil der Prompt schlecht wäre.
Sondern weil ich immer noch selbst die Arbeit orchestriere.
Genau das wollte ich testen.
Für einen fiktiven Product-Review-Prozess bei WunderKammer habe ich zuerst ganz klassisch mit Microsoft 365 Copilot Chat gearbeitet. Danach habe ich denselben Business Case noch einmal mit Cowork aufgesetzt.
Dabei wollte ich ausdrücklich nicht wissen:
Welche Antwort ist besser?
Meine Frage war eine andere:
Was verändert sich, wenn ich nicht mehr jeden Arbeitsschritt einzeln anweise, sondern ein komplettes Arbeitspaket delegiere?
Der Use Case
Bei WunderKammer soll eine neue Produktidee bewertet werden: MakerBox Mini, ein kompaktes Kreativ- und Experimentierset für Kinder von 8 bis 12 Jahren.
Dafür liegen mehrere Informationsquellen vor: Product Brief, Customer Feedback, Sales & Market Review, Operations & Supplier Assessment sowie das interne Product Principles & Review Framework.
Die Aufgabe ist also deutlich mehr als:
„Fasse mir diese Dateien zusammen.“
Das Product Review soll Customer Value, Brand Fit, Commercial Potential, Feasibility und Risk bewerten. Zusätzlich sollen widersprüchliche Signale, fehlende Informationen und noch unvalidierte Annahmen sichtbar werden. Am Ende braucht das Product Review Team eine Empfehlung: Proceed, Proceed with conditions, Hold oder Stop.
Kurz gesagt:
Viele Quellen. Unterschiedliche Perspektiven. Wenig Zeit. Und am Ende muss daraus eine belastbare Entscheidungsgrundlage entstehen.
Product Brief
Customer Feedback
Sales & Market Review
Operations & Supplier Assessment
Product Principles & Review Framework
5 Review Dimensions
Run A: M365 Copilot Chat
Ich starte so, wie viele von uns heute mit Copilot arbeiten.
Ich gebe Copilot die relevanten Unterlagen und einen ausführlichen Prompt.
Sinngemäss:
Bewerte MakerBox Mini anhand der fünf Review-Dimensionen. Nutze das WunderKammer Framework als Bewertungsstandard. Vergleiche Customer Feedback, Sales und Operations. Zeige Konflikte, fehlende Informationen und Annahmen auf und gib am Ende eine Empfehlung.
Das funktioniert.
Sogar ziemlich gut.
Copilot kommt zu:
Proceed with conditions
Customer Value wird mit 4/5 bewertet, Brand Fit mit 5/5, Commercial Potential mit 4/5, Feasibility mit 3/5 und Risk mit 3/5.
Auch die zentralen Spannungen erkennt Copilot sauber: Preisvorstellung versus Marge, Geschenkattraktivität versus Repeat Use, unabhängige Nutzung versus Produktkomplexität, kompakte Positionierung versus aktuelle Verpackung und gute Produktidee versus noch nicht bewiesene operative Skalierbarkeit.
Bis hierhin gibt es wenig zu meckern.
Das Ergebnis ist brauchbar.
Das Problem liegt woanders.
Recommendation
PROCEED WITH CONDITIONS
Ich bin immer noch die Projektleiterin meines eigenen Prompts
Nach der Analyse muss ich den nächsten Schritt selbst starten:
Turn this into a concise Product Review brief for management.
Danach kommt der nächste Prompt:
Now draft a short email to Daniel, Lara and Jonas...
Und danach müsste ich mich noch um Ablage und Organisation kümmern.
Genau das habe ich auch in der Session visualisiert:
Analyse → Copilot.
Management Brief → Nina fragt erneut.
Mail → Nina fragt erneut.
Ablage → Nina kümmert sich weiterhin selbst darum.
Das ist nicht schlecht.
Für einen einzelnen Task kann das sogar genau richtig sein.
Aber die Arbeitslogik bleibt bei mir.
Copilot hilft mir bei jedem Schritt. Ich manage weiterhin die Schritte.
Und genau dort beginnt mein eigentliches Experiment.
STEP I
Analyse the evidence.
→ Copilot
STEP II
Turn it into a management brief.
→ Nina asks again
STEP III
Draft the email.
→ Nina asks again
STEP IV
Save and organise the output.
→ Nina still has to handle it.
Run B: Cowork
Jetzt ändere ich nicht den Business Case.
Ich ändere die Ebene der Delegation.
Statt Analyse, Brief, Mail und Ablage nacheinander anzustossen, bekommt Cowork einen zusammenhängenden Auftrag:
Prepare tomorrow’s Product Review for MakerBox Mini from start to finish.
Danach definiere ich den gewünschten Zielzustand.
Cowork soll den Case analysieren, das vollständige Product Review erstellen, die Team-Kommunikation vorbereiten, den Output organisieren und vor externen Änderungen oder Kommunikation stoppen und eine Freigabe einholen.
Der Unterschied ist damit nicht einfach:
„Mach mehr.“
Sondern:
„Übernimm dieses Arbeitspaket bis zu einer klar definierten Grenze.“
MakerBox Mini Product Review
Prepare tomorrow’s Product Review for MakerBox Mini from start to finish.
Und plötzlich verändert sich die Arbeit
Cowork kopiert nicht einfach die vorherige Antwort in ein Word-Dokument.
Es bewertet den Case erneut und kommt zu einer anderen Empfehlung:
Hold
Genauer:
Hold — time-boxed, with a defined path to Proceed with conditions.
Der entscheidende Punkt dabei ist Feasibility.
Cowork erkennt, dass Safety Labelling und unvollständige Material Declarations beim neuen Supplier nicht einfach Risiken sind, die man bequem während eines Piloten beobachten kann.
Das Framework behandelt sie als Gates, die vor einer Purchase Order geschlossen werden müssen. Zusätzlich bezieht Cowork frühere Product Reviews mit ein und erkennt, dass vergangene Fälle mit Feasibility 2 ebenfalls auf Hold gesetzt wurden.
RUN A → Proceed with conditions
RUN B
HOLD
War Cowork deshalb „schlauer“?
Das wäre mir zu einfach.
Und ehrlich gesagt würde ich diese Schlussfolgerung aus diesem Test auch nicht ziehen.
Was ich interessanter finde:
Cowork hat das Arbeitspaket breiter verarbeitet.
Dadurch wurden drei Spannungen besonders sichtbar.
Der Preis, der verkauft, ist nicht der Preis, der bezahlt
Sales sieht CHF 39–42 als attraktiven Bereich.
Die voll geladenen Kosten liegen aber bei CHF 24.15. Daraus ergeben sich 38.1 % Marge bei CHF 39 und 42.5 % bei CHF 42. Das liegt deutlich unter dem definierten Benchmark von mindestens 55 %.
Das ist keine kleine Optimierungslücke.
Das ist ein echter Entscheidungsbedarf.
Positives Feedback ist noch kein bewiesener Product Value
Die Customer-Signale sehen grundsätzlich gut aus.
Aber niemand hat das Produkt tatsächlich benutzt.
Cowork trennt deshalb konsequent zwischen positiver Reaktion auf ein Konzept und echter Usage Evidence.
Auch das ist ein wichtiger Unterschied.
Eine gute Reaktion auf eine Beschreibung ist noch kein Produktbeweis.
Pilot-ready ist nicht dasselbe wie compliance-ready
Ein Pilot darf Unsicherheit enthalten.
Genau dafür ist er da.
Aber nicht jede Unsicherheit gehört in einen Pilot.
Safety- und Compliance-Fragen können eine Grenze darstellen, die vorher geklärt werden muss. Genau so behandelt Cowork diese Punkte.
Cowork liefert nicht nur eine Antwort
Dann kommt für mich der wichtigere Teil des Experiments.
Cowork erstellt tatsächlich das Product Review.
Nicht nur Chat-Text.
Das Ergebnis ist ein vollständiges Dokument mit Executive Summary, Evidence Used, den fünf Bewertungsdimensionen, Contradictions & Trade-offs, Missing Information, Recommendation, Conditions Before Pilot und Human Decision Required.
Das erzeugte Review umfasst zehn Seiten und endet bewusst nicht mit einer automatisierten Business-Entscheidung, sondern mit den Punkten, über die das Product Review Team entscheiden muss.
Zusätzlich bereitet Cowork bereits die nächsten Schritte vor: Mailentwurf, vorgeschlagene Aktionen, Verantwortliche und Zieltermine.
Das verändert die Arbeitsform.
Ich bekomme nicht nur eine Antwort.
Ich bekomme ein Arbeitsartefakt.
Product Review
MakerBox Mini
Output Stack
Der spannendste Moment kommt aber erst danach
Cowork hat den Auftrag, den Output auch zu organisieren.
Hier hätte der Test leicht in die Richtung kippen können:
„Super, jetzt macht AI einfach alles.“
Genau das passiert aber nicht.
Cowork meldet:
Nothing has been sent, uploaded or filed yet.
Und zeigt zuerst die geplanten Aktionen.
Dabei stellt Cowork ausserdem fest, dass die gewünschten Empfänger im Directory nicht gefunden werden können und dass noch kein passender Product Review Folder existiert.
Statt diese Lücken zu überspielen, werden die geplanten nächsten Schritte transparent gemacht und auf Freigabe gewartet.
Für mich ist das einer der wichtigsten Momente des gesamten Labs.
Denn Delegation sollte nicht bedeuten:
„Mach einfach.“
Sondern:
„Arbeite selbstständig innerhalb klarer Grenzen.“
Nothing has been sent, uploaded or filed yet.
Erst nach der Freigabe passiert wirklich etwas
Nachdem ich Zielpfad und Aktionen bestätigt habe, geht Cowork weiter.
Es erstellt den neuen MakerBox Mini-Ordner, lädt das Product Review hinein und legt einen E-Mail-Entwurf an.
Gesendet wird weiterhin nichts.
Und genau dort wird der Unterschied zwischen den beiden Arbeitsweisen ziemlich greifbar.
Chat versus Cowork ist für mich nicht Feature versus Feature
Ich würde daraus nicht machen:
Chat kann das. Cowork kann jenes.
Der interessantere Unterschied liegt in der Rolle des Menschen.
Bei Copilot Chat zerlege ich die Arbeit, bestimme den nächsten Schritt, frage erneut und manage den Ablauf.
Bei Cowork definiere ich stärker den Arbeitsrahmen: Ziel, Kontext, erwartete Artefakte, Zielzustand, Grenzen und Freigabepunkte.
Cowork übernimmt dafür mehr Verantwortung für den Weg dazwischen.
Oder so, wie ich es in der Session zusammengefasst habe:
Copilot helped Nina through the steps. Cowork took responsibility for the work package.
COPILOT CHAT
Ich zerlege die Arbeit.
Ich bestimme den nächsten Schritt.
Ich frage erneut.
Ich manage den Ablauf.
COWORK
Ziel
Kontext
Artefakte
Zielzustand
Grenzen
Freigabepunkte
Was das Experiment nicht beweist
Das Lab beweist nicht, dass Cowork grundsätzlich bessere Entscheidungen trifft als M365 Copilot Chat.
Chat kam zu Proceed with conditions.
Cowork zu Hold.
Beide Empfehlungen lassen sich auf Basis des vorhandenen Materials argumentieren.
Und die beiden Runs waren nicht als wissenschaftlich sauberer A/B-Test mit komplett identischer Orchestrierung angelegt.
Deshalb wäre für mich die falsche Schlussfolgerung:
„Cowork ist intelligenter.“
Interessanter ist etwas anderes:
Je grösser das delegierte Arbeitspaket wird, desto stärker beeinflussen Scope, Kontext und Arbeitsauftrag auch die Analyse.
Und genau deshalb verschwindet der Human Checkpoint nicht.
Er wird wichtiger.
Was der Test gezeigt hat
Delegiere einen Outcome, nicht nur einzelne Schritte
Ein Cowork-Prompt wird nicht dadurch gut, dass ich möglichst viele To-dos hineinschreibe.
Entscheidend ist die Frage:
Was soll am Ende existieren?
In diesem Test bestand der Zielzustand nicht nur aus einer Analyse.
Das Review sollte fertig sein, die Kommunikation vorbereitet, der Output organisiert und die nächsten Aktionen sichtbar sein.
Das macht aus einer Reihe von Tasks ein Arbeitspaket.
Die Source of Truth gehört in den Auftrag
Im Prompt steht ausdrücklich:
Use the attached WunderKammer materials as your source of truth.
Das klingt unspektakulär.
Je selbstständiger das System aber arbeitet, desto wichtiger wird diese Grenze.
Welche Informationen dürfen als Grundlage gelten?
Welche nicht?
Gerade bei Entscheidungsarbeit würde ich das nicht dem Zufall überlassen.
Ein gutes Ziel braucht eine erkennbare Form
„Create a Product Review“ hätte funktioniert.
Aber wir haben zusätzlich definiert, wie dieses Review strukturiert sein soll: Executive Summary, Evidence Used, Bewertung, Contradictions, Missing Information, Recommendation, Conditions und Human Decision Required.
Das ist für mich ein wiederkehrendes Muster:
Mehr Autonomie braucht nicht weniger Klarheit. Sie braucht ein klareres Zielbild.
Ablage ist Teil der Arbeit
Ein Dokument, das irgendwo erstellt wurde, ist noch nicht automatisch ein abgeschlossenes Arbeitspaket.
Wenn Organisation relevant ist, gehört sie in den Auftrag.
Wo soll das Ergebnis landen?
Wie soll es abgelegt werden?
Was passiert, wenn der erwartete Zielort noch gar nicht existiert?
Genau dieser Punkt wurde im Test sichtbar.
Cowork fand keinen passenden Product Review Folder und stoppte, statt einfach irgendwo abzulegen.
Human Checkpoints sind kein Nachsatz
Für mich ist einer der wichtigsten Sätze im gesamten Prompt:
Do not send the email without my approval. Show me the planned actions before executing anything that communicates externally or changes files.
Das ist nicht nur Sicherheitsprosa am Ende eines Prompts.
Das ist Teil des Arbeitsdesigns.
Je mehr Verantwortung ich delegiere, desto klarer muss definiert sein:
Wo endet Selbstständigkeit und wo beginnt Autorisierung?
Gute Delegation lässt Raum für Rückfragen
Cowork konnte die gewünschten Kontakte nicht finden.
Es erfand sie nicht.
Der gewünschte Ablageort war nicht vorhanden.
Es tat nicht so, als wäre er da.
Es stoppte.
Das finde ich wesentlich wichtiger als maximale „Autonomie“.
Ich möchte kein System, das um jeden Preis etwas tut.
Ich möchte eines, das selbstständig genug arbeitet, um voranzukommen, und vorsichtig genug ist, um bei relevanten Lücken nachzufragen.
Ein Arbeitspaket ist noch kein Agent
Auch das gehört für mich zum Ergebnis.
Nur weil Cowork ein komplettes Arbeitspaket übernehmen kann, folgt daraus noch nicht:
„Jetzt brauchen wir einen Agenten.“
Wenn Nina diesen Review gelegentlich durchführt, kann Cowork genau die richtige Lösung sein.
Erst wenn dieselbe Arbeit regelmässig wiederkehrt, mehrere Personen dieselbe Logik benötigen, Wissen zentral gepflegt werden soll oder Actions und Prozesse standardisiert werden müssen, verändert sich der Use Case erneut.
Dann wird die Frage nach einem Agenten interessant.
Nicht vorher.
Mein Fazit
Ich bin mit einer relativ einfachen Frage gestartet:
Was passiert, wenn ich Cowork mehr von der Arbeit überlasse?
Die spannendere Antwort war:
Ich musste nicht weniger über die Arbeit nachdenken. Ich musste über andere Dinge nachdenken.
Bei einzelnen Copilot-Prompts denke ich stark über den nächsten Schritt nach.
Bei einem delegierten Arbeitspaket verschiebt sich mein Fokus.
Auf Scope.
Auf Source of Truth.
Auf Zielzustand.
Auf Artefakte.
Auf Ablage.
Auf Handlungsgrenzen.
Und auf die Stellen, an denen ein Mensch übernehmen muss.
Der entscheidende Unterschied ist deshalb für mich nicht:
weniger Prompting.
Sondern:
mehr Arbeitsdesign.
Je mehr Arbeit du an AI delegierst, desto weniger solltest du den einzelnen Schritt micromanagen – und desto klarer musst du Ergebnis, Kontext und Grenzen designen.
Oder noch kürzer:
Don't just prompt the task. Design the handoff.