TLDR: Nein, dein KI-Agent ist nicht dumm. Er kennt dich einfach nicht. Das grösste Problem beim Einsatz von KI-Agenten in Unternehmen ist nicht das Modell, sondern die fehlende Infrastruktur darunter. Der Context Layer liefert dem Agenten genau das Wissen, das er für deine Aufgabe braucht. Er funktioniert wie ein Second Brain für Maschinen. Du kannst ihn heute schon aufbauen: mit Notion für den schnellen Einstieg, mit Obsidian für maximale Datensouveränität oder mit einer lokalen RAG-Pipeline für grosse Dokumentenmengen.

Du hast das beste Sprachmodell lizenziert. Dein Agent antwortet in Sekunden. Und trotzdem liegen die Ergebnisse neben der Spur. Nicht weil die KI inkompetent wäre. Sondern weil sie nicht weiss, wie dein Unternehmen tickt.

Andreessen Horowitz hat im März 2026 analysiert, warum Daten- und Analyse-Agenten in der Praxis scheitern: Sie können vage Fragen nicht einordnen, Business-Definitionen nicht entschlüsseln und über verschiedene Datenquellen hinweg nicht sauber arbeiten. Die Ursache ist nicht das Modell. Es ist der fehlende Kontext.

Die meisten Unternehmen versuchen, dieses Problem mit besseren Prompts zu lösen. Das greift zu kurz. Anthropic beschreibt Context Engineering als die natürliche Weiterentwicklung von Prompt Engineering. Der Unterschied: Prompt Engineering fragt, wie formuliere ich die Anweisung. Context Engineering fragt, welche Konfiguration von Informationen erzeugt zuverlässig das gewünschte Verhalten.

InfoWorld definiert Context Engineering als die Disziplin, die den Prompt als nur eine Schicht in einem grösseren System behandelt. Dieses System wählt die richtigen Informationen aus, strukturiert sie und stellt sie so bereit, dass das Sprachmodell seine Aufgabe tatsächlich erfüllen kann.

Nicht die Frage an die KI entscheidet über die Qualität der Antwort. Sondern das, was die KI über dich und dein Business weiss, wenn sie die Frage bearbeitet.

Stell dir vor, du stellst eine neue Mitarbeiterin ein. Sie ist hochqualifiziert, spricht drei Sprachen und hat einen beeindruckenden Lebenslauf. Aber sie weiss nichts über dein Unternehmen. Sie kennt weder deine Kund:innen noch deine Preise, noch wie ihr intern kommuniziert.

Genau so funktioniert ein KI-Agent ohne Context Layer: kompetent, aber ahnungslos.

Dazu kommt ein technisches Problem, das Fachleute als Context Rot bezeichnen. Das Gedächtnis einer KI, das sogenannte Context Window, ist begrenzt. Wenn du einfach immer mehr Daten hineinstopfst, wird die Aufmerksamkeit des Modells zu dünn verteilt. Jeder Token kann auf jeden anderen Token zugreifen, was bei wachsender Menge zu einer exponentiellen Zunahme der Beziehungen führt. Ab einem gewissen Punkt sinkt die Qualität der Antworten, obwohl du mehr Information bereitstellst.

Die Konsequenz: Mehr Daten reinzuwerfen ist keine Lösung. Es braucht einen intelligenten Filter. Und genau das ist die Aufgabe des Context Layers.

Um zu verstehen, was ein Context Layer tut, hilft eine Analogie:

Der Agent ist der Fahrer. Er hat die Absicht, die Fähigkeiten und führt Aktionen aus. Er kann Aufgaben in Teilschritte zerlegen, externe Werkzeuge nutzen und basierend auf Zwischenergebnissen den nächsten Schritt wählen.

Das Model Context Protocol (MCP) sind die Verkehrsregeln. MCP ist ein offener Standard, der von Anthropic entwickelt und inzwischen von OpenAI, Google und anderen übernommen wurde. Er standardisiert, wie KI-Modelle mit Datenquellen und Werkzeugen kommunizieren.

Ursprünglich im November 2024 von Anthropic geschaffen, wurde MCP im Dezember 2025 an die Agentic AI Foundation der Linux Foundation übergeben, mitgegründet von Block und OpenAI. Die Kommunikation läuft über JSON-RPC 2.0. Statt N mal M Custom-Integrationen brauchst du mit MCP nur noch N plus M Verbindungen.

Der Context Layer ist das Armaturenbrett. Er zeigt dem Fahrer nur die Informationen an, die er für die aktuelle Kurve braucht. Er ist nicht das Context Window selbst, sondern die Infrastruktur, die entscheidet, was ins Context Window kommt.

Write Context lässt den Agenten sein eigenes Gedächtnis schreiben. Nach jeder abgeschlossenen Aufgabe erstellt der Agent eine strukturierte Notiz: Was wurde entschieden? Was ist offen? Wohin soll es gehen?

Select Context sorgt dafür, dass nur das Relevante geladen wird. Ein CRM-Agent braucht Kundendaten, keine Produktdokumentation. RAG (Retrieval-Augmented Generation) holt per Embedding-Suche nur die passenden Abschnitte.

Compress Context verhindert, dass das Context Window überläuft. Google beschreibt in seinem ADK-Framework diesen Prozess als Context Compaction: Ein LLM fasst ältere Ereignisse über ein gleitendes Zeitfenster zusammen und schreibt das Ergebnis als neues Ereignis zurück.

Isolate Context teilt komplexe Aufgaben auf spezialisierte Sub-Agenten auf, jeder mit einem sauberen, minimalen Context Window.

-WERBUNG-

Second Brain? Dazu haben wir das KI-Update Kurse entwickelt, schau gerne mal rein:

Der Context Layer arbeitet mit drei Speicherebenen:

Working Memory umfasst den laufenden Dialog und die aktuelle Aufgabe. Sie lebt nur während einer Sitzung.

Episodic Memory speichert Zusammenfassungen vergangener Aufgaben. Was hat der Agent letzte Woche für diesen Kunden entschieden? Diese Ebene überbrückt Wochen und Monate.

Semantic Memory enthält Fakten, Dokumentationen und SOPs. Das ist das dauerhafte Unternehmenswissen.

Der Agent greift dynamisch auf alle drei Ebenen zu, je nach Aufgabe.

Das Konzept des Second Brain, geprägt von Tiago Forte, beschreibt das manuelle Vorläufermodell dieser Architektur. Du sammelst Wissen nach der PARA-Methode (Projects, Areas, Resources, Archives) und rufst es situativ ab.

Forte hat im März 2026 seine Perspektive aktualisiert: Bessere KI-Ergebnisse kommen nicht von besseren Prompts, besseren Tools oder schlaueren Modellen. Sie kommen von besserem Kontext.

Der Unterschied: Beim Second Brain organisierst du dein Wissen für dich selbst. Beim Context Layer organisierst du es so, dass deine Agenten damit arbeiten können.

Je nach Datenschutzanforderung, technischem Know-how und Teamgrösse gibt es drei praxistaugliche Wege.

Notion funktioniert gleichzeitig als Wissensbasis, Episodic Memory und MCP-Server. Das macht es für KMUs und Berater:innen zum einfachsten Einstieg.

Seit dem 24. Februar 2026 bietet Notion Custom Agents an. Diese autonomen KI-Teammitglieder arbeiten rund um die Uhr, ohne manuelles Anstossen. Du definierst eine Aufgabe, setzt einen Trigger oder Zeitplan, und der Agent erledigt die Arbeit eigenständig.

In der Beta-Phase haben Tester:innen über 21’000 Custom Agents gebaut. Notion selbst betreibt intern mehr Agenten als es Mitarbeitende hat.

Die Custom Agents verbinden sich über MCP mit externen Diensten wie Slack, Figma, HubSpot und Linear.

Konkreter Aufbau:

Schritt 1: Erstelle eine Notion-Datenbank «Knowledge Base» mit den Feldern Thema, Kategorie, letzte Aktualisierung und Zugriffsebene. Befülle sie mit SOPs, Prozessbeschreibungen und FAQs. (ca. 2 Stunden)

Schritt 2: Erstelle eine zweite Datenbank «Agent Memory» mit den Feldern Task, Datum, Entscheidungen, offene Punkte und nächster Schritt. (ca. 1 Stunde)

Schritt 3: In den Notion-Einstellungen unter Connections verbindest du Claude oder ChatGPT via MCP. (15 Minuten)

Schritt 4: Ein Make.com- oder n8n-Workflow verbindet die Teile: Trigger, Kontext lesen, verarbeiten, zurückschreiben.

Willst du diesen Weg gehen? Unter notion.ki-power.me findest du ein umfassendes Paket, das dir den Aufbau erleichtert. Strukturiert, praxisnah und sofort einsetzbar.

Für Unternehmen mit strengen Datenschutzanforderungen oder dem Wunsch nach vollständiger Kontrolle ist Obsidian die Alternative. Der Obsidian MCP Server kommuniziert über das Local REST API Plugin direkt mit deinem lokalen Vault. Er kann Dateien auflisten, Inhalte lesen, Notizen erstellen, suchen und den Knowledge Graph traversieren. Nichts davon verlässt deinen Rechner.

Wie die Architektur aussieht:

Der Agent (Claude Desktop, n8n oder ein eigenes System) verbindet sich über einen MCP Client mit dem Obsidian MCP Server. Dieser läuft lokal und kommuniziert über das Local REST API Plugin mit deinem Vault. Der Vault enthält dein gesamtes Wissen als verknüpfte Markdown-Dateien.

Konkreter Aufbau:

Schritt 1: Local REST API Plugin installieren. In Obsidian unter Settings, Community Plugins das Plugin «Local REST API» installieren und aktivieren. Es startet einen lokalen HTTP-Server auf Port 27124. Den API-Key notieren.

Schritt 2: Obsidian MCP Server installieren. Die Advanced-Version benötigt zwei Umgebungsvariablen: OBSIDIAN_API_KEY (aus dem Plugin) und OBSIDIAN_VAULT_PATH (der absolute Pfad zum Vault). Sie bietet zusätzlich Graph-Funktionen über die obsidiantools-Bibliothek, die dem Agenten erlauben, die Vault-Struktur und Verlinkungen zwischen Notizen zu verstehen.

Schritt 3: Claude Desktop verbinden. In der Konfigurationsdatei claude_desktop_config.json den MCP-Server eintragen. Nach einem Neustart kann Claude direkt in deinem Vault suchen, lesen und Notizen erstellen.

Schritt 4: Vault-Struktur für Agenten anlegen. Angelehnt an die PARA-Methode mit einer Agent-Erweiterung:

Der Agent schreibt nach jeder Session automatisch einen Memory-Eintrag in den memory-Ordner. Das ist sein Episodic Memory.

Bonus: Graph RAG in Obsidian. Das Plugin Neural Composer (LightRAG-Integration) baut automatisch einen Knowledge Graph aus deinem Vault. Es erkennt Entitäten und Beziehungen und ermöglicht hybride Suche: präzise Dateisuche und globale Graph-Queries kombiniert. Das funktioniert vollständig offline mit Ollama als lokalem Sprachmodell.

Wann Obsidian die bessere Wahl ist: Wenn du DSGVO- oder DSG-Konformität ohne Cloud-Abhängigkeit brauchst, wenn du als Einzelperson oder kleines Team arbeitest und wenn du den Knowledge Graph (Backlinks, Beziehungen zwischen Notizen) als Kontext nutzen willst.

Wenn du mehr als 5.000 Dokumente hast, mehrere Nutzer:innen gleichzeitig zugreifen oder semantische Suche (nach Bedeutung, nicht nach Stichworten) brauchst, ist eine dedizierte RAG-Pipeline der robustere Weg.

Wie die Architektur funktioniert:

Deine Dokumente (aus Obsidian, Confluence, SharePoint oder anderen Quellen) werden in Textabschnitte (Chunks) zerlegt. Ein Embedding-Modell wandelt diese Chunks in mathematische Vektoren um, die in einer Vektordatenbank gespeichert werden. Wenn der Agent eine Frage bearbeitet, wird die Frage ebenfalls in einen Vektor umgewandelt und per Cosine Similarity mit den gespeicherten Vektoren verglichen. Die relevantesten Chunks landen im Context Window des Sprachmodells.

Lokaler Stack (100% privat):

Konkreter Aufbau mit LlamaIndex:

Im ersten Schritt lädst du die Dokumente aus deinem Vault und indexierst sie mit einem lokalen Embedding-Modell. LlamaIndex übernimmt das Chunking (Aufteilung in sinnvolle Textabschnitte) und die Vektorisierung automatisch. Der Index wird lokal gespeichert.

Im zweiten Schritt erstellst du eine Query Engine, die bei jeder Anfrage die fünf relevantesten Chunks aus dem Index holt und zusammen mit der Frage an das lokale LLM übergibt.

Im dritten Schritt exponierst du die Query Engine als MCP-Tool. Damit kann jeder Agent sie über die standardisierte MCP-Schnittstelle aufrufen, statt direkt im Code verdrahtet zu sein.

Wann RAG die bessere Wahl ist: Wenn du grosse Dokumentenmengen durchsuchbar machen willst (tausende PDFs, Confluence-Seiten, Datenbank-Exporte), wenn semantische Suche nach Bedeutung wichtiger ist als Volltextsuche nach Stichworten und wenn mehrere Agenten oder Nutzer:innen gleichzeitig auf denselben Wissensbestand zugreifen.

Notion ist der schnellste Einstieg (halber Tag, kein Code), skaliert gut für Teams, bietet native Custom Agents und MCP-Integrationen, liegt aber in der Cloud. Ideal für KMUs, Berater:innen und Teams, die sofort starten wollen.

Obsidian bietet 100% lokale Datenhaltung, Agenten-Schreibzugriff, einen Knowledge Graph aus Backlinks und ist in 30 Minuten aufgesetzt. Es braucht keinen Code, skaliert aber nur bis etwa 5.000 Notizen komfortabel. Ideal für Einzelpersonen und kleine Teams mit Datenschutzanforderungen.

Lokale RAG-Pipeline skaliert auf Millionen von Dokumenten, bietet semantische Suche und ist ebenfalls 100% lokal. Sie benötigt aber 2 bis 4 Stunden Setup und Python-Kenntnisse. Der Agent kann standardmässig nur lesen, nicht zurückschreiben. Ideal für grosse Dokumentenmengen und technische Teams.

Meine Empfehlung: Starte mit Notion oder Obsidian, je nach Datenschutzbedarf. Sobald dein Dokumentenvolumen oder deine Teamgrösse wächst, ergänzt du eine dedizierte Vektordatenbank als RAG-Schicht dahinter. Die Wege schliessen sich nicht aus. Sie ergänzen sich.

Und darum bin ich nach wie vor überzeugt: Die Zukunft gehört nicht mehr dem Tippen und Klicken, sondern dem gemAInsamen arbeiten mit intelligenten Systemen.

Also wenn Du reden willst, und wenn Du mit mir zusammenarbeiten willst: melde Dich gerne www.rogerbasler.ch

Disclaimer: Dieser Artikel wurde nach meinem eigenen Wissen und dann mit Recherchen mit KI (Perplexity.Ai und Grok.com sowie Gemini.Google.com) manuell zusammengestellt und mit Deepl.com/write vereinfacht. Der Text wird dann nochmals von zwei Personen meiner Wahl gelesen und kritisch hinterfragt. Das Bild stammt von Ideogram.Ai und ist selbst erstellt. Dieser Artikel ist rein edukativ und erhebt keinen Anspruch auf Vollständigkeit. Bitte melde dich, wenn Du Ungenauigkeiten feststellst, danke.

Quellen und weitere Informationen:

Anthropic. (o.D.). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Cui, J. & Li, J. (2026, 10. März). Your data agents need context. Andreessen Horowitz. https://a16z.com/your-data-agents-need-context/

Forte, T. (2026, 27. März). Introducing the AI Second Brain. Forte Labs. https://fortelabs.com/blog/introducing-the-ai-second-brain/

Google Developers Blog. (2025, 4. Dezember). Architecting efficient context-aware multi-agent framework for production. https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/

InfoWorld. (2026, 5. Februar). What is context engineering? And why it's the new AI architecture. https://www.infoworld.com/article/4127462/what-is-context-engineering-and-why-its-the-new-ai-architecture.html

Notion. (2026, 24. Februar). Introducing Custom Agents. https://www.notion.com/blog/introducing-custom-agents

Notion. (2025, 18. September). Introducing Notion 3.0. https://www.notion.com/blog/introducing-notion-3-0

Pfundstein, M. (o.D.). MCP server that interacts with Obsidian via the Local REST API community plugin [GitHub Repository]. https://github.com/MarkusPfundstein/mcp-obsidian

StackOne. (2026, März). 120+ Agentic AI tools mapped across 11 categories. https://www.stackone.com/blog/ai-agent-tools-landscape-2026/

SurrealDB. (o.D.). The context layer. https://surrealdb.com/why/the-context-layer

ToKiDoO. (o.D.). Advanced MCP server to interact with Obsidian [GitHub Repository]. https://github.com/ToKiDoO/mcp-obsidian-advanced

Atlan. (o.D.). Enterprise context layer. https://atlan.com/know/enterprise-context-layer/

Noxus AI. (o.D.). Why context matters for enterprise AI agents. https://blog.noxus.ai/why-context-matters-for-enterprise-ai-agents/