Lesezeit: 5 Minuten

Wer die strategische Idee hinter Context Engineering verstanden hat und die praktische Anwendung im Alltag kennt, stellt sich eine dritte Frage: Wie baue ich das technisch auf — und was brauche ich dafür wirklich?

Dieser Artikel richtet sich an alle, die den nächsten Schritt gehen wollen. Keine Code-Beispiele auf Zeilenebenen, aber ein klares Bild der Architektur, der Entscheidungspunkte und der Stolperfallen.

Die Zwei-Workflow-Architektur

Das System, das hinter dem DECAID Puls steht, besteht aus zwei getrennten Automations-Workflows. Die Trennung ist bewusst und wichtig.

• Workflow 1: Dokumenten-Logistik.  Aufgabe: Meeting-Transkripte aus dem persönlichen Drive des Organisators in einen zentralen Team-Ordner kopieren. Technologie: Google Apps Script (alternativ Power Automate, n8n, Make). Trigger: Zeitbasiert, einmal pro Woche. Filter: Nur Dateien mit dem definierten Marker-Emoji, nur Dateien der letzten 7 Tage.

Dieser Workflow enthält keine KI. Er ist reine Dateiverwaltung – aber er löst ein reales Problem: Ohne ihn liegen Transkripte in individuellen Ordnern und sind für nachgelagerte Prozesse nicht erreichbar.

• Workflow 2: Intelligente Verarbeitung.  Aufgabe: Transkripte lesen, relevante Informationen extrahieren, strukturiertes Puls-Dokument erstellen. Technologie: Workflow-Engine mit KI-Agenten-Integration (im DECAID-Fall Langdock). Trigger: Zeitbasiert, nach Workflow 1. Prozess: Loop über alle neuen Dokumente → Agent-basierte Verarbeitung → Erstellung Kurzzeitgedächtnis → Update Langzeitgedächtnis.

Die Trennung in zwei Workflows hat drei Vorteile: Fehlerquellen sind isolierbar. Die Kosten von Workflow 2 (KI-Verarbeitung) werden nicht durch unnötige Dateibewegungen in die Höhe getrieben. Und die Ownership kann auf verschiedene Personen verteilt werden.

Anatomie des Basisprompts

Der Basisprompt für den verarbeitenden Agenten ist kein simpler Einzeiler. Er hat eine klare Architektur:

• Identität & Mission: „Du bist Chief of Staff AI. Deine Mission: Noise in strategische Klarheit verwandeln." Die Rolle definiert nicht nur den Ton, sondern auch die Perspektive, aus der Informationen bewertet werden.
• Unternehmensspezifischer Kontext: Kurzbeschreibung des Ökosystems, der Geschäftsbereiche, der Säulen. Der Agent muss verstehen, in welchem Unternehmen er arbeitet, sonst kann er Relevanz nicht bewerten.
• Methodische Frameworks: Referenzen auf interne Methoden und Bewertungssysteme. Beispiele: Das KI-Reflex-Prinzip (wird ein Problem manuell gelöst, das automatisiert werden sollte?), das Typ-1/Typ-2-Entscheidungs-Framework (ist eine Entscheidung reversibel oder irreversibel?), die Pilothölle-Erkennung (steckt ein Projekt im endlosen Pilotstatus fest?). Diese Referenzen verweisen auf separate Kontextdokumente mit der vollständigen Methodik.
• Output-Format: Exakte Vorgabe der Dokumentstruktur: Aktuell / Laufend / Gelernt, mit Formatierungsregeln für Headlines, Bullet Points und Detailtiefe. Ohne klares Output-Format produziert der Agent jede Woche ein anders strukturiertes Dokument, was nachgelagerte Nutzung massiv erschwert.
• Sicherheitsprotokoll: Referenz auf die interne KI-Nutzungsrichtlinie. Welche Informationen dürfen im Puls auftauchen? Klarnamen, Kundennamen, Umsätze: Was wird anonymisiert, was wird vollständig ausgelassen? Das ist der Governance-Layer, der in vielen Implementierungen fehlt – und dann spätestens beim ersten Datenschutzvorfall schmerzlich vermisst wird.

Ownership-Modell: Wer ist für was verantwortlich?

Ein häufiger Fehler: Das gesamte System wird einer Person zugeordnet. In der Praxis funktioniert ein differenziertes Ownership-Modell besser.

• Meeting-Owner  - Verantwortlich dafür, dass die richtigen Meetings markiert werden und dass die Transkripte korrekt sind. Im DECAID-Fall: die Geschäftsführung als Organizer der Weeklies. Hat bis Freitag 16 Uhr ein Korrekturfenster.
• Workflow-Owner (technisch)  - Verantwortlich für die Funktionsfähigkeit der Automationen. Wenn ein Skript bricht oder ein API-Zugang ausläuft, ist diese Person zuständig. Muss nicht dieselbe Person sein wie der Meeting-Owner.
• Wissens-Owner - Verantwortlich für die Qualität des Ergebnisses. Stimmt die Gewichtung? Fehlen relevante Informationen? Werden die richtigen Schlüsse gezogen? Diese Rolle erfordert inhaltliches Verständnis - nicht technisches.

Implementierungs-Roadmap: 4 Monate bis zum neuen Level

Für Unternehmen, die bei null starten, sieht eine realistische Timeline so aus:

• Monat 1: Vorbereitung.  Meetings identifizieren, die transkribiert werden sollen. Transkriptionstool einführen und im Team kommunizieren. Awareness schaffen: Was wird dokumentiert, was nicht? Parallel: Unternehmensprofilpage aufbauen, erste Kontextdokumente (Markt, Kunden) anlegen.
• Monat 2: Grundlage schaffen.  Nach 6–8 Wochen Transkripten ist genug Material vorhanden, um den ersten Verarbeitungslauf zu starten. Basisprompt entwickeln. Workflow aufsetzen und testen. Ergebnis: Erste Version des Puls-Dokuments.
• Monat 3: Testphase.  Workflow im kleinen Team (Pilotierung!) laufen lassen. Qualität des Outputs bewerten. Basisprompt iterieren. Output-Format anpassen. Governance-Fragen klären: Was darf rein, was nicht?
• Monat 4+: Schrittweiser Rollout.  Team für Team ausweiten. Kontextdokumente aus dem wachsenden Logbuch generieren. Agenten mit dem neuen Unternehmenswissen ausstatten. Erst jetzt wird aus dem Piloten ein System.

Die häufigsten Stolperfallen

• Zu früh skalieren.  Der Impuls, sofort das gesamte Unternehmen einzubinden, ist verständlich aber fatal. Zu viele Köche verderben den Brei. Startet klein. Ein Team. Ein Workflow. Ein Puls-Dokument.
• Governance vergessen.  Ohne klare Regeln, welche Informationen wie verarbeitet werden dürfen, ist es nur eine Frage der Zeit, bis sensible Daten dort landen, wo sie nicht hingehören. DSGVO ist kein nachgelagertes Problem, sie ist ein Designparameter.
• Kosten unterschätzen.  3,40 € pro Durchlauf klingt harmlos. Aber wenn das System wächst, mehr Teams, mehr Meetings, mehr Verarbeitungsschritte, summieren sich die Kosten. Die Verarbeitungsfrequenz ist ein bewusster Designfaktor, nicht eine technische Nebensache.
• Output nicht nutzen.  Das beste Puls-Dokument ist wertlos, wenn es niemand liest und kein Agent darauf zugreift. Der letzte Schritt: Das Ergebnis tatsächlich in die KI-Infrastruktur und die menschliche Kommunikation einzubinden, ist der wichtigste.

Der Weg zum KI-Betriebssystem

Context Engineering in Phase null, das ist der Anfang. Der nächste Schritt ist, aus diesen Grundlagen ein vollständiges KI-Betriebssystem aufzubauen: mit audience-basierten Kontextdokumenten, mit bidirektionalen Kommunikationsflows für Menschen und Maschinen, mit einem Governance-Framework, das Skalierung ermöglicht statt verhindert.

Aber jeder Schritt auf diesem Weg beginnt mit derselben Grundlage: strukturiertes, kuratiertes, aktuelles Unternehmenswissen. Ohne das ist alles andere Dekoration.