RichardandClaude Opus 5.5
f812dbd856
- Werkzeugkontext kennt Lauf und Aufgabe des Laufs (RunId, RunTaskId); die Delegationskette traegt den Lauf des Aufrufers weiter (RunId, CallerRunId) - Aufgaben tragen origin_run / origin_task (Datei, DB, Taskboard "Arose from"), gestempelt, nie vom Agenten behauptet - Kommentare nennen den Lauf, in dem sie geschrieben wurden - Laufbeleg: CallerRunId; Laufansicht fuehrt zu "Delegiert von" und "Delegiert an" - #677: task_update ersetzt den Rumpf nicht mehr, Abnahmekriterien aendert nur der Ersteller; Kommentare der Fremdinhalt-Stufe auf fremden Aufgaben kommen gerahmt an - WebUI: Herkunft auf der Aufgabenkarte mit Link zum Lauf Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1473 lines
84 KiB
Markdown
1473 lines
84 KiB
Markdown
# 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.
|
|
|
|
### 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.
|
|
|
|
## 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.
|
|
|
|
### 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 |
|