ClawdDotNet/docs/Organisation-Konzept.md

Organisation — 50 bis 100 Agenten geordnet zusammenarbeiten lassen

Stand: 21. September 2026. 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

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.

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.

---

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.

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

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.

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.

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.

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 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.

---

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.

---

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
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)	Entscheidungen stützen sich auf das Original, nicht auf die vierte Nacherzählung
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 statt Agentenliste, Lage je Abteilung	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) 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).
• 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).
• 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