diff --git a/docs/Organisation-Konzept.md b/docs/Organisation-Konzept.md index 6a39116..9129c41 100644 --- a/docs/Organisation-Konzept.md +++ b/docs/Organisation-Konzept.md @@ -116,10 +116,10 @@ Instanz „Onlinehandel" | Was | Heute | Mit Einheiten | |---|---|---| | **Adressbuch** | alle | die eigene Einheit, die eigene Leitung. Eine Leitung sieht zusätzlich die Leitungen der Geschwistereinheiten | -| **Arbeitsbereich** | `personal`, `shared` | `personal`, `einheit`, `shared`. Die Abteilungsablage ist der Normalfall, `shared` die Ausnahme | +| **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 | Agent, Einheit, Instanz — jede Ebene deckelt die darunter | +| **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 | @@ -165,6 +165,44 @@ Drei Festlegungen dazu: Strukturänderung ist eine Rechteänderung, und die gehört nachvollziehbar — Linie von #205 und #641. +### Arbeitsbereiche: aus einem gemeinsamen werden viele + +Heute gibt es genau zwei — `personal` und `shared` —, und `shared` ist ein Dorfplatz, auf +dem jeder alles sieht. Bei fünfzig Agenten ist das untragbar: Ein Marketing-Agent hat auf +der Ablage der Buchhaltung nichts zu suchen. + +**Der Ordner `SharedWorkspace` wird deshalb zu `SharedWorkspaces` — einem Behälter für +viele.** Jeder darin ist ein eigener Bereich mit Namen, Eigentümer und Mitgliederliste: + +``` +SharedWorkspaces/ +├── einkauf/ Mitglieder: Einkauf (alle Untereinheiten) +├── einkauf-lieferanten/ Mitglieder: Team Lieferanten +├── buchhaltung/ Mitglieder: Buchhaltung — Marketing sieht das nie +├── leitungsrunde/ Mitglieder: die Abteilungsleitungen +├── artikelstamm/ abteilungsübergreifend: Einkauf schreibt, Marketing liest +└── haus/ alle — für das wenige, das wirklich alle angeht +``` + +Vier Festlegungen: + +1. **Jede Einheit bekommt beim Anlegen ihren eigenen Bereich**, Mitglieder sind ihre + Agenten und ihre Untereinheiten. Das ist der Normalfall, und er kostet keine + Entscheidung. +2. **Abteilungsübergreifende Bereiche sind gewollt und ausdrücklich.** Der Artikelstamm + gehört dem Einkauf und wird vom Marketing gelesen — das ist eine Festlegung mit + benanntem Eigentümer, kein Nebenprodukt. Genau das, was Abschnitt 9 verlangt. +3. **Das Recht steht am Bereich, nicht am Agenten.** Heute trägt jeder Agent ein + `sharedAccessLevel` für den *einen* gemeinsamen Bereich. Künftig hat jeder Bereich + seine Mitglieder mit Stufe (lesen / schreiben / verwalten). Wer nicht auf der Liste + steht, sieht den Bereich nicht — auch nicht, dass es ihn gibt. +4. **Ein Umzug ändert die Mitgliedschaft, nicht den Inhalt.** Zieht ein Agent um, verliert + er den alten Bereich und bekommt den neuen. Was er dort abgelegt hat, bleibt liegen — + es gehört der Einheit. + +Für bestehende Instanzen bleibt `workspace: "shared"` gültig und zeigt auf den einen +Bereich, den es dort gibt. Ohne das bräche jede Aufgabe, die heute läuft. + ### Die eine Regel, die alles zusammenhält **Ein Agent kennt nur seine Einheit und seine Leitung.** Alles andere geht über die @@ -615,6 +653,44 @@ Modell stilllegt oder umkonfiguriert, verändert die Organisation ohne menschlic Beteiligung. Die Leitung *schlägt vor* und begründet; ausgeführt wird nach Freigabe — Linie von #205, #641, #687. +### Die Doctrine: wie eine Leitung steuert, ohne jeden Auftrag anzufassen + +Ein Agent wird heute von zwei Texten geprägt: `Identity.md` sagt, **wer** er ist, +`Soul.md`, **wie** er arbeitet. Beides ändert nur ein Mensch (#205). + +Einer Leitung fehlt damit ein Mittel. Sie kann Aufträge verteilen und Ergebnisse prüfen — +aber nicht sagen: „In dieser Abteilung gilt ab sofort, dass jeder Lieferantenkontakt in +der Datenbank landet, bevor er weitergegeben wird." Dafür müsste sie jeden Aufgabentext +einzeln ändern. + +**Die Leitung legt deshalb eine `Doctrine.md` in den Ordner ihrer unterstellten Agenten.** +Ein dritter Text neben Identity und Soul: nicht wer und nicht wie, sondern **was in dieser +Einheit gerade gilt**. + +Vier Festlegungen: + +1. **Nur eine Ebene tief.** Die Doctrine einer Abteilungsleitung erreicht die Agenten + *ihrer* Einheit — sie stößt nicht automatisch in die Untereinheiten durch. Ein Team + unter ihr hat seine eigene Leitung, und die schreibt ihre eigene. Wäre es anders, + summierten sich bei fünf Ebenen fünf Doktrinen in jedem Prompt, und niemand wüsste + mehr, welche Regel woher kommt. +2. **Selten und sichtbar.** Eine Doctrine, die wöchentlich wechselt, ist keine Doktrin, + sondern Mikromanagement mit Tokenkosten. Erzwingen lässt sich das nicht — beobachten + schon: Jede Änderung steht im Audit mit Vergleich zur Vorfassung, und häufige + Änderungen sind ein Befund für die Aufsicht (#680). +3. **Kurz und gedeckelt.** Sie geht in *jeden* Lauf *jedes* unterstellten Agenten. Fünf + Agenten mal vierzig Läufe am Tag mal tausend Token sind 200.000 Token täglich für + einen Text, den niemand mehr liest. Eine Höchstlänge gehört dazu. +4. **Eine belastete Leitung schreibt nicht frei.** Hat der Lauf, in dem die Leitung die + Doctrine ändert, fremde Inhalte gelesen — eine Mail, eine Webseite, einen + Lieferantenbericht —, dann ist die Änderung freigabepflichtig (#651, #659). Sonst wäre + die Doctrine der bequemste Weg, einer ganzen Abteilung von außen etwas unterzuschieben: + ein Text, der ungefragt in jedem Prompt steht. + +Ansonsten darf die Leitung sie ändern, ohne zu fragen. Das ist der Unterschied zu +Identity und Soul, und er ist gewollt: Eine Leitung, die für jede Anweisung an ihre +eigene Abteilung einen Menschen braucht, ist keine Leitung. + ### A/B: welches Modell macht es besser oder billiger? Die Eignungsprobe (#681) beantwortet „kann dieses Modell dieses Werkzeug bedienen?" — @@ -638,6 +714,69 @@ Drei Dinge machen den Unterschied zwischen einer Messung und einem Gefühl: Das Ergebnis ist wieder eine Empfehlung, keine Umstellung: Der Personalmanager legt sie vor, entschieden wird mit Freigabe. +## 8a — Kosten und Prompts: das wichtigste Instrument + +Je größer das Haus, desto weniger sieht man von innen. **Was eine Organisation aus fünfzig +oder hundert Agenten noch steuerbar macht, ist die genaue Erfassung dessen, was sie +kostet und was sie einander sagt.** Ein solches Haus wird früher oder später einige +hundert Dollar im Monat verbrauchen — und die Frage ist nie „können wir uns das +leisten?", sondern „wo davon ist Verschwendung?". + +Die Datenbasis steht bereits: `RunReceipts` (Schritte, Tokens, Kosten je Lauf), +`RunUsage`, `AuditLog` und die Prompt-History aus #660. Was fehlt, ist die Ebene der +Einheit darin — heute lässt sich nur je Agent auswerten. + +### Grenzen bleiben am Agenten, die Einheit rechnet auf + +Festgelegt am 2026-09-22: **Token- und Kostengrenzen bleiben da, wo sie heute sind — am +einzelnen Agenten.** Auf Einheitsebene wird gerechnet, nicht gedeckelt: + +- **Tatsächliche Kosten** je Einheit, aufsummiert über ihre Agenten und Untereinheiten +- **Theoretisches Maximum** je Einheit, als Summe der Agentengrenzen darunter +- beides je Tag, Woche, Monat — und im Vergleich zum Vormonat + +Das ist die sparsamste Lösung, und sie hat einen Vorteil, der erst beim Umziehen auffällt: +**Ein Umzug ändert keine einzige Grenze.** Wäre das Budget der Einheit eine Zuteilung, +müsste bei jeder Umorganisation neu gerechnet werden — bei einer Instanz, die mit ihrem +Projekt wächst, also dauernd. + +### Die Meldung ist wichtiger als die Grenze + +Eine Grenze sagt nur, wann Schluss ist. Was man wirklich wissen will, ist, wann sich etwas +**ändert**: + +> Die Agenten der Marketingabteilung dürften zusammen 100 $ am Tag ausgeben. Seit Wochen +> brauchen sie 30 $. Heute sind es 80 $. + +Da ist nichts überschritten — und trotzdem ist genau das der Moment, in dem man hinsehen +muss. Also: + +- **Abweichung vom eigenen Verlauf.** Ein gleitender Mittelwert je Einheit über die + letzten Wochen; wird er deutlich überschritten, geht eine Meldung raus. Das findet + Schleifen, entgleiste Aufgaben und teure Modellwechsel, bevor sie einen Monat lang + laufen. +- **Annäherung an die Grenze.** Wenn die Summe der Agentengrenzen einer Einheit zu einem + hohen Anteil ausgeschöpft wird, ebenfalls eine Meldung — bevor Agenten reihum in ihr + Limit laufen. +- **Gesamtbetrag erreicht.** Schwellen je Monat, die nichts abschalten, sondern melden. + +Erkennen ist auch hier Code, nicht Modell: Ein Mittelwert und ein Schwellwert sind eine +Abfrage. Ob die Abweichung ein Problem ist, deutet die Aufsicht (#680). + +### Was die Auswertung dafür braucht + +- **Die Einheit als Dimension** in Filtern und Zeitverlauf der Verbrauchsansicht (#660) — + „was kostet mich das Marketing?" muss eine Frage sein, keine Rechenaufgabe. +- **Verdichtete Werte.** Tagessummen je Agent und Einheit, damit eine Sechsmonatsansicht + nicht Millionen Laufzeilen liest (#700). +- **Aufbewahrung auch für Audit und Receipts (#700).** Für Transkripte gibt es eine Frist + und einen Kehrbesen (#660), für `RunUsage` eine Löschung — für `AuditLog` und + `RunReceipts` nichts. Gemessen auf der Testinstanz: 636 Läufe erzeugen 4.155 + Audit-Zeilen. Hundert Agenten kämen auf etwa 7.400 Zeilen am Tag, also einige Millionen + im Jahr — in genau der Tabelle, die jede Auswertung liest. + +--- + ## 9 — Was eine Organisation braucht und ein Agentenhaufen nicht Der Punkt, der beim Bauen am leichtesten übersehen wird: **Eine Organisation lebt von @@ -694,7 +833,8 @@ für sich schon nützt und keine die nächste blockiert. | **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) | Fehler findet die Leitung, nicht erst der Mensch | +| **9** | Kontrollpflicht der Leitung, abgestufte personelle Mittel (#693); Doctrine (#698) | Fehler findet die Leitung, nicht erst der Mensch — und sie kann steuern | +| **9a** | Kosten je Einheit, Abweichungsmeldung (#699), Aufbewahrung (#700) | Ineffizienz wird sichtbar, bevor sie einen Monat lang läuft | | **10** | Oberfläche: Organigramm statt Agentenliste, Lage je Abteilung | Bei fünfzig Agenten ist eine flache Liste keine Übersicht | | **11** | Organisationsvorlagen (#691) | Ein Haus lässt sich weitergeben statt nachbauen | @@ -740,13 +880,12 @@ wächst, wird der Umzug teurer. 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?** Hat Marketing 20 $ und jedes - seiner drei Teams 10 $, sind das 30 $ — bei Deckel-Bedeutung gilt trotzdem die 20, und - wer zuerst kommt, mahlt zuerst. Bei Zuteilung müsste die Summe aufgehen. Vorschlag: - **Deckel**, weil Zuteilung bei jeder Umorganisation neu gerechnet werden muss — plus - eine Mindestzusage je Unterteilung, damit ein gefräßiges Team die Geschwister nicht - aushungert. Dieselbe Frage stellt sich bei der Parallelität, und sie gehört gleich - beantwortet (Stufe 3). +- ~~**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 @@ -755,10 +894,12 @@ Gegenlesen am 2026-09-22 als zu grob aufgefallen: Maschinerie, solange niemand nachsieht. Vorschlag: Das Eskalationswerkzeug sucht von sich aus, bevor es einen Vorgang anlegt — genau wie `task_find` vor `task_create` (#674). Ein Beschluss, den man aktiv lesen müsste, wird nicht gelesen (Stufe 5). -- **Was passiert, wenn die Eskalationsgrenze erreicht ist?** Vorgeschlagen war „zählen - und deckeln", ohne zu sagen, was der Deckel tut. Vorschlag: dieselbe Behandlung wie bei - erschöpftem Budget (#643) — der Vorgang bleibt offen und sichtbar liegen, statt - abgewiesen zu werden. Eine verworfene Eskalation ist ein verlorenes Problem (Stufe 5). +- ~~**Was passiert, wenn die Eskalationsgrenze erreicht ist?**~~ **Entschieden am + 2026-09-22, und schärfer als vorgeschlagen: Eine Eskalation, die nicht gelöst werden + kann, darf es nicht geben.** Finden die Agenten binnen einer einstellbaren Frist keine + Lösung, wird der Mensch gerufen. Er entscheidet — oder fordert an, was ihm fehlt, etwa + eine Stellungnahme jeder Streitpartei. „Bleibt sichtbar liegen" war zu schwach: Ein + Vorgang, den niemand anfasst, ist auch dann verloren, wenn er sichtbar ist (Stufe 5). Und eine Kleinigkeit mit Folgen: **Das Wort „Struktur" meint in Abschnitt 6 die Organisation** (Einheiten, Rechte, Grenzen) — nicht ein Datenbankschema. Eine @@ -786,6 +927,9 @@ nur nicht selbst an. | #695 | Skripte: Schreiben und Benutzen sind zwei Rechte, mit Lieferkette | | #696 | Fehlerablage je Skript — der Läufer schreibt, der Eigentümer liest | | #697 | Stille Post vermeiden: Weitergaben hängen an und tragen den Verweis | +| #698 | Doctrine.md — die Leitung steuert ihre Einheit, eine Ebene tief | +| #699 | Kosten je Einheit aufrechnen und Abweichungen melden | +| #700 | Aufbewahrung für Audit und Receipts, verdichtete Tageswerte | | #654, #196, #657 | Sandbox, Shell, Skriptprüfung — der eigentliche Werkzeugkasten | | #687 | Freigabe durch die Leitung innerhalb von Grenzen | | #688 | Organigramm in Oberfläche und WebUI |