Topics und Gesprächsführung

Topics und Gesprächsführung

0:00 Bisher hat unser Agent geantwortet. Jetzt soll er etwas aufnehmen — und das ist etwas völlig anderes. Eine Auskunft darf frei formuliert sein. Ein Vorgang darf das nicht: Vier Angaben müssen vorliegen, geprüft, vollständig, jedes Mal. Für diesen Teil des Gesprächs gibt es Topics. Sie sind der Gegenentwurf zum Generativen — der Teil, den Sie selbst bestimmen.

0:23 In diesem Modul bauen wir einen solchen Vorgang, mit Eingabeprüfung, Rückfrage und einem sauberen Ausgang, wenn jemand abbricht.

Topics und Gesprächsführung

0:31 Vier Themen. Zuerst klären wir, was ein Topic überhaupt ist und wann sich der Aufwand lohnt. Dann geht es um Fragen, Bedingungen und Variablen — das Handwerkszeug jedes geführten Vorgangs. Im dritten Kapitel schauen wir kurz auf Power Fx und Adaptive Cards, zwei Mittel, die man sparsam einsetzen sollte. Und zum Schluss das Thema, das über den Alltagseindruck entscheidet: Fehlerpfade und Eskalation.

Topics für verbindliche Vorgänge

0:57 Beginnen wir mit der Frage, wann ein fester Ablauf besser ist als eine freie Antwort. Die Antwort ist unromantisch, aber klar. Ein Topic ist ein Ausschnitt eines Gesprächs, den Sie selbst zusammensetzen — aus Knoten auf einer Autorenfläche, ähnlich einem Ablaufdiagramm. Es gibt Systemthemen für das Grundverhalten und eigene Topics für alles Weitere.

1:18 Und hier kommt eine Erinnerung an gestern: Wann ein Topic greift, hängt vom Orchestrierungsmodus ab. Im generativen Modus entscheidet die Beschreibung, im klassischen entscheiden Triggerphrasen. Dasselbe Topic, zwei völlig verschiedene Auslöser. Das sollten Sie wissen, bevor Sie sich wundern, warum Ihre sorgfältig gepflegten Phrasen wirkungslos bleiben.

1:40 Diese acht Knotenarten lassen sich in drei Gruppen denken. Die ersten vier gestalten das Gespräch: mitteilen, fragen, eine Karte zeigen, verzweigen. Die nächsten zwei verwalten den Zustand: Variablen und die Steuerung des Topics selbst — umleiten, übergeben, beenden. Und die letzten beiden führen nach draußen, zu Werkzeugen und erweiterten Funktionen wie der generativen Antwort.

2:02 Wenn Sie beim Entwurf merken, dass Sie ständig in der dritten Gruppe landen, ist das ein Hinweis: Dann gehört die Logik vielleicht in einen Agent Flow, den wir morgen bauen. Der Kern steht im ersten Punkt: Ein Topic läuft bei gleicher Ausgangslage immer gleich ab. Das klingt banal, ist aber genau das, was ein Generativsystem nicht kann und auch nicht soll.

2:24 Für eine Auskunft ist Variabilität ein Vorteil — für eine Anmeldung ist sie ein Risiko. Dazu kommt ein Punkt, den man im Projekt unterschätzt: Ein Topic ist lesbar. Sie können es einer Fachabteilung zeigen, und die sieht, was passiert. Versuchen Sie das mal mit einer Anweisung in Prosa. Der erste Punkt klingt wie eine Schrulle, ist aber ein echtes Ärgernis: Ein Punkt im Namen eines Topics verhindert den Export der Solution — und das merken Sie erst am Tag der Bereitstellung.

2:52 Der zweite betrifft klassische Agents: Fünf bis zehn Triggerphrasen sind nötig, damit die Erkennung trägt; drei reichen nicht. Der dritte ist ein Reifezeichen — Systemthemen umbauen, bevor man das Grundverhalten kennt. Und der vierte ist ausdrücklich dokumentiert: Ein komplettes Topic im Code-Editor zu entwerfen, wird nicht voll unterstützt.

Fragen, Bedingungen und Variablen

3:12 Jetzt zum Handwerk. Erfassen, prüfen, weiterreichen — drei Schritte, die jeder Vorgang braucht. Sie wiederholen sich in jedem Topic, das Sie je bauen werden, in genau dieser Reihenfolge. Das Muster ist immer dasselbe: Ein Frageknoten erfasst eine Angabe und legt sie in einer Variablen ab, ein Bedingungsknoten verzweigt darauf.

3:33 Dazu kommen Ein- und Ausgabeparameter, mit denen Topics Werte untereinander übergeben. Und hier wird es interessant: Bei generativer Orchestrierung füllt der Agent solche Eingaben auch selbst aus dem Gesprächskontext. Wenn jemand vorher erwähnt hat, dass es um fünf Personen geht, fragt er nicht noch einmal nach der Teilnehmerzahl.

3:52 Das ist angenehm — und ein Grund mehr, die Prüfung nicht zu vergessen. Der rote Faden: erst denken, dann klicken. Schritt eins verlangt die Liste der Pflichtangaben, bevor ein einziger Knoten entsteht — sonst wächst der Vorgang, während man ihn baut. Die Schritte zwei und drei sind das eigentliche Handwerk, erfassen und prüfen. Schritt vier trennt Sonderfälle mit einer Bedingung statt mit Prosa.

4:16 Und Schritt fünf ist der, der am meisten Wirkung hat und am häufigsten übersehen wird: das Ergebnis als Ausgabe zurückgeben, nicht als Nachricht ausgeben. Warum, sehen wir gleich. Das ist ein Entwurfsmuster, das Microsoft ausdrücklich empfiehlt. Der Grund: Der Agent kann eine Ausgabe mit anderen Ergebnissen zu einer Antwort verbinden.

4:36 Eine feste Nachricht im Topic kann er das nicht — sie steht einfach da, und wenn der Agent anschließend selbst antwortet, hört die nutzende Person alles doppelt. Genau dieses Doppeln ist ein häufiges Ärgernis im generativen Modus. Der letzte Punkt löst es sauber: Geben Sie zusätzlich einen Status zurück, damit die Orchestrierung weiß, dass der Wunsch bereits bearbeitet ist.

4:59 Der erste Punkt ist eine harte Einschränkung, die man kennen muss: Eigene Entitäten — also geschlossene Listen und Muster — stehen als Eingabeparameter für Topics und Werkzeuge nicht zur Verfügung. Wenn Sie so etwas brauchen, führt der Weg über einen Frageknoten im Topic. Der zweite Punkt ist der häufigste Entwurfsfehler überhaupt: erfassen, aber nicht prüfen.

5:19 Der dritte rächt sich erst nach Monaten, wenn niemand mehr weiß, was eine Variable enthält. Und der vierte ist die Verzweigungsflut — irgendwann testet niemand mehr alle Pfade.

Power Fx und Adaptive Cards

5:30 Zwei Mittel, die mehr Aufmerksamkeit bekommen, als sie verdienen. Schauen wir uns an, wofür sie taugen — und wofür nicht. Power Fx ist die Formelsprache der Power Platform, wer Excel-Formeln kennt, findet sich schnell zurecht. Sie steht in Bedingungen, Variablenzuweisungen und Triggerbedingungen zur Verfügung. Adaptive Cards wiederum zeigen strukturierte Eingaben und Schaltflächen statt reinem Text.

5:55 Beide sind Mittel, keine Ziele. Sie lohnen dort, wo Text ungenau bliebe — etwa bei einem Datum oder einer Auswahl aus festen Optionen. Sie lohnen nicht, um einen Vorgang hübscher zu machen. Das klingt streng, erspart Ihnen aber viel Nacharbeit beim Kanalwechsel. Worauf es hier ankommt, ist nicht die Syntax, sondern das Muster: zwei Bedingungen, die zusammen erfüllt sein müssen.

6:19 Erstens muss überhaupt etwas eingetragen sein, zweitens muss der Zeitraum in der Zukunft liegen. Zwei Zeilen, die eine ganze Klasse von Fehlern abfangen — denn Termine in der Vergangenheit sind die häufigste unsinnige Eingabe bei jeder Terminerfassung. Und beachten Sie die Fußzeile: Sie könnten dieselbe Bedingung auch zusammenklicken. Als Formel ist sie prüfbar, kopierbar und in einem Review lesbar.

6:42 Deshalb lohnt sich der Umstieg früh. Hier kommt die Einordnung, die man vor dem Gestalten braucht: Kanäle sind nicht gleich. Teams unterstützt Markdown nur teilweise und zeigt in einem Frageknoten höchstens sechs Auswahlmöglichkeiten. Wer die Antwort selbst gestaltet, muss die Quellenangaben selbst einbauen — sonst verschwinden die Belege, über die wir gestern gesprochen haben.

7:05 Und ein Punkt, der viele überrascht: Anhänge kann eine nutzende Person in keinem Kanal senden. Der Agent antwortet dann mit einem Hinweis. Wer also eine Karte mit Dateiupload plant, plant ins Leere. Alle vier Punkte haben dieselbe Wurzel: Man gestaltet, bevor man die Bühne kennt. Der erste ist die Karte vor der Kanalentscheidung.

7:25 Der zweite ist Power Fx an der falschen Stelle — Logik, die in ein Werkzeug gehört, wandert in eine Formel, weil das gerade schneller ging. Der dritte ist die Folge davon: Formeln wachsen, bis sie niemand mehr liest. Und der vierte ist der Praxistest, den man sich nicht sparen kann — im Testchat sieht alles gut aus, im Zielkanal bricht es um.

Fehlerpfade und Eskalation

7:47 Zum Schluss des Moduls der Teil, der den Alltagseindruck bestimmt: Was passiert, wenn es nicht funktioniert? Diese Frage beantwortet jeder Agent — nur eben nicht immer so, wie jemand es entschieden hat. Abbrechen können ist eine Funktion, kein Versagen. Copilot Studio bringt dafür Systemthemen mit — für die Eskalation an einen Menschen, für den bestätigten Fehlschlag, für den Neustart.

8:10 Dazu kommt ein nützlicher Knoten, der alle Themen beendet: Er bricht in der generativen Orchestrierung auch die Schritte ab, die der Agent noch geplant hatte. Das ist wichtiger, als es klingt — sonst arbeitet er nach einem Abbruch brav seinen Plan weiter ab, als wäre nichts gewesen. Vier Felder, und drei davon sind Ausstiege, die man aktiv baut.

8:30 Bestätigen kommt vor folgenreichen Schritten und braucht eine sichtbare Zusammenfassung — die Frage „Sind Sie sicher?" ohne Angaben ist keine Bestätigung, sondern eine Formalität. Wiederholen gehört zur unklaren Eingabe und sollte konkret nachfragen. Abbrechen muss sauber enden. Und Eskalieren braucht den vollen Kontext.

8:50 Was Sie hier bauen, entscheidet darüber, ob der Agent als hilfreich oder als Hindernis wahrgenommen wird. Der erste Punkt ist der technisch heikelste: Ein halb ausgeführter Vorgang hinterlässt Datensätze, die niemand erwartet — und die später jemand von Hand aufräumt. Der zweite ist verhaltensbedingt: Menschen brechen ab, wenn sie den nächsten Schritt nicht verstehen; das ist kein böser Wille, sondern ein Entwurfshinweis.

9:15 Und der letzte Punkt ist eine typische Überraschung: Das Zurücksetzen des Gesprächs setzt die globalen Variablen der Sitzung zurück. Das ist selten das, was gemeint war, wenn jemand „von vorn" sagt. Der erste Punkt ist der peinlichste im Betrieb: Der Abbruch führt zur Startnachricht, und die nutzende Person steht wieder am Anfang.

9:34 Der zweite ist eine Feinheit, die dokumentiert und trotzdem überraschend ist — das Zurücksetzen löscht den Gesprächsverlauf nicht, der Agent erinnert sich also weiter. Der dritte ist der organisatorische Dauerbrenner: Eskalation ins Sammelpostfach. Und der vierte ist eine Frage des Tonfalls mit praktischer Folge — Fehlermeldungen sollen den nächsten Schritt nennen, nicht die technische Ursache.

Übung

9:56 Jetzt bauen Sie den ersten verbindlichen Vorgang des Lernlotsen. Bis hierhin konnte er nur reden — von jetzt an nimmt er etwas auf, und zwar vollständig oder gar nicht. Eine Schulungsanfrage bei der Ankerfeld GmbH braucht vier Angaben: Thema, Zeitraum, Teilnehmerzahl und Kostenstelle. Fehlt eine, darf die Anfrage nicht entstehen — das ist der Punkt, an dem aus einem netten Gespräch ein verbindlicher Vorgang wird.

10:21 Zwei Prüfungen machen es interessant: Der Zeitraum darf nicht in der Vergangenheit liegen, und die Kostenstelle muss bekannt sein. Beides sind Fälle, in denen der Lernlotse nachfragen muss, statt einfach weiterzumachen. Das Lernziel ist das Bauen eines verbindlichen Vorgangs mit geprüften Eingaben und einem benannten Ausstieg.

10:41 Achten Sie besonders auf den mittleren Teil des Erfolgskriteriums: Eine unklare Angabe soll genau eine gezielte Rückfrage auslösen. Nicht drei, nicht dieselbe noch einmal — eine, und zwar konkret. Und der Abbruch endet mit einer Übergabe an die Personalentwicklung, nicht im Nichts. Wer früh fertig ist, stellt auf Ausgaben statt Nachrichten um und sieht sich an, was sich dadurch ändert.

11:04 Fünf Schritte, und der letzte ist der wichtigste. Die ersten vier bauen: Fragen anlegen, Prüfungen ergänzen, Rückfragen formulieren, Abbruch und Übergabe als eigene Pfade. Der fünfte prüft, und zwar mit drei unvollständigen Eingaben. Genau dort zeigt sich, ob der Vorgang trägt — bei vollständigen Eingaben funktioniert jeder Entwurf.

11:24 Und achten Sie im dritten Schritt auf die Formulierung der Rückfrage: konkret statt allgemein. „Das habe ich nicht verstanden" hilft niemandem weiter. Der erste Punkt ist der verbreitetste Prüffehler: Die Meldung sagt, dass etwas falsch ist, aber nicht, was erwartet wird. Der zweite ist der halb erfasste Vorgang nach Abbruch — technisch unsauber und organisatorisch lästig.

11:47 Der dritte ist die wörtlich wiederholte Frage; für die nutzende Person klingt das, als hätte der Agent nicht zugehört. Und der vierte ist der Grund, warum Punkt fünf des Ablaufs so wichtig ist: Wer nur mit vollständigen Eingaben testet, hat seine Prüfpfade nie geprüft. Morgen lassen wir den Agenten selbst entscheiden, wann er welchen Baustein benutzt.