# Wessen Wissen gehört in den Kontext? - Author: Thomy Gölles - Published: 2026-11-06 - Language: de - URL: https://thomygoelles.com/deutsch/vier-fragen-kontext/ - Topics: AI Agents, Microsoft Graph > Teil 3 von vier Fragen, die wir stellen, bevor jemand einen Agent baut. Ein Agent ist nur so gut wie der Kontext, den er bekommt, und jedes Stück davon kommt von irgendwo und gehört irgendwem. Irgendwann haben wir uns im Team hingesetzt und gefragt, was eigentlich unser Job ist. Nicht der auf der Visitenkarte, sondern der als Leute, die diese Werkzeuge jeden Tag verwenden und anderen helfen sollen, damit besser zu arbeiten. Brutal verkürzt bleibt eine einzige Sache übrig, und die ist dieselbe, egal ob du Copilot, ChatGPT, Claude oder sonst etwas verwendest. Wir müssen dafür sorgen, dass der richtige Kontext ins Kontextfenster kommt. Daher kommt die dritte Frage aus unserer Masterclass bei [Solvion](https://www.solvion.net/), und sie ist die technischste der vier. ## Am Ende landet alles im Kontextfenster Alle diese Werkzeuge legen einen Harness zwischen dich und ein großes Sprachmodell. Über diese Schicht hab ich schon [nach den CollabDays](https://thomygoelles.com/deutsch/collabdays-belgien-2026/) und in [Cogito, Ergo Build](https://thomygoelles.com/deutsch/cogito-ergo-build/) geschrieben, und kurz gesagt hat das Modell dahinter kein Gedächtnis. Es weiß nichts über dich, deine Firma oder das Gespräch von gestern, nur das, was gerade im Kontextfenster steht. Wenn wir also die Chance auf eine gute Antwort erhöhen wollen, und gut heißt richtig und für uns brauchbar, dann besteht die Arbeit darin, so viel guten Kontext wie möglich in dieses Fenster zu bringen, damit das Modell etwas hat, womit es arbeiten kann. Das passiert auf zwei oder drei Wegen. Der erste läuft implizit, und einen großen Teil davon erledigt Copilot über Microsoft Graph und seine Connectoren für dich. Du schreibst einen Prompt, und bevor das Modell ihn zu sehen bekommt, hat das System rund um das Thema in Teams, SharePoint, OneDrive und deinen Mails nachgeschaut und dazugelegt, was es gefunden hat, beschränkt auf das, was du sehen darfst, ohne dass du dafür irgendetwas tun musst. Der zweite Weg ist organisatorisch, und da wird es unangenehm. Haben die Leute überhaupt Zugriff auf die Informationen, die sie für ihre Rolle brauchen? Liegen die dort, wo man sie findet, und sind sie aktuell? Dann gibt es noch die Systeme außerhalb von Microsoft 365, das ERP, das CRM, ob das jetzt SAP ist, Salesforce, ein Planungstool oder etwas Selbstgebautes. Kommen diese Informationen überhaupt bis ins Kontextfenster? Richtiger Kontext heißt dabei fachlich richtig und aus Sicht der Security richtig, und zwar beides gleichzeitig. ![Diagramm mit dem Titel „Jedes Stück Kontext kommt von irgendwo und gehört irgendwem“. Links drei Quellen, die Köpfe von Fachleuten, Dokumente in SharePoint, Teams und OneDrive und Systeme wie ERP, CRM, SAP, Salesforce und Eigenbau, jede mit der Markierung „Wem gehört’s?“. Sie fließen in den Harness, Copilot oder deinen Agent, wo Graph und Connectoren holen, was der User sehen darf, und von dort ins Kontextfenster, alles, was das Modell ohne Gedächtnis weiß. Darunter steht, dass man für jede Quelle aufschreiben soll, woher sie kommt, wer sie aktuell hält und wer über den Zugriff entscheidet.](https://thomygoelles.com/img/2026/10/vier-fragen-3-fluss.webp) ## Die Frage hat absichtlich zwei Lesarten „Wessen Wissen gehört in den Kontext?“ meint zwei Dinge, und mit „wessen“ sind nicht nur Menschen gemeint. Die erste Lesart fragt nach der Herkunft. Woher kommt das Wissen, wer hat es im Kopf, und in welchem Dokument oder System steht es? Ein Agent ist nur so gut wie der fachliche Kontext, den er bekommt, und der steckt zum Teil in den Köpfen von Fachleuten, zum Teil in Dokumenten und Systemen. Armin Einfalt hatte in der Session ein Beispiel, das wohl jeder schon einmal gesehen hat, einen Teams-Ordner mit einer Datei, die ungefähr „Angebot final final v2 2019“ heißt, und einen Agent, der fröhlich daraus antwortet, weil genau diese Datei am besten zum Prompt passt. Ein Agent lügt nicht, hat Armin gesagt, er ist nur ehrlich falsch. Zum Lügen bräuchte es Absicht, und das Modell nimmt einfach den besten Treffer, den man ihm hingelegt hat. Die zweite Lesart fragt nach der Zuständigkeit. Wem gehört dieses Wissen, und wer darf es freigeben? Wer hält es aktuell und entscheidet über den Zugriff, und wer haftet, wenn es falsch ist? Bei Systemwissen ist die Antwort der Owner des Systems und nicht die Person, die zufällig den Agent baut, der daraus liest. Genau diesen Punkt überspringt man gern, weil im Raum meistens die Person sitzt, die baut. Wer nur die erste Lesart beantwortet, baut Agents, die viel wissen und niemandem gehören. ## Für Unternehmenszahlen gibt es die Antwort schon Für eine Art von Wissen haben beide Lesarten oft schon eine Antwort, und die liegt nicht bei der Person, die den Agent baut. Im Oktober haben Jens Kröhnert von [ORAYLIS](https://www.oraylis.com/) und ich einen ganzen Vortrag darum gebaut, [KI entsteht zweimal](https://thomygoelles.com/deutsch/ki-entsteht-zweimal/). Jens nennt die beiden Seiten Frontend-KI und Backend-KI. Mit Frontend-KI meint er Copilot samt den Agents, die Leute im Fachbereich bauen, mit Backend-KI die Datenplattform, auf der die IT die wichtigen Zahlen aus den operativen Silos in eine einzige Version der Wahrheit geholt hat, mit Definitionen, auf die sich alle geeinigt haben, und mit Governance rundherum. ![Jens Kröhnert und Thomas Gölles auf der Bühne in einem violett beleuchteten Veranstaltungssaal während der Demo, auf der großen Leinwand die Agents, die in Microsoft 365 Copilot verfügbar sind, genau in dem Moment, in dem die Demo vom Fabric Data Agent zu Copilot wechselt.](https://thomygoelles.com/img/2026/10/four-questions-3-stage-fabric-demo.webp#center) Durch die Brille dieser Frage beantwortet die Datenplattform Herkunft und Zuständigkeit ein einziges Mal und zentral für alle. Die Kennzahl kommt von dort, und ihre Definition gehört den Leuten, die die Plattform betreiben. Schwierig wird es, wenn ein Agent diese Schicht überspringt. Mit den richtigen Berechtigungen könnte ich in ungefähr einer Stunde einen Agent bauen, der direkt auf die Quellsysteme geht, und ein Kollege würde mir zu Recht sagen, dass das meine Lösung mit meiner Interpretation der Daten ist. Machen das fünf Leute, gibt es fünf Definitionen derselben Zahl, und keine davon gehört irgendwem. Das Muster, das wir gezeigt haben, geht genau andersrum. Ein Fabric Data Agent sitzt auf den Einkaufsdaten und antwortet in normaler Sprache, und ein Agent in Microsoft 365 Copilot greift auf ihn zu, statt sich die Top-Lieferanten selbst zusammenzurechnen. Wer im Fachbereich fragt, bekommt die Antwort, und die Definition bleibt bei denen, denen sie gehört. Muss der Agent etwas zurückschreiben, erledigt das ein MCP-Server unter der Identität des Users, sodass die Änderung so nachvollziehbar ist, als hätte die Person sie selbst im System gemacht. ## Was das heißt, wenn du Agents baust Egal ob du einen Declarative Agent baust, etwas in Copilot Studio, einen Custom Engine Agent oder etwas ganz Eigenes, ich würde beide Lesarten in eine kurze Liste übersetzen, bevor die erste Wissensquelle angebunden wird. Schreib für jede Quelle auf, woher das Wissen kommt und wem es gehört, also wer es aktuell hält und wer entscheidet, wer es sehen darf. Kannst du beim Owner nichts eintragen, hast du das Problem gefunden, bevor deine User es für dich finden. Das ändert auch, wen du zum ersten Termin einlädst. Liest der Agent aus dem CRM, gehört die Person, der das CRM gehört, mit an den Tisch, weil genau sie den Anruf bekommt, wenn der Agent über einen Kunden etwas Falsches erzählt. Und damit sind wir bei der letzten Frage der Serie, wer einen Agent trägt, sobald sich Leute darauf verlassen.