Ein zweiter KI-Agent kann schwieriger abzugrenzen sein, wenn er von Entscheidungen aus dem ersten Build abhängt. Ausgeschlossene Sonderfälle, teilweise Verbindungen und manuell behandelte Ausnahmen werden zu Abhängigkeiten. Dokumentieren Sie diese Grenzen, bevor Sie annehmen, dass die vorhandene Einrichtung einen weiteren Workflow unterstützt.
Ein enger erster KI-Agent kann gut funktionieren und trotzdem Entscheidungen außerhalb seines Umfangs lassen. Beim nächsten Workflow können vorhandene Tools und Verbindungen helfen. Sie können auch undokumentierte Einschränkungen mitbringen. Prüfen Sie diese Grenzen, bevor Sie die erste Einrichtung als wiederverwendbar behandeln.
Warum ist der erste Agent einfach?
Ein erster Workflow kann von bewusst engem Umfang profitieren. Dokumentieren Sie ausgeschlossene Fälle, vereinbarte manuelle Behandlung und Berechtigungsgrenzen im Build. Ein funktionierender Kernworkflow lässt diese Ausschlüsse nicht für das nächste Projekt verschwinden.
Ein enger Umfang ist sinnvoll, wenn die enthaltenen Fälle zuverlässig funktionieren und Ausnahmen eine Zuständigkeit haben. Undokumentierte Entscheidungen werden zum Problem: ignorierte Eingaben, teilweise Verbindungen und akzeptierte Ausgabegrenzen können spätere Arbeit beeinflussen.
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.
Was erbt der zweite Agent vom ersten?
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 kann Code oder Verbindungen wiederverwenden. Er stützt sich außerdem auf Entscheidungen des ersten Builds. Eine CRM-Verbindung kann nur lesen, während der neue Workflow schreiben muss. Eilbestellungen können manuell geblieben sein, während der neue Workflow ein zuverlässiges Eilbestellungsfeld braucht. Prüfen Sie diese Abhängigkeiten vor der Wiederverwendung.
Die Wiederverwendung einer Verbindung übernimmt auch deren Grenzen: ausgeschlossene Fälle, eingeschränkte Berechtigungen und manuelle Ausnahmepfade. Dokumentieren Sie diese, bevor ein weiterer Workflow davon abhängt.
Das sind Abhängigkeiten, die Dokumentation sichtbar machen kann. Manche brauchen eine Geschäftsregel, andere eine Berechtigungsprüfung oder zusätzliche Verbindungsarbeit. Frühe Identifikation hilft, den neuen Umfang realistisch zu halten.
Wo scheitern zweite Builds typischerweise?
Drei hilfreiche Prüfmuster sind Scope-Creep, Verbindungskonflikte und geerbte Annahmen. Sie sind Planungsrisiken, keine gemessene Rangfolge der Ursachen für das Scheitern zweiter Agenten. In McKinseys Umfrage vom Mai 2024 sagte die Hälfte der Befragten, dass ihre Organisation KI in mindestens zwei Geschäftsfunktionen einsetzt.[1] Das beschreibt die Verbreitung, nicht die primäre Hürde eines zweiten Agenten-Builds.
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.
Annahmenvererbung. 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 |
| Annahmenvererbung | 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 sollten Sie prüfen, 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.
Der Prüfaufwand hängt vom ersten Workflow, vorhandener Dokumentation und den Personen ab, die Ausnahmen erklären können. Klären Sie Zugriff und benötigte Nachweise vor einer Schätzung. Ein pauschales Versprechen von zwei bis vier Stunden kann fehlende Aufzeichnungen oder eine Berechtigungsprüfung verdecken.
Diese Prüfung kann Annahmen sichtbar machen, bevor sie zu Abhängigkeiten des zweiten Builds werden. Sie garantiert keinen Starttermin und verhindert nicht jedes spätere Problem. Prüfen Sie gemeinsame Regeln weiter, wenn sich die Workflows verändern. Siehe warum Projekte nach dem Start ins Stocken geraten können.
Wie verhindern Sie, dass zwei Agenten denselben Datensatz verändern?
Legen Sie vor dem Schreibzugriff des zweiten Agenten die Zuständigkeit für jedes gemeinsame Feld fest. Ändert ein Agent eine Deal-Phase, während der andere ein Follow-up vorbereitet, muss klar sein, welcher Zustand gilt, wann der zweite ihn erneut prüft und wer einen Konflikt auflöst. Testen Sie beide am selben Beispieldatensatz vor echten Änderungen.
Begrenzen Sie die Berechtigungen jedes Agenten auf seine Aufgabe. Eine wiederverwendete Verbindung darf dem zweiten nicht unbemerkt breiteren Zugriff geben. Protokollieren Sie, welcher Workflow eine Änderung vorgenommen hat, halten Sie mehrdeutige Aktualisierungen zur Prüfung an und testen Sie den ersten Workflow nach Änderungen gemeinsamer Felder oder Berechtigungen erneut.
Checkliste für den zweiten KI-Agenten herunterladen (PDF)
Häufig gestellte Fragen
Warum kann der zweite KI-Agent schwieriger zu bauen sein als der erste?
Er kann von ausgeschlossenen Sonderfällen, teilweisen Verbindungen oder manuell behandelten Ausnahmen des ersten Builds abhängen. Vorhandene Infrastruktur hilft nur bei verstandenen Grenzen. Das ist ein Planungsrisiko, keine Aussage, dass jeder zweite Agent schwieriger ist.
Was ist Annahmenvererbung bei KI-Agent-Implementierungen?
Ein weiterer Workflow stützt sich auf eine undokumentierte Datenstruktur, Benennungskonvention oder Prozessregel des ersten Builds. Wird diese gemeinsame Regel veraltet, können beide Workflows falsche Ausgaben erzeugen. Benennen Sie Verantwortung und testen Sie die gemeinsamen Regeln.
Was sollten Sie prüfen, bevor Sie einen zweiten KI-Agenten bauen?
Prüfen Sie ausgeschlossene Fälle, Verbindungen und Berechtigungen, manuelle Ausnahmebehandlung sowie die Übereinstimmung aktueller Ausgaben mit den Geschäftsanforderungen. Identifizieren Sie außerdem gemeinsame Felder und die jeweiligen Änderungsrechte.
Welche Fehlermuster sollten Sie beim zweiten Agenten-Build prüfen?
Prüfen Sie Scope-Creep durch benachbarte Aufgaben, widersprüchliche Verbindungsanforderungen und geerbte Annahmen. Halten Sie den neuen Workflow separat abgegrenzt und testen Sie den ersten nach Änderungen gemeinsamer Felder oder Berechtigungen erneut.
Wie lange dauert die Prüfung des ersten Agenten?
Der Aufwand hängt von Workflow-Breite, Dokumentation, Ausnahmehistorie und Zugriffsprüfungen ab. Vereinbaren Sie die benötigten Nachweise vor der Schätzung. Ein universelles Zwei-bis-vier-Stunden-Audit oder die garantierte Vermeidung späterer Verzögerungen ist nicht belegt.
Warum kann Scope-Creep beim zweiten Agenten-Build auftreten?
Ein verwandter Workflow kann wie eine kleine Erweiterung aussehen. Dadurch werden Aufgaben und Ausnahmen mit unterschiedlichen Regeln zusammengelegt. Definieren Sie Auslöser, Ausgabe, Berechtigungen und Eskalation des zweiten Workflows unabhängig, bevor Sie über gemeinsame Teile entscheiden.
Quellen
- McKinsey & Company, „The state of AI in early 2024: Gen AI adoption spikes and starts to generate value“, 30. Mai 2024. Historische Umfrage zur Nutzung in Geschäftsfunktionen, kein Ergebnis über die Ursachen gescheiterter zweiter Agenten.
