Marketing Knowledge Base für KI aufbauen: 8 Module, klare Regeln und eine Vorlage

Warum Prompts und verstreute Dokumente scheitern

Wenn KI im Marketing enttäuscht, liegt das selten am Modell und meistens am Wissen, mit dem es arbeitet. Eine Knowledge Base für KI ist der Ort, an dem dieses Wissen einmal ordentlich aufgeschrieben steht: wer dein ICP ist, wie dein Buying Center kauft, welche Claims erlaubt sind, was dieses Quartal Priorität hat. Fehlt dieser Ort, schreibt jeder seinen eigenen Prompt, und jeder Prompt erzählt eine leicht andere Geschichte.

Was ich in Projekten immer wieder sehe: zehn Leute, zehn Prompts, zehn Versionen der Positionierung. Der ICP steckt in einem Foliensatz vom letzten Offsite, die Proof Points in einer Sales-Präsentation, die Pricing-Logik in einem Slack-Thread, die Tonalität im Kopf der Marketing-Leitung. Ein erfahrener Mensch setzt sich daraus ein Bild zusammen, ein Agent kann das nicht. Er nimmt, was im Prompt steht, und füllt den Rest mit Allgemeinwissen auf, das plausibel klingt.

Sobald KI produktiv läuft, merkst du das zuerst als Drift. Die Strategie ändert sich, die Prompts nicht: Ein Angle wird im Weekly beerdigt und lebt in sieben Prompts und zwei Automationen weiter. Dann kommen die Widersprüche. Zwei Dokumente sagen Verschiedenes über dasselbe Feature, der Agent greift zufällig zu einem davon, und niemand merkt es, bis ein Interessent nachfragt.

Am meisten nervt mich die fehlende Herkunft. Schreibt ein Agent einen falschen Claim, weißt du nicht, woher er ihn hat. Ohne Quelle gibt es keine Korrektur, und ohne Korrektur lernt das System nichts.

Mehr Geschwindigkeit löst keines dieser Probleme. Sie vervielfacht die Inkonsistenz. Output ↑. Pipeline →.

AI ohne System produziert nur schneller das Falsche.

Unten beschreibe ich, wie ich eine Marketing Knowledge Base aufbaue: welche acht Module hineingehören, wem sie gehören, wie oft sie sich ändern und welche Agenten daraus lesen. Zu jedem Modul gibt es einen ausgefüllten Beispiel-Eintrag, und zusammen ergeben die Beispiele eine Vorlage, deren Struktur du direkt übernehmen kannst. Wie die Knowledge Base im Gesamtsystem sitzt, siehst du in der Übersicht zur RevPrime^® Knowledge Base.

Was ist eine Marketing Knowledge Base für KI?

Eine Marketing Knowledge Base für KI ist eine strukturierte, versionierte Sammlung des Wissens, das Agenten brauchen, um Marketing-Arbeit im Sinne deines Geschäfts zu erledigen. Das gesamte Wissen des Unternehmens muss da nicht hinein, die Revenue-Logik reicht: an wen du verkaufst, wie diese Kunden kaufen, was du sagst und was nicht, was gerade Priorität hat und welche Regeln gelten.

Hilfreich finde ich drei Abgrenzungen:

• Kein Wiki. Ein Confluence- oder Notion-Wiki ist für Menschen geschrieben: Fließtext, Historie, Meinungen, veraltete Seiten neben aktuellen. Agenten brauchen feste Felder, einen Status pro Eintrag und genau eine gültige Version.
• Kein Brand Book. Das Brand Book ist ein Modul von acht. Wer nur die Tonalität hinterlegt, bekommt Texte, die gut klingen und am falschen Segment vorbeigehen.
• Keine Vektordatenbank. Ob Agenten Inhalte später über eine Suche abrufen oder ganz laden, ist eine technische Frage. Die Knowledge Base ist die Quelle. Wie sie gelesen wird, entscheidest du danach.

In RevPrime^® ist die Knowledge Base der Kern. Alle Agenten arbeiten aus derselben Quelle, keiner trägt eigenes Wissen mit sich, und das spürst du im Alltag an zwei Stellen sofort. Ein neuer Agent ist ab Tag eins produktiv, weil er sein Wissen nicht mitbringen muss; er liest es einfach dort. Eine Strategieänderung wiederum erreicht jeden Agenten am selben Tag, weil sie an einer einzigen Stelle passiert. Wie die Agenten selbst aufgebaut sind, beschreibt der Leitfaden zu KI-Agenten im B2B-Marketing.

Agenten verstärken, was da ist: Klarheit genauso wie Chaos. Deine Agenten werden nie besser sein als deine Knowledge Base.

Was gehört in die Knowledge Base – und was in den Prompt?

An dieser Frage scheitern die meisten Setups, weil sie nie bewusst gestellt wird. Meine Faustregel dazu ist simpel. Wenn ein Agent etwas wissen muss, um seinen Job gut zu machen, gehört es in die Knowledge Base.

Der Prompt beschreibt die Rolle, also was dieser Agent tut, in welchen Schritten, mit welchem Output-Format und aus welchen Modulen er liest. In der Knowledge Base steht das Geschäft: was wahr ist, was gilt und was entschieden wurde. Ein guter Agenten-Prompt ist deshalb überraschend kurz und enthält kaum einen Satz über dein Produkt.

Ob etwas in die Knowledge Base gehört, klärst du mit zwei Fragen: Brauchen es mehrere Agenten oder nur einer? Gilt es für Monate oder nur für diese eine Aufgabe?

Ein Warnsignal kannst du heute noch prüfen: Steht in einem deiner Prompts eine Zahl, ein Preis, ein Produktname oder ein Segment? Dann gehört dieser Satz mit hoher Wahrscheinlichkeit in die Knowledge Base. Im Prompt veraltet er still, und zuständig dafür ist niemand.

Umgekehrt gehört nicht alles in die Knowledge Base, nur weil es wichtig ist. Account-Daten, Kampagnen-Performance und Pipeline-Zahlen bleiben in CRM und Ad-Konten. Agenten lesen sie dort, wenn sie sie brauchen. Wer Live-Daten hineinkopiert, hat in ein paar Wochen die nächste veraltete Wahrheit.

Die 8 Module mit Vorlage, Teil 1: Markt und Botschaft

Acht Module haben sich bei mir für sales-led B2B SaaS und AI Companies bewährt. An der Zahl acht ist nichts Magisches. Jedes Modul beantwortet eine andere Frage, hat einen anderen Owner und ändert sich in einem anderen Rhythmus, und deshalb hältst du sie getrennt. Was gemeinsam gepflegt wird, liegt zusammen, was verschiedene Owner hat, bekommt ein eigenes Modul.

Die Zuordnung der Agenten ist ein Startpunkt, an dem du später noch drehen wirst. Wichtig ist, dass sie dokumentiert ist. Jeder Agent liest nur die Module, die er für seine Rolle braucht, das hält den Kontext schlank, und bei jeder Änderung siehst du sofort, welche Agenten betroffen sind.

Für jedes Modul folgt jetzt, wofür es da ist, plus ein ausgefüllter Beispiel-Eintrag. Alle Beispiele stammen aus einem fiktiven Unternehmen: einem Anbieter von Software für Instandhaltungsplanung, der an produzierende Mittelständler verkauft, mit einem ACV von rund 40.000 Euro. Alle Zahlen sind Beispielwerte und keine Benchmarks. Übernimm also die Struktur und schreib deine eigenen Inhalte hinein.

Jeder Eintrag hat denselben Kopf: Datei, Version, Owner, Stand, Status. Das wirkt bürokratisch, ich weiß. Nur so kann ein Agent später aber sagen, auf welcher Version seine Aussage beruht.

01 ICP & Segmente

An wen du verkaufst, und an wen nicht. Die Ausschlusskriterien sind dabei wichtiger als die Wunschliste, denn ein Agent, der nicht weiß, wen du nicht willst, verschwendet Recherche, Budget und Glaubwürdigkeit. Jedes Kriterium braucht einen Beleg aus Win/Loss-Daten. Ohne Beleg ist es eine Meinung.

Segment A (Tier 1)  Produktion, 200–2.000 MA, DACH
  Fit-Signale       eigene Instandhaltung, ≥ 3 Standorte, ERP SAP
  Beleg             Großteil der Win-Deals 2025/26 (Win/Loss-Review Q3)
Segment B (Tier 2)  Lebensmittelproduktion, 100–500 MA
  Fit-Signale       Audit-Druck (IFS), Wartungsprotokolle auf Papier
Ausschluss          < 100 MA: Sales Cycle zu lang für den ACV
                    Vertriebsniederlassungen ohne eigene Produktion
                    Kunden des Vertriebspartners P-2 (Vertragsklausel)
Status: live · nächster Review: Q1 2027

02 Buying Center

Die drei bis acht Rollen pro Deal: was sie wollen, was sie bremst, welchen Proof sie brauchen und wie sie kaufen. Leite das Modell aus gewonnenen und verlorenen Deals ab. Ein Persona-Workshop ersetzt das nicht. Wie Agenten damit Accounts recherchieren, zeige ich im Artikel zur Buying-Center-Analyse mit AI-Agenten.

Rolle          Champion in den meisten Win-Deals
Erkennbar an   Verantwortung für Anlagenverfügbarkeit, nicht am Titel
Pain           ungeplante Stillstände, Wissen in Köpfen einzelner Techniker
Einwand        „Meine Leute pflegen kein weiteres System.“
Proof          Case Study Kunststoffverarbeiter (Freigabe C-04)
Kauft über     Werksleitung (Budget), IT (Anbindung), Einkauf
Status: live · Owner: Revenue Lead

03 Message Angles

Ein Angle ist kein Slogan, sondern eine präzise Wette: 1 Angle = 1 Segment. Er beschreibt Persona, Use Case, den heutigen Workaround, deinen Edge und das Ergebnis. Jeder Angle hat einen Status (live, im Test oder retired). Ohne Status schreibt ein Agent munter mit einem Angle weiter, den du vor zwei Monaten beerdigt hast. Wie aus Angles konkrete Nachrichten werden, steht im Artikel Vom Signal zur Nachricht.

Segment      B · Lebensmittelproduktion
Persona      Qualitäts- und Instandhaltungsleitung
Use Case     Wartungsnachweise für das IFS-Audit
Workaround   Excel und Papierprotokolle, vor dem Audit nachgetragen
Edge         Nachweis pro Anlage auf Knopfdruck, lückenlos
Outcome      Audit-Vorbereitung in Stunden statt Tagen (Case C-12)
Status       im Test seit 2026-09-01 · Review am 2026-10-27

04 Prioritäten & KPIs

Die wenigen Hebel der nächsten 90 Tage, Ziele, Score-Schwellen und die SLAs zwischen Marketing und Sales. Dieses Modul sagt den Agenten, was gerade wichtig ist, und vor allem, was gerade nicht wichtig ist. Ohne Prioritäten optimiert jeder Agent sein eigenes Teilziel. Am Ende ist dann alles ein bisschen besser, und bewegt hat sich nichts.

Hebel 1     Segment A, 60 Tier-1-Accounts · Ziel: 18 SQLs
Hebel 2     Angle A-07 validieren · Go/No-Go am 2026-11-30
Gestoppt    allgemeine Webinar-Reihe, Messe-Leads ohne ICP-Fit
Schwellen   Score ≥ 70 → Sales-Handover · 50–69 → Retargeting
SLA         Sales reagiert auf einen Handover binnen 1 Werktag
KPIs        Pipeline aus Tier 1 · Sales Velocity · Zeit bis Erstgespräch

Mit diesen vier Modulen steht die Revenue-Logik, und Signal-, Content- und Paid-Agenten können damit bereits sinnvoll arbeiten. Vorausgesetzt, das, was sie sagen, stimmt auch. Darum geht es im zweiten Teil.

Die 8 Module mit Vorlage, Teil 2: Wahrheit, Regeln und Gedächtnis

Die ersten vier Module beschreiben Markt und Botschaft. Mit den nächsten vier stellst du sicher, dass die Botschaft stimmt, nach Regeln umgesetzt wird und das System aus jeder Entscheidung lernt.

05 Product Truth

Was das Produkt heute kann. Was die Roadmap verspricht, gehört nicht hierher. Hinein kommen Doku-Auszüge, Release Notes, Pricing-Logik, freigegebene Proof Points und Case Studies. Owner ist Product, und das ganz bewusst. Der Product Truth Agent gleicht Website- und Kampagnen-Copy wöchentlich mit diesem Modul ab und meldet Widersprüche als konkrete Korrekturvorschläge.

Status        verfügbar seit Release 4.8 (2026-09-15)
Darf sagen    „Wartungsaufträge auch ohne Netz erfassen und
              später synchronisieren“
Nicht sagen   „vollständig offline nutzbar“ – Berichte brauchen Netz
Pricing       in allen Paketen enthalten
Beleg         Release Notes 4.8, Produktdoku (intern)
Gültig bis    nächster Major Release

06 Brand, Claims & Legal

Tonalität, Wording-Regeln, verbotene Claims und Compliance-Vorgaben, also die Leitplanken für alles, was live geht. Hier stehen auch deine Regeln zu Kanälen und Ansprache, die du mit Datenschutz und Legal abgestimmt hast. Der QA & Brand Guard Agent prüft jeden Entwurf dagegen, bevor er bei einem Menschen landet.

Ton           klar, technisch, ohne Superlative
Anrede        du auf LinkedIn, Sie in E-Mails
Verboten      „garantiert“, „100 % ausfallsicher“, „ersetzt Techniker“
Pflicht       Kundenzitate nur mit Freigabe-ID aus dem Case-Register
Vergleiche    keine Wettbewerber namentlich in Ads
Ansprache     E-Mail-Erstkontakt nur nach Kanalregel K-03
Legal-Review  2026-07 · nächster Review 2027-01

07 Playbooks & Regeln

Routing-Regeln, Aktivierungsschwellen, Sequenzen und erlaubte Datenquellen, dazu die Routinen, die du einmal freigegeben hast. Jede Regel bekommt eine ID, damit ein Agent im Change-Log sagen kann, nach welcher Regel er gehandelt hat. Was hier als freigegebene Regel steht, darf auf Stufe L3 ohne Einzel-Go laufen; alles andere bleibt Vorschlag.

Auslöser    Opportunity angelegt ODER Antwort eines Kontakts im Account
Aktion      laufende Sequenzen im Account beenden, Owner informieren
Agent       Outreach Routing · Stufe L3 (freigegebene Regel)
Freigabe    RevOps, 2026-08-12
Grund       Doppelansprache in drei Accounts (siehe D-2026-08-09-01)
Prüfung     monatlich: Auslösungen im Change-Log

08 Entscheidungsgedächtnis

Jeder Vorschlag, jedes Go und jedes Nein, jeweils mit Grund, Vorher/Nachher und Ergebnis. Dieses Modul schreibt das System selbst, die Gründe liefern Menschen. Für mich ist es das am meisten unterschätzte Modul, denn ohne Gedächtnis schlägt dir ein Agent nächste Woche wieder vor, was du gestern abgelehnt hast.

Vorschlag   Budget Kampagne A-07 +30 %
Agent       Paid Media · Stufe L1 (Vorschlag)
Entscheid   Nein · Leadership
Grund       Angle im Test – erst nach Go/No-Go am 2026-11-30 skalieren
Folge       Regel-Kandidat: kein Budget-Ausbau für Angles im Test
Ergebnis    offen · Review im Weekly KW 45

Leg diese acht Beispiele nebeneinander, und du hast die Vorlage: acht Dateien mit festem Kopf, definierten Feldern und einem Status. Mehr braucht die erste Version nicht.

Struktur, Versionen und Freigaben: So bleibt die Knowledge Base aktuell

Die beste Modulstruktur hilft nichts, wenn die Inhalte in fünf Tools verteilt sind und niemand weiß, welche Version gilt. Vier Prinzipien halten die Knowledge Base brauchbar.

Eine Quelle der Wahrheit

Jede Information steht nur einmal. Steht das Pricing in Product Truth, steht es nicht zusätzlich im Brand-Modul und in drei Prompts, die anderen Module verweisen darauf. Das klingt banal, und trotzdem ist doppelte Pflege in der Praxis die häufigste Ursache für Widersprüche.

Dateien, Versionen, Owner

Ich lege die Knowledge Base als Markdown- und YAML-Dateien in ein Repo oder einen Workspace, der dir gehört, getrennt vom Modell. Markdown, weil Menschen es lesen und bearbeiten können, YAML für alles, was Agenten als Schwelle oder Regel auswerten. Jede Änderung bekommt Version, Owner und Datum. Mit Git ist das eingebaut, in Notion oder SharePoint braucht es Disziplin (und die lässt im Alltag erfahrungsgemäß als Erstes nach). Weil die Dateien offen sind, bleibt das System außerdem modellunabhängig.

knowledge-base/
├── 01-icp/              icp.md, ausschluss.yaml
├── 02-buying-center/    rollen.md, einwaende.md
├── 03-angles/           A-01.md … A-09.md, status.yaml
├── 04-prioritaeten/     q4-2026.md, schwellen.yaml
├── 05-product-truth/    features/, pricing.md, proof-register.md
├── 06-brand-legal/      ton.md, claims.md, kanalregeln.md
├── 07-playbooks/        routing.yaml, regeln/R-01.md … R-14.md
├── 08-entscheidungen/   decisions.log
└── CHANGELOG.md

Entscheidungsgedächtnis statt Flurfunk

Jede Ablehnung braucht einen Grund, und der Grund landet in Modul 08. Taucht derselbe Grund dreimal auf, ist er ein Kandidat für eine Regel in den Playbooks oder eine Korrektur in einem anderen Modul. So wird aus Korrekturen Wissen, und du musst nicht jede Woche dieselbe Korrektur wieder machen.

Updates nur nach Go – auch für die Knowledge Base selbst

Agenten sehen oft als Erste, dass sich etwas geändert hat: ein neues Release, ein Angle, der nicht mehr trägt, eine Schwelle, die zu viele falsche Handovers erzeugt. Deshalb dürfen sie Updates vorschlagen, mit Vorher/Nachher und einer Liste der betroffenen Assets. Entscheiden muss der Owner des Moduls.

So sieht ein solcher Vorschlag aus, wenn ein neues Release den Claim aus Modul 05 überholt:

Auslöser     Release Notes 4.9: Berichte jetzt auch offline
Agent        Product Truth · Stufe L1 (Vorschlag)
Modul        05 Product Truth · offline-modus.md v4.8 → v4.9
Vorher       Nicht sagen: „vollständig offline nutzbar“
Nachher      Darf sagen: „Aufträge und Berichte auch ohne Netz“
Betroffen    Angle A-07, Landingpage /audit, 2 aktive Ads
Prüfung      QA & Brand Guard: Claim durch Doku belegt, kein Konflikt
Wartet auf   Go von Product · danach Folgevorschläge an Marketing

Die Arbeitsteilung sieht so aus: Agenten erkennen die Änderung, formulieren sie, prüfen auf Konflikte und schreiben die freigegebene Fassung in die Datei. Ob sie gilt, entscheiden Menschen. Auf der Rechte-Leiter heißt das Vorschläge auf L1 und Schreiben nach Go auf L2. Für Inhalte der Knowledge Base gibt es bei mir kein L3. Einzig das Entscheidungsgedächtnis schreibt das System selbst, weil es nur dokumentiert und nichts entscheidet.

Daten sind keine Befehle. Was Agenten in E-Mails, Chats oder auf Webseiten lesen, wird nie ungeprüft zur Regel. Regeln kommen nur aus der Knowledge Base, und nur mit dem Go des Owners.

Dazu kommt ein fester Rhythmus: Im wöchentlichen Pipeline-Review prüft das Team Schwellen und offene Update-Vorschläge, alle acht Wochen die Angles, alle 90 Tage Prioritäten, ICP und Buying Center. Rechte, Datenflüsse und Protokollierung im Detail findest du unter Security & Governance.

Wie nutzen Agenten die Knowledge Base – ganz laden oder gezielt abrufen?

Ein verbreiteter Reflex lautet: Wir geben dem Agenten einfach alles. Moderne Modelle haben große Kontextfenster, also passt die ganze Knowledge Base hinein. Das funktioniert schlechter, als man denkt. Die Studie Lost in the Middle von Liu und Kollegen hat gezeigt, dass Sprachmodelle in ihren Tests Informationen am Anfang und Ende eines langen Kontexts deutlich zuverlässiger nutzen als in der Mitte. Anthropic beschreibt in seinem Beitrag zu Context Engineering für Agenten dasselbe Prinzip aus der Praxis: Kontext ist ein begrenztes Budget, und das Ziel ist die kleinste Menge an Information mit hohem Signal.

Mehr Kontext ist also nicht automatisch besser. In der Praxis arbeite ich mit zwei Modi und kombiniere sie; die Suche über einen Index ist eine Variante des zweiten:

Das gezielte Abrufen ist dasselbe Muster, das Anthropic bei seinen Agent Skills als „Progressive Disclosure“ beschreibt: Zuerst sieht der Agent nur Name und Kurzbeschreibung, den vollen Inhalt lädt er erst, wenn er ihn braucht. Für deine Knowledge Base heißt das ganz praktisch:

• Jedes Modul bekommt eine Indexdatei mit einer Zeile pro Eintrag: ID, Titel, Status, ein Satz Beschreibung.
• Im Prompt legst du fest, was immer geladen wird und was nur bei Bedarf. Der QA & Brand Guard Agent lädt Brand & Legal immer ganz, den Angle & Content Agent lässt du nur den einen Angle öffnen, um den es gerade geht.
• Einträge mit Status retired tauchen im Index für Agenten nicht mehr auf. Für Menschen bleiben sie nachvollziehbar.
• Jeder Output nennt seine Quelle, etwa „Claim aus Product Truth, offline-modus.md v4.8“. Bei einem Fehler siehst du dann sofort, ob der Agent falsch gelesen hat oder die Knowledge Base falsch ist.

Für die meisten Marketing-Teams reicht am Anfang eine Ordnerstruktur mit guten Indexdateien, auch wenn das unspektakulär klingt. Eine eigene Suchinfrastruktur lohnt sich erst, wenn die Bestände so groß sind, dass ein Inhaltsverzeichnis nicht mehr überschaubar ist.

Welche Kennzahlen zeigen, ob deine Knowledge Base wirkt?

Eine Knowledge Base für KI ist kein Dokumentationsprojekt, das fertig ist, wenn alle Felder ausgefüllt sind. Sie wirkt, wenn Agenten mit weniger Korrekturen bessere Arbeit liefern und Strategieänderungen schneller in der Umsetzung ankommen. Das lässt sich messen.

In den ersten Wochen ist die Korrekturquote die wichtigste Zahl. Jede wiederkehrende Korrektur zeigt dir eine Lücke in der Knowledge Base. Am Ende muss sich aber auch die Knowledge Base an Pipeline messen lassen. Aktivität ist nicht Wirkung. Pipeline ist Wirkung. Wie du den Beitrag von Marketing an der Geschwindigkeit deiner Deals festmachst, steht im Artikel Sales Velocity als Marketing-KPI.

Typische Fehler beim Aufbau einer Marketing Knowledge Base

Das Wiki migrieren statt zu entscheiden

Der häufigste Fehler ist, alle bestehenden Dokumente in die neue Struktur zu kopieren. Danach hast du dieselben Widersprüche an einem neuen Ort. Eine Knowledge Base entsteht durch Entscheidungen darüber, welches Segment drin ist, welcher Claim gilt und welcher Angle retired ist. Ein Umzug ersetzt keine davon.

Wissen zur Sicherheit doppelt in Prompts

„Damit der Agent es auch wirklich weiß“, heißt es dann, und schon steht das Pricing doch noch einmal im Prompt. Spätestens beim nächsten Preiswechsel hast du zwei Wahrheiten. Prompts verweisen auf Module, sie wiederholen sie nicht.

Module ohne Owner

Ein Modul, für das niemand zuständig ist, veraltet. Das dauert, passiert aber zuverlässig. Jedes Modul braucht einen Menschen mit Namen, der Updates freigibt und den Review-Termin hält.

Kein Status pro Eintrag

Ohne live, im Test und retired kann ein Agent nicht unterscheiden, was gilt. Beerdigte Angles und abgekündigte Features leben dann in neuen Texten weiter.

Agenten schreiben direkt in die Knowledge Base

Es ist verlockend, Agenten ihre eigene Wissensbasis pflegen zu lassen. Dann übernimmt das System aber irgendwann Inhalte aus einer E-Mail oder einer Webseite als Regel. Agenten schlagen vor, Owner entscheiden. Ausnahmen mache ich da keine.

Marketing Knowledge Base in vier Wochen aufbauen

Du brauchst kein halbes Jahr. Vier Wochen reichen für eine erste Version deiner Knowledge Base für KI, mit der zwei, drei Agenten produktiv arbeiten können. Perfekt wird sie erst im Betrieb.

Woche 1: Inventur und Owner

Sammle, was es schon gibt: Prompts, Foliendecks, Positionierungspapiere, Battlecards, Brand Guidelines, Sales-Präsentationen. Leg für jedes der acht Module einen Owner fest, entscheide, wo die Knowledge Base liegt, und leg die Ordnerstruktur mit festem Dateikopf an. Übertragen wird noch nichts. Erst schaust du, wo sich die Quellen widersprechen.

Woche 2: die Revenue-Logik (Module 01–04)

Nimm die letzten zehn bis zwanzig gewonnenen und verlorenen Deals und leite daraus ICP mit Ausschlusskriterien und das Buying Center ab. Schreib die zwei, drei Angles auf, die heute tatsächlich laufen, mit Status. Leadership legt die Hebel und Schwellen für die nächsten 90 Tage fest. Das ist die Woche mit den unbequemsten Entscheidungen und zugleich die wichtigste.

Woche 3: Wahrheit, Regeln, Gedächtnis (Module 05–08)

Product liefert die Product Truth für die Features, über die ihr im Markt sprecht. Marketing und Legal legen Claims, verbotene Formulierungen und Kanalregeln fest. RevOps dokumentiert die ersten Routing-Regeln mit ID. Das Entscheidungsgedächtnis startet als leeres Log mit festem Format.

Woche 4: Test mit Agenten

Lass zwei, drei Agenten dieselben Aufgaben mit der Knowledge Base erledigen, die bisher über Einzel-Prompts liefen. Vergleich die Ergebnisse, miss die Korrekturquote und streich das Geschäftswissen aus den Prompts. Am Ende der Woche legst du den Review-Rhythmus fest und entscheidest, welcher Agent als Nächstes dazukommt.

• Acht Module angelegt, jedes mit Owner und Review-Termin
• ICP und Buying Center aus mindestens zehn Win/Loss-Deals abgeleitet
• Jeder Angle, jedes Feature und jede Regel mit Status und Version
• Verbotene Claims und Kanalregeln mit Legal abgestimmt
• Prompts verweisen auf Module statt Wissen zu wiederholen
• Update-Vorschläge laufen nur über das Go des Owners
• Korrekturquote vor und nach der Umstellung gemessen

Meine Empfehlung

Fang nicht mit dem Agenten an. Fang mit der Knowledge Base an. Das ist die Reihenfolge, die ich in jedem Projekt einhalte, und sie ist nicht verhandelbar. Ein Agent ohne Knowledge Base ist ein schneller Praktikant ohne Einarbeitung: fleißig, selbstbewusst und regelmäßig daneben.

Ehrlich gesagt ist der schwierigste Teil nicht die Technik. Markdown-Dateien in einem Repo sind schnell angelegt. Schwierig sind die Entscheidungen, die eine Knowledge Base erzwingt: Welches Segment wollt ihr nicht? Welcher Angle ist tot? Welchen Claim darf niemand mehr verwenden? Wenn ihr euch darauf nicht einigen könnt, kann es auch kein Agent. Die meisten Marketing-Probleme sind in Wahrheit System-Probleme, und eine Knowledge Base bringt sie ans Licht.

Für den Start reicht mir Folgendes: die vier Module mit der Revenue-Logik gründlich, die anderen vier in einer ersten, groben Fassung. Lieber 80 Prozent, versioniert und mit Owner, als 100 Prozent in einem Dokument, das nie fertig wird. Den Rest erledigt der Betrieb, weil jedes Nein mit Grund die nächste Version besser macht.

Agenten machen die Arbeit. Menschen treffen die Entscheidungen. Die Knowledge Base ist der Ort, an dem diese Entscheidungen für alle Agenten gelten.

Das alles kannst du selbst bauen, mit den Vorlagen oben und einem Ordner in deinem Workspace. Wenn du es lieber mit mir aufsetzt, baue ich die Knowledge Base im Build-Pfad als Erstes, noch vor jedem Agenten. Und falls du wissen willst, wo dein Wissen heute steckt und was zuerst dran ist, schauen wir uns das im kostenlosen 30-minütigen Diagnose-Call gemeinsam an.