I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Kernpunkte

1. Datum / Quelle. 12. August 2026, LinkedIn Pulse, Newsletter Growth Marketing Fit, ~2.500 Wörter. System gebaut in Claude für ein Marketingteam von ~60 Personen.
2. Kern-Framing. „I thought I was building a content machine. I was building a trust machine, and I didn't know it, so I spent my initial effort in exactly the wrong place." ### Das nackte „pass" verbieten Ein Prüfer ist ein Closed-World-System: Er kann nur über das urteilen, was ihm vorliegt. Steht er vor einer Behauptung, die keine seiner Quellen abdeckt, findet er keinen Widerspruch und liefert ein positives Urteil, das von einer echten Prüfung nicht zu unterscheiden ist. Die Lösung ist eine Formatvorgabe: | Der Bericht muss angeben | Warum | |---|---| | Wie viele Behauptungen geprüft wurden | Nenner: ohne ihn bedeutet ein „OK" nichts | | Wie viele tatsächlich einer Quelle zugeordnet werden konnten | das ist die wahre Abdeckungsrate, immer niedriger | | Welche außerhalb seiner Zuständigkeit lagen | sonst überschreitet der Prüfer seine Kompetenz, und das Schweigen zu anderen Behauptungen wird als Zustimmung gewertet | | Welche keiner Quelle im System zugeordnet sind | das ist das eigentliche Risikoregister der Organisation | „I can't verify this" muss ein vollwertiges Ergebnis sein, gleichrangig mit „pass" und „fail". Das symmetrische Antipattern ist gefährlicher als gar keine Prüfung: „a good review that's worthless is far worse than no review, because it launders the output" – irgendwo weiter unten in der Kette sieht jemand reviewed: pass und schaut nicht mehr genauer hin. Querverweis [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### Die Prüfung, die eine Verifikation pro Asset nicht leisten kann Zwei Assets derselben Kampagne können jedes für sich korrekt sein, jedes auf eine reale Quelle rückführbar, jedes validiert – und sich dennoch widersprechen. Die Prüfung gegen die Truth-Schicht und die Prüfung von Assets gegeneinander sind zwei verschiedene Prüfungen; die erste kann die zweite nicht leisten. Diagnose des Autors: „if you run multi-asset campaigns and only verify one asset at a time, you have this bug right now." Übertragung außerhalb des Marketings: ein PR, der drei Dateien betrifft, ein im Batch generierter Satz von Spezifikationen, ein Dokument und der zugehörige Code, gemeinsam erzeugt. Cross-Konsistenz ist eine Prüfung auf Bundle-Ebene, niemals eine Summe von Einzelprüfungen. ### Die Truth-Schicht Geschilderter Fehler: Produktfakten lebten innerhalb des Skills, der die Artikel schrieb, dann musste dieselbe Tatsache im E-Mail-Skill, im Battlecard, auf der Webseite existieren. „Within a few weeks I had four slightly different versions of our launch date in four different files, and the drift was invisible because each file was individually plausible." Regel: „a document that states facts and a document that produces content are two different documents, with two different owners", jedes versioniert und datiert. Nichts, was Content produziert, darf einen Fakt enthalten – es muss danach fragen. Nutzen: Ändert sich ein Fakt, ändert man ihn einmal, und am nächsten Tag sind alle 35 Skills korrekt; wird eine Behauptung angezweifelt, gibt es nur eine Stelle, an der man nachschauen muss. Warum niemand sie baut: „You cannot demo a truth layer. You can only demo what it prevents, which is nothing visible." Vorgeschlagene Übung: die letzten fünf produzierten Assets öffnen, jede faktische Behauptung markieren, für jede das eine Dokument benennen, dem sie gehört – „the ones you can't assign an owner to are your real risk register." Erweitert [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Zwei Lektionen über Skills 1. Der Output-Vertrag muss paranoid gegenüber Mehrdeutigkeit sein. Wochenlang schrieb der Skill „blog post" Beschreibungen von Artikeln – Abschnittsüberschriften, gefolgt von einem Satz, der erklärte, was der Abschnitt behandeln würde, „every single time" – und bestand jede Prüfung, weil die Struktur makellos war. Ursache: eine mehrdeutige Zeile im Template („the post, under the flavour's own section headers"), die sich vernünftigerweise als Anfrage nach einer Gliederung lesen ließ. Organisatorisches Detail, wichtiger als der Bug selbst: Niemand meldete es, „people assume the tool is right and they're using it wrong." 2. Die wichtigste Aufgabe eines Skills ist zu beschreiben, wofür er nicht gedacht ist. Ab etwa dreißig Skills ist das Problem nicht mehr Qualität, sondern wird zum Routing: Zwei Skills, die beide plausibel „write me something for sales" bearbeiten könnten, konkurrieren um jede Anfrage, und der willkürliche Gewinner produziert das falsche Format. Die Hälfte jeder Beschreibung wurde zu einer expliziten Abgrenzung. Vergleich mit [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Vom Prompt zur Verrohrung Stilregeln verboten Gedankenstriche, jeder Prompt sagte das, Tester fanden sie wochenlang trotzdem: „I kept repeating the rule louder, which is a probabilistic fix to a problem whose deterministic solution was right there." Lösung: eine einzige output-seitige Funktion, die sie entfernt. Verallgemeinerbare Heuristik: „if you catch yourself repeating an instruction, that's the signal to pull it out of the prompt and put it in the plumbing", mit ihrem Korollar – „asking nicely is not a control." ### Der stille Fehler Eine Konstante, die ein unsichtbares Markierungszeichen halten sollte, war zu einem leeren String geleert worden. Kein sichtbarer Diff, kein Fehler. Weiter unten in der Kette begann ein Bereinigungsschritt, jede Ziffer in jedem Prompt zu erfassen und zu entfernen: « 7.1% across 6,000+ orgs, 2500 words » erreichte das Modell als « .% across ,+ orgs, words ». Jede Statistik, jedes Datum, jede Wortzahl und jede Abschnittsnummer wurde stillschweigend entfernt, über eine unbekannte Anzahl von Releases hinweg. Das war der eigentliche Grund, warum zitierte Zahlen immer wieder falsch herauskamen – „and I'd spent weeks blaming the model's tendency to make up numbers. It was making them up because I'd deleted them." Prinzip: „Traditional software crashes when it breaks. These systems keep going, confidently, at reduced quality, and produce something that looks correct." Zwei Korrekturen: die Pipeline testen, nicht nur den Output – ein Test, dessen einzige Aufgabe es ist sicherzustellen, dass Zahlen einen Hin-und-Rückweg durch die Prompt-Zusammenstellung überstehen; und sich daran erinnern, dass die eigene Validierung dieselben Lücken hat wie das System – ein auf 500 Zeichen begrenztes Feld blieb über zwei Releases hinweg bei 688 Zeichen, weil das Skript jedes andere Limit prüfte außer dieses eine. Diagnoseregel: Bevor man einem Modell vorwirft, eine Zahl erfunden zu haben, prüfen, ob die Zahl es überhaupt erreicht hat. ### Schicht 4, interne Verteilung „This is where most internal AI projects die quietly. Not from technical failure. From being technically excellent and used by four people." Der Autor hatte zunächst für sich selbst gebaut – ein Plugin, das Vertrautheit mit der Kommandozeile voraussetzte, was auf sechs von sechzig Personen zutraf. Lösung: dasselbe System zweimal gebaut, gleiches Wissen und gleiche Prüfungen, zwei Zugangspunkte – ein Plugin für Builder, eine Browseranwendung für alle anderen (Katalog, drei Felder, ein Entwurf mit seinen Prüfungen daneben als Schaltflächen). Der feinste Punkt des Abschnitts: Adoption folgt Vertrauen, nicht Fähigkeit. Das Tool wurde stärker genutzt, sobald der Output begann zuzugeben, wobei er sich unsicher war – „A draft that flags \"this customer example is illustrative, find a real one before publishing\" gets used. A draft that confidently presents a made-up customer example gets used once, embarrasses someone, and the tool dies by word of mouth." ### Dem System das Verweigern beibringen Der letzte Baustein passt ein Asset für ein anderes Marktsegment an und kennt das Segment, das das Unternehmen beschlossen hat, nicht zu verfolgen: Wird er für dieses Segment angefragt, lehnt er ab und erklärt, warum. „Same principle as the coverage statement. A system that can only say yes will confidently hand you the wrong thing forever, and you won't be able to tell \"this is right\" from \"this was the only answer available.\"" Verweigerung und das Eingeständnis von Unwissen sind dasselbe Grundprinzip: die Fähigkeit des Systems, den eigenen Kompetenzbereich abzugrenzen. ### Die drei offen gelassenen Unsicherheiten 1. Eingebettete Truth-Schicht oder Live-Abruf? „Embedded copies go stale without anyone noticing. Live fetches are slow and break when someone renames a folder." Der Autor nutzt eine Mischung und sagt, dass sie nicht durchdacht sei. 2. Hält der Verifikationsaufwand noch stand? Ein vollständig geprüftes Asset kostet „several times" so viel wie ein Rohentwurf: lohnend für öffentlichkeitswirksame Arbeit, wahrscheinlich nicht für eine interne Zusammenfassung, „and the line between the two is blurrier than my system claims." Als Erstes zu instrumentierende Governance-Variable: ein an die Asset-Kritikalität gekoppeltes Verifikationsniveau. 3. Wie viel davon überlebt die nächsten zwei Modellgenerationen? Seine als solche präsentierte Wette: Die Truth-Schicht und die Abdeckungsdisziplin überleben, weil sie „solve an organizational problem of provenance and ownership that would exist even with a perfect model." ### Der Plan „falls du Montag anfängst" 1. Die zehn Fakten notieren, die das Team am häufigsten wiederholt, jeweils mit Owner und Datum – Truth-Schicht Version null, „it takes an afternoon." 2. Den besten Prompt nehmen und jeden Fakt daraus in dieses Dokument ziehen; den Prompt danach fragen lassen. 3. Einen Verifikationsschritt bauen, der in einer frischen Session läuft, nur den Entwurf und die Quellen sieht und angeben muss, was er nicht prüfen konnte. 4. Herausfinden, was in Prompts immer wieder wiederholt wird, und es in Code verlagern. 5. Es einer nicht-technischen Person zeigen und zusehen, wie sie es ohne Hilfe nutzt. Vor allem anderen durchzuführender Baseline-Test: ein bereits ausgeliefertes Asset in einer komplett frischen Session durch die Prüfung laufen lassen, mit keinem Kontext außer dem Entwurf und den Quellen. „What comes back is your real quality baseline. It's usually humbling. Mine was."