Die meisten Unternehmen stellen fest, dass der zweite KI-Agent schwieriger ist als der erste. Der erste Agent war erfolgreich, weil der Umfang eng gehalten wurde — und die Entscheidungen dahinter wurden nie dokumentiert. Der zweite Build legt sie offen: ausgeschlossene Sonderfälle, unvollständige Integrationen, Ausnahmepfade, die manuell abgewickelt und nie formalisiert wurden. Das Bauen auf undokumentierten Annahmen ist das, was die zweite Implementierung schwieriger macht.
Der erste KI-Agent gelingt fast immer. Der Umfang wurde eng gehalten, Entscheidungen wurden schnell getroffen, und der Agent wurde zuverlässig für den Kernworkflow eingesetzt. Drei Monate später identifiziert der Gründer den nächsten Workflow, der automatisiert werden soll. Das Team ist bereits eingerichtet. Die Integrationen sind bereits vorhanden. Der zweite Build sollte schneller sein. Das ist er meist nicht — denn der zweite Agent erbt alles, was der erste stillschweigend entschieden hat, zu überspringen.
Der erste Agent ist einfach, weil der Umfang erzwungen wird
Wenn ein Unternehmen seinen ersten KI-Agenten aufbaut, gelingt die Implementierung zum Teil, weil der Umfang künstlich klein gehalten wurde. Ein erfahrener Implementierungspartner widerspricht jedem Sonderfall und jeder Ausnahme. Diese Punkte werden als nicht im Umfang des ersten Builds enthalten protokolliert. Der Agent wird eingesetzt. Das Projekt ist ein Erfolg.
Diese Verdichtung ist der richtige Ansatz für einen ersten Build. Ein Agent, der 80 % eines Workflows zuverlässig abwickelt, ist nützlicher als einer, der 100 % gelegentlich bewältigt. Aber ein enger Umfang hat einen Nebeneffekt: Der erste Build erzeugt ein funktionierendes System auf der Grundlage undokumentierter Entscheidungen — welche Eingaben der Agent ignoriert, welche nachgelagerten Systeme nur teilweise verbunden wurden, welche Ausgaben als gut genug akzeptiert wurden, als das Unternehmen noch herausfand, was gut bedeutet.
Den ersten Workflow eng und unkompliziert zu halten ist eine solide Implementierungspraxis. Aber die Entscheidungen, die ihn eng gemacht haben, müssen für die folgende Arbeit dokumentiert werden.
Der zweite Agent erbt, was der erste übersprungen hat
Der zweite Workflow, den ein Unternehmen automatisiert, ist meist dem ersten benachbart — dasselbe Toolset, dasselbe Team, schneller zu bauen, weil die Infrastruktur bereits vorhanden ist. Diese Logik ist stichhaltig. Die Annahme dahinter oft nicht.
Der zweite Agent teilt nicht den Code des ersten. Der zweite Agent erbt die undokumentierten Entscheidungen des ersten. Die CRM-Integration wurde mit einem Nur-Lese-Token verbunden, weil der Schreibzugriff eine Sicherheitsprüfung erfordert hätte, die den Launch verzögert hätte. Der zweite Agent muss schreiben. Der Ausnahmepfad für Eilbestellungen wurde aus dem ersten Build ausgeschlossen und seitdem manuell abgewickelt. Der Workflow des zweiten Agenten hängt davon ab, ob eine Bestellung eine Eilbestellung ist. Dieses Feld wurde nie standardisiert.
Der zweite Agent erbt nicht den Code des ersten — er erbt die undokumentierten Entscheidungen des ersten: welche Sonderfälle stillschweigend ausgeschlossen wurden, welche Integrationen unvollständig blieben, welche Ausnahmepfade nie formalisiert wurden.
Das sind keine technischen Fehler, sondern Dokumentationsfehler. Die Entscheidungen, die während des ersten Builds getroffen wurden, erschienen damals offensichtlich und wurden nie aufgeschrieben. Der zweite Build ist der Punkt, an dem diese Entscheidungen zu Einschränkungen werden.
Wo zweite Builds typischerweise scheitern
Bei zweiten KI-Agent-Implementierungen treten drei Fehlermuster konsistent auf.
Scope-Creep durch Nachbarschaft. Da der zweite Workflow dem ersten benachbart ist, versuchen Teams, den ersten Agenten zu erweitern oder beide Workflows in einen einzigen zu integrieren. Die Umfangsdisziplin, die Agent 1 erfolgreich gemacht hat, wird mit der Begründung aufgegeben, dass der zweite Workflow im Grunde dasselbe ist. Dort tritt die Komplexität ein.
Integrationskollision. Der erste Agent verband sich mit einem gemeinsamen Tool auf eine Weise, die für seinen spezifischen Job funktionierte. Der zweite Agent benötigt dasselbe Tool für eine andere Aufgabe — andere Berechtigungen, andere Feldzuordnungen, andere Auslöserlogik. Wenn niemand dokumentiert hat, wie die erste Verbindung aufgebaut wurde und warum, beginnt der zweite Build damit, Entscheidungen rückzuentwickeln, die vor Monaten von jemandem getroffen wurden, der möglicherweise nicht mehr beteiligt ist.
Annahmenannahme. Beide Agenten teilen eine Annahme, die beim Aufbau des ersten sinnvoll war, aber nicht mehr zutrifft — eine Benennungskonvention für Verkaufsphasen, eine Produkttaxonomie, eine Kundenkategorisierung. Kein Agent ist einzeln falsch. Beide Agenten erzeugen gemeinsam fehlerhafte Ausgaben, auf eine Weise, die sich verstärkt.
| Fehlermuster | Wie es auftritt | Prävention |
|---|---|---|
| Scope-Creep durch Nachbarschaft | Der zweite Build wird als Erweiterung des ersten gerahmt; Sonderfälle aus beiden gelangen in den Umfang | Den zweiten Build unabhängig vom Workflow-Ähnlichkeitsgrad als separaten Umfangsplanungsprozess behandeln |
| Integrationskollision | Der zweite Agent benötigt eine Tool-Verbindung, die anders aufgebaut ist als beim ersten | Die Verbindungsmethode und Berechtigungen des ersten Agenten vor dem Schreiben des zweiten Umfangs dokumentieren |
| Annahmenannahme | Beide Agenten erzeugen gemeinsam fehlerhafte Ausgaben, ohne dass einer einzeln falsch ist | Gemeinsame Datenstrukturen und Namenskonventionen prüfen, bevor der zweite Brief geschrieben wird |
Der erste Agent funktionierte, weil jemand den Umfang erzwungen hat. Der zweite zeigt alles, was herausgezwungen wurde.
Was Sie prüfen sollten, bevor Sie Build 2 planen
Der zweite Build ist der Zeitpunkt, an dem Implementierungsschulden sichtbar werden. Um dies zu verhindern, ist eine explizite Prüfung des ersten Agenten erforderlich, bevor der zweite Umfang festgelegt wird.
Die Prüfung umfasst vier Punkte. Erstens: Dokumentieren Sie jeden Sonderfall, der explizit aus dem ersten Build ausgeschlossen wurde, und warum. Zweitens: Überprüfen Sie die Integrationsschicht — jedes verbundene Tool, welche Berechtigungen verwendet wurden, welche Felder zugeordnet wurden und was unmapped blieb. Drittens: Prüfen Sie die Ausnahmepfade — die Eingaben, die der erste Agent als nicht behandelbar markiert, und den manuellen Prozess, der diese derzeit abdeckt. Viertens: Überprüfen Sie die Ausgaben — nicht ob der Agent läuft, sondern ob diese Ausgaben noch der aktuellen Definition des Unternehmens von Erfolg für diesen Workflow entsprechen.
Ausgeschlossene Sonderfälle dokumentieren
Rufen Sie das Ausnahme-Log des ersten Agenten ab. Listen Sie jeden Eingabetyp auf, der aus dem Umfang ausgeschlossen oder zur manuellen Bearbeitung markiert wurde. Für jeden: War der Ausschluss beabsichtigt und gilt er noch? Ist der zweite Workflow davon abhängig, dass einer dieser Sonderfälle behandelt wird?
Integrationsschicht überprüfen
Für jedes mit dem ersten Agenten verbundene Tool: Welche Berechtigungen wurden verwendet, welche Felder sind zugeordnet, welche Felder sind leer geblieben, und was hat sich in diesen Tools seit dem Aufbau des ersten Agenten geändert? Der zweite Agent, der Schreibzugriff auf ein Tool benötigt, das der erste nur liest, erfordert eine Berechtigungsänderung, die in der Planung identifiziert werden sollte — nicht während des Builds entdeckt.
Ausnahmepfade prüfen
Überprüfen Sie jede Ausnahme, die der erste Agent markiert — was passiert damit nach der Markierung? Gibt es einen manuellen Prozess, der sie seit dem Launch abdeckt? Ist dieser Prozess irgendwo dokumentiert? Wenn der zweite Workflow erfordert, dass diese Ausnahme automatisch behandelt wird, muss die Lösung vor Baubeginn im zweiten Brief stehen.
Aktuelle Ausgaben gegen aktuelle Standards prüfen
Rufen Sie die letzten 30 Ausgaben des ersten Agenten ab und bewerten Sie sie gegen die aktuelle Definition des Unternehmens von korrekt. Wenn der erste Agent gedriftet ist — Ausgaben, die vor sechs Monaten akzeptabel waren, jetzt aber nicht mehr korrekt sind — sollte dieser Drift korrigiert werden, bevor der zweite Agent dieselbe Logik erbt.
Die Prüfung dauert zwei bis vier Stunden für einen Einzelworkflow-Erst-Agenten. Das ist weniger als die Debug-Zeit für einen zweiten Build, der diese Einschränkungen mitten in der Build-Phase entdeckt.
Diese Prüfung fügt dem zweiten Projekt keine Wochen hinzu. Sie verhindert, dass das zweite Projekt drei Monate nach dem Launch ins Stocken gerät, weil der Umfang auf Annahmen aufgebaut wurde, die sechs Monate alt sind.
Häufig gestellte Fragen
Warum ist der zweite KI-Agent schwieriger zu bauen als der erste?
Der zweite Agent erbt undokumentierte Entscheidungen aus dem ersten Build: ausgeschlossene Sonderfälle, unvollständig verbundene Integrationen und Ausnahmepfade, die manuell abgewickelt und nie formalisiert wurden. Der zweite Build legt diese Entscheidungen als Einschränkungen offen, bevor der Umfang überhaupt festgelegt wird.
Was ist Annahmenannahme bei KI-Agent-Implementierungen?
Annahmenannahme tritt auf, wenn der zweite Agent auf Datenstrukturen, Namenskonventionen oder Prozesslogik des ersten Agenten angewiesen ist — ohne dass einer der Agenten diese Abhängigkeiten dokumentiert hat. Wenn die gemeinsame Annahme veraltet, produzieren beide Agenten gemeinsam fehlerhafte Ausgaben.
Was sollten Sie prüfen, bevor Sie einen zweiten KI-Agenten bauen?
Prüfen Sie vor der Planung des zweiten Builds die ausgeschlossenen Sonderfälle des ersten Agenten, seine Integrationsschicht (Berechtigungen, Feldzuordnungen), seine Ausnahmepfade und ob seine aktuellen Ausgaben noch der Definition des Unternehmens von Erfolg für diesen Workflow entsprechen.
Warum tritt Scope-Creep beim zweiten Agenten-Build häufiger auf?
Der zweite Workflow ist dem ersten benachbart, daher versuchen Teams, den ersten Agenten zu erweitern oder beide Workflows zu kombinieren. Die Umfangsdisziplin, die den ersten Build erfolgreich gemacht hat, wird aufgegeben mit der Annahme, der zweite Workflow sei im Grunde dasselbe — und dort tritt die Komplexität ein.