Ein Unternehmer erklärt, was er vom Agenten erwartet. Zwanzig Minuten später scheint der Umfang klar genug, um mit dem Bauen zu beginnen. Sechs Wochen später funktioniert der Agent — produziert aber weiterhin Ausgaben, die das Team korrigieren muss. Das Gespräch, das den Workflow definiert hat, war kein Briefing. Es war eine Beschreibung. Ein Briefing ist das Dokument, das einen Agenten zuverlässig macht — und das Schreiben dauert länger, als die meisten erwarten.
Das Gespräch, das den Workflow definiert hat, war kein Briefing. Es war eine Beschreibung. Die beiden produzieren sehr unterschiedliche Agenten.
Was ein Briefing wirklich ist (und was nicht)
Die meisten Menschen nähern sich dem Briefing eines Agenten so, wie sie ein Prompt schreiben würden: beschreiben, was der Agent tun soll, Beispiele geben und schauen, was herauskommt.
Dieser Ansatz produziert einen Agenten, der bei Eingaben, die den Beispielen ähneln, gut funktioniert. Bei Eingaben, die das nicht tun, versagt er.
Ein Briefing ist kein Prompt. Es ist eine Spezifikation eines Geschäftsprozesses — das Dokument, das einen Workflow präzise genug definiert, sodass ein neuer Mitarbeiter ohne Vorwissen ihn am ersten Tag richtig ausführen könnte. Das Schreiben ist eine Prozessdokumentationsübung, keine Prompt-Schreibübung.
Diese Unterscheidung ist wichtig, weil ein vages Briefing und ein vager Prompt unterschiedliche Versagensmuster produzieren. Ein vager Prompt produziert inkonsistente Ausgaben. Ein vages Briefing produziert einen Agenten, der erwartete Fälle korrekt bearbeitet und bei allem anderen scheitert — was in einem echten Unternehmen mit echter Eingabevariation viele Fälle sind.
Die fünf Fragen, die jedes Briefing beantworten muss
Ein Briefing sind keine Anweisungen für den Agenten. Es ist eine Spezifikation eines Geschäftsprozesses — Auslöser, Eingaben, Ausgabeformat, akzeptable Ausnahmen und Eskalationspfad. Das Schreiben offenbart jede Lücke darin, wie das Unternehmen die Aufgabe derzeit bearbeitet.
Ein vollständiges Briefing beantwortet fünf Fragen. Wenn auch nur eine davon fehlt, ist das Briefing unvollständig.
1. Was löst den Agenten aus? Ein spezifisches, beobachtbares Ereignis, das den Workflow startet. Nicht „wenn ein Lead nachgefasst werden muss" — „wenn das letzte Aktivitätsdatum eines Leads mehr als fünf Werktage zurückliegt und sein Status 'Angebot gesendet' ist." Der Auslöser muss testbar sein: Entweder er feuert oder er tut es nicht.
2. Was erhält der Agent? Die genauen Eingaben, die zum Zeitpunkt des Starts verfügbar sind. Feldnamen, Datentypen, welche Felder leer sein können, welche immer ausgefüllt sind. Ein Agent kann keine Informationen verwenden, die ihm nicht gegeben wurden. Jede fehlende Eingabe ist eine Lücke, die sich im Produktivbetrieb zeigt.
3. Was produziert der Agent? Die spezifische Ausgabe, in einem spezifischen Format. Nicht „eine Follow-up-E-Mail" — eine Follow-up-E-Mail mit diesen Feldern, diesem Ton, dieser maximalen Länge, dieser Betreffzeilenstruktur. Die Ausgabedefinition ist das Erfolgskriterium.
4. Was sind die akzeptablen Ausnahmen? Jeder Workflow hat Fälle, die außerhalb des Hauptpfads liegen. Das Briefing benennt sie explizit: Welche Eingaben lösen eine andere Ausgabe aus, welche Fälle werden anders weitergeleitet, welche Situationen erfordern eine menschliche Entscheidung. „Es kommt darauf an" ist keine Ausnahmeregel.
5. Was passiert, wenn der Agent nicht entscheiden kann? Der Eskalationspfad. Eine spezifische Aktion für Eingaben, die keinem definierten Fall entsprechen. Nicht „der Agent wird damit angemessen umgehen" — ein benannter Schritt. Zur Prüfung markieren. In eine Warteschlange senden. Mit einer Zwischennachricht antworten. Der Eskalationspfad verhindert, dass der Agent bei Grenzfällen falsche Ausgaben produziert.
Die folgende Tabelle zeigt, was jede Briefing-Komponente erfordert, am Beispiel eines Lead-Follow-up-Workflows.
| Briefing-Komponente | Was sie spezifiziert | Beispiel — Lead-Follow-up-Workflow |
|---|---|---|
| Auslöser | Das beobachtbare Ereignis, das den Workflow startet | Lead-Status = „Angebot gesendet" UND letztes Aktivitätsdatum > 5 Werktage |
| Eingaben | Genaue Datenfelder, die beim Start verfügbar sind | kontakt_name, unternehmensname, angebotswert, letztes_antwortdatum, kontomanager |
| Ausgabe | Das spezifische Ergebnis, Format und Länge | Follow-up-E-Mail: Betreffzeilenformat, max. 150 Wörter, Erste-Person vom Kontomanager |
| Ausnahmeregeln | Benannte Fälle, die einen anderen Pfad nehmen | Tag „Nicht kontaktieren" → überspringen; Angebotswert > 50.000 € → Weiterleitung an Gründer |
| Eskalationspfad | Die definierte Aktion, wenn keine Regel passt | Zur manuellen Prüfung markieren; zur „Bedarf Aufmerksamkeit"-CRM-Warteschlange hinzufügen |
Was passiert, wenn ein Briefing unvollständig ist
Die meisten Implementierungsfehler sind Briefing-Fehler. Der Agent hat geliefert, was er erhalten hat.
Ein unvollständiges Briefing produziert ein spezifisches Versagensmuster. Der Agent funktioniert in den ersten zwei Wochen. Die Eingaben, die er in diesem Zeitraum erhält, entsprechen zufällig den Fällen, für die er gebrieft wurde. Das Team sieht korrekte Ausgaben und nimmt an, die Implementierung ist solide.
Dann kommt ein Fall, den das Briefing nicht abgedeckt hat. Der Agent produziert etwas, das wie eine Ausgabe aussieht, aber nicht richtig ist. Das Team korrigiert es und macht weiter. Ein weiterer Grenzfall kommt. Eine weitere Korrektur. Über einen Monat hinweg verbringt das Team mehr Zeit damit, die Arbeit des Agenten zu prüfen, als es gebraucht hätte, die Aufgabe selbst zu erledigen.
Das ist kein Technologieversagen. Der Agent hat genau das getan, was ihm gesagt wurde. Das Briefing hat ihm gesagt, wie er den häufigen Fall bearbeiten soll, und alles andere undefiniert gelassen. Der Agent hat den häufigen Fall bearbeitet. Als der seltene Fall eintraf, produzierte er die nächstliegende Übereinstimmung, die er finden konnte.
Jede Korrektur, die das Team nach dem Start vornimmt, ist eine Zeile des Briefings, die nie geschrieben wurde.
Wie man ein Briefing schreibt, bevor man weiß, was hineingehört
Die meisten Unternehmen haben ihre Prozesse nicht gut genug dokumentiert, um ein vollständiges Briefing aus dem Gedächtnis zu schreiben. Das Briefing muss entdeckt werden.
Die schnellste Methode ist, die Aufgabe zu begleiten. Setzen Sie sich mit der Person zusammen, die den Workflow derzeit ausführt, und beobachten Sie zwanzig reale Fälle. Beschreiben Sie den Workflow nicht abstrakt — beobachten Sie, wie er bei echten Eingaben läuft und echte Ausgaben produziert.
Halten Sie für jeden Fall fest: was ihn ausgelöst hat, welche Informationen verfügbar waren, welche Entscheidung getroffen wurde, was produziert wurde und ob eine Ausnahme behandelt wurde. Nach zwanzig Fällen ist der häufige Fall klar. Ausnahmen, die in diesen zwanzig Fällen aufgetreten sind, werden zu den expliziten Ausnahmeregeln. Fälle, die nicht aufgetreten sind, aber auftreten könnten — solche, die die Person, die die Aufgabe erledigt, aus Erfahrung beschreiben kann — kommen in den Eskalationspfad.
Eine Begleitungssession produziert einen Briefing-Entwurf. Der Entwurf wird dann gegen fünf reale Eingaben getestet, die nicht Teil der Session waren. Jede Lücke, die in diesem Test auftaucht, ist eine fehlende Zeile im Briefing.
Die richtige Person zur Begleitung wählen
Die Person, die die Aufgabe derzeit ausführt – nicht die, die sie am besten erklärt. Der Erklärer kennt den Idealfall. Der Ausführende kennt, was tatsächlich passiert.
20 reale Fälle beobachten, keine Beispiele
Den Workflow mit echten Eingaben und echten Ausgaben beobachten. Beschriebene Beispiele spiegeln, was die Person zu tun glaubt. Beobachtete Fälle spiegeln, was sie tatsächlich tut – einschließlich Variationen, die ihr nicht bewusst sind.
Dieselben fünf Felder für jeden Fall festhalten
Was ihn auslöste, welche Informationen verfügbar waren, welche Entscheidung getroffen wurde, was produziert wurde und ob eine Ausnahme behandelt wurde. Konsistente Aufzeichnung über 20 Fälle offenbart Muster, die eine Beschreibung nie würde.
Den häufigen Pfad identifizieren
Nach 20 Fällen ist der Hauptpfad aus dem Muster klar. Dieser wird zum primären Fall des Briefings.
Ausnahmeregeln aus realen Fällen extrahieren
Ausnahmen, die in den 20 Fällen aufgetreten sind, werden explizit im Briefing benannt. Jede spezifiziert die Bedingung und den anderen Pfad. „Wenn X, dann stattdessen Y" – nicht „angemessen damit umgehen."
Den Eskalationspfad für alles andere schreiben
Fälle, die nicht aufgetreten sind, aber auftreten könnten, kommen mit einer spezifischen Aktion in den Eskalationspfad. Der Eskalationspfad ist die Definition von „Ich weiß nicht" im Briefing – er darf nicht undefiniert bleiben.
Den Entwurf gegen fünf neue reale Eingaben testen
Fünf Eingaben, die nicht in der ursprünglichen Session waren. Jede Lücke, die auftaucht, ist eine fehlende Zeile. Vor dem Build beheben, nicht danach.
Die häufigsten Briefing-Fehler
Die meisten Briefing-Lücken sind beim Schreiben nicht offensichtlich – sie zeigen sich im Produktivbetrieb, nach Abschluss des Builds, als Korrekturarbeit, die wie ein Agentenproblem aussieht.
| Fehler | Wie er im Briefing aussieht | Was er im Produktivbetrieb produziert |
|---|---|---|
| Beschreibung statt Auslöser | „Wenn ein Lead nachgefasst werden muss" | Agent löst inkonsistent aus; verschiedene Läufe produzieren verschiedene Ergebnisse |
| Allgemeine Eingaben statt Feldnamen | „Die CRM-Informationen zum Kontakt" | Agent scheitert bei Datensätzen mit fehlenden Feldern; Fehler sind unvorhersehbar |
| Ausgabekategorie statt Format | „Eine Follow-up-E-Mail" | Ausgabeformat variiert bei jedem Lauf; Team bearbeitet jede Ausgabe vor dem Senden |
| Keine Ausnahmeregeln | Briefing deckt nur den Hauptpfad ab | Agent wendet Hauptpfad-Logik auf Minderheitsfälle an; falsche Ausgaben häufen sich |
| Kein Eskalationspfad | „Der Agent wird damit umgehen" | Undefinierte Eingaben produzieren überzeugend aussehende, aber falsche Ausgaben |
| Brief aus Idealdaten geschrieben | Alle Beispiele mit vollständigen Datensätzen | Agent scheitert bei unvollständigen, inkonsistenten oder ungewöhnlichen Daten |
Jede Zeile dieser Tabelle ist eine Briefing-Zeile, die nie geschrieben wurde. Jede wird zu Korrekturarbeit nach dem Launch.
Wie man ein Briefing vor dem Build validiert
Ein Briefing fühlt sich vollständig an, wenn es geschrieben wird. Die Lücken erscheinen erst, wenn es gegen Eingaben getestet wird, für die es nicht geschrieben wurde.
Der Neue-Mitarbeiter-Test. Das Briefing ausdrucken und an jemanden ohne Kenntnis des Workflows geben. Ihn bitten, zu beschreiben, was er bei einer realen Eingabe tun würde. Wenn er eine Frage stellt, die das Briefing nicht beantwortet, ist das eine fehlende Zeile. Wenn er etwas anderes beschreibt, als der Workflow tatsächlich erfordert, hat das Briefing eine Mehrdeutigkeit, die der Agent falsch auflöst.
Der Ausnahmendurchlauf. Fünf reale Eingaben aus den letzten 30 Tagen nehmen, die eine ungewöhnliche Entscheidung erforderten. Jede durch das Briefing führen: Spezifiziert das Briefing, was der Agent tun soll? Wenn die Antwort „angemessen damit umgehen" oder „Urteil verwenden" ist, produziert diese Eingabe im Produktivbetrieb eine falsche Ausgabe.
Ein Briefing, das beide Tests besteht, ist keine Garantie für Vollständigkeit – es gibt immer Grenzfälle. Aber ein Briefing, das einen der Tests nicht besteht, erzeugt Korrekturen ab Woche drei. Die Revisionskosten vor dem Build werden in Stunden gemessen. Die Korrekturkosten nach dem Go-live – und das Team absorbiert sie als Hintergrundoverhead – in Wochen, nicht Tagen.
Wie das Briefing zur Implementierung wird
Ein vollständiges Briefing ist keine Vorbereitung für die Implementierung. Es ist die Implementierung.
Die fünf Fragen im Briefing entsprechen direkt den fünf Komponenten eines Agentensystems: Auslöserlogik, Eingabeschema, Ausgabevorlage, bedingte Weiterleitung und Fallback-Behandlung. Ein Entwickler, der ein vollständiges Briefing erhält, braucht keinen langen Discovery-Prozess. Das Briefing sagt ihm, was er bauen soll.
Das Schreiben eines vollständigen Briefings für einen fünfstufigen Workflow dauert üblicherweise zwei bis drei Stunden — einschließlich der Begleitungssession. Das Bauen des Agenten auf Basis eines vollständigen Briefings dauert oft weniger Zeit als das.
Das Briefing ist der Ort, an dem die Qualität jeder Implementierung entschieden wird. Jede Stunde, die damit verbracht wird, es vor dem Start zu vervollständigen, ist eine Stunde, die nicht damit verbracht wird, Ausgaben nach dem Start zu korrigieren.
Häufig gestellte Fragen
Was ist ein KI-Agenten-Briefing?
Ein Agenten-Briefing ist eine Spezifikation eines Geschäftsprozesses — Auslöser, Eingaben, Ausgabeformat, akzeptable Ausnahmen und Eskalationspfad. Ein Briefing ist kein Prompt. Ein Briefing ist präzise genug, dass ein neuer Mitarbeiter ohne Vorwissen den Workflow am ersten Tag korrekt ausführen könnte. Das Schreiben ist eine Prozessdokumentationsübung — keine Prompt-Schreibübung.
Welche fünf Fragen muss ein Agenten-Briefing beantworten?
Jedes Briefing muss beantworten: was den Agenten auslöst, welche Eingaben der Agent erhält, was der Agent produziert, welche Ausnahmen akzeptabel sind und was der Agent tut, wenn er keine Entscheidung treffen kann. Ein Briefing, dem eine dieser Fragen fehlt, ist unvollständig — und jede Lücke wird zu einem Grenzfall, der im Produktivbetrieb eine falsche Ausgabe produziert.
Was passiert, wenn ein Briefing unvollständig ist?
Der Agent funktioniert in den ersten zwei Wochen korrekt bei Eingaben, die den gebrieften Fällen entsprechen. Dann kommen Grenzfälle. Jeder, den das Briefing nicht abgedeckt hat, produziert eine Ausgabe, die das Team korrigieren muss. Über einen Monat hinweg übersteigt der Korrekturaufwand oft den Aufwand für manuelle Bearbeitung. Jede Korrektur nach dem Start ist eine Briefing-Zeile, die nie geschrieben wurde.
Wie schreibt man ein Briefing, wenn der Prozess nicht dokumentiert ist?
Begleiten Sie die Aufgabe: Beobachten Sie die Person, die den Workflow aktuell ausführt, bei zwanzig realen Fällen. Halten Sie für jeden Fall fest: was ihn auslöste, welche Informationen verfügbar waren, welche Entscheidung getroffen wurde, was produziert wurde und ob eine Ausnahme behandelt wurde. Nach zwanzig Fällen ist der häufige Fall klar. Grenzfälle, die aufgetreten sind, werden zu expliziten Ausnahmeregeln. Fälle, die auftreten könnten, aber nicht aufgetreten sind, kommen in den Eskalationspfad.