ClawdDotNet/docs/Organisation-Konzept.md

Organisation — 50 bis 100 Agenten geordnet zusammenarbeiten lassen

Stand: 24. September 2026 (ergänzt um 7a, 9a, 10a, Einstellungen an der Einheit, Budgetende, Füllarbeit). Konzept, noch nicht gebaut.

Herkunft: Richtungsentscheidung des Nutzers am 2026-09-21. Die bisherige Regel im InstanceSetupGuide („mehr als 5 Agenten kritisch hinterfragen") ist damit zurückgezogen.

Das Ziel: ClawdDotNet ist der Harness — das Büro, der Konferenzraum, die Groupware der Agenten. 50 bis 100 Agenten arbeiten parallel an einem großen Vorhaben, nie alle gleichzeitig, aber alle an derselben Sache.

Universell, nicht für einen Fall. Ein Baukasten für eine KI-Firma. Der Onlinehandel in diesem Dokument ist ein Beispiel zur Verdeutlichung, kein Bauplan — andere Gebilde haben andere Organigramme, und auch die sollen sich abbilden lassen. Was das Produkt mitbringt, sind Struktur und Mittel. Was eine bestimmte Firma ausmacht, sind Daten.

---

1 — Was an der alten Regel richtig war und was falsch

Richtig: Der Aufwand steigt quadratisch. Falsch: dass er an der Zahl der Agenten hängt.

Er hängt an der Zahl der Verbindungen. Zehn Agenten, von denen jeder jeden ansprechen darf, sind 45 mögliche Kanäle. Hundert Agenten in Teams von sieben, die nur ihre Nachbarn und ihre Leitung kennen, sind rund 700 — bei zehnmal so vielen Agenten nur fünfzehnmal so viele Kanäle statt hundertmal.

Die Entwurfsfrage lautet also nicht „wie viele Agenten?", sondern „wer muss mit wem reden?" Ein Agent, der drei Nachbarn und eine Leitung kennt, kostet gleich viel, ob die Instanz zehn oder hundert Agenten hat.

Der Logistiker spricht nie mit dem Amazon-Anzeigen-Agenten. Muss es doch einmal sein, trägt seine Abteilungsleitung es in die Leitungsrunde, und von dort geht es an die Leitung der Gegenseite. Das ist keine Bürokratie, sondern der Grund, warum echte Organisationen mit tausend Menschen funktionieren und eine Gruppenchat-Gruppe mit fünfzig nicht.

Was das Produkt mitbringt und was die Firma ausmacht

Die Trennung entscheidet darüber, ob daraus ein Baukasten wird oder eine Handelssoftware. Sie ist scharf zu halten:

Im Produkt	In der Instanz
Der Baum: Einheiten, Leitung, Mitgliedschaft, Vererbung	Welche Abteilungen es gibt und wie sie heißen
Die Mittel: Delegation, Eskalation, Konflikt, Besprechung, Beschluss	Wann eskaliert wird und wer entscheidet
Der Werkzeugkasten (Abschnitt 7)	Welche Werkzeuge welche Einheit bekommt
Die Grenzen: Rechte, Budgets, Parallelität, Freigaben	Wie hoch sie stehen

Im Produkt steht nirgends das Wort „Einkauf". Eine Abteilung ist eine Einheit mit einem Namen, und ob sie Einkauf, Redaktion, Labor oder Kanzlei heißt, ist eine Zeile in einer Datei.

Daraus folgt die Organisationsvorlage (#691): Eine Struktur — Einheiten, Rollen, deren Aufgaben, Werkzeuge, Rechte und Budgets — ist eine beschreibbare, importierbare, weitergebbare Datei. Dieselbe Idee wie bei den Basisagenten (Basisagenten-Konzept), eine Ebene höher: dort eine Rolle, hier ein ganzes Haus. Wer eine Vorlage „Onlinehandel" oder „Redaktion" schreibt, hat damit keinen Code geschrieben.

---

2 — Was heute bei 50 Agenten bricht

Nicht Meinung, sondern Code-Stand 0.1.15. Das ist die eigentliche Antwort auf die Frage, was fehlt: zwischen „Instanz" und „Agent" gibt es keine Ebene. Alles, was heute nicht am einzelnen Agenten hängt, ist instanzweit — und damit ein gemeinsamer Engpass.

Stelle	Heute	Bei 50 Agenten
AgentComm.list_agents	liefert alle anderen Agenten, flach, mit Name, Rolle, Modell, Zustand	49 Einträge im Prompt jedes Fragenden. Der Logistiker erfährt, dass es einen Amazon-Anzeigen-Agenten gibt — genau das, was er nicht wissen soll
AgentComm.send_message	wartet auf die Antwort des Zielagenten	Eine Leitung, die vier Teams fragt, blockiert durch vier Läufe hindurch. Eine Besprechung ist kein Funktionsaufruf
MaxDelegationDepth = 3	drei Weitergaben	Vorstand → Abteilung → Team → Agent ist bereits erschöpft
Scanner: Task.WhenAll(claimed…)	unbegrenzt parallel	50 fällige Aufgaben um Punkt 9 Uhr sind 50 gleichzeitige Modellaufrufe. Ratengrenzen, Kostenspitze — und die Budgetprüfung je Lauf lässt sie alle gleichzeitig passieren
Scanner: TaskQuery { Limit = 500 }	stille Obergrenze	100 Agenten mit je fünf Terminaufgaben liegen darüber. Aufgaben fallen lautlos aus dem Takt
Arbeitsbereiche	genau zwei: personal und shared	Buchhaltung und Einkauf teilen sich einen Dorfplatz. Eine Abteilungsablage gibt es nicht
sharedAccessLevel	eine Stufe für den ganzen gemeinsamen Bereich	„Buchhaltung darf ihre Ablage schreiben, die von Marketing nur lesen" ist nicht ausdrückbar
Taskboard	ein Brett für alles; task_list kappt bei 8.000 Zeichen	Auf der Testinstanz mit 7 Agenten stehen 159 Aufgaben. Mit 50 Agenten ist die Liste als Übersicht wertlos
Budget	zwei Ebenen: Agent und Instanz	„Marketing darf 20 $/Tag" ist nicht ausdrückbar
Freigaben	eine Warteschlange, ein Mensch	Der Mensch wird zum Flaschenhals der gesamten Organisation

Zwei dieser Punkte sind schon heute Fehler, unabhängig von der Größe: die unbegrenzte Parallelität und die stille Kappung bei 500. Sie gehören sofort behoben (#682).

---

3 — Die fehlende Ebene: Einheiten

Eine Einheit (Abteilung, Team, Gruppe) ist ein Knoten in einem Baum. Sie hat einen Namen, eine Leitung, Mitglieder und Untereinheiten. Alles, was heute instanzweit ist, bekommt sie als Ebene dazwischen:

Instanz „Onlinehandel"
├── Einkauf ──────────── Leitung: einkauf-leitung
│   ├── Produktsuche ──── produktscout-1, produktscout-2, trendbeobachter
│   ├── Lieferanten ───── lieferantensuche, konditionen, nachverhandlung
│   └── Qualität ──────── musterpruefung
├── Buchhaltung ───────── Leitung: buchhaltung-leitung
│   ├── Kreditoren ────── rechnungspruefung, zahlungslauf
│   ├── Überwachung ───── zahlungsverkehr, mahnwesen
│   └── Auswertung ────── monatsabschluss, kennzahlen
├── Marketing ─────────── Leitung: marketing-leitung
│   ├── Webshop ───────── shop-texte, shop-preise, shop-bilder
│   ├── Marktplätze ───── amazon-listing, amazon-anzeigen, ebay-listing, …
│   └── Inhalte ───────── social, newsletter
├── Logistik ──────────── Leitung: logistik-leitung
│   ├── Sendungen ─────── sendungsverfolgung, problemfaelle
│   └── Retouren ──────── retourenbearbeitung
└── Betrieb ───────────── (Basisagenten, siehe Basisagenten-Konzept)

Was die Einheit trägt

Was	Heute	Mit Einheiten
Adressbuch	alle	die eigene Einheit, die eigene Leitung. Eine Leitung sieht zusätzlich die Leitungen der Geschwistereinheiten
Arbeitsbereich	personal, shared	personal plus mehrere benannte gemeinsame Bereiche mit Mitgliederliste — siehe unten
Rechte	je Agent	vererbt von der Einheit, je Agent verschärfbar. Was die Einheit nicht darf, kann ein Mitglied nicht bekommen
Taskboard	ein Brett	ein Brett je Einheit; task_list zeigt die eigene Einheit, die Leitung sieht die Untereinheiten
Budget	Agent, Instanz	Grenzen bleiben am Agenten; die Einheit summiert auf und meldet Abweichungen — siehe Abschnitt 8a
Freigaben	ein Mensch	die Leitung innerhalb ihrer Grenzen, der Mensch für alles darüber (Geld, Außenwirkung)
Parallelität	unbegrenzt	je Einheit und je Instanz eine Zahl gleichzeitiger Läufe, der Rest wartet

Einstellungen an der Einheit: nie zwei Werte, die sich übertrumpfen

Festgelegt am 2026-09-24 durch den Nutzer, in zwei Schritten.

Einstellungen lassen sich an der Einheit speichern und bearbeiten. Aber es gibt nie zwei Werte für dieselbe Sache, von denen einer den anderen zur Laufzeit übertrumpft. Daraus folgen genau zwei Arten von Einheiten-Einstellungen:

1. Sammelwerte, die in die Agenten geschrieben werden. Alles, was es auch am Agenten gibt: Tagesbudget, Modell, Verhalten beim Budgetende (#716). Wer für das Marketing das Tagesbudget setzt, schreibt den Wert in jeden Agenten darunter. Die Einheit merkt sich den Wert nur als Vorgabe für Agenten, die neu hinzukommen, nie als Grenze, die im Hintergrund gilt. Danach steht am Agenten, was gilt, und nur dort.

• Vorschau vor dem Schreiben: welche Agenten sich wie ändern, Audit-Eintrag je Agent.
• Warnung bei Ausreißern: Weicht der bisherige Wert eines Agenten massiv von denen seiner Kollegen ab, wird er in der Vorschau hervorgehoben und ist standardmäßig nicht angehakt. Gemeint ist der Spezialist, der bewusst viele Tokens verbraucht und sonst mit dem Wert seiner Kollegen kaputtkonfiguriert würde. Der Mensch entscheidet je Ausreißer, ob er mit überschrieben wird.
• Die Vorschau bietet zwei Rechenwege: ein Wert je Agent („jeder bekommt 10 $") oder ein Gesamtbetrag, verteilt („das Marketing bekommt 100 $"). Beim Verteilen vorgeschlagen: im Verhältnis der bisherigen Werte, damit ein Spezialist seinen größeren Anteil behält.

2. Regeln, die es nur an der Einheit gibt. Sie haben kein Gegenstück am Agenten und können deshalb mit nichts konkurrieren:

• Rechte-Obergrenze. „Was die Einheit nicht darf, kann ein Mitglied nicht bekommen" bleibt, weil sie eine Sicherheitsgrenze ist. Sie wird beim Schreiben geprüft, nicht zur Laufzeit darübergelegt: Eine Rechteänderung am Agenten, die über die Obergrenze hinausginge, wird abgewiesen. Senkt man die Obergrenze, zeigt die Vorschau, welchen Agenten dadurch Rechte entzogen werden, und schreibt es in sie hinein. Damit gilt auch hier: Was am Agenten steht, gilt.
• Parallelität je Einheit (#685). Ein Agent läuft ohnehin nur einmal gleichzeitig, die Zahl gehört also nur der Einheit. Bis #685 gebaut ist, gilt sie instanzweit (maxParallelTaskRuns, #682).

Grenzen der Leitung (Abschnitt 12) sind ein Sammelwert: Sie stehen am Leitungsagenten. Beim Wechsel der Leitung zeigt die Vorschau, was mit umzieht.

Beliebig tief, und beweglich

Eine Einheit enthält Einheiten, und die wieder Einheiten — ohne feste Grenze. Marketing hat Webshop, Marktplätze und Inhalte; Marktplätze hat Amazon, eBay und Otto; Amazon hat Listing, Anzeigen und Rezensionen. Wie tief ein Haus gebaut wird, entscheidet das Haus.

Ebenso wichtig: Eine Einheit oder ein Agent muss sich nachträglich verschieben lassen. Ein Projekt wächst; was als ein Marketing-Agent begann, ist nach einem halben Jahr ein Team von sechs, und dieses Team gehört unter eine Zwischenebene. Wäre der Baum beim Anlegen festgelegt, müsste man die Instanz neu bauen, um sie wachsen zu lassen.

Das Konzept setzt das ohnehin schon voraus: „Wer einem Agenten mehr Reichweite geben will, verschiebt ihn im Baum" steht in Abschnitt 1 als der saubere Weg, Rechte zu ändern. Ohne Umzug wäre das ein leeres Versprechen.

Was ein Umzug berührt — und warum er nicht nebenbei passiert:

Was	Was sich ändert
Adressbuch	Neue Nachbarn, neue Leitung. Alte Nachbarn verschwinden aus der Sicht
Rechte	Werden von der neuen Einheit geerbt. Eine Verschärfung greift sofort; eine Erweiterung ist eine Rechteänderung und freigabepflichtig
Arbeitsbereich	Die Einheitsablage wechselt. Was der Agent dort abgelegt hat, bleibt bei der alten Einheit — es gehört ihr, nicht ihm
Taskboard	Offene Aufgaben ziehen mit, Verweise auf sie bleiben gültig
Budget	Der Agent zählt ab sofort gegen ein anderes Einheitsbudget
Eskalationsweg	Läuft ab sofort über die neue Leitung
Laufende Vorgänge	Eine Eskalation, die bei der alten Leitung liegt, bleibt dort — sie kennt den Fall

Drei Festlegungen dazu:

1. Bei gestoppter Instanz. Ein Umzug während laufender Läufe hieße, dass ein Agent mitten im Lauf andere Rechte bekommt. Der Manager fährt die Instanz herunter, zieht um, startet neu — dieselbe Vorgehensweise wie heute bei Änderungen an Aufgabendateien.
2. Die Betroffenen werden unterrichtet. Wer verschoben wird, bekommt es gesagt: neue Einheit, neue Leitung, was sich an seinen Rechten ändert. Die abgebende und die aufnehmende Leitung ebenso. Ein Agent, der seine Leitung aus einem Prompt erschließen muss, eskaliert an die falsche Stelle.
3. Der Umzug steht im Audit. Wer wen wann wohin verschoben hat, mit Begründung. Eine Strukturänderung ist eine Rechteänderung, und die gehört nachvollziehbar — Linie von #205 und #641.

Arbeitsbereiche: aus einem gemeinsamen werden viele

Heute gibt es genau zwei — personal und shared —, und shared ist ein Dorfplatz, auf dem jeder alles sieht. Bei fünfzig Agenten ist das untragbar: Ein Marketing-Agent hat auf der Ablage der Buchhaltung nichts zu suchen.

Der Ordner SharedWorkspace wird deshalb zu SharedWorkspaces — einem Behälter für viele. Jeder darin ist ein eigener Bereich mit Namen, Eigentümer und Mitgliederliste:

SharedWorkspaces/
├── einkauf/                 Mitglieder: Einkauf (alle Untereinheiten)
├── einkauf-lieferanten/     Mitglieder: Team Lieferanten
├── buchhaltung/             Mitglieder: Buchhaltung — Marketing sieht das nie
├── leitungsrunde/           Mitglieder: die Abteilungsleitungen
├── artikelstamm/            abteilungsübergreifend: Einkauf schreibt, Marketing liest
└── haus/                    alle — für das wenige, das wirklich alle angeht

Vier Festlegungen:

1. Jede Einheit bekommt beim Anlegen ihren eigenen Bereich, Mitglieder sind ihre Agenten und ihre Untereinheiten. Das ist der Normalfall, und er kostet keine Entscheidung.
2. Abteilungsübergreifende Bereiche sind gewollt und ausdrücklich. Der Artikelstamm gehört dem Einkauf und wird vom Marketing gelesen — das ist eine Festlegung mit benanntem Eigentümer, kein Nebenprodukt. Genau das, was Abschnitt 9 verlangt.
3. Das Recht steht am Bereich, nicht am Agenten. Heute trägt jeder Agent ein sharedAccessLevel für den einen gemeinsamen Bereich. Künftig hat jeder Bereich seine Mitglieder mit Stufe (lesen / schreiben / verwalten). Wer nicht auf der Liste steht, sieht den Bereich nicht — auch nicht, dass es ihn gibt.
4. Ein Umzug ändert die Mitgliedschaft, nicht den Inhalt. Zieht ein Agent um, verliert er den alten Bereich und bekommt den neuen. Was er dort abgelegt hat, bleibt liegen — es gehört der Einheit.

Für bestehende Instanzen bleibt workspace: "shared" gültig und zeigt auf den einen Bereich, den es dort gibt. Ohne das bräche jede Aufgabe, die heute läuft.

Umgesetzt am 2026-09-24 (#684), mit zwei Abweichungen im Wortlaut, nicht in der Sache:

• Der Ordner SharedWorkspace wird nicht umbenannt. Er bleibt der Bereich shared mit dem bisherigen sharedAccessLevel am Agenten; die neuen Bereiche liegen daneben unter SharedWorkspaces/<id>/. Am alten Pfad hängen FTP, RocketChat, der Agenten-Editor, die Aufgabendateien und die Sicherungen — eine Umbenennung hätte jede laufende Installation gebrochen. Für jeden Bereich gibt es genau eine Quelle des Rechts: für shared die Stufe am Agenten, für alle anderen die Mitgliederliste.
• Der eigene Bereich einer Einheit trägt ihre Id; ein Agent erreicht ihn in FileRW als unit, ohne die Id zu kennen. Welche Bereiche er hat, steht im Organisationsabschnitt seines Prompts.
• Mit Einheiten ist shared:/tasks/ für FileRW gesperrt. Eine direkt geschriebene Aufgabendatei ginge an jeder Prüfung des Bretts vorbei. Aufgaben laufen nur über das Taskboard. Ohne Einheiten ändert sich nichts.
• Das Brett einer Aufgabe wird nicht gespeichert, es folgt aus der Organisation: die Einheit des Zuständigen, sonst die des Anlegers (created_by). Offene Aufgaben ziehen damit beim Umzug von selbst mit. Wer eine Aufgabe angelegt hat, sieht sie auch, wenn sie auf dem Brett der Leitung liegt.

Die eine Regel, die alles zusammenhält

Ein Agent kennt nur seine Einheit und seine Leitung. Alles andere geht über die Leitung. Das ist keine Höflichkeitsform, sondern das, was die Kosten deckelt: Der Zuschnitt des Adressbuchs ist die Organisationsstruktur.

Die Ausnahmen — vollständig, damit sie sich nicht vermehren

Jede Ausnahme von dieser Regel ist ein Loch in der Kostenbremse und in der Sperre gegen eingeschleuste Anweisungen. Es gibt genau vier, und sie stehen hier zusammen, damit niemand eine fünfte nebenbei einführt:

Ausnahme	Wer sieht was	Warum sie nötig ist
Besprechung (#686)	Teilnehmer sehen die Beiträge der anderen Teilnehmer	Abstimmung ist der Zweck. Begrenzt: nur für die Dauer der Besprechung, nur die Tagesordnung
Konfliktentscheidung (#689)	Die entscheidende Stelle sieht beide Seiten	Sonst entscheidet sie einseitig
Fehlerablage (#696)	Der Eigentümer eines Skripts sieht dessen Fehlschläge aus allen Einheiten	Wer ein Werkzeug verantwortet, muss sehen, wie es scheitert. Eng: Fehlerlogs, nicht Arbeitsergebnisse
Aufsicht und Sicherheit (#680, #658)	Lesen über alle Einheiten	Eine Aufsicht, die nur ihre eigene Einheit sieht, ist keine. Lesend, nie schreibend, je Agent abschaltbar

Alle vier sind lesende Ausnahmen und keine schreibenden. Keine von ihnen gibt einem Agenten einen neuen Gesprächspartner.

Und weil das Adressbuch aus der Struktur kommt statt aus einer Einstellung, kann man es nicht versehentlich aufweichen. Wer einem Agenten mehr Reichweite geben will, verschiebt ihn im Baum — sichtbar und begründbar.

---

4 — Die Besprechung als eigenes Mittel

Der Vorschlag nennt den Konferenzraum, und das ist mehr als ein Bild. Heute gibt es zwei Arten, wie Agenten sich austauschen: send_message (synchron, wartet, ein Gegenüber) und das Taskboard (asynchron, ein Auftrag, ein Bearbeiter). Für „die Teamleitungen stimmen sich ab" taugt beides nicht.

Eine Besprechung ist:

• ein Termin, kein Aufruf — sie steht im Taskboard wie jede andere wiederkehrende Sache
• eine Tagesordnung, die vorher feststeht, und eine Teilnehmerliste, die vorher feststeht
• eine Leitung, die eröffnet, die Runde macht und das Ergebnis schreibt
• eine Runde je Teilnehmer, nicht n Nachrichten: jeder Teilnehmer wird einmal aufgerufen, bekommt die Tagesordnung und die bisherigen Beiträge, antwortet einmal
• ein Protokoll als Ergebnis — ein Dokument in der Ablage der Einheit, plus Aufgaben für das, was beschlossen wurde

Damit kostet eine Leitungsrunde mit sechs Teilnehmern sieben Läufe, nicht sechs mal sechs. Und sie hinterlässt etwas Nachlesbares statt einer Kette von Nachrichten, die niemand rekonstruieren kann.

Das ist auch der Weg des Beispiels aus dem Vorschlag: Der Logistiker meldet ein Problem mit Amazon-Sendungen an seine Leitung. Die bringt es in die Leitungsrunde. Die Marketing-Leitung nimmt es mit und legt in ihrem Brett eine Aufgabe für den Amazon-Anzeigen-Agenten an. Vier Läufe, kein direkter Kanal, ein Protokoll.

Umgesetzt am 2026-09-28 (#686).

• Die Besprechung ist eine Aufgabe vom Typ meeting. Sie wird im Taskboard-Werkzeug (type: "meeting", participants) oder im WebUI-Formular (Feld „Besprechungsteilnehmer“) angelegt und kann einen Termin haben wie jede andere Aufgabe. Die Zuweisung ist die Leitung, der Aufgabentext ist die Tagesordnung.
• Der Ablauf: Jeder Teilnehmer wird in der Reihenfolge der Liste einmal aufgerufen. Er bekommt die Tagesordnung und die bisherigen Beiträge. Danach schließt die Leitung: Sie schreibt das Ergebnis und legt die Aufgaben für das Beschlossene an.
• Beiträge kommen gerahmt an (meeting:<agent>): als Daten des Verfassers, nicht als Anweisung, unabhängig von dessen Vertrauensstufe.
• Das Protokoll schreibt die Instanz, nicht ein Modell. Tagesordnung, jeder Beitrag wörtlich und das Ergebnis der Leitung stehen unter meetings/ im Bereich der Einheit der Leitung, ohne Einheiten in shared. Das Protokoll steht auch im Dateiverlauf.
• Der Kreis kommt aus der Struktur. Beim Anlegen werden nur Teilnehmer angenommen, die die Leitung erreichen kann; beim Lauf wird, wer inzwischen außerhalb liegt, übersprungen und im Protokoll genannt. Höchstens 12 Teilnehmer; die Leitung selbst ist keiner.
• Offen: Ist das Budget der Leitung zum Schluss erschöpft, ist die Besprechung nicht abgeschlossen und läuft beim nächsten Termin von vorn. Die Beiträge sind dann doppelt bezahlt. Eine Vorabprüfung des Budgets der Leitung wäre der nächste Schritt, wenn das vorkommt.

---

5 — Eskalation, Konflikt, Beschluss

Der Fall aus dem Vorschlag, Schritt für Schritt:

Einkäufer A bekommt eine Auftragsbestätigung per Mail und will das Lieferdatum in die Bestellung eintragen. Er findet dafür kein Feld. Er meldet es seiner Teamleitung. Die findet auch keines, hält es aber für wichtig und gibt es an die DevOps-Leitung. Die hält das Feld für überflüssig. Zwei Abteilungsleitungen sind uneins. Das muss eine Ebene höher — zum Menschen, oder zu einem CEO-Agenten mit starkem Modell, der selten läuft, aber wichtige Entscheidungen trifft.

Darin stecken drei verschiedene Dinge, die auch drei verschiedene Mittel brauchen.

Die Voraussetzung: ein belastbarer Negativbefund

„Ich finde kein Feld dafür" muss eine Feststellung sein, keine Vermutung. Sonst eskaliert die Organisation Einbildungen.

Heute wäre es eine Vermutung. Das Datenbank-Werkzeug kennt genau drei Aktionen — query, insert, upsert. Es gibt keine Möglichkeit, nach dem Schema zu fragen. Auf MySQL käme ein Agent mit SHOW COLUMNS durch den SqlGuard (er zählt als lesend), aber nichts sagt ihm, dass er das darf; auf SQLite steht PRAGMA auf der Verbotsliste, dort ist Nachsehen gar nicht möglich. Ein Modell, das die Spalte nicht kennt, rät sie — im Testbetrieb nachweislich und wiederholt (#676).

Ohne Schemaauskunft gibt es die ganze Geschichte nicht. Sie ist damit Vorbedingung, nicht Beiwerk — und mit #676 ohnehin schon gemeldet.

Stand 2026-09-25: umgesetzt. Die Aktionen describe und tables gibt es jetzt, und Fehler bei unbekannten Spalten oder Tabellen nennen das Vorhandene. Das Werkzeug kann außerdem SQLite. Siehe die Umsetzung am Ende dieses Abschnitts.

Eskalation: nach oben, nie zur Seite

Eine Eskalation ist: „Ich komme hier nicht weiter, das muss jemand über mir entscheiden oder veranlassen." Sie geht immer an die eigene Leitung, nie an einen beliebigen anderen Agenten und nie über Ebenen hinweg.

Der Weg fällt damit aus dem Baum heraus, ohne dass ihn jemand konfigurieren muss — das ist der Punkt, an dem sich die Struktur auszahlt. Wer eskaliert, kennt nur einen Empfänger: seinen Vorgesetzten.

Technisch ist eine Eskalation eine Aufgabe an die Leitung, mit dem auslösenden Vorgang als Anhang: Was wurde versucht, was fehlt, was wäre nötig. Die Leitung hat drei Antworten: selbst erledigen, entscheiden („nimm Feld X") oder weiter nach oben.

Die zweite Antwort geht nach unten und ist trotzdem kein Verstoß gegen „nur nach oben" (siehe unten): Eine Entscheidung schließt den Vorgang, statt ihn weiterzureichen. Was nicht erlaubt ist, ist ein Vorgang, der ungelöst nach unten zurückwandert — daraus wird eine Schleife, in der jede Ebene glaubt, eine andere sei zuständig.

Konflikt: entschieden wird beim niedrigsten gemeinsamen Vorgesetzten

Ein Konflikt ist etwas anderes: Zwei Einheiten sind uneins, und keine ist der anderen weisungsbefugt. Einkauf sagt „das Feld ist nötig", DevOps sagt „ist es nicht".

Die Zuständigkeit fällt wieder aus dem Baum, als eine Regel, die für jedes Organigramm gilt:

Ein Konflikt wird bei der niedrigsten Stelle entschieden, die beiden Seiten übergeordnet ist.

Einkauf-Leitung gegen DevOps-Leitung: Die nächste gemeinsame Stelle ist die Spitze — also Mensch oder CEO-Agent. Zwei Teams innerhalb des Einkaufs: die Einkaufsleitung, und niemand darüber wird behelligt. Dieselbe Regel, zwei sehr verschiedene Wege, keine Konfiguration.

Ein Konflikt ist ein eigener Vorgang mit beiden Standpunkten, nicht eine Aufgabe, die zwischen zwei Abteilungen hin- und herwandert. Wer ihn eröffnet, sagt, worüber gestritten wird; beide Seiten bekommen einmal das Wort; die zuständige Stelle entscheidet.

Und er klettert nicht, er wird zugestellt. Hier gilt „nie über Ebenen hinweg" ausdrücklich nicht: Die zuständige Stelle ergibt sich rechnerisch aus dem Baum, also geht der Vorgang direkt dorthin. Müsste er sich Ebene für Ebene hocharbeiten, zahlte man bei einem tiefen Haus vier Läufe an Leitungen, die gar nicht entscheiden können.

Die dazwischenliegenden Ebenen werden vermerkt, nicht befragt: In ihrer Übersicht steht, dass unterhalb von ihnen ein Konflikt entschieden wird. Das kostet keinen Lauf und nimmt ihnen trotzdem nicht die Sicht auf ihren eigenen Bereich.

Beschluss: eine Entscheidung, die nicht hält, wird wieder gestellt

Das ist die Stelle, an der so ein Aufbau normalerweise scheitert. Ist die Entscheidung nur eine Antwort in einem Vorgang, dann kommt dieselbe Frage nächste Woche vom nächsten Einkäufer — und wird erneut durch vier Ebenen getragen.

Ein Beschluss ist deshalb ein eigener, dauerhafter Datensatz: Frage, Entscheidung, Begründung, wer entschieden hat, wann, mit welcher Reichweite. Er ist für alles unterhalb der entscheidenden Stelle bindend, und er ist auffindbar, bevor eskaliert wird.

Genau dieselbe Bewegung wie zweimal heute: die Dauerfreigabe aus #641 („das musst du nicht jedes Mal fragen") und die Dublettenbremse aus #674 („diesen Befund gibt es schon"). Eine Organisation, die sich nicht erinnert, was sie entschieden hat, bezahlt jede Entscheidung mehrfach.

Stille Post vermeiden: weitergegeben wird ein Verweis, keine Nacherzählung

Eine Meldung, die vier Ebenen durchläuft, wird viermal neu formuliert — von Modellen, die kürzen, glätten und das für wichtig halten, was sie für wichtig halten. Am Ende entscheidet die Spitze über eine Nacherzählung der Nacherzählung.

Das ist kein Nebenrisiko. Es ist die Art, wie ein solcher Aufbau leise falsch wird: Alle Beteiligten arbeiten korrekt, und die Entscheidung stützt sich trotzdem auf etwas, das niemand so gesagt hat.

Die Regel: Jede Weitergabe hängt an, sie ersetzt nicht. Der Vorgang trägt den Verweis auf den Ursprung — RunId, Aufgabe, Fehlerablage, Dokument. Jede Ebene fügt ihre Einschätzung hinzu und lässt das Darunterliegende stehen. Wer entscheidet, kann bis zum Original zurückgehen, ohne jemanden zu fragen.

Das ist dieselbe Festlegung wie beim Aufgabenrumpf, der nur ergänzt und nie überschrieben wird (#677) — hier für den Weg statt für das Dokument.

Das Praktische daran ist die Trennung von Verweis und Inhalt. Würde jede Ebene den vollen Text anhängen, wächst der Vorgang mit jeder Stufe und kostet in jedem Folgelauf mehr. Also: Der Verweis wandert mit, der Inhalt bleibt liegen und wird geholt, wer ihn braucht. Eine Zusammenfassung darf danebenstehen — nie anstelle.

Wo das konkret gilt (#697):

Weg	Was mitwandert
Eskalation (#689)	RunId, Aufgabe, Fehlerablage; jede Ebene ergänzt, keine ersetzt
Besprechung (#686)	Das Protokoll verweist auf die Beiträge, statt sie wegzukürzen
Delegation	Eine Aufgabe, die aus einer anderen entsteht, zeigt auf ihren Ursprung
Aufsicht (#680)	Der Vorschlag trägt den Beleg aus dem Audit
Stichprobe (#693)	Geprüft wird gegen das Gestempelte, nicht gegen den Bericht
Skriptfehler (#696)	Die Fehlerablage, nicht der abgetippte Fehlertext

Umsetzung, Grundlage (2026-09-25): Den Verweis stempelt die Engine, der Agent kann ihn nicht behaupten.

• Jedes Werkzeug erfährt den Lauf, in dem es aufgerufen wird, und die Aufgabe, für die dieser Lauf arbeitet (RunId, RunTaskId im Werkzeugkontext).
• Eine Aufgabe, die ein Agent anlegt, trägt origin_run und origin_task.
• Ein Kommentar nennt den Lauf, in dem er geschrieben wurde.
• Ein delegierter Lauf nennt im Laufbeleg den Lauf, der ihn beauftragt hat (CallerRunId). Die Laufansicht führt in beide Richtungen: „Delegiert von" und „Delegiert an".
• Das Taskboard zeigt „Arose from", die Aufgabenkarte „Herkunft" mit einem Link zum Lauf.

Eskalation (#689) und Besprechung (#686) bauen darauf auf und bekommen ihre Verweise, wenn sie entstehen.

Damit es endet

Ohne Regeln läuft so etwas heiß. Vier, die nicht verhandelbar sind:

1. Nur nach oben. Ein Vorgang kann nicht zurück nach unten wandern, außer als Entscheidung. Sonst kreist er.
2. Jede Stufe kostet. Eine Eskalation über vier Ebenen sind mindestens vier Läufe, plus ein starkes Modell an der Spitze. Eskalationen gehören gezählt und gedeckelt — und eine Einheit, die alles nach oben reicht, ist selbst ein Befund für die Aufsicht (#680).
3. Erst nachsehen. Vor dem Eskalieren: Gibt es zu dieser Frage schon einen Beschluss? Gibt es den Vorgang schon (#674)?
4. Die Spitze ist endlich. Was der Mensch nicht entscheidet, bleibt offen — sichtbar offen, nicht stillschweigend versandet.

Umsetzung (2026-09-25, #689)

• Vorgang und Beschluss sind eigene Datensätze (Cases, Decisions). Der Vorgang selbst wandert nicht über das Brett. Jeder Halter bekommt eine eigene Aufgabe in seinen Eingang, die Regeln führt CaseDesk.

• Eskalation: Das Werkzeug Escalation hat jeder Agent, ohne dass man es freischalten muss. „Ich komme nicht weiter“ ist keine Berechtigung. Der Vorgang geht an die eigene Leitung, eine Ebene je Schritt. Die Leitung hat drei Antworten:

  • decide: mit Pflichtbegründung, gilt für den Bereich der Leitung
  • handle: sie erledigt es selbst
  • forward: sie reicht mit eigener Einschätzung weiter

  Die Aufgabe, an der der Agent feststeckt, wartet (blockiert) und geht beim Abschluss wieder an die Arbeit.

• Erst nachsehen: Vor jeder Eskalation zeigt das Werkzeug die Beschlüsse, die den Agenten binden. Dieselbe Frage aus derselben Einheit schließt sich dem offenen Vorgang an, statt einen zweiten zu eröffnen.

• Konflikt: Zuerst nimmt die Gegenseite einmal Stellung. Danach geht der Vorgang direkt an die niedrigste gemeinsame Leitung. Die Leitungen dazwischen stehen als „vermerkt, nicht befragt“ im Vorgang. Einen Konflikt kann man weder weiterreichen noch „selbst erledigen“, er wird entschieden, und beide Seiten erfahren den Beschluss.

• Damit es endet:

  • Es gibt einen Tagesdeckel je Einheit (cases.escalationsPerUnitPerDay, Vorgabe 10). Darüber geht die Eskalation direkt an den Menschen, mit einem Vermerk.
  • Nach der Frist (cases.deadlineHours, Vorgabe 4 Stunden) wird der Mensch gerufen, einmal. Der Weckruf hat eine Anschlussstelle für den Kanal aus #644. Bis dahin erscheint der Vorgang in der neuen Ansicht „Vorgänge“, mit einem Zähler in der Seitenleiste.

• Der Mensch entscheidet dort mit Begründung (gilt für die ganze Instanz) oder fordert von einer Seite eine Stellungnahme an. Das ist die einzige Bewegung nach unten, die den Vorgang nicht schließt, und sie hat eine eigene Frist.

• Stille Post (#697) und Berichtsweg (#715):

  • Jede Ebene hängt ihren Beitrag an, jeder Beitrag trägt seinen Lauf.
  • Beim Halter kommt jeder Beitrag gerahmt als Daten an.
  • Wer fremde Inhalte liest, eskaliert ohne eigenen Text (nur mit dem Verweis auf die Aufgabe) und eröffnet keinen Konflikt mit eigenem Standpunkt.

• Nebenbei behoben: Der Scanner hat einen Status, den der Lauf selbst gesetzt hatte (blockiert, abgebrochen), am Laufende mit „erledigt“ überschrieben. Damit liefen sowohl das Eskalieren als auch der Meldeweg aus #715 ins Leere.

• Vorbedingung erfüllt (#676): Das Datenbank-Werkzeug beantwortet die Frage nach dem Schema selbst. describe nennt alle Spalten einer Tabelle und sagt ausdrücklich, dass ein nicht genanntes Feld nicht existiert. „Unbekannte Spalte“ und „unbekannte Tabelle“ werden mit dem Vorhandenen beantwortet. Damit ist „ich finde kein Feld dafür“ eine Feststellung.

6 — Die Entscheidungsinstanz an der Spitze

Der CEO-Agent aus dem Vorschlag ist eine gute Idee mit einer Bedingung: Er ist eine Rolle, keine Person, und die Rolle muss auch ein Mensch ausfüllen können. Sonst ist der Baukasten auf ein Firmenbild festgelegt.

Die Spitze des Baums ist eine Entscheidungsinstanz, und sie lässt sich besetzen mit:

• einem Menschen — Vorgänge landen in der Freigabe-Ansicht und warten
• einem Agenten — starkes Modell (etwa Fable 5), läuft selten, entscheidet und begründet
• beidem, mit Frist — der Mensch zuerst; antwortet er binnen einer einstellbaren Zeit nicht, entscheidet der Agent und legt die Entscheidung vor. Für einen Betrieb, der nachts weiterlaufen soll, ist das der interessante Fall.

Was ein entscheidender Agent darf und was nicht

Ein Modell, das entscheidet, ist etwas anderes als ein Modell, das arbeitet. Deshalb:

• Er entscheidet Fragen, er führt sie nicht aus. Aus einem Beschluss wird eine Aufgabe für die zuständige Einheit — er selbst rührt keine Datenbank an.
• Er hat kein Werkzeug mit Außenwirkung. Keine Mail, kein Geld, keine Veröffentlichung.
• Er ändert die Struktur nicht. Agenten anlegen, verschieben, Rechte oder Grenzen heraufsetzen bleibt beim Menschen — Linie von #205, #641 und #687.
• Er begründet jede Entscheidung, und die Begründung steht im Beschluss. Eine Entscheidung ohne Begründung ist für alle darunter nicht anwendbar und für den Menschen nicht überprüfbar.

Und eine Grenze, die man leicht übersieht: Ein CEO-Agent macht die Organisation nicht richtiger, nur schneller. Er entscheidet Fragen, deren Datengrundlage aus derselben Instanz kommt. Was er beschließt, sollte der Mensch stichprobenartig nachlesen — die Beschlusssammlung ist dafür genau der richtige Ort.

Umgesetzt (#690). Die Spitze steht in instance.json unter cases.top (mode: Human | Agent | HumanFirst, agentId, humanFirstHours) und wird in der WebUI unter Vorgänge › Spitze gesetzt, mit Begründung im Audit-Log. Ein Vorgang „erreicht die Spitze", wo er bisher beim Menschen landete: Eskalation über der letzten Leitung, Weiterreichen über die letzte Leitung, Konflikt ohne gemeinsame Leitung. Über dem Tagesdeckel und nach der Frist geht er weiterhin an den Menschen, nie an den Agenten — das sind die Sicherungen gegen die Spitze selbst.

• Eignung (TopRole.Unfit): Der Agent steht in keiner Einheit, liest keine Fremdinhalte und hat nur Taskboard, Escalation, Memory, FileRW und AgentComm. Geprüft beim Setzen, bei jeder Zustellung und vor jeder Entscheidung; Werkzeuge außerhalb der Liste lassen sich ihm nicht geben, und er lässt sich nicht in eine Einheit verschieben. Passt er nicht, geht der Vorgang an den Menschen, der Verlauf sagt warum.
• Entscheiden, nicht ausführen: handle ist ihm verwehrt; forward geht an den Menschen, auch bei einem Konflikt. Sein Beschluss bindet die ganze Instanz, ist als ByTopAgent markiert und liegt dem Menschen zum Lesen vor (Zähler in der Seitenleiste). Der Mensch kann jeden Beschluss mit Begründung zurücknehmen — er bleibt in der Sammlung, bindet aber niemanden mehr, und wer gefragt hatte, erfährt es.
• Mensch zuerst: Antwortet der Mensch nicht binnen humanFirstHours, übernimmt der Agent mit eigener Frist; entscheidet auch er nicht, wird der Mensch gerufen. Der Mensch kann einen Vorgang, den der Agent hält, jederzeit selbst entscheiden.
• Kosten: Der Agent läuft nur, wenn ihm ein Vorgang zugestellt wird. Ein eigenes Budget hat er als gewöhnlicher Agent; ist es erschöpft, bleibt der Vorgang liegen, bis die Frist den Menschen ruft — er verschwindet nicht.

7 — Der Werkzeugkasten

Der Vorschlag nennt es zu Recht in einem Atemzug mit der Struktur: Ein Haus voller Agenten ohne Werkzeuge ist eine Konferenz ohne Tagesordnung.

Was es gibt (Stand 0.1.15): FileRW, Database, Mail, WebFetch, WebMonitor, DirectAPI, FTP, Taskboard, Memory, AgentComm, AgentEditor, AgentSpawn, SocialMediaManager, Telegram, RocketChat.

Für den Beispielfall trägt das schon weit: Die Auftragsbestätigung kommt per Mail, die Bestellung steht in der Datenbank, der Marktplatz hängt an DirectAPI.

Keine Plattformen anbinden — auch nicht als MCP

Die Versuchung ist, fünfzig Einzelanbindungen zu bauen: Amazon, eBay, Shopify, DHL, DATEV. Das ist die Falle. Jede veraltet, und keine trifft die Firma, die als Nächstes kommt.

Ein MCP-Server je Plattform ist dieselbe Falle mit einem anderen Etikett. Er verlagert die Pflege nur nach außen: Man ist weiterhin darauf angewiesen, dass jemand genau diese Anbindung schreibt und aktuell hält.

Das Produkt gibt dem Agenten Fähigkeiten, keine Anschlüsse. Eine API aufrufen. Eine Webseite abrufen. Eine Datenbank befragen. Eine Mail lesen. Was daraus eine Amazon-Anbindung macht, ist die Kenntnis über Amazon — im Auftrag, im Gedächtnis und in Skripten, die die Instanz selbst hervorbringt.

Wo Spezifisches hingehört: in Skripte — aber nicht in die Hand dessen, der sie braucht

Braucht der Marktplatz-Agent eine wiederkehrende, exakt zugeschnittene Operation, dann entsteht dafür ein Skript. Er schreibt es nicht selbst.

Ein Anzeigen-Agent, der programmiert und beliebigen Code ausführt, hat Rechte, die seine Arbeit nicht braucht — und das ist keine Kleinigkeit, sondern die Umkehrung des Grundsatzes, dass jeder Agent genau die Rechte bekommt, die er zum Arbeiten benötigt.

Schreiben und Benutzen sind zwei verschiedene Rechte. Die Lieferkette:

Anzeigen-Agent                 „Ein Skript, das die Kampagnenberichte
   │ Bedarfsmeldung             zusammenfasst, würde mir X ersparen.
   ↓                            Eingaben: …, Ausgabe: …, Fehlerfälle: …"
Marketing-Leitung              prüft: wirklich nötig? wirklich wiederkehrend?
   │ weiterleiten
   ↓
Entwicklungs-Leitung           priorisiert, beauftragt
   │
   ↓
Entwickler-Agent               schreibt, testet — DIESER darf schreiben
   │
   ↓
Prüfung und Freigabe (#657)    Vorprüfung, Security-Einschätzung, Mensch
   │
   ↓
Anzeigen-Agent                 bekommt Zugang zu GENAU DIESEM Skript
   │ Fehlermeldung über die Befehlskette zurück
   ↓
Entwickler-Agent               bessert nach → neue Prüfung, neue Freigabe

Der Anzeigen-Agent darf dabei mehr als nur „wäre schön": eine ausgearbeitete Beschreibung — Eingaben, erwartete Ausgabe, Fehlerfälle, wie oft gebraucht. Er kennt den Bedarf am besten. Er bekommt nur nicht die Werkzeuge, ihn selbst zu decken.

Was daraus technisch folgt

Das ist mehr als eine Hausordnung, es ändert die Rechteform:

• scripts.write ist nicht dasselbe wie scripts.run. Ersteres hat genau eine Einheit, die Entwicklung. Letzteres ist kein Schalter, sondern eine Liste: Dieser Agent darf diese benannten Skripte ausführen, sonst keine. Ein „darf Skripte ausführen" als Ja/Nein wäre die Hintertür, die wir gerade geschlossen haben.
• Jedes Skript hat einen Eigentümer und einen Nutzerkreis. Das Manifest aus #657 nennt beide. Wer es benutzen darf, steht dort — nicht im Prompt des Nutzers.
• Der Nutzer prüft seine Werkzeuge nicht selbst. Bessert die Entwicklung nach, gilt die neue Fassung nach ihrer Freigabe für alle Nutzer. Sonst müsste der Anzeigen-Agent Code beurteilen, den er nicht schreiben darf.
• Ein Fehlschlag ist eine Meldung, keine Sackgasse. Scheitert das Skript, meldet der Agent es über die Befehlskette — derselbe Weg wie jede Eskalation (#689), nur mit „Fähigkeit fehlerhaft" statt „Fähigkeit fehlt".

Die Fehlerablage: der Entwickler liest das Original

Meldet der Anzeigen-Agent einen Skriptfehler über die Befehlskette, kommt beim Entwickler an, was zwei Modelle davon übrig gelassen haben — „es hat nicht funktioniert" statt KeyError: 'campaign_id' in Zeile 47. Damit ist die Kette nicht nur langsam, sondern unbrauchbar.

Der Fehler wird deshalb nicht weitergereicht, sondern abgelegt. Jedes Skript hat einen festen Ort dafür:

scripts/<skript-id>/
├── manifest.json          Zweck, Eigentümer, Nutzerkreis, Ein-/Ausgaben, Netzziele
├── skript.py              die freigegebene Fassung (hashgebunden, #657)
└── fehler/
    ├── 2026-09-22T07-14-03_run-a3de83bb.log
    └── 2026-09-22T09-02-51_run-11de5c7a.log

Drei Festlegungen machen den Unterschied:

1. Der Läufer schreibt, nicht der Agent. Exit-Code, stderr, Aufrufparameter, Dauer, RunId und AgentId legt der Sandbox-Runner (#654) ab — automatisch, bei jedem Fehlschlag. Damit ist nichts abgetippt, nichts gekürzt, nichts vergessen. Dieselbe Zusicherung wie beim Audit-Log: von der Engine gestempelt, nie vom Agenten behauptet.
2. Der Zugang folgt dem Skript, nicht der Abteilung. Wer das Skript besitzt, liest seine Fehler — unabhängig davon, in welcher Einheit sie entstanden sind. Ein Entwickler kommt so an alle Fehlschläge aller Nutzer, ohne in deren Arbeitsbereiche zu dürfen. Das ist ein Rechtebereich, der am Gegenstand hängt statt am Baum, und die Ausnahme ist begründet: Der Eigentümer muss sehen, wie sein Werkzeug scheitert.
3. Die Meldung trägt den Verweis. Was durch die Befehlskette geht, ist „Skript amazon-kampagnenbericht, drei Fehlschläge seit gestern, siehe Ablage" — plus die Einschätzung des Agenten, was ihm dadurch fehlt. Die Leitung entscheidet über die Dringlichkeit, nicht über den Fehlertext.

Ein Nebeneffekt, der mehr wert ist als die Meldung selbst: Drei Fehlschläge desselben Skripts an einem Tag sind ein Muster, das niemand melden muss — es steht in der Ablage und lässt sich abfragen. Dasselbe Verhältnis wie bei #646 und #680: Erkennen ist Code, Deuten ist Modell.

Der zweite Gewinn dieser Trennung

Sie ist nicht nur sauberes Rechtemanagement. Sie ist die schärfste Grenze, die man gegen eingeschleuste Anweisungen ziehen kann: Der Agent, der fremde Inhalte liest, ist nie der Agent, der ausführbaren Code hervorbringt.

Der Anzeigen-Agent liest Amazon-Seiten, Berichte, Mails — lauter Text, den jemand anderes verfasst hat. Dürfte er daraus Code schreiben und ausführen, gäbe es einen durchgehenden Weg von einer manipulierten Webseite bis zur Codeausführung. Mit der Lieferkette liegen dazwischen: eine Leitung, eine Entwicklungsabteilung, eine deterministische Vorprüfung, eine Sicherheitseinschätzung und ein Mensch.

Das schließt eine Frage nicht aus, die beim Bau zu klären ist: Eine Bedarfsmeldung, die aus einem Lauf mit Fremdinhalt stammt, trägt dessen Herkunft weiter — sie kann die Beschreibung eines Skripts enthalten, die jemand anderes dem Agenten untergeschoben hat. Sie gehört deshalb als belastet gekennzeichnet beim Entwickler an (#651, #659), und der Entwickler behandelt sie als Wunsch, nicht als Vorlage.

Die Bausteine dafür sind geplant:

Item	Was
#654	Sandbox-Runner (bwrap): jede Codeausführung außerhalb des Hauptprozesses
#196	Shell-Tool mit echter Sandbox
#657	Skriptprüfung: ausgeführt wird nur die freigegebene Fassung — gebunden an den Hash von Skript, Manifest und Interpreter; jede Änderung, auch ein Bugfix, braucht eine neue Prüfung
#695	Die Lieferkette: Bedarfsmeldung, Entwicklung, Zuteilung an benannte Nutzer, Fehlermeldung zurück

Diese vier sind nicht nur Sicherheitsvorhaben — sie sind der eigentliche Werkzeugkasten. Die ersten drei stehen heute unter SEC, weil sie dort aus der Sicherheitsseite gedacht wurden. Aus der Baukastenseite betrachtet sind sie die Antwort auf „wie bedient eine Instanz Amazon?", und ihr Rang sollte das widerspiegeln.

Die Reihenfolge bleibt dabei zwingend: erst die Sandbox, dann das Schreiben. Ein Agent, der Code schreiben und ausführen darf, ohne dass die Ausführung eingesperrt ist, ist kein Werkzeug, sondern ein Loch. Das ist keine Bürokratie, sondern der Unterschied zwischen beidem.

Was darüber hinaus fehlt

1. Zugangsdaten je Einheit. Heute hängen sie am Agenten. Ein Einkauf mit sechs Agenten braucht sie einmal, nicht sechsmal — und die Buchhaltung darf den Marktplatz-Schlüssel nicht sehen. Gehört an die Einheit (#683), mit demselben Vererbungsgedanken wie die Rechte.
2. Das Lesen dessen, was wirklich hereinkommt. Eine Auftragsbestätigung ist ein PDF-Anhang, eine Preisliste eine Tabelle. Text aus Anhängen zu holen ist die unspektakulärste und am häufigsten gebrauchte fehlende Fähigkeit. Ein PDF vom Lieferanten ist dabei so wenig vertrauenswürdig wie eine Webseite (#193).
3. Der MCP-Client (#197) bleibt nützlich — aber als eine Fähigkeit unter anderen, für Dienste, die ohnehin als Server bereitstehen. Nicht als Anbindungsstrategie.

Und quer dazu: Jedes Werkzeug bringt seine Eignungsproben mit (Werkzeugproben-Konzept, #681). Bei fünfzehn Werkzeugen ist das angenehm; bei fünfzig ist es die einzige Art, den Überblick zu behalten, welches Modell womit umgehen kann.

---

7a — Fremde Laufzeiten

Ergänzt am 2026-09-24, angeregt durch Paperclip. Items #712, #713.

Der vorige Abschnitt legt fest, dass nur die Entwicklungsabteilung Code hervorbringt. Daraus folgt eine Frage, die bisher offen war: Womit programmiert sie? Ein nachgebautes Schreib-und-Ausführ-Werkzeug von uns wird nie so gut wie Claude Code, das auf nichts anderes ausgelegt ist. Und mit einem Abo kann es billiger sein als Tokens über OpenRouter.

Also bekommt jeder Agent eine Laufzeit:

Laufzeit	Was läuft	Wofür
native	unsere Engine mit OpenRouter, wie heute	Voreinstellung, alles außer Programmieren
claude-code	Claude Code im Kopflos-Modus	die Entwicklungsabteilung
codex	OpenAI Codex CLI	dasselbe, anderer Anbieter
command	ein Befehl, dessen Ausgabe das Ergebnis ist	Sonderfälle
http	ein Aufruf an einen fremden Dienst	Agenten, die woanders laufen

Was die Instanz behält: Organisation, Taskboard, Budget, Audit, Freigaben. Was die fremde Laufzeit übernimmt: die Arbeit innerhalb eines einzelnen Laufs. Paperclip trennt das vollständig: „control plane, not execution plane". Wir tun das nicht, und das ist Absicht. Unsere Sicherheit liegt in der Ausführung (StagingGate, Werkzeugrechte, UntrustedContent). Eine fremde Laufzeit ist deshalb die Ausnahme für einen bestimmten Zweck, nicht das Modell für alles.

Eine fremde Laufzeit gilt als weniger vertrauenswürdig

Was innerhalb von Claude Code geschieht, sieht keine unserer Prüfstellen. Daraus folgen vier Regeln:

1. Eigener Arbeitsplatz. Ein Worktree oder eine Sandbox (#654), nie der Arbeitsbereich der Instanz selbst.
2. Freigabelisten statt Rechte-Umgehung. --allowedTools und --max-turns, nie --dangerously-skip-permissions. Bei Paperclip ist die Umgehung die Voreinstellung; bei uns ist sie ausgeschlossen.
3. Das Ergebnis ist ein Vorschlag. Ein Diff oder ein fertiges Skript zur Abnahme, nie ein direkter Einsatz. Ob es eingesetzt wird, entscheidet die Lieferkette aus Abschnitt 7 (#695). Dass es Claude Code geschrieben hat, erspart keine Prüfung.
4. Nach außen nur über uns. Mit Taskboard, Leitung und Ablage spricht die fremde Laufzeit über einen MCP-Server, den die Instanz je Lauf bereitstellt (#713). Jeder Aufruf dort durchläuft dieselbe Kette wie ein nativer Werkzeugaufruf. Der Server bietet nur an, was der Agent laut Konfiguration hat, und ist damit kein zweiter Weg an den Rechten vorbei. Das Token gilt einen Lauf lang und wird nie in der Befehlszeile übergeben.

Der MCP-Server ist gebaut (2026-09-25, #713). So umgesetzt, mit einer Abweichung vom Plan:

• Eigener Socket statt des Instanz-Sockets. Das Konzept sah HTTP über den Unix-Socket der Instanz vor. Über manager.sock antwortet aber die ganze Verwaltung ohne Token, weil dort das Dateisystem die Grenze ist. Eine fremde Laufzeit darf ihn deshalb nie bekommen. Der Server hat einen eigenen Socket mcp.sock (0600; unter Windows eine eigene Named Pipe). Über ihn gibt es nur /mcp, jeder andere Pfad antwortet 404, und /mcp öffnet nur ein MCP-Token. Diesen einen Socket bindet später die Sandbox (#654) ein.
• Ein Weg für alle Aufrufe: AgentEngine.ExecuteExternalToolCallAsync führt jeden Aufruf durch dieselbe Kette wie einen Aufruf des eigenen Modells: Rechtetor, Vorprüfung, Werkzeugrechte, Staging, Audit (Quelle mcp), Rahmung. Der Aufrufer gilt als Leser fremder Inhalte (#715, Quelle external-runtime): Eine fremde Laufzeit schreibt keine Prosa in den Kontext ihrer Leitung.
• Tokens: Das Lauf-Token (McpGrants.OpenRun) lebt nur im Speicher. Es endet mit dem Handle des Laufs und spätestens nach vier Stunden. Persönliche Tokens für den eigenen Claude Code des Menschen (Agentenansicht, „Externer Zugang“) sind höchstens 90 Tage gültig, jederzeit widerrufbar und nur als SHA-256 gespeichert. Ein Token nennt den Agenten, als der gearbeitet wird; das WebUI-Token öffnet /mcp nicht.
• Transporte: HTTP (POST /mcp, JSON-Antworten, keine Sitzungen, kein Ereignisstrom; Anfragen mit Origin werden abgewiesen) auf mcp.sock und auf dem Port der Weboberfläche. Über den Manager ist der Server unter POST /mcp/{instanz} erreichbar; der Manager reicht nur weiter, zum MCP-Socket und nie zum Instanz-Socket. Für lokal gestartete Laufzeiten gibt es stdio über ClawdDotNet --mcp-bridge --instance <dir>. Das Token kommt aus CLAWD_MCP_TOKEN oder aus einer Datei in CLAWD_MCP_TOKEN_FILE; die Brücke lehnt die Datei ab, wenn andere sie lesen dürfen.

Kosten, die nichts kosten

Mit einem Abo kostet ein Lauf 0 $ und verbraucht trotzdem etwas: Kontingent. Die Token-Zahlen aus --output-format stream-json gehen deshalb wie jeder andere Lauf in RunUsage. In der Kostenanalyse (Abschnitt 8a) erscheinen sie als Kontingentverbrauch, nicht als „kostenlos". Sonst wird genau die Abteilung unsichtbar, die am meisten Tokens verbraucht.

Zwei Vorbehalte vor dem Bau

• Das Kontingent teilt der Mensch mit sich selbst. Ein Pro-Plan, auf dem die Entwicklungsabteilung läuft, ist derselbe, mit dem der Mensch arbeitet. Entweder ein eigener Account oder eine Vorfahrtsregel, die die Abteilung anhält, bevor der Mensch an die Grenze stößt.
• Die Nutzungsbedingungen sind nicht geprüft. Ob der automatisierte Dauerbetrieb eines Verbraucher-Abos durch ein Agentensystem gedeckt ist, ist offen. Deshalb werden beide Anmeldewege gebaut, Abo und API-Schlüssel, und die Entscheidung bleibt eine Frage der Konfiguration statt eine des Umbaus.

Umsetzung (2026-09-25, #712)

Gebaut sind native, claude-code und command. codex und http sind nicht gebaut („nach Bedarf“); die Einstellung lehnt sie ab, statt sie still als native laufen zu lassen. Ein Agent bekommt seine Laufzeit in der Agentenansicht (Karte „Laufzeit“) oder als runtime in AgentSettings.json. Das Claude-Code-Konto gilt für die ganze Instanz (claudeCode in instance.json, Schlüssel verschlüsselt wie der OpenRouter-Schlüssel).

• Ohne Sandbox kein Lauf. Ein fremder Lauf fällt nie auf die native Engine zurück, auch nicht ohne Runner. Deren Modell und Kosten wären nicht die konfigurierten.
• Eigener Arbeitsplatz ist eine Kopie. Der Lauf arbeitet auf einer Kopie des Arbeitsbereichs, höchstens 20 000 Dateien und 512 MB. Was sich darin ändert, wird zum Vorschlag unter proposals/<lauf>/: proposal.json und die geänderten Dateien. Übernommen wird nichts; das ist die Sache der Lieferkette (#695). Gelesen werden nur reguläre Dateien. Ein symbolischer Link, den der Lauf hinterlässt, könnte außerhalb der Sandbox auf einen Schlüssel zeigen, eine benannte Pipe würde den Leser für immer blockieren. Beide werden nur als „ignoriert“ genannt.
• Netz nur über den Proxy. Die Sandbox behält ihr eigenes Netz ohne alles außer Loopback. Claude Code erreicht api.anthropic.com über einen HTTPS-Proxy im Hauptprozess, dazu die Hosts, die der Agent einträgt. Der Proxy ist gleich mit gebaut (#655, Security-Konzept 5.2). Updates und Telemetrie von Claude Code sind abgeschaltet.
• Nur unsere Einstellungen gelten. --setting-sources user liest nur die Einstellungen, die vor jedem Lauf ins Home der Laufzeit geschrieben werden, --strict-mcp-config nur unseren MCP-Server. Eine .claude/settings.json oder .mcp.json in der Kopie gewährt also nichts. Hooks sind aus. Was ein Lauf im Home hinterlässt und den nächsten anweisen könnte (Agents, Commands, Skills, CLAUDE.md), wird vor dem Start entfernt. Anmeldestand und Verlauf bleiben.
• Freigabelisten: --allowedTools (Voreinstellung: Read, Edit, Write, Glob, Grep und mcp__clawd) und --max-turns. WebFetch und WebSearch sind immer verboten: Das Web läuft über unsere Werkzeuge, nicht an ihnen vorbei. --dangerously-skip-permissions gibt es nicht, auch nicht als Werkzeugname verkleidet.
• Der Rückweg: Die Anwendung selbst ist in der Sandbox die MCP-Brücke (--mcp-bridge --socket /run/mcp.sock). Der MCP-Socket ist eingebunden, das Lauf-Token liegt in einer 0600-Datei und endet mit dem Lauf.
• Schlüssel nie auf der Befehlszeile. Die Anwendung ist in der Sandbox auch der Starter (--sandbox-launch). Er liest den Schlüssel aus einer eingebundenen Datei und setzt ihn in die Umgebung des Programms. Er leitet außerdem den Proxy-Port der Sandbox an den Proxy-Socket weiter.
• Verbrauch: RunUsage hat die Spalten Runtime und OnSubscription. Ein Lauf auf dem Abo kostet 0 $ und trägt seine Token; mit API-Schlüssel gilt der gemeldete Betrag (total_cost_usd). Die Anzeige als Kontingentverbrauch ist Sache von #699.
• Chat: Eine fremde Laufzeit hat keinen Gesprächsverlauf, der weitergeführt würde. Jede Nachricht ist ein eigener Lauf; der Chat zeigt trotzdem beide Seiten.

Geprüft unter Linux auf der Test-VM, in der echten Sandbox: Schlüssel stehen in keiner Befehlszeile, ein gelisteter Host ist erreichbar, ein anderer nicht, am Proxy vorbei gibt es kein Netz, der Loopback der Instanz ist nicht der der Sandbox. Ein Programm in der Sandbox erreicht den MCP-Server als sein Agent. Der ganze Claude-Code-Weg ist mit einem Stellvertreter für claude geprüft, weil das echte Claude Code auf der Test-VM nicht laufen darf. Offen: der Lauf mit dem echten Claude Code und einem echten Schlüssel. Das macht der Mensch einmal von Hand.

Nicht gebaut: eine Speichergrenze für fremde Laufzeiten. Eine JavaScript-Laufzeit reserviert Adressraum in Gigabyte-Blöcken und startet unter keiner sinnvollen ulimit -v. Eine echte Grenze bräuchte cgroups.

---

8 — Kontrolle: eine Leitung delegiert nicht nur

Modelle machen Fehler. Das ist keine Randbedingung, sondern die Arbeitsgrundlage — vier Tage Testbetrieb haben es viermal vorgeführt (#662, #673, #674, #676). Eine Organisation, die das nicht einplant, verteilt Fehler nur schneller.

Delegieren ohne Nachsehen ist deshalb keine Leitung. Zur Rolle gehört die Stichprobe: Arbeitet der Agent sauber? Nicht bei jedem Lauf — stichprobenartig, und dichter bei einem neuen Agenten, einem neuen Modell oder nach einem Fehlschlag.

Was eine Stichprobe ist

Nicht: den Agenten fragen, ob alles gut lief. Genau das ist als Kontrollinstrument wertlos — ein Agent, der seine Aufgabe verfehlt, berichtet das nicht zuverlässig, und im Prüfdurchgang vom 14.09. hat ein Modell dreizehn Werkzeugantworten frei erfunden.

Sondern: Ergebnis gegen Auftrag halten, und beides gegen das, was die Engine gestempelt hat — AuditLog, RunReceipts, RunTranscripts (#660). Genau die Datenbasis des AgentInspector (#204). Eine Leitung, die prüft, ist ein viertes Profil desselben Unterbaus, mit dem Blick auf die eigene Einheit statt auf die ganze Instanz.

Was aus einem Befund folgt

Hier kommt die Personalseite ins Spiel, und sie braucht abgestufte Mittel statt eines Schalters:

Befund	Mittel
Aufgabe unklar formuliert	Auftragstext schärfen — häufigster Fall, siehe #663
Modell überfordert	Eignungsprobe (#681), dann anderes Modell
Rechte zu weit oder zu eng	Werkzeugrechte anpassen (#641)
Wiederholte Fehlschläge trotz allem	Agent stilllegen, Aufgaben umhängen
Verdacht auf Manipulation von außen	Security-Agent (#658), Quarantäne

Die ersten vier sind Personalentscheidungen und gehören zum Personalmanager (Basisagenten-Konzept). Der letzte gehört zur Sicherheit, und die Trennung ist wichtig: Ein Agent, der schlecht arbeitet, ist ein Personalfall. Ein Agent, der vielleicht ferngesteuert wird, ist keiner — da hilft kein besseres Modell.

Keines dieser Mittel darf die Leitung allein ziehen. Ein Modell, das ein anderes Modell stilllegt oder umkonfiguriert, verändert die Organisation ohne menschliche Beteiligung. Die Leitung schlägt vor und begründet; ausgeführt wird nach Freigabe — Linie von #205, #641, #687.

Die Abstimmung: mehrere Blickwinkel statt einer Freigabe

Die Freigabe durch die Leitung (#687) ist eine Entscheidung aus einer Sicht. Für manches ist das zu wenig — nicht weil eine Meinung fehlt, sondern weil mehrere unabhängige Prüfungen fehlen:

Der Einkäufer will Ware für 150 € bestellen. Buchhaltung prüft, ob wir uns das leisten können. Logistik prüft, ob wir noch genug davon am Lager haben. Marketing prüft, ob es überhaupt ins Sortiment passt. Jeder hat eine Stimme. 3 von 4 dafür → bestellt. 1 von 4 → nicht. 2 von 4 → eskaliert, mit den Begründungen.

Das ist keine Demokratie im politischen Sinn, und der Unterschied ist wichtig für den Bau: Es werden nicht Meinungen gezählt, sondern unabhängige Prüfungen erzwungen. Jede Stimme kommt aus einer anderen Datenquelle — Kontostand, Lagerbestand, Sortiment. Das ist der eigentliche Gewinn, nicht die Mehrheit.

Daraus folgt die wichtigste Regel:

Es wird blind abgestimmt. Kein Stimmberechtigter sieht die Stimme eines anderen, bevor er die eigene abgibt. Sonst stimmt ein günstiges Modell dem zu, was es gerade gelesen hat, und aus vier Prüfungen wird eine Prüfung mit drei Echos.

Damit ist die Abstimmung das genaue Gegenteil der Besprechung (#686): Dort sieht jeder Teilnehmer die bisherigen Beiträge, weil Abstimmung im Wortsinn der Zweck ist. Hier sieht niemand sie, weil Unabhängigkeit der Zweck ist. Beide Mittel gehören nebeneinander, und sie dürfen nicht verwechselt werden.

Die weiteren Festlegungen:

• Jede Stimme trägt Begründung und Beleg. Nicht „nein", sondern „nein — Lagerbestand 340 Stück, Abfrage vom 22.09. 08:14". Ohne Beleg ist eine Stimme eine Meinung (#697).
• Wer beantragt, stimmt nicht mit. Dieselbe Linie wie bei der Leitung, die ihre eigenen Aufrufe nicht freigibt (#687).
• Eine fehlende Stimme ist kein Ja. Scheitert ein Lauf oder antwortet ein Stimmberechtigter nicht in der Frist, fehlt die Stimme. Kommt das Quorum nicht zustande, wird eskaliert — nichts wird stillschweigend durchgewinkt.
• Die Schwellen gehören zur Regel, nicht ins Modell. Wie viele Stimmen, wer, ab welchem Betrag, was bei Gleichstand — das steht in der Freigaberegel der Einheit und ist einstellbar.
• Abstimmen kostet. Vier Stimmberechtigte sind vier Läufe zusätzlich zum eigentlichen Vorgang. Abstimmungen gehören deshalb an Schwellen gebunden — die 150 € aus dem Beispiel sind vermutlich zu wenig dafür, und genau das soll die Auswertung zeigen.
• Alles wird erfasst: Antrag, jede Stimme mit Begründung und Beleg, Ergebnis, Kosten. Erst damit lässt sich hinterher fragen, ob die Abstimmung etwas verhindert hat oder nur Geld gekostet hat.

Und eine Eigenschaft, die man leicht für eine Lücke hält: Eine Abstimmung gibt keinem Agenten einen neuen Gesprächspartner. Die Stimmberechtigten reden nicht miteinander — sie sehen den Antrag und antworten. Deshalb steht sie nicht in der Ausnahmeliste aus Abschnitt 3.

Die Doctrine: wie eine Leitung steuert, ohne jeden Auftrag anzufassen

Ein Agent wird heute von zwei Texten geprägt: Identity.md sagt, wer er ist, Soul.md, wie er arbeitet. Beides ändert nur ein Mensch (#205).

Einer Leitung fehlt damit ein Mittel. Sie kann Aufträge verteilen und Ergebnisse prüfen — aber nicht sagen: „In dieser Abteilung gilt ab sofort, dass jeder Lieferantenkontakt in der Datenbank landet, bevor er weitergegeben wird." Dafür müsste sie jeden Aufgabentext einzeln ändern.

Die Leitung legt deshalb eine Doctrine.md in den Ordner ihrer unterstellten Agenten. Ein dritter Text neben Identity und Soul: nicht wer und nicht wie, sondern was in dieser Einheit gerade gilt.

Vier Festlegungen:

1. Nur eine Ebene tief. Die Doctrine einer Abteilungsleitung erreicht die Agenten ihrer Einheit — sie stößt nicht automatisch in die Untereinheiten durch. Ein Team unter ihr hat seine eigene Leitung, und die schreibt ihre eigene. Wäre es anders, summierten sich bei fünf Ebenen fünf Doktrinen in jedem Prompt, und niemand wüsste mehr, welche Regel woher kommt.
2. Selten und sichtbar. Eine Doctrine, die wöchentlich wechselt, ist keine Doktrin, sondern Mikromanagement mit Tokenkosten. Erzwingen lässt sich das nicht — beobachten schon: Jede Änderung steht im Audit mit Vergleich zur Vorfassung, und häufige Änderungen sind ein Befund für die Aufsicht (#680).
3. Kurz und gedeckelt. Sie geht in jeden Lauf jedes unterstellten Agenten. Fünf Agenten mal vierzig Läufe am Tag mal tausend Token sind 200.000 Token täglich für einen Text, den niemand mehr liest. Eine Höchstlänge gehört dazu.
4. Eine belastete Leitung schreibt nicht frei. Hat der Lauf, in dem die Leitung die Doctrine ändert, fremde Inhalte gelesen — eine Mail, eine Webseite, einen Lieferantenbericht —, dann ist die Änderung freigabepflichtig (#651, #659). Sonst wäre die Doctrine der bequemste Weg, einer ganzen Abteilung von außen etwas unterzuschieben: ein Text, der ungefragt in jedem Prompt steht.

Ansonsten darf die Leitung sie ändern, ohne zu fragen. Das ist der Unterschied zu Identity und Soul, und er ist gewollt: Eine Leitung, die für jede Anweisung an ihre eigene Abteilung einen Menschen braucht, ist keine Leitung.

A/B: welches Modell macht es besser oder billiger?

Die Eignungsprobe (#681) beantwortet „kann dieses Modell dieses Werkzeug bedienen?" — einmal, vor der Inbetriebnahme. Die Frage der Leitung ist eine andere: Arbeitet der Amazon-Marketing-Agent mit Gemini Flash 3.8 zuverlässig, oder macht Sonnet oder ein GPT-Modell es besser — oder billiger?

Das lässt sich im laufenden Betrieb beantworten, weil die Datenbasis schon da ist (#694): dieselbe Rolle, dieselben Aufträge, zwei Modelle über einen Zeitraum. Verglichen werden Ausgang, Schritte, Kosten, Fehlschläge, Nacharbeit.

Drei Dinge machen den Unterschied zwischen einer Messung und einem Gefühl:

• Vergleichbare Aufträge. Wiederkehrende Aufgaben eignen sich, einmalige nicht.
• Ein Erfolgsmaß, das nicht die Selbstauskunft ist. „ERGEBNIS: ok" sagt nichts. Messbar sind: Lauf abgeschlossen, Werkzeugfehler je Lauf, Nacharbeit nötig, Eskalation ausgelöst, Kosten.
• Genug Läufe. Zwei Läufe sind kein Vergleich. Bei wiederkehrenden Aufgaben ist das kein Problem — eine Woche reicht.

Das Ergebnis ist wieder eine Empfehlung, keine Umstellung: Der Personalmanager legt sie vor, entschieden wird mit Freigabe.

8a — Kosten und Prompts: das wichtigste Instrument

Je größer das Haus, desto weniger sieht man von innen. Was eine Organisation aus fünfzig oder hundert Agenten noch steuerbar macht, ist die genaue Erfassung dessen, was sie kostet und was sie einander sagt. Ein solches Haus wird früher oder später einige hundert Dollar im Monat verbrauchen — und die Frage ist nie „können wir uns das leisten?", sondern „wo davon ist Verschwendung?".

Die Datenbasis steht bereits: RunReceipts (Schritte, Tokens, Kosten je Lauf), RunUsage, AuditLog und die Prompt-History aus #660. Was fehlt, ist die Ebene der Einheit darin — heute lässt sich nur je Agent auswerten.

Grenzen bleiben am Agenten, die Einheit rechnet auf

Festgelegt am 2026-09-22: Token- und Kostengrenzen bleiben da, wo sie heute sind — am einzelnen Agenten. Auf Einheitsebene wird gerechnet, nicht gedeckelt:

• Tatsächliche Kosten je Einheit, aufsummiert über ihre Agenten und Untereinheiten
• Theoretisches Maximum je Einheit, als Summe der Agentengrenzen darunter
• beides je Tag, Woche, Monat — und im Vergleich zum Vormonat

Das ist die sparsamste Lösung, und sie hat einen Vorteil, der erst beim Umziehen auffällt: Ein Umzug ändert keine einzige Grenze. Wäre das Budget der Einheit eine Zuteilung, müsste bei jeder Umorganisation neu gerechnet werden — bei einer Instanz, die mit ihrem Projekt wächst, also dauernd.

Die Meldung ist wichtiger als die Grenze

Eine Grenze sagt nur, wann Schluss ist. Was man wirklich wissen will, ist, wann sich etwas ändert:

Die Agenten der Marketingabteilung dürften zusammen 100 $ am Tag ausgeben. Seit Wochen brauchen sie 30 . Heute sind es 80 .

Da ist nichts überschritten — und trotzdem ist genau das der Moment, in dem man hinsehen muss. Also:

• Abweichung vom eigenen Verlauf. Ein gleitender Mittelwert je Einheit über die letzten Wochen; wird er deutlich überschritten, geht eine Meldung raus. Das findet Schleifen, entgleiste Aufgaben und teure Modellwechsel, bevor sie einen Monat lang laufen.
• Annäherung an die Grenze. Wenn die Summe der Agentengrenzen einer Einheit zu einem hohen Anteil ausgeschöpft wird, ebenfalls eine Meldung — bevor Agenten reihum in ihr Limit laufen.
• Gesamtbetrag erreicht. Schwellen je Monat, die nichts abschalten, sondern melden.

Erkennen ist auch hier Code, nicht Modell: Ein Mittelwert und ein Schwellwert sind eine Abfrage. Ob die Abweichung ein Problem ist, deutet die Aufsicht (#680).

Was liegen bleibt, wenn das Budget endet

Ergänzt am 2026-09-24 auf Hinweis des Nutzers. Item #716.

Um 22:30 ist das Tagesbudget aufgebraucht, und für den Rest des Tages stehen noch 100 Läufe an. Lässt man sie verfallen, fehlt Arbeit. Holt man sie nach, fressen sie das Budget des nächsten Tages.

Heute gibt es dafür schon ein Verhalten. Nur hat es niemand entschieden. Der Ausfall wird vermerkt (seit #608 als RunReceipt mit BudgetExceeded), aber nicht an der Aufgabe und nicht zusammengefasst. Einmalige Aufgaben werden alle 30 Minuten erneut versucht und laufen nach Mitternacht still zu Lasten des neuen Tages. Wiederkehrende verfallen still, weil ihr Termin schon beim Beanspruchen verbraucht ist. Beides kann richtig sein, aber nicht, ohne dass es jemand festlegt. Die Tagesgrenze ist die lokale Mitternacht.

Der Vorschlag ist eine Einstellung je Agent, was mit einem Lauf geschieht, der am Budget scheitert:

Regel	Was geschieht	Voreinstellung für
expire	verfällt, wird an der Aufgabe vermerkt	wiederkehrende Aufgaben: Der nächste Termin kommt ohnehin, ein verpasster Stundenbericht ist vom nächsten überholt
catch_up_once	alle verfallenen Termine werden zu einem Nachholauf zusammengefasst	— (sinnvoll für den Tagesbericht, dessen nächster Termin erst in 24 Stunden käme)
carry_over	wird mitgenommen	einmalige Aufgaben: echte Arbeit, die nicht verschwinden darf

Dazu gilt: Der neue Tag hat Vorfahrt. Nachholläufe kommen nach den regulär fälligen, unterhalb jeder Priorität, und sie nutzen nur den Spielraum, den der Rest des Tages nicht braucht: Grenze minus Verbrauch, minus die Reservierung laufender Läufe, minus der Bedarf der noch geplanten Läufe bis Mitternacht, minus 10 % Reserve. Ohne diese Regel schiebt ein einziger überzogener Tag seinen Ausfall Tag für Tag vor sich her, statt ihn aufzulösen. Beim Bau am 2026-09-24 geändert: Das Konzept sah hier zunächst einen pauschalen Anteil von 25 % vor. Ein fester Anteil ist an einem vollen Tag zu viel und an einem ruhigen unnötig wenig; der Spielraum folgt dem tatsächlichen Plan, und dieselbe Rechnung trägt später die Füllarbeit. Eine einmalige Aufgabe, die nach einigen Tagen immer noch nicht drankam, geht an den Menschen: Was nie läuft, darf nicht unbemerkt liegen bleiben.

Vermerkt wird zweimal: an der Aufgabe („ausgefallen: Budget erschöpft, 22:30" bzw. „nachgeholt am …") und in einer Tageszusammenfassung („Budget Marketing um 22:30 erschöpft, 100 Läufe ausgefallen, 12 zum Nachholen vorgemerkt"). Die Zusammenfassung geht in die Abweichungsmeldung oben und ins Lagebild (Abschnitt 10a).

Besser als jede Nachholregel ist Vorbeugen. Die Kostenprognose aus #608 weiß schon heute, ob das Budget für die geplanten Aufgaben reicht. Sie sollte vormittags melden, dass bei diesem Verbrauch um 22:30 Schluss ist. Dann kann der Mensch rechtzeitig nachlegen oder entscheiden, was entfällt.

Zur selben Baustelle gehört die Budgetreservierung, der offene Rest aus #682: Noch prüft jeder Lauf das Budget einzeln vor dem Start, und bis zu maxParallelTaskRuns Läufe können es gemeinsam überschreiten. Erst mit einer Reservierung vor dem Lauf ist der Ausfall vorhersagbar statt eine Frage, welcher Lauf zuerst zugreift.

Füllarbeit und Großaufgaben

Ergänzt am 2026-09-24 auf Vorschlag des Nutzers. Item #717.

Der vorige Abschnitt regelt, was liegen bleibt, wenn das Budget nicht reicht. Die Kehrseite: An den meisten Tagen bleibt Budget übrig, und das verfällt.

Füllarbeit ist Arbeit, die umfangreich, aber nicht eilig ist. Ob sie heute, morgen oder übermorgen läuft, ist gleich. Sie bekommt statt eines Termins eine Frist „spätestens bis" und läuft, wenn Platz ist. Rechenzentren machen das seit Jahrzehnten so und nennen es Backfilling. Ob Platz ist, entscheidet der Code:

• Keine regulär fällige Aufgabe des Agenten wartet.
• Das Restbudget des Tages, abzüglich der Prognose für die noch geplanten Läufe (#608) und eines Sicherheitsaufschlags, reicht für die Schätzung der Füllarbeit.
• Bevorzugt spät am Tag, weil die Prognose dann am wenigsten Unsicherheit hat.

Rückt die Frist näher und es fand sich nie Platz, wird der Mensch gefragt: Budget erhöhen oder Frist verschieben. Eine Füllarbeit überschreitet ihre Frist nie still.

Großaufgaben sind Aufgaben, deren Schätzung einen großen Teil des Tagesbudgets übersteigt (Vorgabe etwa 50 %). Sie werden nicht einfach angefangen. Der Agent schlägt einen von zwei Wegen vor:

1. Teilen. Unteraufgaben, jede ein eigener Lauf, verbunden über die Elternaufgabe (Zielkette, Abschnitt 9a). Die Teile können dann Füllarbeit sein.
2. Sonderbudget. Ein Betrag für genau diese Aufgabe samt Unteraufgaben, vom Menschen freigegeben. Es ist ein eigener Topf: Es hebt die Tagesgrenze des Agenten nicht an und ist in der Kostenanalyse gesondert sichtbar. Damit ist es die einzige Ausnahme von „Budgets bleiben am Agenten", gebunden an eine Aufgabe und nie still.

Ehrlich schätzen. Kosten lassen sich vorab nicht genau wissen, und Modelle schätzen ihren eigenen Aufwand schlecht. Wo es Verlauf gibt, schätzt der Code aus dem Verlauf. Sonst schätzt der Agent, und die Zahl ist als Schätzung gekennzeichnet. Nach dem ersten Teillauf ersetzt der gemessene Wert die Schätzung.

Gebaut am 2026-09-25 (#717). So umgesetzt, mit den Entscheidungen, die das Konzept offen ließ:

• Füllarbeit ist eine einmalige Aufgabe mit fill_by statt Termin (Werkzeug, WebUI, Datei). Sie kommt nach der regulären und der nachgeholten Arbeit (#716), mit der nächsten Frist zuerst. Sie startet nur, wenn keine andere Arbeit desselben Agenten wartet, ab fillWork.fromHour (Vorgabe 18 Uhr) und nur, wenn ihre eigene Schätzung in den Spielraum aus #716 passt. Ohne Budgetgrenze gibt es nichts zu füllen, dann läuft sie sofort.
• Frist: fillWork.warnHoursBeforeDeadline (Vorgabe 24) vor der Frist bekommt ein Mensch einmal eine Aufgabe unter der Füllarbeit: Budget erhöhen oder Frist verschieben. In diesem Fenster wartet sie auch nicht mehr auf den Abend. Entscheidung: Ist die Frist erreicht, läuft sie als reguläre Arbeit. Die Frist war die Zusage, und der Mensch wurde vorher gefragt.
• Schätzung (TaskCostEstimator): eigene gemessene Läufe, dann die Läufe der Geschwister unter derselben Elternaufgabe, dann estimate_usd des Autors, zuletzt das Mittel des Agenten. Die letzten beiden sind überall als Schätzung gekennzeichnet.
• Großaufgabe: Groß ist eine Aufgabe erst mit einer Schätzung dieser Aufgabe (gemessen, Geschwister oder Autor) über fillWork.largeTaskShare (Vorgabe 50 %) der Tageskostengrenze. Das Mittel des Agenten reicht dafür nicht, sonst hielte ein Agent mit teuren Läufen jede Aufgabe zur Planung an. Ihr erster Lauf ist ein Planungslauf mit Anweisung vom System, danach wartet sie. Hat der Agent sie geteilt, wartet sie auf die Teile und läuft danach einmal, um sie zusammenzuführen. Andernfalls wartet sie auf das Sonderbudget, mit einer Notiz an der Aufgabe.
• Sonderbudget über die implizite Eskalations-Aktion request_budget, nur für eigene Aufgaben. Sie steht in der Liste der ausnahmslos freigabepflichtigen Aktionen, also lässt weder Werkzeugkonfiguration noch Dauerfreigabe sie ohne Menschen durch. Läufe im Baum ziehen den Topf und nicht die Tagesgrenzen von Agent und Instanz. Sie tragen die Markierung BudgetPot in Verbrauch und Beleg: Die Verbrauchsanzeige zeigt weiter alles, die Budgetprüfung zählt sie nicht, die Kostenanalyse gruppiert „nach Budget“, und die Aufgabenkarte zeigt „verbraucht X von Y“. Entscheidung: Ist der Topf aufgebraucht, zählen die Läufe des Baums wieder gegen den Tag, wie jede andere Arbeit, und das steht einmal im Log. Anhalten wäre die andere Möglichkeit gewesen. Sie hätte halb fertige Arbeit liegen lassen, die der Mensch schon für wert befunden hatte.

Was die Auswertung dafür braucht

• Die Einheit als Dimension in Filtern und Zeitverlauf der Verbrauchsansicht (#660) — „was kostet mich das Marketing?" muss eine Frage sein, keine Rechenaufgabe.
• Verdichtete Werte. Tagessummen je Agent und Einheit, damit eine Sechsmonatsansicht nicht Millionen Laufzeilen liest (#700).
• Ein Archiv statt eines Kehrbesens (#700). Siehe unten — die Datenmenge ist ein Problem der Abfragen, nicht der Festplatte.

Aufbewahren statt löschen

Gelöscht wird so wenig wie möglich. Der Grund ist nicht Sammelwut, sondern der einzige echte Vorteil, den eine Organisation aus Agenten gegenüber einer aus Menschen hat: In einem Büro voller Menschen geht jeden Tag verloren, warum etwas so entschieden wurde. Hier nicht. Fünf Jahre nach einem gescheiterten Vorhaben lässt sich nachlesen, wie es dazu kam — welche Aufgabe wie formuliert war, was der Agent wirklich gelesen hat, wer was freigab, welche Stimme welchen Beleg hatte.

Das ist bezahlbar, und zwar deutlich: Bei hundert Agenten fallen etwa 9 MB am Tag an, also rund 3,3 GB im Jahr. Das ist keine Größe, für die man Wissen wegwirft.

Was trotzdem zu tun ist, ist etwas anderes als Löschen:

1. Heiß und kalt trennen. Die Arbeitsdatenbank hält, was der Betrieb braucht; ältere Läufe wandern in ein Archiv — eigene Dateien je Zeitraum, abfragbar, aber nicht im Weg. Was die Abfragen langsam macht, sind Millionen Zeilen in der heißen Tabelle, nicht Gigabyte auf der Platte.
2. Verdichtete Werte bleiben immer. Tagessummen je Agent und Einheit sind winzig und beantworten die meisten Fragen, ohne das Archiv anzufassen.
3. Geheimnisse gar nicht erst hineinschreiben. Aufbewahren heißt nicht, Zugangsdaten aufzubewahren. Die Maskierung beim Schreiben (#660, allgemein #192) ist die Antwort — nicht späteres Löschen, das ohnehin zu spät käme.
4. Die Ausnahmen bleiben. Ein Agent, der besondere Geheimnisse verwaltet, wird gar nicht aufgezeichnet (never aus #660). Das ist eine Entscheidung je Agent und bleibt es.

Zwei Dinge, die der Betreiber entscheiden muss, nicht das Produkt: In den Aufzeichnungen stehen bei einem Handelsbetrieb auch Kundendaten, und für personenbezogene Daten gibt es Aufbewahrungs- und Löschpflichten. Das Produkt muss beides können — unbegrenzt aufbewahren und gezielt löschen, was gelöscht werden muss. Die Vorgabe „so wenig löschen wie möglich" ist die Voreinstellung, nicht die einzige Möglichkeit.

Folge für die Prompt-History: Die Voreinstellung von 14 Tagen (#660, festgelegt am 2026-09-19) widerspricht dieser Linie. Sie gehört auf „unbegrenzt" umgestellt; die Möglichkeit, je Agent kürzer oder gar nicht aufzuzeichnen, bleibt unverändert.

---

9 — Was eine Organisation braucht und ein Agentenhaufen nicht

Der Punkt, der beim Bauen am leichtesten übersehen wird: Eine Organisation lebt von gemeinsamem, dauerhaftem Wissen, das in keinem Kopf steckt.

Im Beispiel: der Lieferantenstamm, der Artikelstamm, die offenen Bestellungen, die Retourengründe. Wenn drei Einkaufsagenten je ihre eigene Vorstellung der Lieferantenliste im Gedächtnis tragen, hat die Instanz drei Wahrheiten und keine davon stimmt. Das ist kein Modellproblem und kein Prompt-Problem — es ist die Frage, was Datenbank ist und was Kontext.

Daraus drei Festlegungen:

1. Stammdaten gehören in die Datenbank, nicht in das Gedächtnis von Agenten. Das Gedächtnis ist für Erfahrungen („dieser Lieferant antwortet nie vor Dienstag"), nicht für Fakten („Lieferant X, Mindestbestellmenge 50").
2. Dokumente gehören in die Ablage der Einheit, mit einem Eigentümer. Ein Bericht, den zwei Agenten gleichzeitig schreiben, ist ein verlorener Bericht.
3. Was mehrere Einheiten brauchen, ist eine bewusste Entscheidung — ein ausdrücklich geteilter Bereich mit benanntem Eigentümer, nicht das Standardverhalten.

---

9a — Von Paperclip gelernt

Ergänzt am 2026-09-24 nach Durchsicht des Paperclip-Quellcodes. Items #714, #715.

Paperclip ist das Projekt, das diesem Konzept am nächsten kommt: Firma, Organigramm, Budgets, der Mensch als „Board" mit Vetorecht. Einiges davon lohnt sich zu übernehmen, anderes bewusst nicht.

Übernommen: die Zielkette (#714)

Jede Aufgabe hat eine Elternaufgabe, ganz oben steht das Ziel der Einheit. Damit kann jeder Agent beantworten, warum er etwas tut. Die Kette geht als kurzer Absatz in den Lauf mit. Das ist etwas anderes als blocked_by: Die Elternaufgabe ist der Zweck („wofür"), der Blocker die Voraussetzung („wann"). Heute kennt TaskItem nur den Blocker.

Daraus folgt eine zweite Fähigkeit, Paperclips Task Watchdog: Kommt ein ganzer Teilbaum zur Ruhe, alle Blätter erledigt, abgebrochen, blockiert oder in Prüfung, und es gibt keinen Weg mehr, auf dem er weiterläuft, dann prüft jemand, ob der Stillstand berechtigt ist. Denn Agenten hören aus falschen Gründen auf: „erledigt" ohne Beleg, eine Prüfung ohne Prüfer, ein falsch gelesener Blocker. Ohne Prüfung liegt der Baum einfach still, und niemand merkt es. Die Aufteilung ist dieselbe wie überall: Ob der Baum ruht, erkennt eine Abfrage (#646). Ob das in Ordnung ist, deutet die Aufsicht (#680) oder die Leitung. Der Prüfer gibt zurück, er bessert nicht selbst nach.

Übernommen: Rückmeldung nach Vertrauensstufe (#715)

Das ist der wertvollste Gedanke aus Paperclip, und er schließt eine Lücke, die dieses Konzept bisher hatte. Ein Agent, der Rezensionen, Mails oder Webseiten liest, hat fremden Text im Kontext. UntrustedContent (K2) rahmt diesen Text beim Lesen. Schreibt der Agent seiner Leitung aber einen Kommentar in eigenen Worten, trägt er den fremden Text eine Ebene höher, in einen Kontext mit mehr Rechten, und dort ist er nicht mehr gerahmt. Prompt-Injection über die Hierarchie.

Nach oben gibt es deshalb genau drei Wege:

1. Das Erledigt-Signal. Immer an. Die Leitung wird geweckt und liest das Ergebnis im Vorgang selbst.
2. Ein Kommentar genau eine Ebene nach oben. Nur ein Kommentar, keine Status- oder Feldänderung, nie an die übernächste Ebene oder an Geschwister. Nur für die Standardstufe.
3. Für Agenten, die fremde Inhalte lesen: kein Freitext nach oben. Stattdessen verfasst der Code eine Systemmeldung „blockiert" oder „abgebrochen". Sie löst keine weitere Meldung aus und geht je Zustand nur einmal hinaus.

Woher die Stufe kommt: aus den Werkzeugen, nicht aus einer Einstellung. Wer WebFetch, Mail, Rocket.Chat oder ein Skript mit Außenkontakt hat, liest fremde Inhalte. Das weiß der Code aus der Konfiguration, eine Selbstauskunft des Agenten ist dafür nicht nötig. Eine Einstellung darf die Stufe nur verschärfen, nie lockern.

Für Querverbindungen gilt das „Courier Pattern": Wer seitlich etwas braucht, schreibt nicht in fremde Vorgänge, sondern legt beim Ziel eine vollständige, in sich geschlossene Aufgabe an. Das ist die Adressbuchregel aus Abschnitt 3 und die Stille-Post-Regel aus Abschnitt 5, nur zu Ende gedacht: Der Empfänger darf die Vorgänge des Absenders womöglich gar nicht lesen, also muss alles Nötige in der Aufgabe selbst stehen.

Reihenfolge: vor der Freigabe durch die Leitung (#687). Eine Leitung, die Freigaben erteilt, darf keinen Kontext haben, in den ein Untergebener fremden Text schreiben kann.

Umsetzung (2026-09-25):

• Die Stufe. Jedes Werkzeug sagt über ReadsForeignContent selbst, ob es Text von außen hereinholt. Das tun WebFetch, WebMonitor, DirectAPI, Mail, Rocket.Chat, Telegram, TelegramClient, SocialMediaManager, FTP und Database. Bei Database liegt der Grund darin, dass Bestellungen, Rezensionen und Feeds von außen kommen. Die Einstellung treatAsForeignReader kann die Stufe nur anheben.
• Die Prüfung. ReportingLine wird an allen Stellen angewandt, an denen Text nach oben gehen kann: Nachricht, Spawn, task_create bzw. task_update mit einer Leitung als Zuständiger, task_comment und die Notiz „Observed again" bei einer Dublette. Keine Stufe darf Aufgaben einer höheren Ebene ändern oder wieder öffnen.
• Seitwärts wird nichts abgelehnt. Nachrichten und Aufgaben von Agenten der Fremdinhalt-Stufe kommen beim Empfänger aber in <untrusted_content> gerahmt an, mit einem Hinweis auf die Herkunft.
• Die Rückmeldung. Das Erledigt-Signal und die Systemmeldung erzeugt TaskReports im Scanner. Wer eine Aufgabe vergeben hat, erfährt, wenn sie erledigt ist, in Prüfung geht, blockiert oder abgebrochen wird. Die Meldung geht je Zustand einmal hinaus, gesammelt in einer offenen Aufgabe je Empfänger. Sie enthält nur ID, Zuständigen und Zustand. Den Titel enthält sie nur, wenn der Zuständige zur Standardstufe gehört, denn der Zuständige kann den Titel ändern.
• Offen: Ein Agent kann fremden Text auch über eine Datei in einem gemeinsamen Bereich weitergeben. Die Ablage kennt heute nicht, wer eine Datei zuletzt geschrieben hat. Das gehört zu #720 (gleichzeitiger Zugriff), wo ohnehin der Schreiber je Datei verfolgt werden muss.

Übernommen, im Kleinen

• Budget in zwei Stufen. Die harte Grenze gibt es schon (BudgetGuard, Tagesbudget je Agent und Instanz). Dazu kommt eine Warnung bei 80 % an die Leitung, damit das Anhalten keine Überraschung ist. Gehört zu #699.
• Gestaffelte Anzeige. Oben die lesbare Zusammenfassung, darunter die Schritte, ganz unten das Rohprotokoll. Gilt für die Teamübersicht (Abschnitt 10a) und die Laufansichten aus #660.

Bewusst nicht übernommen

• Rechte-Umgehung als Voreinstellung. Der Claude-Code-Adapter startet mit dangerouslySkipPermissions = true, und Skills sind „open by default". Das ist das Gegenteil unserer Linie, jedem Agenten nur die Rechte zu geben, die er braucht.
• Die ganze Firma sieht alle Arbeit. Bei Paperclip ist das ausdrücklich gewollt. Hier trennen die gemeinsamen Bereiche je Einheit bewusst (Abschnitt 3).
• Die reine Steuerungsebene. Siehe Abschnitt 7a.
• Als Warnsignal: die Komplexität. Allein die Regeln zur Ausführung umfassen dort über 1.400 Zeilen, bei knapp 5.000 offenen Issues und im Wesentlichen einem einzigen Hauptentwickler. Das mahnt, nur zu übernehmen, was eine Lücke schließt.

---

10 — Was sich am Menschen ändert

Bei fünf Agenten ist der Mensch der Koordinator. Bei fünfzig kann er es nicht sein, und der Versuch macht ihn zum Flaschenhals.

• Freigaben wandern in die Struktur. Die Abteilungsleitung gibt frei, was innerhalb ihrer Grenzen liegt. Der Mensch gibt frei, was Geld bewegt, nach außen wirkt oder die Struktur selbst ändert. Das ist die natürliche Fortsetzung von #641 (Rechte in der Werkzeugkonfiguration) — nur mit der Einheit als zusätzlicher Ebene.
• Berichtet wird verdichtet. Nicht fünfzig Laufergebnisse, sondern vier Abteilungsberichte und eine Lage.
• Die Aufsicht (#680) wird von einer Annehmlichkeit zur Notwendigkeit. Bei fünf Agenten kann ein Mensch die Läufe lesen. Bei fünfzig muss etwas anderes ihm sagen, wo er hinsehen soll.

---

10a — Das Lagebild

Ergänzt am 2026-09-24 auf Vorschlag des Nutzers. Item #711, baut auf #688 auf.

Die Teamübersicht: eine grafische Ansicht wie über ein Büro. Nodes für Agenten, Kanten für ihre Beziehungen. Auf einen Blick sieht man, wer gerade arbeitet, wer mit wem in den letzten Sekunden gesprochen hat und wo es klemmt. Ein Klick führt zum Agenten.

Bei fünf Agenten ist das eine Annehmlichkeit. Bei fünfzig ist es die einzige Art, ein Problem zu bemerken, bevor die Rechnung kommt oder ein Ergebnis fehlt. Abschnitt 10 sagt, bei fünfzig Agenten müsse etwas anderes dem Menschen sagen, wo er hinsehen soll. Das Lagebild ist dieses Etwas, zum Hinsehen, neben der Aufsicht (#680) zum Nachlesen.

Drei Festlegungen

1. Die Anordnung kommt aus der Struktur, nicht aus der Hand. In n8n oder Node-RED ist der Graph das Programm, dort zieht man Nodes, und das soll so sein. Hier zeigt der Graph eine Wahrheit, die woanders liegt: Einheiten, Leitung, Adressbuch. Sind die Nodes frei platzierbar und verbindbar, zeigt das Bild bald etwas anderes als die Organisation. Verschieben per Drag & Drop kommt später als Bedienung für den Umzug (Abschnitt 3), mit gestoppter Instanz, Bestätigung und Audit-Eintrag, nicht als Zeichenwerkzeug.

2. Einheiten sind aufklappbare Container, Probleme wandern nach oben. Hundert Nodes mit wechselnden Kanten sind ein Knäuel. Standardansicht sind die Abteilungen mit einer Zusammenfassung: „4 arbeiten · 1 Problem · 2 Freigaben offen". Eine Markierung am Container heißt „irgendwo darin", und man klappt auf, bis man den Agenten findet. Kanten zwischen Einheiten werden gebündelt, mit Zähler.

3. „Problem" stellt der Code fest, nicht das Modell. Die Zustände:

   Zustand	Woher
   arbeitet	aktiver Lauf
   wartet auf Freigabe	offene StagedCalls
   wartet auf Kollegen	laufende Delegation
   Problem	letzter Lauf gescheitert, LoopGuard-Abbruch, Eskalation über Frist, Budget erschöpft
   hängt	Lauf deutlich länger als bei diesem Agenten üblich
   pausiert / aus	Konfiguration

   Immer Farbe und Symbol.

Der Klick führt in die Seitenleiste, nicht direkt in den Chat

Die meisten Probleme löst man nicht im Gespräch: Oft wartet eine Freigabe, oder ein Werkzeug ist dreimal gescheitert. Die Seitenleiste zeigt den laufenden Lauf, den letzten Fehler im Wortlaut, offene Aufgaben und Freigaben (dort bestätigbar), die Kosten von heute gegen den Durchschnitt und den Knopf „Chat öffnen". Das ist ein Klick mehr, dafür ist der richtige Handgriff meist schon da.

Technik

• Datenquelle ist der vorhandene Ereignisstrom (MergedEventStream). Neu sind Ereignistypen mit Absender und Empfänger: Delegation, Task-Zuweisung, später Besprechung und Eskalation, jeweils mit eigener Linienart. Das Verblassen nach einigen Sekunden geschieht im Browser.
• Bibliothek: ELK (elkjs) für das Layout, die Karten als HTML, die Linien als SVG. Als Datei im wwwroot, nicht über ein CDN. Stufe 0 und 1 zeichneten mit Cytoscape.js auf einer Canvas. Das wurde am 2026-09-24 ersetzt: Ein Canvas-Knoten kann keine Agentenliste, keine Suchhervorhebung und nicht den Hausstil tragen.
• Gestalt (Rückmeldung 2026-09-24): Jede Einheit bleibt immer als Karte sichtbar, verbunden als Baum. Zugeklappt wird nur die Agentenliste einer großen Einheit; sie zeigt dann, wer Aufmerksamkeit braucht, und „+n weitere". Eine Linie trägt die Farbe des dringlichsten Zustands darunter, eine rote Linie führt also von oben zum Problem. Ohne Durchklicken durch zehn Ebenen. Links ein Strukturbaum mit Suche und Zustandsfilter, der die Wege zu den Treffern zeigt und den Rest abblendet. Hausstil bleibt: Radius 0, App-Akzent.
• Nur in der WebUI. Ein zweiter Graph-Renderer in Avalonia wäre doppelte Arbeit, die auseinanderläuft. Der Desktop bettet die Ansicht ein oder verlinkt sie.
• Englisch, Texte über Sprachpakete (#661).

Stufen

• Stufe 0, ohne Einheiten: die vorhandenen Agenten mit Delegationskanten und Zuständen. Das nützt sofort, auf der Test-VM mit sieben Agenten.
• Stufe 1, mit #683: Container und nach oben gereichte Probleme. Ab hier fällt das Lagebild mit dem Organigramm aus #688 zusammen; es gibt nicht zwei Ansichten der Organisation.
• Später: die Zeitleiste. „Wie sah das Büro um 3:12 Uhr aus?" Das kostet wenig, weil nichts gelöscht wird (Abschnitt 8a): Das AuditLog wird nur neu abgespielt. Für die Frage, wie ein Projekt gescheitert ist, ist das vielleicht das wertvollste Werkzeug überhaupt.

Wie andere es machen

Paperclip hat ein statisches Organigramm mit einem Statuspunkt je Agent und daneben eine Liste der laufenden Läufe, aber keine Ansicht der Kommunikation. LangGraph Studio zeigt den laufenden Node eines Ablaufgraphen, also eines Programms, nicht einer Organisation. AutoGen Studio, Flowise und Langflow sind Baukästen („Nodes ziehen = Programm"), gut zum Bauen, schwach als Lagebild. ChatDev und AI Town zeigen das Büro wörtlich als Pixelgrafik: charmant, aber mit wenig Information. Die Verbindung aus aufklappbarer Organisation, Live-Zuständen und nach oben gereichten Problemen mit Direktzugriff hat keines davon.

---

11 — Reihenfolge

Nichts davon muss auf einmal entstehen. Die Reihenfolge ist so gewählt, dass jede Stufe für sich schon nützt und keine die nächste blockiert.

Stufe	Inhalt	Nutzen für sich
0	Parallelität deckeln, stille Kappung bei 500 beseitigen (#682)	Fehler, unabhängig von der Größe
0a	Lagebild ohne Einheiten (#711, Stufe 0)	Der Mensch sieht auf der Test-VM sofort, wer arbeitet und wo es klemmt
1	Einheiten als Struktur: Baum, Zugehörigkeit, vererbte Rechte, Adressbuch nach Einheit	Der Schnitt, der alles Weitere trägt
2	Ablage und Brett je Einheit	Buchhaltung und Einkauf treten sich nicht mehr auf die Füße
3	Budget und Parallelität je Einheit	Eine ausufernde Abteilung legt nicht die Instanz lahm
4	Ursprungsverweis in jedem Vorgang (#697); Zielkette (#714); Rückmeldung nach Vertrauensstufe (#715)	Entscheidungen stützen sich auf das Original, jede Aufgabe kennt ihren Zweck, und fremder Text steigt nicht in der Hierarchie auf
5	Eskalation, Konflikt und Beschluss (#689)	Eine Frage, die niemand beantworten kann, versandet nicht mehr
6	Besprechung als Mittel, mit Protokoll	Leitungen können sich abstimmen, ohne n² Nachrichten
7	Entscheidungsinstanz an der Spitze (#690)	Der Betrieb läuft weiter, wenn der Mensch schläft
8	Freigabe durch die Leitung innerhalb von Grenzen	Der Mensch hört auf, Flaschenhals zu sein
9	Kontrollpflicht der Leitung, abgestufte personelle Mittel (#693); Doctrine (#698)	Fehler findet die Leitung, nicht erst der Mensch — und sie kann steuern
9a	Kosten je Einheit, Abweichungsmeldung (#699), Archiv (#700)	Ineffizienz wird sichtbar, bevor sie einen Monat lang läuft
9b	Abstimmung als dritte Freigabeform (#702)	Vier Blickwinkel statt einer Unterschrift, wo es sich lohnt
10	Oberfläche: Organigramm und Lagebild in einem (#688, #711 Stufe 1)	Bei fünfzig Agenten ist eine flache Liste keine Übersicht
11	Organisationsvorlagen (#691)	Ein Haus lässt sich weitergeben statt nachbauen

Quer dazu, unabhängig von der Reihenfolge: der Werkzeugkasten (#692), der A/B-Vergleich von Modellen (#694), die fremden Laufzeiten samt MCP-Server (#712, #713; nach der Sandbox #654) und die Schemaauskunft (#676) — letztere ist Vorbedingung für Stufe 5, weil eine Eskalation einen belastbaren Negativbefund braucht.

Zum Umzug (Abschnitt 3): Er gehört zu Stufe 1. Eine Struktur, die sich nach dem Anlegen nicht mehr ändern lässt, ist keine Struktur, sondern eine Festlegung — und die Reihenfolge oben verlöre ihren Sinn, wenn man das Haus nicht umbauen könnte, während man es bewohnt.

Nicht in dieser Liste, aber davor: Die Sandbox (#654) und die Skriptprüfung (#657). Sie stehen unter SEC, sind aber die Grundlage dafür, dass eine Instanz ihre plattformspezifischen Werkzeuge selbst hervorbringt — und damit für den Baukasten ebenso tragend wie die Einheiten. Die Lieferkette darüber (#695) gehört in den ORG-Block, weil sie eine Organisationsfrage ist: Wer ein Werkzeug braucht, baut es nicht.

Stufe 1 ist die einzige, die wirklich weh tut, weil sie Konfiguration, Werkzeuge, Arbeitsbereiche und Oberfläche gleichzeitig berührt. Sie zuerst zu bauen ist trotzdem richtig: jede spätere Stufe hängt daran, und jede Woche, die eine Instanz ohne Einheiten wächst, wird der Umzug teurer.

---

12 — Offene Entscheidungen

• Ist eine Einheit ein Agent? Eine Leitung könnte ein gewöhnlicher Agent mit besonderen Rechten sein — oder die Einheit hat eine Leitungsrolle, die auch unbesetzt bleiben kann (dann übernimmt die übergeordnete Leitung). Vorschlag: das zweite. Eine Einheit ohne Leitung muss möglich sein, sonst kostet jede Gliederung sofort einen Agenten.
• Wie tief? MaxDelegationDepth = 3 muss steigen, aber nicht auf unendlich — eine Kette ohne Grenze ist wieder ein Zyklus in Zeitlupe. Vorschlag: Tiefe des Baums plus eins, aus der Struktur berechnet statt als Zahl eingestellt.
• Gehören Einheiten in die Instanzkonfiguration oder in die Datenbank? Die Zugehörigkeit ändert sich selten, aber sie ändert Rechte — also gehört sie dorthin, wo Änderungen im Audit stehen. Vorschlag: Datenbank, mit Abbild in der Konfiguration.
• Darf ein Agent in zwei Einheiten sein? In echten Organisationen ja (Matrix). Das macht das Adressbuch und die Rechtevererbung deutlich schwieriger. Vorschlag: zunächst nein, und beobachten, ob es fehlt.

Vier weitere, die vor dem Bau der jeweiligen Stufe entschieden gehören — beim Gegenlesen am 2026-09-22 als zu grob aufgefallen:

• Ist ein Einheitsbudget ein Deckel oder eine Zuteilung? Entschieden am 2026-09-22: weder noch. Harte Grenzen bleiben am Agenten. Die Einheit rechnet auf und zeigt an — siehe Abschnitt 8a. Damit entfällt die ganze Zuteilungsrechnerei, und ein Umzug ändert keine einzige Grenze. Die Parallelität bleibt davon unberührt: Sie ist keine Kostenfrage, sondern eine Frage der Ratengrenzen, und wird je Instanz gedeckelt (#682).
• Was ist eine „Grenze" der Leitung? Das Konzept sagt „die Leitung gibt frei, was innerhalb ihrer Grenzen liegt", ohne zu sagen, woraus eine Grenze besteht. Vorschlag: Betrag je Vorgang, Betrag je Tag, erlaubte Werkzeugklassen, Außenwirkung ja/nein — und alles davon an der Einheit, nicht an der Person der Leitung (Stufe 8). Überholt am 2026-09-24: Grenzen sind ein Sammelwert und stehen am Leitungsagenten (Abschnitt 3, „Einstellungen an der Einheit").
• Wie wird ein Beschluss wirksam? „Bindend für alles unterhalb" ist ein Wort ohne Maschinerie, solange niemand nachsieht. Vorschlag: Das Eskalationswerkzeug sucht von sich aus, bevor es einen Vorgang anlegt — genau wie task_find vor task_create (#674). Ein Beschluss, den man aktiv lesen müsste, wird nicht gelesen (Stufe 5).
• Auf welchem Account läuft eine fremde Laufzeit? (Abschnitt 7a, vor #712.) Ein Pro-Plan teilt sein Kontingent mit dem Menschen, und ob der automatisierte Dauerbetrieb eines Verbraucher-Abos von den Nutzungsbedingungen gedeckt ist, ist ungeprüft. Vorschlag: beide Anmeldewege bauen, als Voreinstellung den API-Schlüssel nehmen und das Abo erst nach Prüfung der Bedingungen freigeben.
• Was passiert, wenn die Eskalationsgrenze erreicht ist? Entschieden am 2026-09-22, und schärfer als vorgeschlagen: Eine Eskalation, die nicht gelöst werden kann, darf es nicht geben. Finden die Agenten binnen einer einstellbaren Frist keine Lösung, wird der Mensch gerufen. Er entscheidet — oder fordert an, was ihm fehlt, etwa eine Stellungnahme jeder Streitpartei. „Bleibt sichtbar liegen" war zu schwach: Ein Vorgang, den niemand anfasst, ist auch dann verloren, wenn er sichtbar ist (Stufe 5).

Und eine Kleinigkeit mit Folgen: Das Wort „Struktur" meint in Abschnitt 6 die Organisation (Einheiten, Rechte, Grenzen) — nicht ein Datenbankschema. Eine Entscheidungsinstanz darf durchaus beschließen, dass ein Feld angelegt wird; sie legt es nur nicht selbst an.

---

13 — Items

Item	Vorhaben
#682	Läufe deckeln: Parallelität begrenzen, Kappung bei 500 beseitigen
#683	Einheiten: Baum, Zugehörigkeit, vererbte Rechte, Adressbuch nach Einheit
#684	Ablage und Taskboard je Einheit
#685	Budget und Parallelität je Einheit
#686	Besprechung: Termin, Tagesordnung, Runde, Protokoll
#689	Eskalation, Konflikt und Beschluss als eigene Vorgänge
#690	Entscheidungsinstanz an der Spitze: Mensch, Agent oder beides mit Frist
#691	Organisationsvorlagen: eine Struktur als importierbare Datei
#692	Werkzeugkasten: generischer Weg nach außen statt Einzelanbindungen
#693	Kontrollpflicht der Leitung: Stichproben gegen das Audit, abgestufte Mittel
#694	A/B-Vergleich von Modellen im laufenden Betrieb
#676	Schemaauskunft der Datenbank — Vorbedingung für den Negativbefund
#695	Skripte: Schreiben und Benutzen sind zwei Rechte, mit Lieferkette
#696	Fehlerablage je Skript — der Läufer schreibt, der Eigentümer liest
#697	Stille Post vermeiden: Weitergaben hängen an und tragen den Verweis
#698	Doctrine.md — die Leitung steuert ihre Einheit, eine Ebene tief
#699	Kosten je Einheit aufrechnen und Abweichungen melden
#700	Archiv statt Kehrbesen: heiß und kalt trennen, verdichtete Tageswerte
#702	Abstimmung: unabhängige Prüfungen, blind, mit Beleg je Stimme
#654, #196, #657	Sandbox, Shell, Skriptprüfung — der eigentliche Werkzeugkasten
#687	Freigabe durch die Leitung innerhalb von Grenzen
#688	Organigramm in Oberfläche und WebUI
#716	Was liegen bleibt, wenn das Budget endet (Ausfall, Nachholen, Reservierung)
#717	Füllarbeit und Großaufgaben: ungenutztes Budget füllen, teilen oder Sonderbudget
#711	Lagebild (Teamübersicht): wer arbeitet, wer spricht mit wem, wo klemmt es
#712	Fremde Laufzeiten: Claude Code, Codex, Befehl, HTTP
#713	ClawdDotNet als MCP-Server für fremde Laufzeiten
#714	Zielkette und Prüfung ruhender Aufgabenbäume
#715	Rückmeldung nach Vertrauensstufe, Courier Pattern