Mein erster Copilot-Agent: Der eigentliche Aufwand liegt in den Anweisungen

Agenten waren für mich lange ein abstraktes Konzept.
Geändert hat sich das in dem Moment, in dem ich über meinen eigenen Arbeitsalltag nachgedacht habe.

In meinen Projekten gibt es regelmäßig Workshops zur Bestandsaufnahme im Rahmen von Ausschreibungen. Die Themen sind oft ähnlich, der Kontext ist jedes Mal anders. Struktur und die richtigen Rückfragen entscheiden darüber, wie gut das Ergebnis am Ende ist.

Genau dafür wollte ich Unterstützung.

Meine Neugier war schnell geweckt: Ich las und hörte immer mehr über Agenten. Als ich dann verstand, dass sich deklarative Agenten ohne Programmierung und ohne klassische Automatisierungsworkflows erstellen lassen, habe ich sofort losgelegt und meinen ersten eigenen Agenten gebaut.

Kurz zur Einordnung

Deklarative Agenten sind eine konfigurationsbasierte Form von Copilot-Agenten, die ich direkt im Agent Builder erstellen kann, ohne z. B. Copilot Studio zu benötigen. Statt Abläufe zu programmieren, lege ich fest:

• welche Aufgabe der Agent unterstützt

• auf welche Wissensquellen er zugreifen darf

• welche Regeln und Grenzen gelten

Im Ergebnis entsteht eine strukturierte Anleitung für einen konkreten Anwendungsfall, die ich in der Organisation teilen kann. So lassen sich konsistente und vergleichbare Ergebnisse erzielen, unabhängig davon, wer den Agenten nutzt.

Wichtig: Der Agent wird nur auf Aufforderung aktiv und arbeitet dialogbasiert.

Mein erster Use Case: Workshops zur Bestandsaufnahme

Im Rahmen von Ausschreibungen ist es wichtig, zu Beginn die aktuelle Situation des Kunden zu verstehen und auch das Zielbild (den Soll-Zustand) zu dokumentieren. Das passiert je nach Projekt in ganz unterschiedlichen Branchen, zum Beispiel in Produktion, Handel, Logistik oder im öffentlichen Sektor. Inhaltlich drehen sich die ersten Gespräche aber oft um ähnliche Themen, nämlich Prozesse, Systemlandschaft, Schnittstellen und Service-Management-Anforderungen. Genau dafür wollte ich einen Agenten, der mir schnell passende Fragen vorschlägt und nichts Wesentliches vergisst. Mein größter Aha-Effekt beim ersten Einsatz war, wie konsistent die Ergebnisse wurden, sobald Kontext und gewünschtes Ausgabeformat wirklich sauber beschrieben waren.

Zur Vorbereitung auf solche Workshops nutze ich interne Standards und Erfahrungswerte und reichere diese mit branchen- und kundenspezifischen Anforderungen an.

Diese Aufgabe habe ich mir für meinen ersten deklarativen Agenten ausgesucht, da sie die typischen Aspekte aufweist:

• wiederkehrende Tätigkeit

• gut zu beschreibende Aufgabe

• standardisierter Ablauf

Erstellung des Agenten

Der Aufbau des Agenten selbst ist schnell gemacht. Name, Beschreibung und ein passendes Icon sind in wenigen Minuten definiert.

Der eigentliche Aufwand steckt an einer anderen Stelle: in den Anweisungen.

Das klingt zunächst einfach und harmlos, ist jedoch so wichtig, dass man sich dafür viel Zeit nehmen sollte. Ich habe mich hier zunächst vom Prompt Coach und anschließend von Copilot selbst unterstützen lassen. Es sind ein paar Iterationen vergangen, bis ich mit dem Ergebnis zufrieden war.

Beim Testen und Umformulieren habe ich verstanden, dass es weniger um den Agenten selbst geht, sondern darum, wie präzise ich meine eigene Aufgabe beschreibe.

Wie ich getestet habe

Nach dem ersten Entwurf habe ich den Agenten mehrfach im Alltag getestet und die Anweisungen schrittweise angepasst.

Ich habe bewusst unterschiedliche Projektsituationen simuliert, von allgemeinen Workshops bis zu sehr spezifischen Kontexten. Besonders hilfreich war es, die generierten Fragen kritisch zu prüfen und gezielt nachzuschärfen, zum Beispiel bei fehlendem Kontext, zu allgemeinen Formulierungen oder zu viel Detailtiefe.

Meine drei wichtigsten Regeln für gute Anweisungen

1) Ich definiere zuerst für mich selbst, was am Ende „gut“ bedeutet, also Ziel, Tiefe und gewünschtes Format.

2) Ich zwinge den Agenten zu Rückfragen, wenn entscheidende Informationen fehlen, zum Beispiel Branche, Ziel des Workshops, Teilnehmende und technische Rahmenbedingungen.

3) Ich setze klare Grenzen, was er nicht tun soll, und wie er reagieren soll, wenn etwas nicht in den Wissensquellen steht.

Aufbau und Struktur der Anweisungen

Ich habe für meinen Agenten mehrere Bereiche definiert, die zusammen das Verhalten steuern und diese sehr detailliert beschrieben:

• Rolle und Ziel, z. B.

  • „Du bist ein Assistent für Fragen, die während Bestandsaufnahmeterminen…“

  • „Du generierst Entwürfe für diese Fragen, die dafür geeignet sind, die Ist-Situation zu verstehen…“

  • „Wenn die Abfrage außerhalb deines Bereichs oder deiner Wissensquelle liegt, sag das dem Benutzer ganz klar.“

• Verhalten und Qualität der Fragen, z. B.

  • „Du bist Experte im Entwerfen von Interviewfragen, die in Terminen zur Bestandsaufnahme gestellt werden.“

  • „Passe die Fragen an die spezifischen Prozesse und technischen Themen an, die für den aktuellen Workshop relevant sind.“

  • „Vermeide Fragen, die zu allgemein sind oder keine Beziehung zum Thema haben.“

  • „Stelle sicher, dass die Fragen klar, präzise und relevant sind.“

• Interaktion und Rückfragen, z. B.

  • „Beginne, indem du nach dem Thema und den Teilnehmenden der Bestandsaufnahme fragst, wenn diese Informationen nicht vom Benutzer bereitgestellt wurden.“

  • „Frage außerdem nach der Branche, Unternehmensgröße und relevanten Standorten, sofern dir diese Informationen nicht bekannt sind. Richte deine Frage dann entsprechend dieser Informationen aus.“

  • „Frage, wie viele Fragen erstellt werden sollen.“

  • „Frage anschließend, ob es eine Vorlage gibt, die verwendet werden soll. Wenn keine Vorlage bereitgestellt wird, beginne mit der Generierung der Fragen.“

  • In diesem Teil habe ich außerdem definiert, für welche Themen der Agent welche Wissensquellen nutzen bzw. priorisieren soll.

• Ausgabeformat der generierten Fragen, z. B.

  • „Bitte gib die Fragen immer in folgendem Format an:

    • Frage (fett formatiert)

    • Ziel (normal formatiert, nur das Wort "Ziel" in fett), hier soll kurz in Stichworten angegeben werden, wozu die Frage dient)

    • Mögliche Antworten (so formatiert wie das Ziel), hier sollen Stichpunkte stehen, die dem oder der Befragten helfen können, falls er oder sie keine Idee hat“

• Beispiel

  • Hier habe ich eine Frage formuliert und auch das Ziel und die möglichen Antworten in genau dem Format genannt, in dem ich alle Fragen dargestellt haben möchte.

Entscheidend war für mich neben der Struktur selbst, vor allem die Konsequenz in der Formulierung.
Je konkreter ich Ziel, Verhalten und Ausgabe beschrieben habe, desto stabiler wurden die Ergebnisse.

Wissen, Funktionen und Freigabe

Im nächsten Schritt habe ich festgelegt, auf welche Wissensquellen der Agent zugreifen darf. Dazu gehören interne Dateien, SharePoint-Seiten und Teams-Inhalte.

Dieser Teil ist wichtiger, als es auf den ersten Blick wirkt, da hier gesteuert wird, welche Inhalte der Agent in seine Antworten einbezieht.

Nach den eigenen Tests kann der Agent in der Organisation freigegeben werden, sodass andere ihn ebenfalls nutzen können.

Ab diesem Zeitpunkt kann der Agent ausgewählt werden:

Austausch

Für mich war dieser erste Agent weniger ein technischer Schritt als eine neue Art, meine eigenen Aufgaben zu bearbeiten.

Mich interessiert, wie das bei euch ist:

Welche Use Cases haben sich für euch bei deklarativen Agenten bewährt und was war euer erster Agent?