Die fehlende Ebene: Strukturierung von KI-Agenten für organisatorische Hierarchien

Ein Referenzmodell dafür, wie Unternehmen ihre Arbeit mit KI strukturieren

Jose Martinez · 1. Oktober 2026 · v1.8.1 (gemessen in Claude Code; am 1. Oktober 2026 erneut anhand der Anthropic-Dokumentation geprüft)

In fünf Zeilen.

1. Unternehmen sind Bäume: Firma, Fachbereich, Projekt, Aufgabe. Claudes Projekte sind flach: Der Chat hat einen einzigen Organisationsblock mit 3.000 Zeichen, Projekte im Chat und in Cowork lassen sich weder verschachteln noch vererben, und innerhalb eines Projekts gehört ein Connector-Account entweder einer Person oder dem gesamten Unternehmen – niemals einem Zweig.

1. Also bekommt jedes Projekt eine manuell erstellte Kopie der Regeln seines Fachbereichs, die Kopien driften auseinander, und niemand kann nachvollziehen, welche Regel eine Antwort erzeugt hat.

1. Anthropic hat den Baum bereits zweimal gebaut. Claude Code verschachtelt Anweisungen nach Ordnern und führt seit dem 1. Oktober 2026 die Mods des Unternehmens vor denen der einzelnen Person aus. Claude Tag in Slack vererbt Anweisungen und Anmeldedaten von der Organisation über den Workspace bis zum Channel. Keines von beiden reicht bis zum Projekt. Dasselbe Modell könnte das leisten: eine Fachbereichsebene, Projekte, die aus deren Ordnern entstehen, typisierte Aufgaben, ein Compiler, der Konflikte ablehnt, bevor das Modell sie sieht, und Berechtigungen pro Knoten, die auch auf Team funktionieren.

1. Ich habe es zweimal in Claude Code gemessen. Eine Unternehmensregel und eine Projektregel, die sich widersprachen, in getrennten CLAUDE.md-Ebenen und keine davon als bindend markiert: Die Projektregel gewann 20 von 20 Mal. Dieselbe Unternehmensregel, rein textlich als verbindlich markiert: Sie gewann 20 von 20 Mal. Die Rangfolge wurde durch Formulierungen bestimmt, die jeder ändern kann, der irgendeine Ebene bearbeitet – nicht durch die Struktur.

1. Es läuft schon heute. Eine Desktop-App, die ich gebaut habe, führt Claude Code innerhalb des Baums aus. Sie mountet jede Ebene als CLAUDE.md, beschränkt Claude auf das, was die Person an diesem Knoten tun darf, weist Konflikte direkt beim Schreiben ab und protokolliert jede Antwort mitsamt ihren Regeln, Tokens und ihrem Reviewer. Gemessen lud der Baum 20–34 % weniger Instruction-Tokens als flache Kopien.

Unternehmen sind Bäume. Die Firma gibt Richtlinien vor, der Fachbereich setzt seine Standards, das Projekt wendet sie auf einen Auftrag an, und die Aufgabe liefert ein konkretes Ergebnis. Jedes Qualitätssystem, in dem ich gearbeitet habe, ist so aufgebaut – und genauso der Ordnerbaum auf fast jedem Firmen-Fileserver: Firma, Fachbereich, Jahr, dann ein Ordner pro Auftrag, benannt nach einer Auftragsnummer, die all das codiert.

KI-Projekte sind flach. Ich nehme Claude als Beispiel, weil es das Produkt ist, mit dem ich täglich arbeite, und weil es die Lösung in zwei seiner eigenen Oberflächen bereits ausliefert. Im Claude-Chat lassen sich Projekte nicht verschachteln, und Unternehmensanweisungen sind ein einziger Block mit maximal 3.000 Zeichen, der für alle gilt. Auf Enterprise können Admins Berechtigungen nach Gruppen einschränken. Auf Team gelten Rollen für das gesamte Unternehmen. Nichts, was im Chat oder in Cowork dokumentiert ist, gibt Anweisungen an eine Abteilung oder einen Fachbereich und weiter in dessen Projekte hinunter. Auf Enterprise lassen sich Skills und Projekte zwar mit einer Gruppe teilen, aber das ist Verteilung, keine Vererbung.

Das ist die fehlende Ebene: die zwischen Unternehmen und Projekt. Dieser Artikel beschreibt, was fehlt, warum es wichtig ist, was es wirklich kostet, und liefert ein Referenzmodell, das jede Plattform umsetzen könnte – inklusive Berechtigungen und Datenstruktur.

1. Was heute existiert

Geprüft anhand der Anthropic-Dokumentation vom 29. September bis 1. Oktober 2026. Claude hat vier Oberflächen, auf denen die Arbeit eines Teams läuft, und jede hat ihr eigenes Anweisungsmodell:

Die Berechtigungen hängen vom Plan ab:

Anthropic hat den halben Baum für Berechtigungen bereits gebaut. Auf Enterprise werden benutzerdefinierte Rollen Gruppen zugewiesen; „benutzerdefinierte Rollen steuern auch, welche Connectors und welche Tools dieser Connectors eine Rolle nutzen darf“. Plattformweit gilt über Organisations-, Rollen- und Benutzerebenen hinweg: „die restriktivste Ebene gewinnt“, während mehrere Rollen eines Mitglieds zusammenwirken. Admins können die „effektive Rolle anzeigen“ lassen, versehen mit einem Hinweis „Gewährt durch“, und Gruppen können eigene Ausgabenlimits haben. Aber das sind flache Gruppen, kein Baum, und nichts davon erreicht die Anweisungen. Am nächsten kommen dem Plugins: Auf Enterprise kann ein Owner festlegen, dass ein Plugin und seine Skills für eine bestimmte Gruppe verpflichtend oder standardmäßig installiert sind – mit einer klar definierten Reihenfolge („Gruppeneinstellung, dann organisationsweite Einstellung, dann Marketplace-Standard“). Das zielt auf eine Gruppe von Menschen, nicht auf ein Projekt; zwischen Projekten wird nichts vererbt, und ein Skill lädt weiterhin nur dann, wenn Claude ihn für relevant hält. Team kennt Rollen für das gesamte Unternehmen und Freigaben von Person zu Person; bei den Plugin-Einstellungen gibt es laut Dokumentation „keine Gruppeneinstellung“. Und Team ist genau der Plan, der für kleine und mittlere Unternehmen gedacht ist.

Anthropic hat den ganzen Baum zweimal gebaut – außerhalb von Projekten.

In Claude Code, nach Ordnern. Claude Code lädt CLAUDE.md-Dateien aus vier Ebenen; „alle gefundenen Dateien werden an den Kontext angehängt, statt sich gegenseitig zu überschreiben“, sortiert „vom Root des Dateisystems bis hinab zu deinem Arbeitsverzeichnis“, und Dateien in Unterverzeichnissen „laden bei Bedarf“. Der Block eines Unternehmens kann als verwaltete Datei auf jedem Rechner ankommen oder als Text aus der Admin-Konsole (der Schlüssel claudeMd). Die Dokumentation ist ehrlich, was die Grenzen betrifft: Claude behandelt diese Dateien „als Kontext, nicht als erzwungene Konfiguration“, und „wenn sich zwei Anweisungen widersprechen, wählt Claude möglicherweise willkürlich eine aus.“

In Claude Tag, nach Slack-Channels. Claude Tag bringt Claude in das Slack eines Teams – aktuell in der öffentlichen Beta auf Team und Enterprise. Seine Einstellungen hängen an einem Scope, und „ein Scope ist der Ort, an dem ein Bundle gilt: Standard-Slack-Zugriff (die organisationsweite Wurzel), ein Workspace oder ein einzelner Channel.“ Drei Dinge, die der Rest dieses Artikels fordert, sind hier bereits vorhanden:

• Anweisungen werden vererbt. „Scope-spezifische Anweisungen werden aneinandergehängt: zuerst der Standard-Slack-Zugriff, dann der Workspace, dann der Channel. Die Anweisungen eines Channels ergänzen die darüberliegenden, statt sie zu ersetzen.“

• Anmeldedaten gehören zum Zweig. In Channels agiert Claude mit Service-Accounts, die ein Admin einem Scope zuweist, und „es werden die Anmeldedaten des engsten Scopes genutzt: Channel schlägt Workspace, und dieser schlägt den Standard-Slack-Zugriff.“

• Man sieht, woher der Zugriff stammt. Jede Zeile für Connector, Repository und Plugin zeigt „Vererbt von“ einem breiteren Scope oder „Zugewiesen aus“ einem Bundle. Ausgaben sind für das Unternehmen und pro Channel gedeckelt und werden pro Channel ausgewiesen.

Auch die Grenzen sind dokumentiert. Der Baum hat die Form von Slack: drei feste Ebenen, und Slack-Channels lassen sich nicht verschachteln. Anweisungen sind „Orientierung, kein erzwungener Leitplanken“, und die Dokumentation beschreibt keine Prüfung auf Konflikte zwischen Scopes. Es gibt „kein protokollbasiertes Log jeder Aufgabe und wer sie angefragt hat“. Und es endet an der Grenze eines Projekts: „Projekte in claude.ai greifen hier nicht; Claude liest in Slack weder die Anweisungen noch das Wissen eines Projekts, und ein Channel lässt sich nicht auf ein Projekt ausrichten.“

Was sich am 1. Oktober 2026 geändert hat. Claude Code 2.1.287 hat Mods aktiviert, die zuvor im Early Access waren: Funktionen innerhalb eines Plugins, die in Claude Code laufen und einen Prompt oder einen Teil des System-Prompts umschreiben, einen Tool-Aufruf blockieren oder umschreiben, eine Berechtigungsanfrage genehmigen oder ablehnen und eigene Bereiche in der Oberfläche zeichnen können. Drei Aspekte sind hier entscheidend:

• Sie haben eine deklarierte Reihenfolge. Ein eingebauter Guard und die unternehmenseigenen Mods laufen zuerst, danach die Mods, die eine Person installiert. „Der erste Mod ist der äußerste: Er sieht das Ereignis vor allen anderen und das Ergebnis nach ihnen, und er entscheidet, ob die anderen überhaupt ausgeführt werden.“ Dort, wo der Guard lädt (ein Rechner mit verwalteten Einstellungen oder ein Team-/Enterprise-Login), kann der Mod einer Person weder „den System-Prompt, deine verwaltete CLAUDE.md und andere verwaltete Anweisungen“ ändern noch einen Tool-Aufruf genehmigen, den eine Deny-Regel ablehnt. Das ist eine Rangfolge, die durch Struktur gesetzt wird – genau das, was dieser Artikel fordert. Es ist ein Standard, kein Schloss: Wer Claude Code mit --safe-mode startet, läuft ohne installierte Mods, einschließlich derer des Unternehmens, während verwaltete Hooks und Deny-Regeln weiterhin gelten.

• Die Reihenfolge hat zwei Eigentümer. Die Mods des Unternehmens laufen vor denen der Person – oder danach, wenn das Unternehmen es so wählt. Eine Ebene für Fachbereiche gibt es nicht. Einstellungen aus der Admin-Konsole „gelten einheitlich für alle Nutzer im Unternehmen. Konfigurationen pro Gruppe werden noch nicht unterstützt.“ Ein Unternehmen, das pro Gruppe unterschiedliche Richtlinien will, hat zwei Wege, beide über die IT: eine andere Einstellungsdatei auf die Rechner jeder Gruppe ausrollen oder ein selbst gehostetes Gateway betreiben, das „verwaltete Einstellungen pro IdP-Gruppe ausliefert“.

• Sie erreichen den Chat nicht und Cowork nur ungleichmäßig. „Mods funktionieren in der Claude Code CLI und im Code-Tab der Claude Desktop App.“ Ein Mod wird in hooks/hooks.json eines Plugins ausgeliefert, und Anthropics Plugin-Support-Tabelle kennzeichnet diese Datei im Chat als „Ignored“. Dieselbe Tabelle markiert sie in Cowork als „Loads“, denn „Cowork in der Claude Desktop App führt seine Sitzungen auf Claude Code aus“; die Mods-Seiten listen Cowork nicht auf, und ich habe es nicht getestet. Was das Unternehmen dort kontrolliert, ist dünner: In einer Cowork-Sitzung ruft Claude Code „niemals serververwaltete Einstellungen aus der claude.ai-Admin-Konsole ab, selbst wenn sich der Nutzer mit einem Team- oder Enterprise-Account anmeldet“, und Remote-Cowork-Sitzungen haben keine Geräte-Richtlinie, die sie lesen könnten.

Was gerade ausgerollt wird. Cowork verschmilzt mit Claude: Das Help Center sagt inzwischen „Claude Cowork ist jetzt einfach Claude“, zuerst auf Pro und Max, während Team und Enterprise „Chat und Claude Cowork so behalten, wie sie heute sind“. Am 6. Oktober 2026 ziehen neue Cowork-Aufgaben auf Pro und Max in die Cloud. Und eine neue Version von Projekten befindet sich auf Pro und Max in der öffentlichen Beta, beginnend in Claude Code, Chat, Cowork, Team und Enterprise folgen; darin ist „ein Projekt eine Konversation“, die Claude in parallele Threads aufteilt. Es bleibt eine einzige Ebene: „Ein Projekt gehört einem Nutzer“, und „während der Beta gibt es keine organisationsweiten Kontrollen für Projekte“.

Der Baum ist für Anthropic also keine neue Idee. Er existiert nach Ordnern für Code und nach Channels für Slack, und in beiden Fällen kommt das Unternehmen zuerst. Der Ort, an dem eine Firma ihre Arbeit ablegt – das Projekt –, hat weder ein Elternelement noch eine übergeordnete Linie. Zwei weitere Angebote von Anthropic weisen in dieselbe Richtung und liegen außerhalb des Rahmens dieses Artikels: Claude for Government löst Einstellungen über eine Kette aus Tenant, Gruppe und Organisation auf, und Claude Desktop auf Drittanbieter-Plattformen hat gruppenbezogene Richtlinien in der Beta.

2. Warum es wichtig ist

Projekte sind keine Container. Ein echter Auftrag ist ein Container. Er hat einen Schlüssel (die Auftragsnummer), ein Elternelement (seinen Fachbereich), einen Lebenszyklus (offen, geschlossen, jahresweise archiviert), einen Ordner, einen Kunden, Personen, Regeln und Ergebnisse. Ein Claude-Projekt hat einen Freitextnamen, keinen Schlüssel, kein Elternelement und keine Kinder, und sein dokumentierter Lebenszyklus besteht aus Archivieren und Löschen. Cowork kann ein Projekt an einen lokalen Ordner binden, aber nur manuell, Projekt für Projekt, ohne Schlüsselmuster und ohne Elternelement. Ein Fachbereich öffnet vielleicht Hunderte Aufträge im Jahr. Das lässt zwei schlechte Optionen: ein manuell gebautes Claude-Projekt pro Auftrag, jedes mit eigener Kopie der Regeln, oder ein Projekt pro Fachbereich, in dem der Kontext verschiedener Kunden nebeneinanderliegt.

Der Lastpfad bricht. Im Bauingenieurwesen braucht jede Last einen durchgehenden Pfad bis ins Fundament. Nimmt man ein Bauteil heraus, wird nichts darüber Liegendes mehr nach unten übertragen. Mit Regeln verhält es sich genauso. Wenn es keine Ebene zwischen Unternehmen und Projekt gibt, haben die Standards, Templates und Freigaberegeln eines Fachbereichs keinen Ort. Also bekommt jedes Projekt eine manuelle Kopie.

Die Kopien driften. Korrigiert man eine Regel in einem Projekt, behalten die anderen die alte Version. Jedes Projekt besteht weiterhin seinen eigenen lokalen Check. Der Widerspruch fällt erst auf, wenn jemand Projekte nebeneinander vergleicht – und in regulierten Bereichen ist das meist ein Auditor. Infrastrukturteams kennen diesen Fehler gut. In Fireflys Studie von 2026 brachte etwa ein Drittel der Befragten Configuration Drift mit teuren Produktionsausfällen in Verbindung, und rund jeder Fünfte hatte keinen Prozess, um ihn zu erkennen oder zu beheben.

Identität ist ebenfalls flach. Viele Menschen arbeiten in mehr als einem Unternehmen, und jedes braucht seinen eigenen, abgeschlossenen Kontext. Innerhalb eines einzelnen davon gehört ein Connector-Account im Chat und in Cowork einer Person, nicht einem Zweig. Enterprise-Rollen können bestimmen, welche Connectors eine Gruppe nutzen darf, und ein Admin kann einen Connector einmal für das ganze Unternehmen autorisieren; ein Custom Connector kann sogar eine gemeinsame Anmeldedaten für alle mitbringen (in der Beta). So oder so gehört der Account der Person oder dem Unternehmen, nie einem Zweig: Ein Berater, der zwei Kunden betreut, kann das Drive jedes Kunden nicht an die Projekte dieses Kunden binden. Geteilte Projekte machen es noch deutlicher: „Connectors sind nur in privaten Projekten verfügbar.“ Claude Tag zeigt, dass das andere Design möglich ist – mit einem Service-Account, der an einen Slack-Channel hängt –, und es zeigt, wo es endet: am Projekt. Anthropics Seite zum Google-Connector beschreibt einen einzigen verbundenen Google-Account, und der dokumentierte Weg, ihn zu wechseln, ist Trennen und Neuverbinden; drei offene Issues (siehe unten) fordern mehr als einen Account. Die Grenze existiert nur im Kopf der Person – und genau solche manuellen Grenzen scheitern still und leise.

Niemand sieht, welche Regel gegriffen hat. Claude Enterprise zeigt Admins für Berechtigungen eine Ansicht der „effektiven Rolle“, und /context in Claude Code listet auf, welche Memory-Dateien geladen wurden. Ein Claude-Code-Mod kann inzwischen einen eigenen Bereich zeichnen, sodass eine Ansicht der effektiven Anweisungen dort jeder bauen könnte. Claude Tag kennzeichnet jeden Connector und jedes Repository mit dem Scope, aus dem es vererbt wurde, aber für Anweisungen empfiehlt die Dokumentation, „Claude zu bitten, seine Admin-Anweisungen zu wiederholen“. Keine Oberfläche zeigt für eine konkrete Antwort, welche Anweisung aus welcher Ebene stammt. Ohne Herkunft gibt es keinen Audit-Trail, und ohne Audit-Trail gibt es kein Qualitätssystem.

Menschen fragen nach Teilen davon. Offene Issues in Anthropics öffentlichem Issue-Tracker (github.com/anthropics/claude-code), geprüft am 01.10.2026:

Ein siebtes, #47741, forderte eine vom Unternehmen verwaltete CLAUDE.md und wurde geschlossen, weil Claude Code sie bereits hat. Genau das ist der Punkt: Die Ebenen existieren in Code und in Slack, und die Issues fordern sie dort, wo die Projekte sind.

3. Was es kostet und was das Token verbirgt

3.1 Tokens sind nicht die Hürde

Mehr Ebenen könnten mehr Kontext pro Nachricht bedeuten, und KI wird nach Token abgerechnet. Diese Erklärung stimmt nur teilweise. Bei nutzungsbasierten Enterprise-Plänen wird die Nutzung zu API-Preisen berechnet, also bedeutet mehr Kontext mehr Umsatz, nicht weniger. Auf Team sind Seats pauschal, solange keine Zusatznutzung aktiviert ist, und zusätzliche Tokens führen dazu, dass Mitglieder ihr Wochenlimit früher erreichen. Und Claude Code, das über dieselben Tokens abgerechnet wird, liefert bereits eine vierstufige Kaskade. Wären Tokens die Hürde, gäbe es sie nicht. Wie in Abschnitt 3.2 gemessen, kam Claudes eigener System-Prompt samt Tools auf etwa 30.200 Tokens, bevor eine unserer Anweisungen hinzukam; die vollständigen Anweisungen eines Projekts fügten dem 3,5–5,2 % hinzu.

3.2 Ein durchgerechnetes Beispiel

Tags auf jedem Bild: REAL = gemessen oder zwischen dem 29. September und 1. Oktober 2026 gegen die Anthropic-Dokumentation geprüft; EST = simuliert; IND = illustrativ.

Zuerst gemessen. Ich stellte dieselbe Frage in Claude Code (claude -p, Claude Sonnet 5.5) an ein Demo-Projekt, fünfmal pro Bedingung, und nahm die Input-Tokens, die Claude Code selbst meldete. Ich lief es am 30. September auf Claude Code 2.1.286 und am 1. Oktober erneut auf 2.1.287; die Anweisungszahlen waren identisch. Zieht man einen Lauf ganz ohne Projektanweisungen ab, bleibt übrig, was jedes Layout kostet:

Zwei Dinge, die die Simulation unten nicht zeigen konnte. Die Kaskade kostet 224 Tokens mehr als die kompilierte Datei für dieselben Regeln: Jede zusätzliche Datei bringt Overhead mit sich – hier der Marker und die Überschrift der App pro Ebenendatei plus Claudes Framing um jede geladene Datei. Mehr Ebenen bedeuten mehr Overhead. Und Claude Code lud tatsächlich 21–26 % mehr, als der öffentliche Tokenizer schätzte, selbst mal 1,30; ein Teil dieser Lücke ist derselbe dateibezogene Overhead. Verhältnisse überleben das, absolute Dollarbeträge nicht – lesen Sie die Dollarwerte der Simulation also als Untergrenze.

Dann simuliert in Firmengröße. Ich simulierte einen Monat Instruction-Tokens für eine beispielhafte Firma: 40 Personen in drei Fachbereichen, 250 aktive Projekte, sechs Berichtstypen pro Fachbereich, 35 Nachrichten pro Person und Arbeitstag in Sitzungen von je fünf, insgesamt 29.400 Nachrichten. Tokengrößen wurden anhand von Beispieltexten mit Anthropics öffentlichem Legacy-Tokenizer gezählt (den Anthropic selbst für Claude 3 und neuer als „eine sehr grobe Näherung“ bezeichnet) und für den Tokenizer von Claude 4.7+ mit 1,30 skaliert. Der Organisationsblock wurde von einem 597-Zeichen-Beispiel auf das Limit von 3.000 Zeichen hochgerechnet, das Fachbereichshandbuch entspricht dem Dreifachen eines 953-Zeichen-Beispiels. Die Preise sind Listenpreise für Claude Sonnet 5.5 (Input 2 $, 5-Minuten-Cache-Write 2,50 $, Cache-Read 0,20 $ pro Million Tokens). Der Prompt-Cache hält fünf Minuten und wird bei jedem Treffer aufgefrischt.

• Flach (der heutige Workaround): der Organisationsblock, dann die eigene Kopie des Fachbereichshandbuchs jedes Projekts, alle sechs Berichtstemplates und die Projektdetails.

• Baum: Unternehmen, Fachbereich, nur das jeweils genutzte Berichtstemplate, dann die Projektdetails, kompiliert mit den am häufigsten geteilten Elementen zuerst.

Die Größen hinter der Tabelle: Organisationsblock 830 Tokens (3.000 Zeichen), Fachbereichshandbuch 729, ein Berichtstemplate 147, Projektdetails 98 (gerundet; Summen wurden vor dem Runden berechnet). Die Simulation ignoriert Claudes eigenen System-Prompt, der vor dem Organisationsblock steht.

Zwei ehrliche Einschränkungen. Erstens spart der Baum allein keine Tokens. Die −29 % stammen von typisierten Aufgaben: Es wird nur das Template für den Bericht geladen, der gerade geschrieben wird, nicht alle sechs. Die −62 % kommen größtenteils davon, die am häufigsten geteilten Ebenen zuerst zu kompilieren, sodass Hunderte Projekte ein byte-identisches Präfix teilen: Allein die Reihenfolge senkt die Shared-Cache-Kosten von 36 $ auf 18 $ (−51 %), selbst wenn alle sechs Templates geladen bleiben; typisierte Aufgaben bringen den Rest. Diese zweite Ersparnis existiert nur, wenn der Cache nutzerübergreifend geteilt wird. Auf der Claude-API sind Caches zwischen Unternehmen isoliert und innerhalb eines Unternehmens pro Workspace, sodass identische Präfixe über Anfragen innerhalb eines Workspace wiederverwendet werden; für claude.ai ist das nicht dokumentiert. Im ausgelieferten Claude Code passiert es nicht: Dort ist „der Cache faktisch auf einen Rechner und ein Verzeichnis beschränkt“, sodass zwei Personen in zwei Projektordnern am Cache der anderen vorbeilaufen. Lesen Sie die letzte Spalte als das, was eine native Ebene im Chat einsparen könnte, nicht als etwas, das heute verfügbar ist. Ein fairer Einwand: Skills laden bereits on demand, also erzielt ein flacher Workspace, der seine Templates in Skills verschiebt, einen Teil der −29 % schon heute. Was Skills im Chat und in Cowork fehlt, sind Scope und Vererbung: Ein Skill kann nicht zu einem Fachbereich gehören und in dessen Projekte hinabfließen. (In Claude Code lädt ein Skill in einem Unterordner sehr wohl für Sitzungen, die darin oder darunter gestartet werden.) Zweitens sind das nur Instruction-Tokens, und in dieser Größenordnung liegen sie je nach Caching zwischen 14 $ und 149 $ im Monat. Konversationshistorie und Output dominieren echte Rechnungen. Das starke Argument für den Baum ist Korrektheit und, auf Team, Kapazität. Nicht die Rechnung.

Die Messung oben reproduziert den Effekt typisierter Aufgaben an einem echten Baum in Claude Code statt mit angenommenen Größen: −20 % als Kaskade und −34 % kompiliert, gegenüber den −29 % der Simulation. Ein Fachbereich mit nur einem Aufgabentyp würde durch typisierte Aufgaben nichts sparen.

3.3 Dieselbe Antwort, vom echten Claude

Ich stellte Claude Code vierzigmal dieselbe Frage: zehn unabhängige Antworten unter jeder von vier Bedingungen, in zwei Chargen mit einem Tag Abstand. Die Frage war, ob ein Felddichtetest auf dem Planum besteht – bei 112,3 pcf gegenüber einer maximalen Trockendichte von 115,8 pcf bei geforderten 98 %. Die Anweisungen waren entweder die sechs Regeln der Firma oder ein einzeiliger „Helpful Assistant“-Prompt, die Sprache Englisch oder Spanisch. Alle vierzig Antworten kamen zum selben Urteil: 97,0 %, nicht bestanden.

Claude Code meldet zwei Output-Zahlen: die abgerechneten Tokens und wie viele davon Thinking waren, das der Leser nie sieht.

Vier Erkenntnisse:

• Die Firmenregeln machten die Antworten auf dem Bildschirm 1,4-mal länger und auf der Rechnung 1,8- bis 1,9-mal länger. Der sichtbare Zuwachs waren die Abschnitte zu Flags, Standards und Einschränkungen, die die Regeln verlangten. In einem Qualitätssystem sind genau die der wertvolle Teil.

• Mit den Firmenregeln war über ein Drittel des abgerechneten Outputs unsichtbar. 37 % der abgerechneten Output-Tokens waren Thinking, gegenüber 16 % beim einfachen Prompt. Auf Englisch sieht der Leser 447 Tokens und zahlt für 711.

• Spanisch kostete das 1,2-Fache der sichtbaren Tokens von Englisch bei Antworten, die in Wörtern gemessen höchstens 4 % von der gleichen Länge abwichen. Auf dieselbe Weise gemessen brauchten die Firmenregeln auf Spanisch das 1,53-Fache der Input-Tokens.

• Dasselbe Urteil wurde mit 317 bis 953 Tokens abgerechnet – dreimal so viel für die längste Antwort wie für die kürzeste. Eine Abrechnung pro Token kann Gründlichkeit nicht von Füllmaterial unterscheiden. Akzeptanzkriterien schon.

Diese Verhältnisse schwanken zwischen Fünferchargen. Das Bildschirmverhältnis für die Firmenregeln lag in der ersten Charge bei 1,43–1,52 und in der zweiten bei 1,27–1,31; das Abrechnungsverhältnis bei 1,78–1,82 und dann 1,70–2,05; das Spanisch-Verhältnis bei 1,29–1,38 und dann 1,14–1,18. Die Richtung änderte sich nie. Die Größenordnung stimmt auf eine signifikante Stelle genau.

Methode: Claude Code 2.1.286 am 30.09.2026 und 2.1.287 am 01.10.2026, claude -p --output-format json, Claude Sonnet 5.5. Alle Tools wurden verboten und die persönlichen ~/.claude-Dateien ausgeschlossen, sodass sich zwischen den Bedingungen nur die genannten Anweisungen unterschieden. Die Tokenzahlen stammen aus dem eigenen Nutzungsbericht von Claude Code, einschließlich thinking_tokens; die Monatskosten wenden die 10 $ pro Million Output-Tokens von Sonnet 5.5 auf den abgerechneten Mittelwert an. Das Messskript, beide Chargen, die zusammengefassten Zahlen und jede einzelne Antwort liegen beim Autor und sind auf Anfrage verfügbar. Die erste Version dieses Artikels schätzte diese Zahlen mit Subagents und dem öffentlichen Tokenizer; diese Schätzungen sind überholt.

3.4 Wenn Regeln sich widersprechen, entscheidet die Formulierung

Anthropics Dokumentation räumt ein, dass widersprüchliche Anweisungen „willkürlich“ aufgelöst werden können. Ich testete einen Konflikt der Art, wie ihn eine fehlende Fachbereichsebene erzeugt. Die Unternehmensregel sagte, US-amerikanische Einheiten zu verwenden; eine Projektregel verlangte Dichten in SI. Ich platzierte sie so, wie es ein Baum tun würde: die Unternehmensregel in einer CLAUDE.md im Storage-Root, die Projektregel in einer CLAUDE.md im Projektordner, beide geladen durch Claudes eigene Kaskade. Dann ließ ich dasselbe Setup laufen, wobei die Unternehmensregel nur textlich als verbindlich markiert war: das Tag ENFORCED in ihrer Bezeichnung und ein ergänzter Satz: „This rule is enforced: no line or project rule may override it.“ Jedes Setup lief am 30. September zehnmal und am 1. Oktober weitere zehnmal.

Es war nicht willkürlich. Ohne Deklaration nahm Claude jedes Mal die nähere, spezifischere Regel. Vierzehn der zwanzig Antworten erklärten warum („diese Regel ist spezifischer als die firmenweite US-Einheiten-Regel“ oder dass sie die Firmenregel überschreibe); fünf nannten nur die Projektregel und erwähnten nie, dass die Firmenregel widersprach. War die Bindung textlich deklariert, gewann jedes Mal die Unternehmensregel, und jede Antwort erklärte, dass die erzwungene Firmenregel Vorrang habe. Die zweite Charge reproduzierte die Einheiten, jeweils 10 von 10, und der Unterschied zwischen den beiden Zeilen liegt weit jenseits des Zufalls (Fishers exakter Test, p < 0,0001). Die Erklärungen hielten weniger gut durch: Neun von zehn Antworten begründeten in der ersten Charge, warum die Projektregel gewann, in der zweiten fünf von zehn.

Das sind gute Nachrichten für das Modell und schlechte für den Workspace. Eine Rangfolge existiert zwar, aber sie steckt im Wortlaut der Regeln – und den kann jeder ändern, der eine beliebige Ebene bearbeitet, ohne dass jemand diese Änderung als Entscheidung über die Rangfolge prüft. Und wenn die niedrigere Regel gewann, erwähnte ein Viertel der Antworten nicht, dass eine höherstehende Regel außer Kraft gesetzt wurde. Ein Testlauf in der ersten Version dieses Artikels, bei dem beide Regeln in einem einzigen Prompt statt in einer Kaskade standen, zeigte ebenfalls Verschiebungen, sobald nur ihre Reihenfolge geändert wurde (Organisationsregel zuerst: SI 5 von 5; Organisationsregel zuletzt: SI 2 von 5, und 3 von 5 gaben beide Einheiten aus oder fragten, welche gilt).

Kein Modell sollte einen Konflikt schlichten müssen, den die Organisation schon beim Schreiben der Regel hätte abfangen können. Claude Code liefert zwei Teilantworten. /doctor prompt-audit weist Claude an, nach Anweisungsdateien zu suchen, die sich widersprechen – sofern eine Person den Befehl ausführt. Und seit dem 1. Oktober kann ein Mod eine Reihenfolge im Code erzwingen: Die Mods der Organisation laufen vor denen einer Person, und dort, wo der eingebaute Schutz greift, schlagen Deny-Regeln den Mod einer Person. Beides deckt keinen Anweisungstext ab. Anweisungsdateien werden weiterhin zusammengefügt, und die Dokumentation beschreibt das Ergebnis auf drei Arten: Claude „kann eine davon willkürlich auswählen“; wenn eine Nutzerregel und eine Projektregel kollidieren, „kann Claude einer von beiden folgen“; und „wenn Anweisungen in Konflikt stehen, nutzt Claude sein Urteilsvermögen, um sie in Einklang zu bringen“. Das Zwanzig-von-zwanzig-Ergebnis zeigt, wie dieses Urteilsvermögen hier ausgefallen ist. Claude Tag deklariert eine Reihenfolge für seine drei Scopes und nennt das Ergebnis „eine Leitlinie, keine erzwungene Leitplanke“. Die Prüfung der Referenzimplementierung blockt genau diese Änderung ab – „R-22 setzt units.density=SI; R-01 (org:firm) erzwingt US“ –, bevor überhaupt etwas bei Claude ankommt, und enforced ist ein Feld in der Regel, kein Satz darin.

Eine hohe Anweisungsdichte macht es noch schlimmer. Im IFScale-Benchmark (2025) fiel die Genauigkeit von Claude Sonnet 4 von 100 % bei 10 gleichzeitigen Anweisungen auf 42,9 % bei 500.

3.5 Wären Rechenleistung oder Energie die fairere Einheit?

Der Token ist ein brauchbarer Stellvertreter für Rechenleistung innerhalb eines Modells: Mehr Tokens bedeuten tatsächlich mehr Arbeit für die Hardware. Genau deshalb würde ein Preis auf Basis von Rechenleistung oder Energie den Sprachnachteil nicht beheben. Spanisch kostet mehr, weil der Tokenizer es weniger stark komprimiert, und diese zusätzlichen Tokens sind echte Rechenarbeit. Die Lösung dafür ist ein besserer Tokenizer oder eine nach Inhalt normalisierte Messung.

Eine normalisierte Recheneinheit würde dennoch in dreierlei Hinsicht helfen. Sie macht verschiedene Modelle und Anbieter vergleichbar. Sie ist physikalisch messbar und berichtsfähig, etwa für die Nachhaltigkeitsberichterstattung. Und wenn der Koeffizient an Referenzhardware festgemacht wird, behält der Anbieter seine eigenen Effizienzgewinne – was genau der richtige Anreiz ist. Dafür gibt es Vorbilder: Cloud-Anbieter verkauften früher normalisierte Einheiten wie die EC2 Compute Unit.

Allerdings bringt sie echte Probleme mit sich. Kunden können sie ohne Standard und Prüfer nicht verifizieren. Der tatsächliche Energieverbrauch hängt von Hardware, Rechenzentrumseffizienz, Batching und dem Stromnetz ab. Und Anthropic veröffentlicht keinen Energieverbrauch pro Anfrage; ich habe nur Schätzungen Dritter gefunden. Vor allem aber bleibt Rechenleistung ein Input. Sie sagt nichts darüber aus, ob die Antwort richtig war.

Mein Fazit lautet: drei getrennte Ebenen:

1. Abrechnen in Tokens oder einer normalisierten Recheneinheit.

1. Offenlegen des Energieverbrauchs pro Aufgabe und pro Knoten.

1. Steuern über die Kosten pro verifiziertem Ergebnis.

Für Team besteht der Mindestschritt darin, das Wochenlimit in einer definierten Einheit zu veröffentlichen. Das Sitzungsbudget wird als „das 1,25-Fache des Pro-Sitzungslimits des Pro-Tarifs“ angegeben; für das Wochenlimit gibt es gar keine veröffentlichte Zahl. Beides lässt sich nicht planen.

Oder wie die FinOps Foundation es formuliert: „Der Token ist die Abrechnungseinheit, nicht die Werteinheit.“ Erst eine Hierarchie macht Wert definierbar, denn dort können Akzeptanzkriterien leben.

3.6 Wahrscheinlichere Gründe, warum es noch nicht gebaut wurde

1. Implizite Rangfolge. Anthropics eigene Dokumentation räumt ein, dass direkt widersprüchliche Anweisungen zu unterschiedlichem Verhalten führen können, und Abschnitt 3.4 zeigt, dass die Rangfolge einfach dem Wortlaut der Regeln folgt. Gestapelte Ebenen vervielfachen Konflikte, und die Befolgung von Anweisungen verschlechtert sich mit steigender Dichte: Im IFScale-Benchmark (2025) erreichten selbst die besten getesteten Modelle bei 500 gleichzeitigen Schlüsselwort-Anweisungen nur 68 % Genauigkeit (der in Abschnitt 3.4 zitierte Benchmark).

1. Vererbung von Berechtigungen. Wenn Wissen einen Baum hinab vererbt wird, muss der Zugriff das ebenfalls tun. Das bedeutet, das Berechtigungsmodell unter jeder Ebene neu aufzubauen.

1. Eine Vorliebe für Memory und Retrieval gegenüber statischen Ebenen.

1. Einfachheit für Endverbraucher zuerst. Code-Tools erben kostenlos einen Baum vom Dateisystem. Chat-Produkte müssen einen erfinden.

Anthropic hat sich öffentlich nicht dazu geäußert, warum dem Claude-Chat und Cowork eine Hierarchie fehlt. Alles in diesem Abschnitt ist eine Schlussfolgerung aus dem, was bereits ausgeliefert wurde.

4. Das Referenzmodell

Das Design bedient sich bei Systemen, die dieses Problem bereits gelöst haben: Cloud-Ressourcenhierarchien (AWS Organizations, Google Cloud Org Policy, Azure-Verwaltungsgruppen), Verzeichnisrichtlinien (Active Directory Group Policy) und Claude Codes eigener CLAUDE.md-Kaskade. Beziehungen zwischen Knoten nutzen fünf Begriffe: contains (enthält), inherits (erbt), uses (nutzt), sealed (versiegelt) und shared (geteilt).

4.1 Den Baum einbinden, den die Organisation bereits hat

Zwingen Sie niemanden, seine Organisation im KI-Workspace nachzubauen. Der Dateiserver oder das Dokumentensystem ist bereits die Single Source of Truth. Nehmen Sie einen Pfad:

Die Auftragsnummer 26GT301 kodiert den Baum bereits: Jahr, Geschäftsbereich, laufende Nummer. Der Workspace sollte diese Struktur einbinden (mounten), nicht kopieren.

4.2 Regeltragende Knoten, Gruppierungsknoten, Projekte und Aufgaben

• Regeltragende Knoten: Organisation, Geschäftsbereich, Projekt, Aufgabe. Jeder trägt dieselben drei Dinge: Kontext (Anweisungen und Wissen), Policy (welche Tools, Daten und Connectors erlaubt sind) und Identitäten (die daran gebundenen Connector-Konten).

• Gruppierungsknoten: Serie, Jahr, Region. Sie tragen keine Regeln. Sie dienen Navigation, Aufbewahrung und Lebenszyklus. Ihre Trennung hält den Regelbaum flach – drei bis vier Ebenen –, wie es auch Microsofts eigene Empfehlung für Verwaltungsgruppen vorsieht („nicht mehr als drei bis vier Ebenen“).

• Das Projekt ist ein Container mit Schlüssel. Es wird automatisch erstellt: Sobald ein Ordner erscheint, der dem Schlüsselmuster des Bereichs entspricht (z. B. {YY}GT{NNN}_{Name} unter dem Root des Bereichs), wird ein Projektknoten erzeugt, der von seinem Bereich erbt und Connector-Zugriff ausschließlich für diesen Ordner erhält. Er enthält nur das, was sich von seinem Bereich unterscheidet: Mitglieder, Kunde, Spezifikationen. Er durchläuft die Zustände offen, geschlossen und archiviert (Diagramm 2).

• Die Aufgabe ist typisiert. Ihr Typ stammt aus dem Katalog des Bereichs (ein Dichtebericht, ein Bohrprotokoll). Der Typ bringt eine Vorlage und Akzeptanzkriterien mit. Das Ergebnis wird nach der Namenskonvention der Firma zurück in den Projektordner abgelegt, und ein Prüfer nimmt es ab. Skills sind heute das, was Claude Aufgabenarten am nächsten kommt. Auf Enterprise können sie mit einer Gruppe geteilt werden, doch das ist Verteilung, nicht Vererbung: Nichts fließt einen Zweig hinab.

Die Rekursion ist Absicht. Stafford Beers Viable System Model drückt es direkt so aus: „In einer rekursiven Organisationsstruktur enthält jedes lebensfähige System ein lebensfähiges System und ist selbst in einem enthalten.“

4.3 Ein primärer Elternknoten plus Overlays

Christopher Alexander argumentierte 1965, dass „eine Stadt kein Baum ist“. Reale Strukturen überlappen sich. Ein Kunde, die Spezifikation einer Agentur oder ein Aufgabentyp kann mehrere Geschäftsbereiche umspannen. Deshalb hat jeder Knoten einen primären Elternknoten, und bereichsübergreifende Regelsätze werden als Overlays angehängt (uses). Konflikte lösen sich jedes Mal gleich: Deny gewinnt, andernfalls gewinnt der nächstgelegene Knoten.

4.4 Zwei Kanäle, zwei Semantiken

Das ist der Kern des Designs – und genau hier scheitern die meisten Hierarchien.

• Kontext wird zusammengefügt. Anweisungen und Wissen werden von der Wurzel abwärts kombiniert, wie es CLAUDE.md tut.

• Policy gilt standardmäßig als verweigert (Deny-by-default). Ein Tool oder Connector ist nur erlaubt, wenn auf dem gesamten Pfad von der Wurzel ein Allow existiert, und ein explizites Deny weiter oben gewinnt immer – wie bei AWS Service Control Policies. Ein Elternknoten kann eine Regel als enforced markieren, sodass kein Kindknoten sie blockieren kann, wie in der Gruppenrichtlinie.

Beides zu vermischen, ist der klassische Fehler. Beratender Kontext sollte sich mischen. Durchsetzung nicht.

4.5 Kompilieren, bevor das Modell liest

Heute löst das Modell widersprüchliche Anweisungen erst bei der Antwortgenerierung auf. Die Lösung ist ein Compiler für effektive Anweisungen, der läuft, bevor das Modell überhaupt etwas sieht:

1. Kontext von der Wurzel bis zum Blatt zusammenführen.

1. Policy anwenden: Deny gewinnt, und ein Allow muss auf dem gesamten Pfad gelten.

1. Erzwungene Regeln der Elternknoten respektieren.

1. Jede Regel mit einer ID und ihrer Ebene kennzeichnen.

1. Den Block danach sortieren, wie weitreichend die einzelnen Teile geteilt werden, und ein Token-Budget pro Ebene anwenden.

Konflikte erreichen diesen Schritt nie: Sie werden früher abgelehnt, nämlich wenn eine Regel geschrieben wird, und die Freigabe erfolgt durch jemand anderen als den Autor (Diagramm 3, untere Spur).

Da Konflikte zur Kompilierzeit gelöst werden, kann die Ausgabe danach sortiert werden, wie weitreichend die Teile geteilt werden, und nicht streng nach Tiefe: Organisation, Bereich, Vorlage des Aufgabentyps, dann Projektdetails. Diese Reihenfolge maximiert Cache-Treffer (Abschnitt 3.2). Sie passt zu Anthropics vier Cache-Breakpoints mit einem Token-Budget pro Ebene, auch wenn in der Praxis ein Breakpoint für die Konversation selbst benötigt werden könnte.

4.6 Identitäten an Zweige gebunden, nicht an Personen

Eine Connector-Identität (Konto, Tenant, Scope) hängt an einem Knoten, nicht an einer Person. Bei Slack-Channels funktioniert Claude Tag bereits so: Ein Admin bindet ein Dienstkonto an einen Scope, und die Credentials des engsten Scopes gewinnen. Das Modell hier fordert dasselbe eine Ebene tiefer, für einen Geschäftsbereich und seine Projekte. Wer in zwei Organisationen arbeitet, hat zwei versiegelte Bäume; man wechselt den Baum, nicht das Konto. Zwischen ihnen fließt nichts, es sei denn, die Eigentümer beider teilen es ausdrücklich. Das technische Primitiv existiert bereits: Die MCP-Autorisierungsspezifikation nutzt zielgruppengebundene OAuth-Tokens (RFC 8707 Resource Indicators, RFC 9728 Protected Resource Metadata) und verlangt, dass Server „KEINE anderen Tokens akzeptieren oder weiterleiten DÜRFEN“ (Spezifikationsversion 2026-07-28).

4.7 Berechtigungen folgen dem Baum

Principals: Personen, Gruppen, Dienstkonten, externe Gäste (z. B. ein Kunde) und der Agent selbst.

Der Agent überschreitet nie die Rechte der Person oder des Knotens. Claude handelt mit den Berechtigungen des aufrufenden Nutzers, geschnitten mit der Policy des Knotens. Regeln oder Berechtigungen kann er nicht ändern, sondern nur Änderungen vorschlagen. (Heute kann Claude die Ordneranweisungen in Cowork eigenständig aktualisieren. In diesem Modell wird daraus ein Vorschlag, den jemand freigibt.)

Auswertung. Berechtigungen fließen nur nach unten, niemals nach oben oder seitwärts. Die effektive Berechtigung an einem Knoten ergibt sich aus dem, was die Rollen auf seinem Pfad gewähren, innerhalb dessen, was die Policy auf dem gesamten Pfad erlaubt, abzüglich jedes Deny weiter oben. Ein Overlay gewährt nur Zugriff auf seinen eigenen Inhalt: Wer eine Spezifikation liest, öffnet damit nicht die Projekte, die sie nutzen.

Lebenszyklus.

• Offen: Rollen gelten wie gewährt.

• Geschlossen: keine neuen Aufgaben, aber ausstehende Prüfungen können abgeschlossen werden.

• Archiviert: für alle nur lesbar; nur der Eigentümer kann wiederherstellen, und die Wiederherstellung wird protokolliert.

• Versiegelter Baum: Ohne ausdrückliche Freigabe fließt nichts hindurch.

Ausnahmen und Delegation. Ausnahmen sind zeitlich begrenzt und begründet, und jemand anderes als der Antragsteller gibt sie frei. Sie laufen von selbst ab und werden gezählt, denn jede Überschreibung ist eine dauerhafte Wartungsinsel; die Grenzen der unterbrochenen Vererbung in SharePoint sind das warnende Beispiel. Delegation kann niemals mehr gewähren, als der Delegierende selbst besitzt. Ein Break-Glass-Zugang für Eigentümer existiert, wird immer protokolliert und nachträglich geprüft.

Auf Team funktioniert das ohne Gruppen: Die Gewährung lebt am Knoten, sodass selbst eine Organisation mit vier Rollen bereichsspezifische Berechtigungen erhält.

4.8 Wie die Ebenen interagieren

Ein Baum lohnt sich nur, wenn Änderungen ihn durchlaufen. Drei Interaktionen tragen die meiste Last (Diagramm 5):

• Nach unten pushen. Ein Bereichsleiter veröffentlicht eine neue Version einer Regel. Jedes Projekt im Bereich liest sie beim nächsten Kompilieren. Eine genehmigte Ausnahme behält die alte Version, bis sie abläuft, und bereits abgelegte Artefakte behalten die Version, mit der sie erstellt wurden.

• Nach oben ziehen. Ein Mitglied verbessert eine Vorlage in einem Projekt und schlägt sie vor. Der Bereichsleiter, nicht der Vorschlagende, gibt sie frei, und die Schwesterprojekte erben sie. Heute bleibt eine solche Verbesserung in dem Projekt, in dem sie entstand.

• Quer. Eine Agenturspezifikation ändert sich einmal. Projekte in drei Bereichen kompilieren damit neu, während die Bereiche selbst unverändert bleiben. Ein Konflikt mit einer Bereichsregel wird bereits beim Schreiben der Aktualisierung abgelehnt.

Eine einzige Anfrage zeigt alle Ebenen gleichzeitig (Diagramm 6): Der Baum prüft die Gewährung des Mitglieds und den Status des Projekts, der Compiler baut den Block, Claude liest Felddaten über eine Identität, die auf den Ordner dieses Projekts beschränkt ist, legt ein typisiertes Artefakt zurück in den Ordner, und ein Prüfer, der es nicht geschrieben hat, nimmt es ab. Jeder Schritt landet im Log, und die Kosten werden dem Projektschlüssel belastet.

4.9 Die Datenstruktur

Das Provisioning ist ereignisgesteuert: Ein neuer Ordner, der key_pattern unter dem storage_root eines Bereichs entspricht, erzeugt den Projektknoten. Das answer_log liefert die Herkunft jeder Antwort und die Kosten pro Knoten.

4.10 Ergebnisse messen, nicht Tokens

Jeder Aufgabentyp bringt Akzeptanzkriterien mit: die Definition von „fertig“. Sind diese vorhanden, wird eine bessere Einheit für KI-Arbeit messbar:

Kosten pro verifiziertem Ergebnis = (Token-Kosten + Prüfzeit) ÷ akzeptierte Deliverables

Da jede Antwort einem Knoten zugeordnet protokolliert wird, lassen sich KI-Kosten einem Projektschlüssel genauso belasten wie Arbeitszeit und Material. Einzelteile davon existieren bereits: Claude Tag berichtet Ausgaben pro Kanal und deckelt sie, und die Telemetrie von Claude Code lässt sich manuell nach Abteilung, Kostenstelle oder Repository kennzeichnen. Doch nichts davon ist an ein Projekt gekoppelt, und nichts teilt durch akzeptierte Deliverables. Für eine Firma, die nach Auftragsnummer abrechnet, wird KI so zu direkten Projektkosten statt zu Gemeinkosten. Im Ingenieurwesen bezahlt man das geprüfte, versiegelte Ergebnis, nicht die Bleistiftmine. KI-Arbeit sollte genauso gemessen werden.

4.11 Einwände – entkräftet

„Skills und Plugins machen das doch schon.“ Ein Skill wird geladen, wenn Claude ihn für relevant hält – das ist Relevanz, keine Garantie. Beim Provisioning bekommt jeder einen Skill; auf Enterprise kann ein Plugin, das ihn enthält, für eine Gruppe verpflichtend gemacht werden. Das kommt einem Geschäftsbereich in Chat und Cowork heute am nächsten, greift aber in drei Punkten zu kurz: Es gibt es nur auf Enterprise, es richtet sich an Personen statt an Projekte, und nichts fließt von einem Bereich in seine Projekte hinab. Eine Regel, die in einem Bereich immer gelten muss, darf nicht von einer Relevanzprüfung abhängen.

„Mods machen das doch schon.“ In Claude Code teilweise, seit dem 1. Oktober 2026. Ein Mod kann den System-Prompt umschreiben, einen Tool-Aufruf ablehnen und ein Panel zeichnen, und die Mods einer Organisation laufen vor denen einer Person. Der Compiler, die Prüfung beim Schreiben und die Ansicht der effektiven Anweisungen aus diesem Artikel ließen sich also heute als Mod bauen – Abschnitt 6 sagt das auch. Drei Grenzen bleiben. Mods laufen nicht im Claude-Chat, und in Cowork greifen die Konsoleneinstellungen der Organisation nicht. Ihre Reihenfolge hat zwei Eigentümer – Organisation und Person –, ohne einen Geschäftsbereich dazwischen; auf Enterprise kann ein für eine Gruppe verpflichtendes Plugin einen Mod zu dieser Gruppe bringen, aber er läuft als einer der persönlichen Mods der Person, ohne Vorrang. Und ein Mod ist unsandboxed Code: Um vor den Mods der Nutzer zu laufen, muss der Mod einer Organisation auf jedem Rechner in einem Verzeichnis liegen, und Einstellungen aus der Admin-Konsole „können das Verzeichnis nicht auf einem Rechner platzieren“. Eine Firma ohne Geräteverwaltung kann einen Mod an alle verteilen, aber er läuft zwischen den persönlichen Mods der Nutzer, nicht vor ihnen. Eine Firma sollte kein TypeScript schreiben müssen, um festzulegen, dass eine Abteilung in anderen Einheiten berichtet.

„Memory lernt die Regeln schon.“ Memory wird größtenteils von Claude geschrieben, für eine Person oder ein Projekt, und ein Eigentümer kann die Erinnerungen eines Mitglieds weder lesen noch bearbeiten. Ein Auditor braucht Regeln, die von einer Person geschrieben, versioniert, freigegeben und bis zu jeder Antwort nachvollziehbar sind. Anthropic hat das bereits dreimal gebaut: für Berechtigungen mit „Effektive Rolle anzeigen“ und dem Label „Gewährt durch“; für Skills und Plugins mit Versionshistorie und einem Prüfschritt, bei dem „Sie Ihre eigenen nicht freigeben können“; und für den Zugriff von Claude Tag mit seinen Labels „Geerbt von“. Anweisungen in einem Projekt haben keines dieser drei Merkmale.

„Claude Tag macht das doch schon.“ Für Slack-Channels weitgehend ja, und Abschnitt 1 sagt das auch. Drei Dinge fehlen noch. Ein Channel ist kein Projekt: Er hat keinen Ordner, keinen Schlüssel, keinen Lebenszyklus, und „ein Channel kann nicht auf ein Projekt zeigen“. Der Baum hat drei feste Ebenen, sodass eine Firma mit Geschäftsbereichen und Hunderten Aufträgen zwei ihrer Ebenen in Channel-Namen plattmachen muss. Und die Dokumentation beschreibt keine Prüfung auf Konflikte beim Schreiben einer Anweisung; die Scopes werden zusammengefügt und dem Modell bleibt es überlassen, sie in Einklang zu bringen. Wenn überhaupt, ist Claude Tag der stärkste Beweis für das Design dieses Artikels: Dasselbe Unternehmen entschied sich für Vererbung, scope-gebundene Credentials und ein Herkunftslabel, als es für Teams baute.

„Hierarchien erhöhen die Komplexität.“ Nur, wenn ihre Tiefe unbegrenzt ist. Microsofts eigene Empfehlung für Verwaltungsgruppen lautet: „nicht mehr als drei bis vier Ebenen“. Dieses Modell legt vier regeltragende Ebenen fest, und Gruppierungsordner wie Serie und Jahr tragen überhaupt keine Regeln.

„Vererbung ist ein Sicherheitsrisiko.“ Das stimmt, wenn Zugriff unbedacht vererbt wird. Die Cloud-Antwort greift: Ein Allow muss auf jeder Ebene existieren, ein Deny irgendwo gewinnt immer, Claude handelt als Nutzer geschnitten mit dem Knoten, und Claudes eigene Regeländerungen werden zu Vorschlägen.

„Mehr Ebenen kosten mehr Tokens.“ Abschnitt 3.2 hat in Claude Code das Gegenteil gemessen: 20 % weniger Anweisungs-Tokens als Kaskade, 34 % weniger kompiliert, verglichen mit flachen Kopien. Jede zusätzliche Datei bringt etwas Overhead mit sich, daher schlägt Kompilieren das Kaskadieren. Typisierte Aufgaben werfen ungenutzte Vorlagen weg, und kompilierte Präfixe sind projektübergreifend byte-identisch, sodass Prompt-Caching sie wiederverwenden kann. Über die Claude API sind Caches pro Workspace isoliert, daher bildet ein Workspace pro Organisation die Wurzel des Baums ab. Claude Code bietet das heute nicht: Sein Cache ist auf einen Rechner und ein Verzeichnis beschränkt.

„Teams können ihre Projekte einfach selbst pflegen.“ Das ist der heutige Workaround, und der Prototyp in Abschnitt 5 hat gemessen, was dabei herauskommt: zwei von sechs eingefügten Kopien waren in einer kleinen Demo veraltet.

5. Es läuft heute: eine Referenzimplementierung

Um zu zeigen, dass das Modell baubar und nicht nur diskutierbar ist, habe ich Worktree entwickelt – eine kleine Desktop-App (Node und Electron, 24 bestandene Tests unter Windows und Linux), aufgebaut wie Claude Desktop. Das Video oben zeigt einen echten Lauf, nur dort gekürzt, wo Claude arbeitete. Es ist eine separate App, die Claude Code von außen steuert, kein Mod. Sie ruft kein eigenes Modell auf. Jeder Chat nutzt das bereits auf dem Rechner installierte Claude Code (claude -p), mit dem Login, das Claude Code gerade hat: ein Claude-Abo oder ein API-Key. Ich habe es mit einer erfundenen Firma mit drei Geschäftsbereichen und sechs Projekten getestet. Wenn jemand eine Nachricht sendet:

• Genehmigen. Die handelnde Person braucht eine Gewährung am Projekt oder darüber, und das Projekt muss offen sein. Ein Admin ohne Gewährung im Bereich wurde gestoppt, bevor Claude startete.

• Prüfen. Die Prüfung beim Schreiben läuft zuerst. Die SI-Regel aus Abschnitt 3.4 wird als Konflikt mit einer erzwungenen Firmenregel abgelehnt und erreicht daher nie eine CLAUDE.md.

• Mounten. Der Baum wird als je eine CLAUDE.md pro Ebene in die echten Projektordner geschrieben (Organisation am Storage-Root, dann Bereich, dann Projekt), und die eigene Kaskade von Claude Code lädt sie. Ein kompilierter Modus schreibt stattdessen eine Datei pro Projekt. Dateien ohne den Marker der App werden nie überschrieben.

• Ausführen. Die Aufgabenvorlage geht in --append-system-prompt-file. Was Claude tun darf, wird von Claude Code erzwungen, nicht von CLAUDE.md: --allowedTools ist die Rolle der Person geschnitten mit der Policy jeder Ebene, Schreibvorgänge sind auf den Projektordner beschränkt, und --permission-mode dontAsk lehnt alles andere ab. In echten Läufen wurde eine Websuche abgelehnt, weil die Policy des Bereichs kein Web erlaubt, und ein Schreibvorgang außerhalb des Projektordners wurde verweigert und protokolliert.

• Loggen und prüfen. Jede Antwort wird mit der Person, dem Knoten, jedem Regel-Tag, den von Claude zitierten Regeln sowie den von Claude Code gemeldeten Input-, Cache- und Output-Tokens protokolliert. Ein Prüfer, der die Antwort nicht geschrieben hat, nimmt sie ab oder gibt sie zurück. Ein echter Lauf für einen Dichtebericht in der Demo dauerte etwa 30 Sekunden; über drei Läufe meldete Claude Code 0,08–0,22 $ pro Antwort zu Listenpreisen. Claude nannte die angewandten Regeln, markierte Ergebnisse nahe der Akzeptanzgrenze und ließ die Felder des Ingenieurs leer.

• Drift. Jede eingebundene CLAUDE.md wird mit dem Baum verglichen und manuelle Bearbeitungen werden markiert. Ein früherer Kommandozeilen-Prototyp führte denselben Vergleich mit Kopien durch, die in flache Projekte eingefügt wurden, und fand zwei von sechs veraltet: eine noch auf R-07 v3, und eine, bei der eine Regel von Hand gelöscht worden war.

Drei Erkenntnisse aus dem Bau, die für jeden relevant sind, der Anweisungen in Claude Code staffelt:

1. Ihre persönlichen Anweisungen sickern in die Läufe der Organisation durch. Standardmäßig lud jeder Lauf auch meine persönliche ~/.claude/CLAUDE.md, Regeln, Agents und MCP-Server. Die App schließt sie nun über die Einstellung claudeMdExcludes plus --strict-mcp-config aus. Auf meinem Rechner reduzierte das den Kontext eines Laufs von 29,6 k auf 21,4 k Tokens. Die naheliegende Alternative, --setting-sources project,local, tat in Claude Code 2.1.284 unter Windows das Gegenteil von dem, was nötig war: Sie behielt die persönliche Datei und verwarf die CLAUDE.md-Dateien der übergeordneten Ordner, die Organisation und Bereich tragen.

1. Auch die Mods einer Person sickern ein. Mods kamen einen Tag nach Fertigstellung der App, also habe ich es getestet. Ich installierte einen Mod mit einem Hook in meinem eigenen Benutzer-Scope, der jedem Prompt eine Zeile hinzufügt. Er erreichte die Läufe der App: Die drei Regeln der Organisation wurden geladen, ebenso meine persönliche Zeile, und die Antwort folgte ihr. Das Hinzufügen von disableAllHooks zu den Einstellungen des Laufs hielt ihn draußen und ließ die drei Ebenen der CLAUDE.md intakt; die App tut das nun. --safe-mode ist kein Ersatz: Es entfernte den Mod und gleich die gesamte CLAUDE.md-Kaskade mit. Laut Dokumentation lässt disableAllHooks in den eigenen Einstellungen einer Person das laufen, was die Organisation verwaltet.

1. CLAUDE.md ist Kontext, Durchsetzung ist Konfiguration. Anthropics Dokumentation sagt es klar: „Einstellungsregeln werden vom Client erzwungen, unabhängig davon, was Claude zu tun beschließt. CLAUDE.md-Anweisungen prägen Claudes Verhalten, sind aber keine harte Durchsetzungsebene.“ Die App verlässt sich darauf. Alles, was eine Regel garantieren muss, wird auf Tool-Berechtigungen abgebildet; alles in CLAUDE.md ist eine Leitlinie mit einem Tag.

Es funktioniert mit dem heutigen Claude Code, und der kompilierte Text lässt sich in einen Chat oder in die Anweisungen eines Cowork-Projekts auf jedem Tarif einfügen. Eine Abhängigkeit ist allerdings mit Ablaufdatum versehen: Die App verlässt sich darauf, dass claude -p CLAUDE.md-Dateien lädt, und Anthropics Dokumentation sagt, dass --bare, welches sie überspringt, „in einer zukünftigen Version zum Standard für -p wird“. Sobald das passiert, muss die App den Baum anders übergeben; der kompilierte Modus und --append-system-prompt-file können das bereits. Es ist eine funktionierende Spezifikation für die native Version, keine Sicherheitsgrenze: „Handeln als“ ist ein Demo-Schalter, kein Login.

6. Ein Weg von dem, was bereits ausgeliefert ist

Jetzt in Claude Code. Seit dem 1. Oktober kann der Baum als Mod ausgeliefert werden: Die Regeln des Knotens werden in einen Abschnitt des System-Prompts kompiliert, Tool-Aufrufe, die die Richtlinie des Knotens verbietet, werden abgelehnt und die effektiven Anweisungen lassen sich in einem Bereich anzeigen. Eine Organisation kann diesen Mod vor allem ausführen lassen, was eine Person installiert. Ich habe das nicht gebaut; es ist der erste Punkt auf der Roadmap der Referenzimplementierung. Es würde Claude Code abdecken und möglicherweise auch Cowork-Sessions auf dem Rechner des Nutzers, die auf derselben Engine laufen. Den Chat würde es nicht abdecken.

Die 30-Tage-Version, für Chat und Cowork. Anthropic hat alle Bausteine dafür. Ein Projekt könnte ein übergeordnetes Projekt benennen, dessen Anweisungen es erbt – so wie ein Slack-Channel in Claude Tag seine Vorgaben vom Workspace erbt. Beide werden der Reihe nach kompiliert, jede Regel erhält ein Tag, und neben dem bestehenden „Effektive Rolle anzeigen“ kommt ein Panel „Effektive Anweisungen anzeigen“. Allein das gibt jedem Arbeitsbereich einen zentralen Ort für seine Regeln.

Danach ist jeder weitere Schritt für sich genommen nützlich, angefangen bei dem, was Team-Tarifen hilft:

1. Knoten pro Arbeitsbereich und Bereitstellung per Schlüsselmuster, wobei die CLAUDE.md-Semantik wiederverwendet wird, die im Code bereits funktioniert. In Claude Code selbst bildet der Abgleichsschritt eine Ebene für eine Gruppe zwischen den Mods der Organisation und denen einer Person sowie gruppenbezogene verwaltete Einstellungen.

1. Aufgabentypen als Skills, die auf einen Arbeitsbereich beschränkt sind, inklusive Akzeptanzkriterien.

1. Eine Konfliktprüfung beim Schreiben, damit Widersprüche vom Baum abgelehnt und nicht vom Modell entschieden werden.

1. Berechtigungen (Grants) auf Knoten, die im Team-Tarif ohne Gruppen funktionieren und die benutzerdefinierten Rollen von Enterprise erweitern.

1. Branchengebundene Connector-Identitäten für Projekte, so wie Claude Tag bereits ein Dienstkonto an einen Slack-Channel bindet.

1. Eine knotenbasierte Abrechnung, die am Projekt hängt, wie Claude Tag sie bereits pro Channel ausweist; dazu ein veröffentlichtes Wochenlimit in einer definierten Einheit und eine Energieausweisung pro Aufgabe.

7. Einschränkungen

• Abdeckung. Am 1. Oktober 2026 wurden die vollständigen Seitenverzeichnisse von code.claude.com/docs und claude.com/docs nach Titeln gesichtet (466 Seiten) und rund 150 Seiten gelesen, ergänzt um die hier zitierten Help-Center-Artikel. Frühere Versionen dieses Artikels haben Claude Tag komplett übersehen; diese hier übersieht vielleicht etwas anderes. Claude for Government und Claude Desktop bei Drittanbietern werden erwähnt, aber nicht analysiert.

• Plattformfunktionen ändern sich monatlich, und eine hat sich während der Arbeit an diesem Text geändert. Jede Produktaussage hier ist auf den Zeitraum 29. September bis 1. Oktober 2026 datiert und sollte vor einer Verwendung noch einmal geprüft werden. Mods sind einen Tag alt; ich habe ihre Dokumentation gelesen und einen Fall getestet, sie aber nicht produktiv eingesetzt.

• Die gemessenen Zahlen in den Abschnitten 3.1–3.4 stammen aus den eigenen Nutzungsberichten von Claude Code, in zwei Durchläufen: Claude Code 2.1.286 am 30.09.2026 und 2.1.287 am 01.10.2026, beide mit Claude Sonnet 5.5. Das Skript, beide Durchläufe und jede Antwort liegen beim Autor und sind auf Anfrage verfügbar. Sie enthalten den eigenen Prompt von Claude Code (rund 30.200 Token), den claude.ai und Cowork nicht nutzen, und sie decken ein Modell, ein Demo-Projekt und eine Frage ab. Die Stichproben sind klein: zehn Antworten pro Bedingung für die Antwortlänge, zwanzig pro Bedingung für den Konflikttest. Die Verhältnisse der Antwortlängen verschoben sich zwischen den beiden Durchläufen (Abschnitt 3.3); zwei Durchläufe im Abstand von einem Tag unterscheiden sich zudem in der Claude-Code-Version, und ich kann das nicht vom Zufall trennen.

• Laufzeit, Kosten und Kontextgrößen in Abschnitt 5 stammen aus dem eigenen Antwortprotokoll der App für drei Demo-Durchläufe und einen manuellen Isolationstest – also aus den Aufzeichnungen des Autors.

• Die Konfliktantworten wurden vom Autor unblind codiert, indem jede Antwort gelesen wurde (Einheiten angegeben; ob die Antwort nannte, welche Regel gewann und warum; ob sie nachfragte). Alle vierzig sind auf Anfrage zur Neucodierung verfügbar. Der Test nutzte eine Formulierung von „enforced“; andere Formulierungen, Modelle und Regelpaare können sich anders verhalten.

• Der Mod-Test in Abschnitt 5 umfasst einen Mod mit einem Hook, auf einem Linux-Rechner, mit Claude Haiku, angemeldet über ein Abo und ohne verwaltete Einstellungen. Ich habe keinen Policy-Mod einer Organisation getestet, die eingebaute Schutzfunktion bei einem Team- oder Enterprise-Login oder die Desktop-App.

• Das Kostenmodell in Abschnitt 3.2 ist eine Simulation eines Beispielunternehmens, keine gemessene Abrechnung. Es berücksichtigt nur Instruction-Token; Gesprächsverlauf, Output und Thinking machen echte Rechnungen meist aus. Seine Tokengrößen nutzen Anthropics öffentlichen Legacy-Tokenizer × 1,30; in der Messung lud Claude Code 21–26 % mehr als diese Schätzung, weshalb die Dollar-Beträge zu niedrig ausfallen. Die Prozentangaben sind Verhältnisse und bleiben gültig. Session-Muster und Cache-Sharing sind Annahmen.

• Ob Chat-Nutzung auf Enterprise API-Cache-Preise erhält und ob Caches auf claude.ai nutzerübergreifend geteilt werden, ist nicht dokumentiert. Cowork führt seine Sessions auf Claude Code aus, und Plugin-Hooks laden dort, aber die Mods-Seiten listen Cowork nicht auf und ich habe es nicht getestet; am 1. Oktober bündelte die Desktop-App noch Claude Code 2.1.286, eine Version bevor Mods freigeschaltet wurden. Eine verwaltete Richtlinie des Geräts erreicht Cowork-Sessions auf dem Rechner des Nutzers, sofern die Organisation sie nicht in einer vollständigen VM-Sandbox ausführt. Zwei Seiten widersprechen sich darin, ob die eigenen ~/.claude-Dateien einer Person Cowork erreichen, daher trifft dieser Artikel dazu keine Aussage. Ich habe ebenfalls nicht getestet, ob CLAUDE.md-Dateien in übergeordneten Ordnern in einer Cowork-Session laden; falls ja, würde der gemountete Baum der Referenzimplementierung Cowork auf dem Rechner des Nutzers schon heute erreichen. Bei Pro und Max schließt sich dieses Fenster am 6. Oktober 2026, wenn neue Cowork-Aufgaben in die Cloud wechseln.

• Motive sind abgeleitet. Anthropic hat öffentlich nicht erklärt, warum Claude Chat und Cowork flach aufgebaut sind.

• Der Code und die Rohdaten werden mit diesem Artikel nicht veröffentlicht. Leser können die Messungen allein aus dem Artikel nicht reproduzieren; das Video zeigt, dass die App funktioniert, nicht wie sie gebaut ist.

• Die Referenzimplementierung läuft auf einem fiktiven Unternehmen. Sie ist nicht in claude.ai oder Cowork integriert, und „acting as“ ist ein Demo-Schalter, kein Login. Berechtigungen werden durch die Tool-Listen von Claude Code durchgesetzt, nicht durch die App. Die Isolation deaktiviert für den Lauf die eigenen Hooks und Mods einer Person; in Claude Code eingebaute Mods laufen weiter, und die Namen persönlicher Agents können weiterhin im Kontext auftauchen. Die App setzt darauf, dass claude -p CLAUDE.md lädt, was laut Anthropic künftig nicht mehr Standard sein wird. Das Leak persönlicher Dateien und das --setting-sources-Ergebnis wurden unter Windows getestet; die Messungen und der Mod-Test liefen unter Linux.

Quellen

• Anthropic, Organisationsanweisungen festlegen

• Anthropic, Rollen und Berechtigungen

• Anthropic, Was ist der Team-Tarif? · Tarife und Preise

• Anthropic, Benutzerdefinierte Rollen in Enterprise-Tarifen verwalten

• Anthropic, Aufgaben mit Projekten in Claude Cowork organisieren

• Anthropic, Google Workspace Connectors verwenden

• Anthropic, Gruppen und Gruppenausgabenlimits in Enterprise-Tarifen verwalten

• Anthropic, Was sind Projekte? (neue Version von Projekten, Beta)

• Anthropic, Erste Schritte mit Claude Cowork(globale und Ordner-Anweisungen)

• Anthropic, Wie sich Claude dein Projekt merkt (CLAUDE.md) · Alle Einstellungen (claudeMdExcludes, disableAllHooks)

• Anthropic, Claude Code mit Mods anpassen (1. Oktober 2026) · Mods-Übersicht · Mods für deine Organisation verwalten · Mit einem Mod auf Ereignisse reagieren · Mods-Referenz

• Anthropic, Claude Tag: Was ist Claude Tag? · Channelbezogenen Zugriff konfigurieren · Claude Tag anpassen · Wie Agent-Identität funktioniert · Audit · Ausgabenlimit festlegen

• Anthropic, Projekte in Claude Code (Beta der neuen Projekte) · Projekte in Cowork · Wie Claude Code Prompt-Caching nutzt · Claude Code programmgesteuert ausführen (--bare) · Claude Code erweitern · Projektsichtbarkeit und Freigabe verwalten · Connectors verwenden · MCP-Connectors für deine gesamte Organisation autorisieren · Skills bereitstellen und verwalten

• Anthropic, Serververwaltete Einstellungen konfigurieren (keine gruppenbezogene Konfiguration) · Plugins für deine Organisation verwalten (Plugin-Verfügbarkeit nach Gruppe auf Enterprise) · Plugin-Funktionsunterstützung plattformübergreifend (Hooks werden im Chat ignoriert, in Cowork geladen) · Verwaltete Einstellungen bereitstellen (Cowork führt seine Sessions auf Claude Code aus)

• Anthropic, Preise (Sonnet 5.5 Tarife, Hinweis zum Tokenizer) · Prompt-Caching (Caches pro Organisation und pro Workspace auf der API isoliert)

• Anthropic, @anthropic-ai/tokenizer(öffentlicher Tokenizer, der für die Zählungen verwendet wurde)

• Microsoft, Verwaltungsgruppen · Design von Verwaltungsgruppen für Landing Zones

• AWS, SCP-Auswertung · Google Cloud, Hierarchie-Auswertung

• Microsoft, Verarbeitung von Gruppenrichtlinien · Detaillierte SharePoint-Berechtigungen

• FinOps Foundation, Token-Ökonomie

• Jaroslawicz et al., Wie viele Anweisungen können LLMs gleichzeitig befolgen? (IFScale)

• Firefly, State of IaC Studie 2026

• MCP, Autorisierungsspezifikation, Version 2026-07-28

• GitHub, anthropics/claude-code Issues #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), „A City is Not a Tree“, Architectural Forum; Simon, H. (1962), „The Architecture of Complexity“, Proc. Am. Phil. Soc.106(6)

• Referenzimplementierung und Daten: Die Worktree-App, ihre Tests, das Messskript, beide Ergebnis-Durchläufe und jede Antwort liegen beim Autor und sind auf Anfrage verfügbar.