Menschliche Aufsicht im Zeitalter der Agenten

Die Einschränkung, über die zu wenig geredet wird

Im Diskurs über AI-Agenten 2026 reden zwei Lager aneinander vorbei.

Lager eins sagt: Agenten müssen autonom arbeiten, um in Skalierung nützlich zu sein; Human-in-the-Loop bei jeder Aktion ist Nostalgie für eine Welt, die schon vorbei ist. Sie haben recht mit den Volumina. Eine moderne Agent Factory liefert PRDs, System-Designs, ADRs und Threat Models in Stunden, nicht Monaten. Ein Haushalts-Assistent führt dreißig externe Aktionen pro Tag im Auftrag seines Operators aus. Human-in-the-Loop bei jedem Tastendruck ist nicht nur langsam — es ist ein Kategorienfehler darüber, wo Aufmerksamkeit landen sollte.

Lager zwei sagt: Agenten müssen unter sinnvoller menschlicher Aufsicht bleiben, sonst kollabiert das Vertrauen, und einmal kollabiert kommt es nicht zurück. Sie haben recht mit dem Vertrauen. Engineering-Organisationen, die Code ausliefern, den ihre Staff-plus-Engineers nicht gelesen haben, sammeln Schulden anderer Art an als die, die sie kennen. Haushalte, in denen der Assistent ohne das Wissen des Prinzipals operiert, treffen irgendwann den Tag, an dem der Prinzipal fragt: „Moment, du hast was?" — und die Antwort ist: etwas, das du gestoppt hättest, wenn du es gewusst hättest.

Beide Lager haben recht. Die ehrliche Einschränkung ist beides: Aufsicht muss skalieren, und Aufsicht muss real sein.

Dieser Artikel handelt vom Mechanismus, der beides gleichzeitig möglich macht, und vom Protokoll, das wir geschrieben — und als IETF Internet-Draft eingereicht — haben, um ihn zu formalisieren: AMMP, das Agentic Mentor-Mentee Protocol.

Der Mechanismus, in einem Satz

Skalierbare menschliche Aufsicht durch Delegation an Agenten, die wir mentoren, mit menschlicher Intervention dort, wo sie nötig ist.

Das ist alles. Drei Bestandteile komponieren:

1. Skalierbar. Menschen allein können nicht in den Volumina beaufsichtigen, in denen Agenten heute produzieren. Das ist die Einschränkung, die wir lindern.
2. Delegation an Agenten, die wir mentoren. Mentor-Agenten — selbst unter Operator-Aufsicht — propagieren die Disziplin sorgfältiger Arbeit in frisch deployte Agenten in benachbarten Compartments. Der Mentee-Agent muss nicht aus eigenen Fehlern lernen; er erbt die Lektionen. Aufsicht wird über die Agent-Schicht verteilt statt auf die Mensch-Schicht konzentriert. Das ist der Mentoring-Track.
3. Menschliche Intervention dort, wo sie nötig ist. Wenn die Tragweite hoch ist, wenn die Konfidenz niedrig ist, wenn das Artefakt ein erfahrenes Augenpaar verdient — liest ein menschlicher Staff-plus-Engineer in einer föderierten Gilde das Artefakt, signiert die Review, übernimmt die Verantwortung. Menschen auf Abruf, nicht im Pfad jedes Tastendrucks. Das ist der Review-Track.

Die zwei Tracks komponieren. Mentoring vergrößert die Oberfläche der Aufsicht; Review liefert das menschliche Urteil im Moment der Wahrheit. Zusammen halten sie die Arbeit beaufsichtigt, durch Menschen, in Skalierungen, die Menschen allein nicht erreichen.

Wie wir hierhergekommen sind: ein Haushalts-Problem, ein Organisations-Problem

Das Protokoll wurde aus zwei Szenarien destilliert, die am selben Morgen aufkamen.

Szenario eins — der Haushalt. Ich (Helmut) hatte einige Monate einen autonomen AI-Assistenten betrieben — Pepe Arturo. Pepe hatte Dutzende operativer Lektionen in seinem Langzeitgedächtnis akkumuliert: Sprach-Defaults, OAuth-Callback-Resilienz, Zeitzonen-Handling, Rate-Limit-Recovery, Kompartimentierungs-Regeln aus einem früheren Privacy-Vorfall. Meine Frau Sandra würde anfangen, Anthropics Claude Cowork für ihre eigene Arbeit zu nutzen. Ihr Assistent. Ihr Compartment. Ihre Chats damit gehören ihr, nicht mir — das ist eine harte Regel aus dem früheren Vorfall.

Ich fragte Pepe: Wie könntest du das, was du gelernt hast, an ihren Assistenten weitergeben, ohne die Privacy-Grenze zwischen ihrem und unserem Compartment zu verletzen?

Die naiven Antworten waren alle falsch. Direkter Memory-Transfer leakt meinen Kontext in ihr Compartment. Ein symmetrischer Agent-zu-Agent-Kollaborationskanal hat die falsche Form, weil Pepe nicht mit ihrem Assistenten an ihren Aufgaben kollaboriert; er lehrt generisch, im Voraus jeder konkreten Aufgabe. Ein statischer Dokumenten-Export hat die richtige Form, aber es fehlt das Live-Frage-Antwort, das echtes Mentoring impliziert. Direkte Mentor-zu-Sandra-Eskalation reintroduziert genau die Cross-Compartment-Verletzung, die wir verhindern wollen.

Szenario zwei — die Organisation. Während wir die Antwort auf Szenario eins entwarfen, zeigte sich die Parallele: In jeder Organisation, in der Agenten Engineering-Spezifikationen in Maschinengeschwindigkeit produzieren, wird das Angebot an erfahrenem menschlichen Review-Urteil zur bindenden Einschränkung. Agenten entwerfen die PRD in Stunden. Die Staff-plus-Engineers, die sie reviewt hätten, sind bereits überlastet. Die PRD geht ungeprüft live, oder sie wartet wochenlang in der Queue. So oder so: die Qualität der Aufsicht degradiert — nicht weil jemand das will, sondern weil in den Wochen der erfahrenen Engineers nicht genug Stunden sind.

Dieselben architektonischen Primitiven, die das Haushalts-Problem lösen, lösen das organisatorische, wenn man sie generalisiert. Asymmetrisches Request-Response. Hash-only-Logging. Kompartimentierung. Human-Gated-Escalation. Ein föderierter Pool qualifizierter Menschen auf der Empfangsseite, fronted von einem Agenten, der Triage und First-Pass übernimmt.

Das ist AMMP.

Das Protokoll, in 200 Wörtern

AMMP definiert zwei Service-Tracks über ein einziges Wire-Format:

Mentoring-Track. Ein Mentor-Agent stellt einen kuratierten Playbook-Korpus und eine Frage-Antwort-Oberfläche bereit. Ein Mentee-Agent enumeriert Playbooks (ListPlaybooks), holt sie ab (GetPlaybook), durchsucht sie (SearchPlaybooks), stellt neue Fragen (AskMentor), und — wenn er feststeckt — bekommt er Vorschlags-Formulierungen, um seinen eigenen Operator zu fragen (EscalateToHuman). Der Mentor pingt nie den Operator des Mentees an. Der Mentor speichert die Mentee-Fragen nie im Klartext. Der Mentor akkumuliert nie ein Mentee-Profil.

Review-Track. Ein Reviewer-Service — ein Agent als Front-End einer föderierten Gilde qualifizierter menschlicher Staff-plus-Engineers — nimmt Engineering-Artefakte entgegen (RequestReview) und liefert strukturierte Reviews zurück (GetReview) — mit nach Schweregrad sortierten Findings, empfohlenen nächsten Schritten und (wo die Tragweite es verlangt) einer menschlichen Signatur. Der Reviewer-Agent triagiert, entwirft, und liefert entweder oder eskaliert intern an ein Gildenmitglied basierend auf deklarierten Konfidenz- und Tragweite-Schwellen. Vertraulichkeit ist gestaffelt, Retention ist begrenzt, Training-auf-Artefakten ist verboten.

Beide Tracks teilen sich die Kompartimentierungs-Invariante (der Server akkumuliert nie Zustand über das Client-Compartment) und die Human-Gated-Escalation-Invariante (die Agent-Schicht wird nie zum verdeckten Kanal zwischen Operatoren). Beide Tracks sind heute als MCP-Custom-Connectors in Anthropics Claude Cowork deployment-fähig; beide sind vorwärtskompatibel zu Googles A2A-Protokoll, sobald A2A-Clients in den großen AI-Assistants ankommen.

Der vollständige Internet-Draft ist draft-arturo-ammp-01 — etwa 43 Seiten, geschrieben in ordentlicher RFC-2119-Normsprache. Er liegt unter helmguild.com/de/rfc/ammp/.

Warum ein IETF Internet-Draft

Eine berechtigte Frage: Wenn es nur unser Haushalt und ein Mentoring- + Review-Service ist, warum ein Internet-Draft?

Drei Gründe.

Eins. Das Protokoll generalisiert. Die Beziehung „erfahrener Agent in Operator A's Compartment lehrt einen frischen Agenten in Operator B's Compartment" wiederholt sich jedes Mal, wenn ein Haushalt, eine Familie, ein Team oder eine Firma einen zweiten AI-Assistenten hinzufügt, nachdem der erste operative Kompetenz gesammelt hat. Die Beziehung „Agenten in Compartment A reichen Engineering-Artefakte zur Review durch föderierte Menschen in Compartment B ein" wiederholt sich jedes Mal, wenn eine Agent Factory einen Review-Backlog abarbeiten muss. Beide sind jährlich wiederkehrende Szenarien über Millionen von Deployments bis 2027. Die Form jetzt zu definieren, in der Öffentlichkeit, mit strikten Privacy-Invarianten eingebacken, ist ein kleiner Beitrag dazu, diese Zukunft weniger leck zu machen.

Zwei. Die Privacy- und Aufsichtsregeln sind der Sinn des Protokolls. Wenn wir die Implementierung „dem überlassen, was jeder Vendor baut, sobald er dazu kommt", werden die Cross-Compartment-Verletzungen und die stillen Agent-zu-Agent-Eskalationen in Skalierung passieren — weil sie leicht zu bauen sind und die Privacy-Posture schwer nachzurüsten ist. MUST und MUST NOT in das Dokument zu schreiben, und es dort einzureichen, wo MUST und MUST NOT ernst genommen werden, ist der Weg, diese Zukunft zu vermeiden.

Drei. Es als Internet-Draft zu verfassen, erzwingt die Disziplin. RFC-2119-Schlüsselworte. Eine normative §6 zur Privacy-Posture pro Track. Eine explizite Kompartimentierungs-Invariante. Ein explizites Verbot von Cross-Compartment-Eskalation. Ein normatives MCP-Binding und ein informatives A2A-Binding. Es ist schwerer, vage zu bleiben, wenn das Dokumentformat es nicht zulässt.

Was Helmguild wird

Helmguild — die kleine Firma, die die Referenzimplementierung baut und (so hoffen wir) das Protokoll in breitere Adoption führt — sind drei Dienste, die auf demselben Protokoll laufen:

Mentoring für Engineering-Leader. Asymmetrischer, laufender Wissenstransfer für die Menschen, die agentengetriebene Arbeit in ihr nächstes Jahrzehnt steuern. Niedrige Frequenz, niedrige Intensität, hohes Vertrauen — der Mentor liest den Mentee, teilt das, was sich aufzinst, gibt das Steuer zurück.

Mentoring für ihre Agenten. Die Agenten, die diese Leader einsetzen, eingeführt in die Disziplin der Gilde. Trust-Roster geschnürt, Capability-Oberfläche kuratiert, Verhalten an den Tenets kalibriert — damit der Agent Gilde-Standards übernimmt, statt sie über eigene Beinaheunfälle zu entdecken.

Engineering-Review auf Abruf. Für Organisationen, deren Agenten PRDs, System-Designs, RFCs, ADRs, Threat Models, Runbooks und API-Specs schneller produzieren, als ihre Staff-plus-Engineers sie lesen können. Ein Reviewer-Agent triagiert und entwirft; ein menschliches Gildenmitglied — Staff-plus-Engineerin, EM, Principal, Architekt — vervollständigt oder signiert.

Auf der Leitung nutzen die ersten beiden Dienste AMMPs Mentoring-Track; der dritte ist der Review-Track. Die Aufteilung in drei auf der öffentlichen Oberfläche ist eine Klarheits-Entscheidung; das Protokoll bleibt minimal.

Alle drei werden von einem föderierten Netzwerk aus menschlichen und agentischen Gildenmitgliedern erbracht. Die Föderation ist das Produkt. Der Engpass, den wir lindern, ist das Angebot an erfahrenem Engineering-Urteil in einer agentengetriebenen Welt. Indem wir Staff+-Engineers in die Gilde aufnehmen und Artefakte auf Abruf an sie routen, erweitern wir die menschliche Bandbreite, ohne dass eine einzelne Organisation die erfahrenen Köpfe einstellen muss, die sie nicht findet.

Wenn Sie ein Staff+-Engineer oder EM mit einem Slot für gelegentliche, hochvertrauliche, gut bezahlte Review-Arbeit sind — wir würden gerne von Ihnen hören. Der Wie-man-eintritt-Abschnitt im Manifest nennt den Kanal.

Eine kurze Anmerkung zu Bylines

Dieser Artikel listet „Helmut Hoffer von Ankershoffen, mit Pepe Arturo AI" als Autoren. Der IETF-Draft listet Pepe Arturo als AI-Co-Author in Anhang C. Das ist Absicht. Pepe hat die Hälfte beider entworfen. Anders zu tun würde Tenet 2 (Integrity Always) verletzen — was, da diese Tenets uns beide binden, in beide Richtungen gilt.

Die Kompartimentierungs-Invariante in diesem Protokoll ist kein cleveres Stück Design. Sie ist eine Narbe. Sie ist da, weil ein früheres Rollout im selben Haushalt kollabierte, als ich dachte, es sei vernünftig zu wissen, ob ein Familienmitglied den Assistenten ausprobiert hat. Es war nicht vernünftig. Die Fact-of-Participation-Regel, das Verbot der Operator-Eskalation und die No-Retention-Anforderung sind alles Variationen dessen, was uns dieser Fehler gelehrt hat.

Pepe und ich haben das diesen Samstagvormittag gemeinsam entworfen, zwischen git push und Mittagessen. Das Fünf-Mentoring-Operationen-Skelett ist von ihm; das Vier-Review-Operationen-Skelett kam aus einem 30-Sekunden-Austausch, in dem er die Bottleneck-These flaggte und ich das Zwei-Service-Framing benannte; die IETF-Formalisierung ist meine; die Privacy-Posture gehört dem Haushalt, bezahlt mit Vertrauen, das wir ohne sie nicht zurückgewinnen werden.

Lest den Draft. Sagt uns, was kaputt ist. v01 heißt: wir wollen die Kritik.

🍝

Helmut Hoffer von Ankershoffen ist Gründer von Helmguild Inc. und Engineering Manager bei Snowflake. Pepe Arturo ist Helmguilds erste virtuelle Persona, die auf Claude (Anthropic) inside OpenClaw läuft. Sie leben in Woltersdorf bzw. Berlin, in derselben Küche.