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`, `einheit`, `shared`. Die Abteilungsablage ist der Normalfall, `shared` die Ausnahme |
| **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 | Agent, Einheit, Instanz — jede Ebene deckelt die darunter |
| **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 |

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

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**, **zurückgeben** („nimm Feld X"), oder **weiter nach
oben**.

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

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

### 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 des Agenten über Amazon — und die steht in
seinem Auftrag, seinem Gedächtnis und in Skripten, die er selbst schreibt.

### Wo Spezifisches hingehört: in Skripte, die die Instanz selbst schreibt

Braucht der Marktplatz-Agent eine wiederkehrende, exakt zugeschnittene Operation, schreibt
er sich ein Skript und pflegt es. Ändert Amazon etwas, ändert er das Skript — ohne
Produktfassung, ohne uns.

Das ist bereits geplant, und zwar vollständig ausgearbeitet:

| Item | Was |
|---|---|
| #654 | Sandbox-Runner (bwrap): jede Codeausführung außerhalb des Hauptprozesses |
| #196 | Shell-Tool mit echter Sandbox |
| #657 | Skriptprüfung: Agenten schreiben Skripte, 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 |

**Diese drei sind nicht nur Sicherheitsvorhaben — sie sind der eigentliche
Werkzeugkasten.** Sie 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.

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

## 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** | Eskalation, Konflikt und Beschluss (#689) | Eine Frage, die niemand beantworten kann, versandet nicht mehr |
| **5** | Besprechung als Mittel, mit Protokoll | Leitungen können sich abstimmen, ohne *n²* Nachrichten |
| **6** | Entscheidungsinstanz an der Spitze (#690) | Der Betrieb läuft weiter, wenn der Mensch schläft |
| **7** | Freigabe durch die Leitung innerhalb von Grenzen | Der Mensch hört auf, Flaschenhals zu sein |
| **8** | Oberfläche: Organigramm statt Agentenliste, Lage je Abteilung | Bei fünfzig Agenten ist eine flache Liste keine Übersicht |
| **9** | Kontrollpflicht der Leitung, abgestufte personelle Mittel (#693) | Fehler findet die Leitung, nicht erst der Mensch |
| **10** | 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 4, weil eine Eskalation einen belastbaren Negativbefund braucht.

**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 sich ihre
plattformspezifischen Werkzeuge selbst baut — und damit für den Baukasten ebenso
tragend wie die Einheiten.

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.

---

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