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](InstanceSetupGuide.md) („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](Basisagenten-Konzept.md)), 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](Werkzeugproben-Konzept.md), #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](Basisagenten-Konzept.md)). 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 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).
- **Aufbewahrung auch für Audit und Receipts (#700).** Für Transkripte gibt es eine Frist
  und einen Kehrbesen (#660), für `RunUsage` eine Löschung — für `AuditLog` und
  `RunReceipts` nichts. Gemessen auf der Testinstanz: 636 Läufe erzeugen 4.155
  Audit-Zeilen. Hundert Agenten kämen auf etwa 7.400 Zeilen am Tag, also einige Millionen
  im Jahr — in genau der Tabelle, die jede Auswertung liest.

---

## 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), Aufbewahrung (#700) | Ineffizienz wird sichtbar, bevor sie einen Monat lang läuft |
| **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 | Aufbewahrung für Audit und Receipts, verdichtete Tageswerte |
| #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 |