ClawdDotNet/docs/Organisation-Konzept.md

# Organisation — 50 bis 100 Agenten geordnet zusammenarbeiten lassen

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

> Herkunft: Richtungsentscheidung des Nutzers am 2026-09-21. Die bisherige Regel im
> [InstanceSetupGuide](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 |

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

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

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

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

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

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

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

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

### Beliebig tief, und beweglich

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

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

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

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

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

Drei Festlegungen dazu:

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

### Arbeitsbereiche: aus einem gemeinsamen werden viele

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

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

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

Vier Festlegungen:

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

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

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

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

### Die eine Regel, die alles zusammenhält

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

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

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

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

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

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

---

## 4 — Die Besprechung als eigenes Mittel

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

Eine **Besprechung** ist:

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

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

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

---

## 5 — Eskalation, Konflikt, Beschluss

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

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

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

### Die Voraussetzung: ein belastbarer Negativbefund

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

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

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

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

### Eskalation: nach oben, nie zur Seite

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

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

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

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

### Konflikt: entschieden wird beim niedrigsten gemeinsamen Vorgesetzten

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wo das konkret gilt (#697):

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

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

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

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

### Damit es endet

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

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

### Umsetzung (2026-09-25, #689)

- **Vorgang und Beschluss** sind eigene Datensätze (`Cases`, `Decisions`). Der Vorgang
  selbst wandert nicht über das Brett. Jeder Halter bekommt eine eigene Aufgabe in seinen
  Eingang, die Regeln führt `CaseDesk`.
- **Eskalation:** Das Werkzeug `Escalation` hat jeder Agent, ohne dass man es freischalten
  muss. „Ich komme nicht weiter“ ist keine Berechtigung. Der Vorgang geht an die eigene
  Leitung, eine Ebene je Schritt. Die Leitung hat drei Antworten:
  - `decide`: mit Pflichtbegründung, gilt für den Bereich der Leitung
  - `handle`: sie erledigt es selbst
  - `forward`: sie reicht mit eigener Einschätzung weiter

  Die Aufgabe, an der der Agent feststeckt, wartet (blockiert) und geht beim Abschluss
  wieder an die Arbeit.
- **Erst nachsehen:** Vor jeder Eskalation zeigt das Werkzeug die Beschlüsse, die den
  Agenten binden. Dieselbe Frage aus derselben Einheit schließt sich dem offenen Vorgang
  an, statt einen zweiten zu eröffnen.
- **Konflikt:** Zuerst nimmt die Gegenseite einmal Stellung. Danach geht der Vorgang direkt
  an die niedrigste gemeinsame Leitung. Die Leitungen dazwischen stehen als „vermerkt,
  nicht befragt“ im Vorgang. Einen Konflikt kann man weder weiterreichen noch „selbst
  erledigen“, er wird entschieden, und beide Seiten erfahren den Beschluss.
- **Damit es endet:**
  - Es gibt einen Tagesdeckel je Einheit (`cases.escalationsPerUnitPerDay`, Vorgabe 10).
    Darüber geht die Eskalation direkt an den Menschen, mit einem Vermerk.
  - Nach der Frist (`cases.deadlineHours`, Vorgabe 4 Stunden) wird der Mensch gerufen,
    einmal. Der Weckruf hat eine Anschlussstelle für den Kanal aus #644. Bis dahin
    erscheint der Vorgang in der neuen Ansicht „Vorgänge“, mit einem Zähler in der
    Seitenleiste.
- **Der Mensch** entscheidet dort mit Begründung (gilt für die ganze Instanz) oder fordert
  von einer Seite eine Stellungnahme an. Das ist die einzige Bewegung nach unten, die den
  Vorgang nicht schließt, und sie hat eine eigene Frist.
- **Stille Post (#697) und Berichtsweg (#715):**
  - Jede Ebene hängt ihren Beitrag an, jeder Beitrag trägt seinen Lauf.
  - Beim Halter kommt jeder Beitrag gerahmt als Daten an.
  - Wer fremde Inhalte liest, eskaliert ohne eigenen Text (nur mit dem Verweis auf die
    Aufgabe) und eröffnet keinen Konflikt mit eigenem Standpunkt.
- **Nebenbei behoben:** Der Scanner hat einen Status, den der Lauf selbst gesetzt hatte
  (blockiert, abgebrochen), am Laufende mit „erledigt“ überschrieben. Damit liefen sowohl
  das Eskalieren als auch der Meldeweg aus #715 ins Leere.
- **Vorbedingung erfüllt (#676):** Das Datenbank-Werkzeug beantwortet die Frage nach dem
  Schema selbst. `describe` nennt alle Spalten einer Tabelle und sagt ausdrücklich, dass
  ein nicht genanntes Feld nicht existiert. „Unbekannte Spalte“ und „unbekannte Tabelle“
  werden mit dem Vorhandenen beantwortet. Damit ist „ich finde kein Feld dafür“ eine
  Feststellung.

## 6 — Die Entscheidungsinstanz an der Spitze

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

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

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

### Was ein entscheidender Agent darf und was nicht

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

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

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

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

---

## 7a — Fremde Laufzeiten

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

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

Also bekommt jeder Agent eine **Laufzeit**:

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

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

### Eine fremde Laufzeit gilt als weniger vertrauenswürdig

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

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

### Kosten, die nichts kosten

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

### Zwei Vorbehalte vor dem Bau

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

---

## 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 Abstimmung: mehrere Blickwinkel statt einer Freigabe

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

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

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

Daraus folgt die wichtigste Regel:

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

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

**Die weiteren Festlegungen:**

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

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

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

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

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

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

Vier Festlegungen:

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

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

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

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

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

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

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

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

## 8a — Kosten und Prompts: das wichtigste Instrument

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

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

### Grenzen bleiben am Agenten, die Einheit rechnet auf

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

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

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

### Die Meldung ist wichtiger als die Grenze

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

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

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

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

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

### Was liegen bleibt, wenn das Budget endet

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

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

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

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

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

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

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

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

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

### Füllarbeit und Großaufgaben

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

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

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

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

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

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

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

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

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

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

### Was die Auswertung dafür braucht

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

### Aufbewahren statt löschen

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

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

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

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

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

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

---

## 9 — Was eine Organisation braucht und ein Agentenhaufen nicht

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

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

Daraus drei Festlegungen:

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

---

## 9a — Von Paperclip gelernt

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

[Paperclip](https://github.com/paperclipai/paperclip) ist das Projekt, das diesem Konzept
am nächsten kommt: Firma, Organigramm, Budgets, der Mensch als „Board" mit Vetorecht.
Einiges davon lohnt sich zu übernehmen, anderes bewusst nicht.

### Übernommen: die Zielkette (#714)

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

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

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

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

Nach oben gibt es deshalb genau drei Wege:

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

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

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

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

**Umsetzung (2026-09-25):**

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

### Übernommen, im Kleinen

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

### Bewusst nicht übernommen

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

---

## 10 — Was sich am Menschen ändert

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

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

---

## 10a — Das Lagebild

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

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

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

### Drei Festlegungen

1. **Die Anordnung kommt aus der Struktur, nicht aus der Hand.** In n8n oder Node-RED ist
   der Graph das Programm, dort zieht man Nodes, und das soll so sein. Hier zeigt der
   Graph eine Wahrheit, die woanders liegt: Einheiten, Leitung, Adressbuch. Sind die
   Nodes frei platzierbar und verbindbar, zeigt das Bild bald etwas anderes als die
   Organisation. Verschieben per Drag & Drop kommt später als Bedienung für den Umzug
   (Abschnitt 3), mit gestoppter Instanz, Bestätigung und Audit-Eintrag, nicht als
   Zeichenwerkzeug.
2. **Einheiten sind aufklappbare Container, Probleme wandern nach oben.** Hundert Nodes
   mit wechselnden Kanten sind ein Knäuel. Standardansicht sind die Abteilungen mit einer
   Zusammenfassung: „4 arbeiten · 1 Problem · 2 Freigaben offen". Eine Markierung am
   Container heißt „irgendwo darin", und man klappt auf, bis man den Agenten findet.
   Kanten zwischen Einheiten werden gebündelt, mit Zähler.
3. **„Problem" stellt der Code fest, nicht das Modell.** Die Zustände:

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

   Immer Farbe **und** Symbol.

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

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

### Technik

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

### Stufen

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

### Wie andere es machen

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

---

## 11 — Reihenfolge

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

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

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

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

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

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

---

## 12 — Offene Entscheidungen

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

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

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

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

---

## 13 — Items

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