Delegierungsverträge für KI-Agententeams: Umfang, Akzeptanz und Handhabung von Fehlern
Warum die Jobbezeichnungen von Agenten keine fehlerhaften Übergaben verhindern und wie ein Delegierungsvertrag mit durchgesetzten Richtlinien sowie unabhängigen Regeln für Akzeptanz und Fehler überprüft werden kann.
Stellen Sie sich einen Produktwechsel vor, der von drei Agenten bearbeitet wird: Es werden Cursor-Seiteneinstellungen für eine API, den Client, der sie aufruft, sowie die Tests hinzugefügt. Alle drei melden Erfolg, doch der Client kann das, was die API zurückgibt, nicht parsen. Der API-Agent gibt next_cursor aus, der Client-Agent erwartet nextCursor, und der Test-Agent überprüft Mocks, die auf der Annahme des Clients basieren. Jede einzelne Aufgabe scheint erledigt zu sein, doch die kombinierte Änderung versagt bereits bei der ersten echten Anfrage.
Die Benennung der Agenten als Ingenieur, Klientenspezialist und Prüfer sagt nicht aus, welche Schnittstelle gewinnt oder wer das Ergebnis freigibt. Solche Entscheidungen müssen in einem Delegierungsvertrag festgelegt werden, der eine konkrete Zuweisung enthält, in der die Eingaben, der zulässige Umfang, das erforderliche Ausgabeergebnis, die Akzeptanzbedingungen sowie das Vorgehen bei Fehlern benannt werden. Der Wert solcher Verträge ergibt sich daraus, wie das System diese Vereinbarungen nutzt – und nicht daraus, dass ein weiteres Dokument erstellt wird.
Betrachten Sie es in Schichten: Eine Rolle bestimmt, wie ein Agent die Arbeit angeht, während ein Vertrag klarlegt, welche Beiträge zulässig sind. Die Laufzeitrichtlinien legen fest, was ein Agent tatsächlich tun kann, und die Akzeptanzentscheidung bestimmt, ob der Beitrag in einen produktiven Zustand übergeht.
Spezialisierung lässt die Übergabe offen
Eine Rolle beschreibt eine Sichtweise, wie beispielsweise die Suche nach Sicherheitsproblemen, der Aufbau des Clients oder die Kritik am Design. Ein Aufgabenvertrag beschreibt eine bestimmte Aufgabe: Diese Schnittstelle überarbeiten, diese Dateien ändern, diesen Beweis einreichen. Die Laufzeitberechtigungen bestimmen, was der Mitarbeiter tatsächlich lesen, ändern oder ausführen darf.
Durch diese Trennung bleibt eine nützliche Rolle weiterhin nützlich, ohne für alles verantwortlich zu sein. Ein Prüfer kann einen brisanten Änderungsvorschlag erkennen, ohne ihn genehmigen zu dürfen, und ein Ingenieur kann eine überarbeitete Schnittstelle vorschlagen, ohne die Befugnis zu haben, sie zur offiziellen Version zu machen.
Anthropics Forschung zu mehreren Agenten aus August 2026 macht das Abhängigkeitsproblem greifbar. In ihren Experimenten zur Erstellung von Spielen änderten sich die vorgegebenen Rollen sowie eine CEO-ähnliche Hierarchie kaum, und die Spiele blieben schlecht – obwohl einige Modelle bei Koordinationsmaßnahmen bessere Ergebnisse erzielten. Derselbe Bericht weist auf korreliertes Verhalten sowie korrelierte Fehler hin. Diese Ergebnisse stammen aus spezifischen Experimenten und sagen nichts Endgültiges über jedes Agententeam aus; zudem unterscheiden sich ihre Vergleiche zur Vulnerabilitätsfindung in Umfang und Ressourcennutzung, weshalb Rohdatenzusammenfassungen nicht eruieren können, welcher Anteil auf die Koordination zurückzuführen ist.
Es existiert ein Gegenbeispiel. Anthropics technische Dokumentation zu seinem Forschungssystem berichtet von Vorteilen durch parallele Forschungsarbeiten und beschreibt Aufgaben mit Zielen, Ausgabeformaten, Tool-Anleitungen sowie Grenzen. Zudem wird ein höherer Ressourcenverbrauch angegeben und vor Arbeiten mit vielen Abhängigkeiten gewarnt. Das spricht dafür, die Aufgabenzerlegung ernst zu nehmen, zeigt aber nicht, dass eine Forschungsarchitektur unverändert in die Ingenieurarbeit in einer gemeinsamen Codebasis übertragen werden kann.
Der Vorschlag hier bezieht sich auf die Grenze zwischen delegierter und übernommener Arbeit. Ob das Explizit Machen dieser Grenze sich durch die damit verbundenen Aufwände lohnt, muss getestet werden.
Die Aufgabe um die Abhängigkeit herum formulieren
Zur Änderung der Paginierung sollte zunächst der Produktverantwortliche das gewünschte Verhalten korrigieren und der API-Verantwortliche die Schnittstelle freigeben. Angenommen, die Schnittstelle verwendet next_cursor, wobei null die letzte Seite kennzeichnet. API- und Client-Prozesse können anschließend auf einer bestimmten Revision arbeiten, während Akzeptanztests das zusammengeführte Ergebnis überprüfen.
Der folgende YAML-Text dient als Beispiel für einen Vertrag für den Client-Prozess. Die darin enthaltenen Pfade, Revisionsnamen und Prüfidentifikatoren gehören zum Beispiel und stellen weder ein Standardformat noch einen Bestandteil einer Framework-API dar.
task_id: pagination-client-17
objective: Fetch successive pages using next_cursor; stop at null.
inputs:
repository:
ref: product-repo
revision: base-42
requirement:
ref: pagination-behavior
revision: r3
interface:
ref: api/pagination.yaml
revision: r7
scope:
writable:
- client/pagination.ts
- tests/client/pagination.test.ts
non_goals:
- interface_changes
- api_changes
- deployment
deliverable:
- patch_against_base-42
- check_results_bound_to_patch_and_input_revisions
acceptance:
checks:
- client-pagination-unit
- pagination-api-client-e2e
owner: product-maintainer
policy_ref: client-worker-v2
failure:
stale_or_conflicting_input: stop_and_report_to_owner
missing_evidence: return_incomplete
authority_required: request_owner_decision
max_attempts: 2
exhausted: return_unaccepted_to_owner
Die Namen der Prüfungen müssen auf echte Befehle und Aussagen in einem Register verweisen, das vom Ausführer kontrolliert wird. In diesem Beispiel bezeichnen sie Einheitenprüfungen zur Cursorverarbeitung sowie eine End-to-End-Prüfung, die mehrere Seiten anhand der tatsächlichen Kandidaten-API durchläuft, einschließlich des schließenden null. Der Client-Worker kann seine eigenen Einheitenprüfungen ausführen, während der Integrationsschleifer die kombinierten Nachweise erstellt, sobald beide Patches vorhanden sind.
Ebenso bezeichnet policy_ref lediglich eine Richtlinie. Der Dispatcher muss die genehmigte Zuweisung an einen authentifizierten Worker binden und die Richtlinie in einer Konfiguration nachschlagen, die der Worker nicht ändern kann. Eine unbekannte Referenz oder eine Anfrage nach einer strengeren Richtlinie muss die Validierung scheitern lassen, und das Bearbeiten der YAML-Datei sollte niemals zusätzlichen Zugriff gewähren.
Die Beschränkung der Arbeit auf zwei Versuche ist eine lokale Entscheidung, die die Reparaturzyklen begrenzt, sagt aber nichts über Zuverlässigkeit aus. Ein vom Betreiber festgelegtes endliches Ausführungsbudget stellt sicher, dass kein einzelner Versuch ewig andauert.
Eine strukturierte Aufgabe ist keine Autorisierungsgrenze. YAML kann den beabsichtigten Umfang beschreiben, doch der Laufzeitumgebung bleibt es überlassen, ihn durchzusetzen.
Ein Schritt-für-Schritt-Verlauf, der den Vertrag Wirklichkeit werden lässt
Rund um die Worker gibt es einen Schritt-für-Schritt-Verlauf. Das „Harness“ ist hier einfach die Software, die die Worker startet, ihre Tools vermittelt und das Geschehene aufzeichnet.
- Genehmigung der Abhängigkeiten: Die Betreiber von Produkt und API geben die Anforderungen sowie die Schnittstelle frei.
- Validierung der Zuweisung: Der Verfasser stellt den Vertrag sowie die finalen Überarbeitungen bereit.
- Auslösung nach festgelegter Richtlinie: Der Dispatcher startet isolierte API- und Client-Worker.
Die Aufgabe kann von einem Menschen oder von einem anderen Agenten erstellt werden. Anschließend finden zwei Überprüfungen statt. Ein deterministischer Validator überprüft die Struktur sowie die Korrektheit aller Verweise, während der zuständige Verantwortliche sicherstellt, dass der Text tatsächlich die Produktanforderungen widerspiegelt. Danach wartet der Dispatcher, bis alle notwendigen Abhängigkeiten genehmigt sind, lädt die festgelegten Eingaben hoch und startet jeden Worker innerhalb seiner Grenzen.
Vier Fragen müssen getrennt bleiben. Die Gültigkeit des Schemas prüft, ob die erforderlichen Felder vorhanden sind und korrekt formatiert sind. Die semantische Angemessenheit prüft, ob die Zuweisung die richtige Aufgabe beschreibt. Die Durchsetzung von Berechtigungen prüft, ob ein Mitarbeiter seine Befugnisse überschreiten kann. Die Ergebnisüberprüfung prüft, ob das kombinierte Produkt den Anforderungen entspricht. Ein strukturell gültiges Dokument beantwortet nur die erste Frage.
Zur Durchsetzung muss eine Liste der schreibbaren Pfade zu einer echten Laufzeitbeschränkung werden, die durch eine Überprüfung geänderter Dateien bei der Integration gestützt wird. Der Shell-Zugriff darf keinen zweiten Weg um die Datei- oder Netzwerkkontrollen herum bieten. Ein separater Checkout hält Vorschläge voneinander getrennt, stellt aber für sich genommen keine Autorisierungsgrenze dar.
Gibehous Ankündigung zu den verwalteten Berechtigungen vom 9. September beschreibt Abläufe, die zentral blockiert werden, eine Genehmigung erfordern oder gestattet sind, wobei es Grenzen gibt, die durch Workspace-Einstellungen nicht gelockert werden können. Seine Beschreibung der Architektur für agierende Workflows erläutert isolierte Ausführungen sowie schrittweise, überprüfte Schreibvorgänge. Beides sind Beispiele für Durchsetzungsmechanismen, und keines davon beweist, dass dieses Delegierungsdesign die Lieferung verbessert oder korrekte Änderungen garantiert.
Eigentum am zusammengeführten Ergebnis
In dem Beispiel zur Paginierung verschmilzt der Integration Runner die Vorschläge aus API und Client in einem temporären Kandidaten-Workspace. Er prüft den Umfang, überprüft die Eingabenversionen und führt die registrierten Akzeptanzprüfungen genau gegen diesen Kandidaten durch. Der Verantwortliche für die Akzeptanz liest anschließend die Beweise und bewertet alle produktbezogenen Entscheidungen, die die Prüfungen nicht klären können.
Unabhängige Akzeptanz bedeutet, dass der Mitarbeiter, der die Arbeit erledigt hat, nicht allein über die Kriterien und die Beweise entscheidet. End-to-End-Aussagen sowie Fixtures bleiben außerhalb des Schreibzugriffs des Mitarbeiters, und die Ergebnisse werden mit dem Kandidaten-Digest verknüpft. Die Akzeptanz kann deterministische Überprüfungen mit einem menschlichen Betreuer kombinieren, wobei ein weiteres LLM optional ist. Die Benennung eines Modells als Supervisor schafft keine Autorität und macht dessen Urteil nicht vertrauenswürdiger.
Nur ein autorisierter Eigentümer darf die Akzeptanzkriterien ändern, und zwar mit einem aufgezeichneten Grund sowie einer neuen Überarbeitung der Zuweisung. Der ausführende Agent kann einen Änderungswunsch stellen, darf jedoch keinen fehlerhaften Test aus dem Testumfang ausschließen oder die Paginierung nach einer Seite als abgeschlossen umdefinieren.
Schließlich übernimmt ein autorisierter Integrator den akzeptierten Kandidaten über den bereits vorhandenen, geschützten Merge-Pfad. Die Akzeptierungsprotokolle nennen den genauen Kandidaten sowie die betroffenen Eingaberevisionen. Sollte der Zielzweig vor der Integration weiterentwickelt werden, wird der Kandidat neu erstellt und zunächst erneut gegen die neue Basis überprüft.
Ausgaben, die in Konflikt geraten, werden an denjenigen zurückgegeben, der für die umstrittene Grenze verantwortlich ist. Zwei plausible Schnittstellen bleiben weiterhin zwei inkompatible Schnittstellen – solange dieser Verantwortliche keine Entscheidung trifft, wird keines der Vorschläge allein durch seine frühere Einreichung zur gemeinsamen Definition.
Fehlerbehandlung gehört zum selben Workflow
Jeder dieser Fälle sollte getrennt voneinander im Paginierungsworkflow getestet werden, wobei eine erwartete Reaktion sowie eine zuständige Stelle zur Durchsetzung festgelegt werden müssen.
Sollten beide Mitarbeiter versuchen, die Schnittstelle zu ändern, lehnt der Dispatcher ein überlappendes Eigentumsrecht ab und Laufzeitbeschränkungen verhindern die unbefugte Bearbeitung. Die Integration lehnt jeden Patch ab, der außerhalb seines zugewiesenen Umfangs liegt, und der API-Eigentümer entscheidet über die beantragte Änderung.
Falls sich die Schnittstellenversion während der Bearbeitung ändert, markiert die Abhängigkeitsprüfung den Vorschlag als veraltet. Der Eigentümer entscheidet, ob er ihn unter Berücksichtigung der neuen Version erneut einreicht, und die Integration darf die für die alte Version gesammelten Beweise nicht einfach akzeptieren.
Wenn plausibler Code ohne entsprechende Beweise auftaucht, registriert das Akzeptanzsystem dies als unvollständig. Ein vertrauenswürdiger Ausführender führt die erforderlichen Prüfungen durch, und eine selbstsichere Bestätigungsmitteilung kann die Ergebnisse nicht ersetzen.
Wenn ein Worker auf halbem Weg stoppt, protokolliert das Harness die Unterbrechung und behält den teilweisen Vorschlag für sich. Bevor mit der Ersetzungsarbeit begonnen wird, wird der alte Versuch zurückgezogen, damit er später kein akzeptiertes Ergebnis einreichen kann.
Falls eine erneute Ausführung dazu führen könnte, dass derselbe Vorschau-Umgebung zweimal erstellt wird, vereinbart der externe-Aktion-Adapter zunächst die frühere Anfrage. Wo der Anbieter die Deduplizierung unterstützt, wird eine stabile Betriebskennung verwendet, und die noch unklaren Auswirkungen werden zum Überprüfen an den zuständigen Benutzer weitergeleitet.
Falls die Integration Berechtigungen erfordert, die der Worker nicht besitzt, blockiert die Tool-Policy die Aktion und sendet eine Anfrage an den richtigen Benutzer. Der Vorschlag bleibt unakzeptiert, bis diese Entscheidung vorliegt.
Das Szenario des Vorschauumfelds ist ein optionales Add-on zum Beispiel, das vom Integrationsservice bereitgestellt wird, wobei die Bereitstellung außerhalb der Zuständigkeit des Client-Workers liegt. Eine Operationsschlüssel bezeichnet die gewünschte Wirkung bei allen Wiederholungsversuchen, ein Versuchskennzeichen trennt die einzelnen Ausführungen voneinander, und ein Wiederholungsversuch darf keinen neuen Operationsschlüssel erzeugen, nur um eine unklare Antwort zu umgehen.
Temporals frühes Agent Harness-Konto beschreibt dauerhafte Ausführungen sowie Steuerpunkte innerhalb eines inneren Agentenloops, einschließlich Wartezeiten für Wiederherstellung und Freigabe. Es handelt sich um ein sich weiterentwickelndes Projekt des Anbieters und nicht um unabhängige Vergleichsbelege. Für externe Aktionen ist weiterhin anbieterspezifische Deduplizierung oder Abstimmung erforderlich, da allein eine dauerhafte Orchestrierung keine exakt-eins-Wirkungen in einem beliebigen Service nachweisen kann, und Temporals eigene Dokumentation zu Wiederholungsversuchen fordert die Erkennung von Duplikaten in der Nachverarbeitung.
Jede Reparatur verbraucht einen Teil des deklarierten Versuchs- und Ressourcenbudgets. Wenn eines davon aufgebraucht ist, gibt der Workflow ein nicht akzeptiertes Ergebnis zusammen mit den dazugehörigen Belegen sowie einem benannten Verantwortlichen zurück. Auch Eskalationen benötigen ein Ablaufdatum oder eine Möglichkeit zur Stornierung, damit die Verantwortung nicht in einem aufgegebenen Gespräch verloren geht.
Verträge können fehlerhafte Arbeiten formalisieren
Die hohen Kosten sind der stärkste Einwand. Wenn ein einzelner Mitarbeiter eine isolierte Funktion bearbeitet, reichen bereits das Problem sowie die vorhandenen Tests aus, um den Umfang und die Akzeptanz zu kontrollieren. Einmalige Prototypen sowie unabhängige, risikofreie Forschungsaufgaben benötigen meist nur klare Anweisungen. Ein Vertragsdienst zu schaffen, nur um solche Vereinbarungen neu zu benennen, wäre sinnlos.
Auch Verträge können keine Produktabsichten hervorbringen oder Fähigkeiten simulieren, die fehlen. Eine mangelhafte Aufteilung bleibt weiterhin schlecht, korrelierte Fehler bestehen fort, und ein fehlerhafter Akzeptanzmechanismus – also der Test oder die Beurteilung, ob das Ergebnis korrekt ist – bleibt ebenfalls fehlerhaft. Angenommen, der End-to-End-Test verwendet die fehlerhafte Mock-Implementierung des Clients: Das positive Ergebnis übersieht dann völlig den ursprünglichen Fehler.
Deshalb verdient das Design einen Vergleich mit einfacheren Alternativen, einschließlich eines einzelnen Agenten oder eines deterministischen Workflows. Die Frage ist, ob die zusätzliche Koordination die Qualität der Ergebnisse verbessert oder tatsächliche Risiken für die zu bewältigende Arbeitslast kontrolliert.
Wie man es testet
Für diesen Ansatz wurden bisher keine neuen Experimente durchgeführt. Drei Konfigurationen lohnen einen Vergleich: ein einzelner Agent (A), mehrere Agenten mit rollenbasierten Zuweisungen (B) sowie mehrere Agenten unter Verwendung expliziter Delegierungsverträge und des oben beschriebenen Ansatzes (C).
Fairness erfordert, dass A, B und C identische Aufgabeninformationen sowie Akzeptanzkriterien, vergleichbare Werkzeuge und Sicherheitsgrenzen, übereinstimmende Ausgangsumgebungen sowie ein festgelegtes Gesamtbudget für Ressourcen erhalten. B und C teilen sich Modelle sowie die Anzahl der Mitarbeiter, während A bei Möglichkeit ein entsprechendes Modell verwendet. Die untersuchte Variable ist das Delegierungs- und Koordinationsmechanismus, ohne zusätzliche Fähigkeiten oder versteckte Anforderungen auf der einen Seite.
B sollte gewöhnliche Schutzmaßnahmen sowie nützliche Aufgabenbeschreibungen beibehalten. Falls natürlicherweise ausführlichere Übergabevereinbarungen entstehen, sollte dieses Verhalten aufgezeichnet werden und nicht verboten werden. Die tatsächlichen Konfigurationen sollten veröffentlicht werden, damit der Vergleich nicht zu einer aufpolierten Implementierung gegenüber einem absichtlich schwachen Basismodell wird.
Wählen Sie Aufgaben aus, die die tatsächliche Mischung widerspiegeln: einige mit unabhängigen Teilen, einige mit sequenziellen Abhängigkeiten, einige mit Schnittstellen oder Ressourcen, die unter den Arbeitern geteilt werden. Die Tests werden in zufälliger Reihenfolge in neu initialisierten Umgebungen wiederholt, wobei normale Aufgaben von absichtlich eingeführten Fehlern getrennt bleiben. Nach einem Pilotversuch werden die Konfigurationen festgelegt, die zurückbehaltenen Aufgaben leiten den eigentlichen Vergleich an, und die Unsicherheit wird je nach Abhängigkeitsstruktur berichtet.
Anthropics Bewertungsmethode unterscheidet zwischen einer Transkription und dem Zustand der Umgebung, den sie hinterlässt, und bewertet das Modell zusammen mit seinem Umfeld. Das bestimmt den richtigen Messpunkt: Funktioniert die Seitenzahlung in der kombinierten Umgebung? Dass drei Agenten mitteilen, sie hätten fertig, beweist nichts.
Drei Hauptkriterien gelten: die angenommenen End-to-End-Ergebnisse, die Gesamtkosten für jedes angenommene Ergebnis sowie die bis zur Annahme verstrichene Zeit. Zu den Kosten gehören fehlgeschlagene Versuche, Koordination, Wiederholungsversuche, Überprüfungen, Einrichtung sowie die Erstellung von Verträgen. Die anfängliche Einrichtung wird gesondert ausgewiesen, ebenso wie die wiederkehrenden Kosten; jede Annahme bezüglich der Amortisierung wird angegeben, und die von Menschen aufgewendete Zeit wird offen erfasst. Falls nichts angenommen wird, sollen die Ausgaben sowie null Erfolge angegeben werden, anstatt einen scheinbar endlichen, aber irreführenden Einheitspreis zu zeigen.
Neben diesen Kriterien werden Integrationsfehler, doppelte Arbeiten, Fehler aufgrund veralteter Eingaben, menschliche Eingriffe, Überschreitungen des Aufgabenumfangs sowie Ergebnisse, die nach Angabe ihrer Fertigstellung abgelehnt wurden, erfasst. Versuche und erfolgreiche Überschreitungen werden getrennt ausgewiesen, und unvollendete Versuche sowie Zeitüberschreitungen bleiben erfasst, damit schnelle Erfolge lange Fehlschläge nicht verdecken.
Die korrekte Ablehnung eines veralteten Patches beweist zwar, dass die Kontrollfunktionen funktionieren, doch die Produktaufgabe gilt weiterhin als fehlgeschlagen, es sei denn, ein gültiges Ergebnis wird innerhalb des Budgets akzeptiert. Frühe Pilotergebnisse deuten lediglich in eine Richtung. Sollten Verträge zusätzliche Kosten verursachen, ohne bessere Ergebnisse oder signifikant geringeres Risiko zu liefern, ist der vernünftige Rat, sie für diese Arbeitslast auszulassen.
Fangen Sie mit einer Übertragung an, die überprüft werden kann
Ein sinnvoller Ausgangspunkt ist ein bestehender Workflow mit zwei Mitarbeitern und einem benannten Verantwortlichen für die Akzeptanz. Die Integrationstests liegen außerhalb der Kontrolle der Mitarbeiter, und jeder Fehlerfall wird getrennt getestet, bevor das Aufgabenspektrum erweitert wird. Eine kurze Anweisung in dieser Richtung kann an einen Programmieragenten gesendet werden:
Add the minimum delegation contract to [WORKFLOW].
Acceptance owner: [OWNER].
Preserve existing safety boundaries.
1. Inspect current delegation, inputs, permissions, and acceptance.
Exit: map who assigns, executes, checks, accepts, and commits.
2. Identify missing boundaries; reuse existing issues and checks.
Exit: owner-approved scope, revisions, deliverable, and criteria.
3. Wire the minimum contract into dispatch and result handling.
Exit: references resolve; proposals cannot accept themselves; unauthorized operations are blocked by the actual runtime.
4. Exercise valid and invalid handoffs in isolated fixtures.
Exit: demonstrate acceptance, conflict rejection, stale-input detection, missing-evidence rejection, interruption recovery, bounded retries, and authority escalation. Mock external effects.
5. Report changed files, commands run, outcomes, and remaining gaps.
Exit: distinguish implemented controls from unverified behavior.
Ersetzen Sie die Orchestrierungsplattform nicht oder ändern Sie unverwandte Aufgaben, und veröffentlichen, bereitstellen oder erweitern Sie keine Berechtigungen.
Die API, der Client und die Tests sind weiterhin auf leistungsstarke Worker angewiesen. Die Veränderung liegt in den Regeln, die ihre Funktionsweise steuern. Bevor die gemeinsame Arbeit als abgeschlossen gilt, muss klar definiert werden, was jeder Beitrag beinhalten muss, wer ihn akzeptieren darf und was passiert, wenn er nicht akzeptiert werden kann. Jobbezeichnungen ziehen niemals solche Grenzen.