Grundlagen4 Min. Lesezeit
Was ist Context Management?
Context Management verbindet Unternehmenswissen mit seinem Zweck, seiner Geltung und seiner Verantwortung. Was das im Mittelstand bedeutet, lässt sich an einer einfachen Systemfrage zeigen.
In diesem Beitrag
Context Management bedeutet für NEXTHORIZN, die Zusammenhänge zwischen Strategie, Prozessen, Rollen, Systemen und Wissen gezielt zu erfassen und zu pflegen. Dadurch wird nachvollziehbar, welche Information für eine Aufgabe gilt, wer sie verantwortet und welche Handlung daraus folgen darf.
„Können wir dieses System abschalten?“
Stellen wir uns einen Mittelständler vor, der seine Anwendungen konsolidieren will. Auf einer Liste steht ein altes Ticketsystem. Ein neues ist bereits eingeführt. Die Lizenzkosten sind bekannt; der technische Betrieb könnte das alte System abschalten. Reicht das für die Entscheidung?
Erst die Beziehungen machen den Fall verständlich: Ein Serviceprozess nutzt das alte System noch für Gewährleistungsfälle. Eine Arbeitsanweisung verweist auf dessen Fallnummern. Der zuständige Bereich braucht den Zugriff auf offene Vorgänge. Eine Person verantwortet den fachlichen Übergang, eine andere den technischen Betrieb.
„System vorhanden“ ist eine Information. „Dieses System wird in diesem Prozessschritt für diese Fälle benötigt, bis der Übergang bestätigt ist“ beschreibt den relevanten Kontext. Er verbindet mehrere vorhandene Informationen zu einer prüfbaren Grundlage für eine Entscheidung.
Was zusammengehört
Die Strategie erklärt in unserem Beispiel, warum Anwendungen konsolidiert werden sollen. Der Prozess zeigt die betroffene Arbeit. Die Organisation benennt die verantwortlichen Rollen. Der Systembezug führt zur Anwendung. Das Wissen enthält die geltende Arbeitsanweisung. Keine dieser Perspektiven allein beantwortet die Abschaltfrage.
Eine solche Unternehmenskarte ist nur so belastbar wie die gepflegten Beziehungen. „Wird verwendet von“ sollte auf einen konkreten Prozess oder eine Rolle zeigen. Ein freier Hinweis wie „wichtig für den Service“ hilft zwar beim Suchen, lässt aber offen, wer die Verwendung beurteilen kann. Diesen Gedanken einer fortlaufend gepflegten Karte habe ich in meinem Beitrag zur nächsten Stufe der KI entwickelt.
Quelle [1]Der Kontext muss auch Zeit und Geltung berücksichtigen. „Benötigt bis zur Migration“ ist ohne prüfbare Bedingung wenig brauchbar. Besser wäre hier: Der Service bestätigt, dass die offenen Gewährleistungsfälle übernommen oder anderweitig zugänglich sind; anschließend prüft der Systemverantwortliche die Abschaltung.
Wo Wissensmanagement und technische KI-Arbeit anschließen
Wissensmanagement kümmert sich unter anderem darum, Wissen verfügbar, nutzbar und aktuell zu halten. Context Management, wie wir den Begriff verwenden, rückt die Beziehungen zu den übrigen Unternehmensbereichen in den Vordergrund. Die Aufgaben überschneiden sich. Ein Unternehmen mit gut gepflegten Zuordnungen hat bereits einen wesentlichen Teil dieser Arbeit geleistet.
Context Engineering betrachtet die technische Zusammenstellung der Informationen, mit denen ein Sprachmodell arbeitet: Welche Inhalte werden ausgewählt, in welcher Form und mit welchem verfügbaren Platz? Anthropic beschreibt Kontext entsprechend als begrenzte Ressource, deren Auswahl und Pflege die Arbeit eines Agenten beeinflussen.
Quelle [2]MCP wiederum ist ein Protokoll, über das Anwendungen Kontext und Werkzeuge bereitstellen können. Die Spezifikation legt nicht fest, wie eine KI-Anwendung den erhaltenen Kontext verwendet.
Quelle [3]Auf unser Ticketsystem übertragen: Die fachliche Arbeit klärt, warum der Service die Anwendung noch braucht. Die technische Umsetzung entscheidet, wie eine KI diese Information erhält. Ein zusätzlicher Anschluss kann den Hinweis zugänglich machen; ob der Hinweis noch stimmt, muss weiterhin jemand im Unternehmen beurteilen.
Wie viel Kontext braucht ein Mittelständler?
Für die Abschaltentscheidung wären alle Beziehungen der gesamten Organisation zu viel. Benötigt werden die betroffenen Abläufe, die offene Übergangsbedingung und die Personen, die darüber entscheiden können. Die vollständige Historie jedes Tickets muss dafür nicht in einer zweiten Plattform abgelegt werden.
Bestehende Systeme können die führenden Orte für Vorgänge und Dokumente bleiben. Die zusätzliche Arbeit besteht darin, diese Orte eindeutig zuzuordnen und Änderungen an den Beziehungen zu verfolgen. Bei sensiblen Inhalten gehört dazu auch, wer auf den Inhalt zugreifen darf; eine sichtbare Zuordnung darf keine Rechte umgehen.
Ein sinnvoller Einstieg ist deshalb eine wiederkehrende Frage, für deren Antwort heute mehrere Personen oder Ablagen nötig sind. Die Abschaltfrage wäre ein möglicher Fall. Wenn sich an einer Zuordnung weder eine Entscheidung noch ein Prüfanlass festmachen lässt, ist sie für den ersten Umfang wahrscheinlich entbehrlich.
Wie PULSE diesen Kontext organisiert
PULSE von NEXTHORIZN verbindet Strategie, Prozesse, Organisation, Systeme und versioniertes Wissen in einer gemeinsamen Umgebung. Die Verknüpfungen helfen, vom Prozess zur verantwortlichen Rolle, zur Anwendung oder zur passenden Wissensseite zu gelangen. So wird der Zusammenhang selbst Teil der gepflegten Arbeitsgrundlage.
Das schafft eine Grundlage für Menschen und für KI-Unterstützung. Es ist zugleich eine organisatorische Aufgabe: Eine veröffentlichte Wissensseite braucht fachliche Verantwortung, eine Prozesszuordnung einen klaren Zweck. PULSE kann diese Arbeit abbilden; die Entscheidung, ob das alte Ticketsystem abgeschaltet werden darf, bleibt beim verantwortlichen Unternehmen.
Der Einführungsleitfaden zeigt an einer Serviceübergabe, was in eine erste gemeinsame Arbeitssitzung gehört. Den ersten Anwendungsfall bearbeiten
Quellen & Einordnung
- Felix Drösel: Die nächste Stufe der KI braucht eine Unternehmenskarte
Grundlage des hier verwendeten Verständnisses von Unternehmenskontext; 15. August 2026. Das Systembeispiel ist hypothetisch.
- Anthropic: Effective context engineering for AI agents
Technische Einordnung der Auswahl und Verwaltung von Modellkontext; 29. September 2025.
- Model Context Protocol: Architecture overview
Offizielle Beschreibung des Protokollumfangs. Abgerufen am 9. September 2026.


