Eine Professional-Services-Firma wollte einen Agenten, der Client-Intake-E-Mails bearbeitet. Das Briefing war klar genug: eingehende E-Mails lesen, CRM auf bestehenden Client-Status prüfen, eine Antwort entwerfen und den Entwurf zur Überprüfung vorlegen. Der Build begann. Drei Wochen später stockte die Prompt-Testphase. Der Agent konnte nicht zuverlässig bestimmen, welche E-Mails als neue Client-Intake-E-Mails galten und welche als Fragen bestehender Clients. Niemand hatte den Unterschied schriftlich definiert. Der Build wurde nach zwei weiteren Wochen wiederaufgenommen, die mit dem Schreiben verbracht wurden, was vor dem Start hätte geschrieben werden sollen.
Workflow dokumentieren
Jeden Schritt, Entscheidungspunkt, Input und Output dokumentieren. Wenn ein neuer Mitarbeiter dies allein aus dem Dokument nicht befolgen könnte, kann der Agent es auch nicht.
Integrationen mappen
Identifizieren, welche Tools der Agent liest und beschreibt, welche Daten jede Verbindung durchlaufen und welche exakte Berechtigungsebene jede Integration benötigt.
Prompts schreiben und testen
Prompts gegen reale Input-Beispiele schreiben. Mit Inputs testen, die der Agent tatsächlich erhalten wird — nicht mit hypothetischen, die darauf ausgelegt sind, zu bestehen.
Edge Cases testen
Inputs senden, für die der Agent nicht entworfen wurde. Mehrdeutigkeiten und Lücken in den Anweisungen finden, bevor das Unternehmen sie in der Produktion findet.
Mit definierten Erfolgskriterien launchen
Vor dem Go-live definieren, wie ein funktionierender Agent in Zahlen aussieht: Task-Completion-Rate, Eskalationsrate, Fehlerrate. Die Baseline festlegen, bevor der erste echte Input läuft.
Stufe 1: Workflow dokumentieren, bevor etwas gebaut wird
Ein Custom Agent ist kein Technologieprojekt. Es ist ein Prozessdefinitionsprojekt, das Technologie zur Ausführung benötigt. Das Prozessdokument ist die Spezifikation, gegen die der gesamte Build läuft. Wenn der Prozess nicht dokumentiert ist, hat der Build keine Spezifikation.
Stufe 1 ist kein vorbereitender Schritt — sie ist der Build. Die technische Implementierung folgt dem Prozessdokument. Wenn der Prozess nicht klar genug ist, um ihn einem neuen Mitarbeiter ohne Kontext zu übergeben, ist er nicht klar genug, um ihn als Agenten zu implementieren.
Ein vollständiges Workflow-Dokument beantwortet fünf Fragen für jeden Schritt im Prozess:
- Was löst diesen Schritt aus? Der spezifische Input oder das Ereignis, das die Aktion startet — eine eingehende E-Mail, eine Formulareinreichung, ein sich aktualisierender Datenbankdatensatz.
- Welche Daten benötigt der Agent? Die spezifischen Felder, aus welchen Systemen, an welchem Punkt im Workflow.
- Welche Entscheidung trifft der Agent? Die Logik: Wenn Input X Bedingung Y erfüllt, tue Z. Wenn nicht, tue W oder eskaliere.
- Was ist der Output? Das genaue Format und Ziel — ein entworfenes E-Mail in Gmail, eine Slack-Nachricht, eine Datensatzaktualisierung in HubSpot.
- Wann muss ein Mensch überprüfen? Jeder Punkt, an dem eine menschliche Genehmigung oder Überschreibung erforderlich ist, bevor der Agent fortfährt.
Die erforderliche Tiefe ist keine Zusammenfassung — es ist das Detailniveau, das einer Person, die mit dem Prozess nicht vertraut ist, ermöglicht, ihn beim ersten Versuch korrekt auszuführen. Alles darunter produziert Mehrdeutigkeiten, die als Bugs in Stufe 3 auftauchen.
Stufe 2: Integrationen auf die exakten Berechtigungen mappen
Jedes Tool, mit dem der Agent verbunden wird, hat ein anderes Berechtigungsmodell. Eine Gmail-Integration, die alle E-Mails liest, und eine Gmail-Integration, die nur markierte E-Mails liest, sind nicht dieselbe Integration — die zweite ist sicherer, wartbarer und weniger anfällig für unerwarteten Zugriff auf nicht zusammenhängende Daten.
Für jedes verbundene Tool gibt die Integrationsmap an: welches System es ist, welche Daten der Agent daraus liest, welche Daten der Agent darin schreibt, die minimale Berechtigungsebene für diese Operationen und wer die Credentials besitzt. Credential-Eigentümerschaft ist wichtig, weil die Integration stillschweigend bricht, wenn ein Teammitglied, das die Integration eingerichtet hat, das Unternehmen verlässt.
Die Richtlinien von Anthropic zum Bau effektiver Agenten identifizieren eingeschränkten Zugriff als wichtigen Zuverlässigkeitsfaktor: Agenten mit minimal notwendigen Berechtigungen scheitern vorhersehbarer und produzieren kleinere Schadensradien, wenn etwas schiefgeht.[¹] "Alle lesen"-Zugriff fühlt sich einfacher zu konfigurieren an und schafft größere, schwieriger zu diagnostizierende Fehlermodi.
Die Integrationsmap dokumentiert auch, was passiert, wenn ein verbundenes Tool nicht verfügbar ist. Wenn das CRM ausgefallen ist, wenn eine Intake-E-Mail eingeht, stellt der Agent die E-Mail in die Warteschlange zum Wiederversuch, eskaliert zu einem Menschen oder entwirft eine Zwischenantwort? Jede Abhängigkeit braucht einen definierten Fallback.
Stufe 3: Prompts gegen reale Inputs schreiben, nicht hypothetische
Ein Prompt, der gegen einen hypothetischen Input geschrieben wurde, wird mit diesem Input erfolgreich sein. Derselbe Prompt wird mit den realen Inputs scheitern, gegen die er nicht geschrieben wurde. Prompts gegen hypothetische Szenarien zu schreiben optimiert für den Test, nicht für den Workflow.
Effektive Prompt-Entwicklung beginnt mit einer Stichprobe von 20–30 realen Inputs aus dem tatsächlichen Prozess — E-Mails, Formulareinreichungen, CRM-Datensätze — repräsentativ für die gesamte Bandbreite der Inputs, die der Agent erhalten wird. Der erste Prompt-Entwurf wird gegen diese Stichprobe getestet. Die Fehlerfälle zeigen Mehrdeutigkeiten in den Anweisungen auf.
Das Prozessdokument ist der Build. Alles danach ist Implementierung.
Für jeden Fehler lautet die Frage: Ist dies ein Prompt-Fehler oder ein Prozessdokumentationsfehler? Wenn der Prompt scheiterte, weil die Anweisungen mehrdeutig waren — der Agent wusste nicht, welchen von zwei gültigen Pfaden er nehmen sollte — muss das Prozessdokument aktualisiert werden, bevor der Prompt überarbeitet wird. Prompts gegen einen unterspezifizierten Prozess zu korrigieren produziert Prompts, die lokal korrekt und global unzuverlässig sind.
Ein gut getesteter Prompt-Satz bearbeitet die 20–30 Stichproben-Inputs korrekt. Stufe 4 ist für alles außerhalb dieser Stichprobe.
Stufe 4: Inputs testen, für die der Agent nicht entworfen wurde
Stufe 4 ist keine Fortsetzung von Stufe 3. Es ist eine andere Übung: absichtlich Inputs zu senden, für die der Agent nicht entworfen wurde, um zu finden, wo die Anweisungen versagen.
Ein strukturierter Edge-Case-Test deckt vier Kategorien ab. Unvollständige Inputs — ein Feld entfernen, das der Prompt als vorhanden annimmt, und testen, was der Agent tut. Mehrdeutige Inputs — einen Input senden, der vernünftigerweise auf zwei verschiedene Arten klassifiziert werden könnte, und testen, welchen Pfad der Agent nimmt. Widersprüchliche Inputs — Daten aus zwei verbundenen Systemen senden, die sich widersprechen, und testen, welcher Quelle der Agent vertraut. Volumen- und Timing-Inputs — Inputs mit einer Rate oder Häufigkeit außerhalb der normalen Verteilung senden und auf reduzierte Performance testen.
Jeder in Stufe 4 gefundene Fehler ist ein vor dem Go-live behobener Bug. Jeder nicht gefundene Fehler wird zu einem Support-Ticket, einer schlechten Ausgabe, die an einen Client gesendet wird, oder einer stillen Degradierung der Agent-Zuverlässigkeit. Stufe 4 sollte nicht komprimiert werden, um einen Launch-Termin einzuhalten. Eine zweiwöchige Stufe 4, die zwölf Edge Cases aufdeckt, verhindert zwölf Produktionsvorfälle.
Stufe 5: Erfolgskriterien vor dem ersten Deployment definieren
Ein Agent, der ohne definierte Erfolgskriterien gestartet wird, kann nicht bewertet werden. Das Team weiß, dass er läuft. Das Team weiß nicht, ob er korrekt läuft, sich verbessert oder degradiert.
Erfolgskriterien werden definiert, bevor reale Inputs laufen — nicht nach der ersten Woche, nicht wenn etwas bricht. Drei Metriken gelten für die meisten Custom-Agent-Builds:
Task-Completion-Rate — der Prozentsatz der Inputs, die der Agent zu einem vollständigen Output ohne Eskalation bearbeitet. Ein neues Deployment in einem gut dokumentierten Workflow sollte innerhalb der ersten zwei Wochen eine Completion-Rate von 70–80% erreichen. Wenn die Rate niedriger ist, muss Stufe 1 oder 3 überprüft werden.
Eskalationsrate — der Prozentsatz der Inputs, die der Agent an einen Menschen weiterleitet, weil die Anweisungen den Fall nicht abdeckten. Hohe Eskalation im ersten Monat ist erwartet und nützlich: sie zeigt reale Edge Cases auf, die Stufe 4 nicht gefunden hat. Eine Eskalationsrate, die nach Monat zwei über 20% bleibt, zeigt an, dass die Prompt-Abdeckung zu eng ist.
Fehlerrate — der Prozentsatz der Ausgaben, die ein prüfender Mensch vor der Genehmigung bearbeitet. Eine sinkende Fehlerrate über drei Monate ist der primäre Indikator dafür, dass der Agent sich verbessert. Eine flache oder steigende Fehlerrate deutet auf Prompt-Drift oder ein Integrationsproblem hin.
Diese Schwellenwerte vor dem Launch zu definieren bedeutet, dass das Team ab Tag eins weiß, wie "Funktionieren" aussieht — und ab Tag dreißig weiß, ob es das hat. Für Kontext, was die Aufrechterhaltung dieser Schwellenwerte nach dem Launch kostet, siehe Was ein Custom Agent wirklich kostet. Für einen Überblick über Custom Agents und wann sie passen, siehe Was ist ein Custom Agent.
Häufig gestellte Fragen
Wie lange dauert es, einen Custom Agent zu bauen? Ein einzelner, klar definierter Workflow dauert 4–8 Wochen von Start bis Launch. Der Zeitplan hängt davon ab, wie vollständig die Prozessdokumentation zu Beginn von Stufe 1 ist, von der Integrationskomplexität, der Anzahl der in Stufe 4 aufgedeckten Edge Cases und dem Genehmigungsprozess für Prompt-Änderungen. Builds, die am häufigsten stocken, stocken in Stufe 1 — der Workflow wurde beschrieben, aber nicht vollständig dokumentiert.
Was ist der häufigste Grund, warum Custom-Agent-Builds scheitern? Mehrdeutige Prozessdokumentation. Der Agent scheitert nicht, weil das Modell die Aufgabe nicht ausführen kann — er scheitert, weil die Anweisungen nicht in genügend Fällen spezifizieren, was zu tun ist. Das Fehlermuster ist konsistent: der Agent performt gut bei häufigen Inputs und scheitert bei Edge Cases, die im Workflow-Dokument nie explizit adressiert wurden.
Wie viele Integrationen sollte ein erster Custom-Agent-Build haben? Eine bis zwei. Jede zusätzliche Integration erhöht die Build-Zeit, den Wartungsaufwand und eine neue Fehlerquelle. Ein erster Build, der sich mit einem oder zwei Tools verbindet und einen Workflow zuverlässig bearbeitet, ist wertvoller als ein Build, der sich mit fünf Tools verbindet und drei Workflows inkonsistent bearbeitet.
Was bedeutet "Edge Cases testen" in der Praxis? Inputs senden, für die der Agent nicht entworfen wurde — unvollständige Inputs mit fehlenden Feldern, mehrdeutige Inputs, die auf zwei Arten klassifiziert werden könnten, Inputs aus zwei Systemen, die sich widersprechen — und testen, was der Agent mit jedem davon tut. Das Ziel ist es, Lücken in den Anweisungen zu finden, bevor das Unternehmen sie findet. Jeder in Tests gefundene Edge Case ist ein weniger Produktionsvorfall.
Quellen
- Anthropic, Building effective agents, 2024. https://www.anthropic.com/research/building-effective-agents