Week 11 · Fase 4: Orkestreren STRETCH

Kennisbank 2.0: domein-Notebooks + agents

Mw-35 gaf je één kennisbank-agent. Kennisbank 2.0 is een architectuur van meerdere.

Tijd
28 min
Level
Level 5 🔥🔥🔥🔥🔥
Domeinen
3-6
Stappen
4
Proof-of-concept
2
  • Copilot Notebooks
  • Mind Map
  • Quick Create
Wat je leert

Van één kennisbank-agent naar een federatie van domein-experts

Op niveau 5 verschuift het werk van implementatie naar ontwerp. Een enkele kennisbank-agent werkt tot je tegen de grenzen van grounding-kwaliteit aanloopt: dertig documenten in een Notebook geeft minder scherpe antwoorden dan zes per domein. En een gebruiker die niet weet welk Notebook hij moet kiezen, gebruikt geen enkel Notebook.

De L5-sprong van deze MW is het denken op architectuur-niveau: in plaats van een grote kennisbank ontwerpen we een federatie van kleine domein-kennisbanken plus een navigatielaag die gebruikers helpt het juiste domein te vinden. Orkestratie betekent hier niet tientallen agents gelijktijdig laten draaien, maar een gelaagde structuur bouwen waarin elke laag zijn eigen verantwoordelijkheid heeft.

Drie lagen, drie verantwoordelijkheden. Laag 1: domein-Notebooks met drie tot acht scherp geselecteerde documenten per domein. Laag 2: een declarative domein-agent per Notebook die scope-scherpte afdwingt via cross-verwijzings-instructies. Laag 3: een navigatie-mind-map als entry-point voor de gebruiker die nog niet weet welk domein zijn vraag hoort.

De grondlegging is meer denken dan bouwen; het bouwen volgt. In deze MW ontwerp je de architectuur en zet je een proof-of-concept op met twee domeinen. De overige domeinen rol je in de weken erna uit met inhoudelijke experts per domein.

Voorbereiding · open als je wil checken Wat je vooraf klaar wil hebben
  • Een organisatie of team waar de kennis nu versnipperd is over meerdere bronnen (SharePoint-sites, intranet, Confluence, papieren dossier)
  • Drie tot zes logische kennis-domeinen bepaald door gebruikers-perspectief (niet organisatie-perspectief)
  • Per domein drie tot acht kern-documenten die de essentie dekken (niet alles, de essentie)
  • Microsoft 365 Copilot licentie plus Copilot Studio plus Notebooks toegang; voor Mind Map een Copilot Pages of Visio-toegang als visualisatie-surface
  • Een week om het ontwerp uit te rollen en een proof-of-concept met twee domein-Notebooks op te zetten; de overige drie tot vier domeinen volgen in de maand erna
De bouw-stappen

De architectuur in vier stappen

Vier stappen van versnipperde kennis naar een federatief kennis-ecosysteem. Stap 1 is het ontwerp: domein-grenzen bepalen vanuit gebruikers-perspectief. Stap 2 is de bouw-basis: domein-Notebooks aanmaken met kern-documenten. Stap 3 koppelt een domein-agent aan elk Notebook met cross-verwijzings-instructies. Stap 4 legt de navigatielaag en onboarding-flow als entry-point voor gebruikers.

  1. Stap 1 · Domein-grenzen bepalen

    Gebruik de domein-grenzen-vraag (prompt 1 hieronder) om drie varianten van je architectuur naast elkaar te zetten: strakke grenzen met weinig overlap, brede domeinen met meer overlap, en een entry-domein plus gespecialiseerde sub-domeinen. Kies vanuit gebruikers-perspectief, niet vanuit de organisatiestructuur. Een goede domein-grens is waar de gebruiker geen twijfel heeft bij welk Notebook zijn vraag hoort. Resultaat: een getekende domein-boom met drie tot zes domeinen, elk met naam en gebruikers-heuristiek.

  2. Stap 2 · Domein-Notebooks aanmaken

    Maak per gekozen domein een Copilot Notebook aan. Voeg per Notebook drie tot acht kern-documenten toe die de essentie van dat domein dekken. Niet alles, de essentie: coherentie telt meer dan volume. Begin met de twee best-afgebakende domeinen voor het proof-of-concept; de overige domeinen volgen in de weken erna met de inhoudelijke experts per domein. Check na toevoegen dat elk Notebook de documenten correct heeft geïndexeerd.

  3. Stap 3 · Domein-agents instellen met cross-verwijzing

    Bouw voor elk van de twee proof-of-concept Notebooks een declarative agent via Agent Builder. Gebruik prompt 2 (hieronder) als basis voor de instructies: domein-scope, cross-verwijzingsregel naar aangrenzende agents, bronvermelding-eis, en escalatie-pad voor vragen die buiten alle domeinen vallen. De cross-verwijzings-regel is de architectuur-lijm: zonder hem ontstaan eilanden; met hem ontstaat een geïntegreerd systeem. Test met drie vragen waarvan minstens een bewust op de grens tussen de twee domeinen valt.

  4. Stap 4 · Mind Map plus Quick Create onboarding

    Maak een visuele navigatie-landkaart: een Copilot Pages-artifact of Visio-diagram met per domein een node, welke drie kern-documenten erin zitten, en welke agent erbij hoort. Maak hem klikbaar: elke node linkt direct naar het bijbehorende Notebook of start de bijbehorende agent. Richt daarnaast een Quick Create-onboarding-flow in via prompt 3 (hieronder): een router-agent die nieuwe gebruikers naar het juiste domein begeleidt zonder dat zij de kaart al kennen. Publiceer de mind-map op een prominente intranet-plek.

Begin met twee domeinen als proof-of-concept, niet met de volledige architectuur. Een perfect ontwerp van zes domeinen dat pas in vier weken klaar is, helpt niemand vandaag. Twee werkende domeinen in een middag leveren directe waarde en valideren je architectuur-keuzes voor de rest.

Prompts voor je agent

Prompts per bouw-stap

Gebruik deze prompts in Copilot Studio's natural-language designer. Ze beschrijven de agent in termen die Studio direct vertaalt naar trigger-config, topics en actie-definities.

Stap 1 : Domein-grenzen-vraag voor ontwerp 
Ik heb kennis over [lijst van onderwerpen] en wil hem opdelen in drie tot zes domeinen voor een kennis-architectuur. Help me domein-grenzen bepalen vanuit gebruikers-perspectief, niet afdeling-perspectief. Stel drie varianten voor: variant A met strakke onderwerp-grenzen en weinig overlap, variant B met bredere domeinen en meer overlap, variant C met een entry-domein plus gespecialiseerde sub-domeinen. Per variant: welke domeinen zijn er, wat is de gebruikers-heuristiek om te kiezen, wat zijn de risico's.
Waarom werkt dit

Dit is een ontwerp-prompt, niet een bouw-prompt. Gebruik hem in Copilot Chat voor een brainstorm-sessie met een collega; beslis daarna welke variant past. Het doel is drie gestructureerde varianten naast elkaar, zodat je een bewuste architectuur-keuze maakt in plaats van default-afdelings-grenzen aan te houden.

Stap 3 : Domein-agent instructies met cross-verwijzing 
Je bent een domein-specialist voor [domein-naam]. Je kennis-bron is Notebook [naam]. Antwoord alleen op vragen die duidelijk binnen dit domein vallen. Als een vraag deels over [aangrenzend domein 1] of [aangrenzend domein 2] gaat, verwijs de gebruiker expliciet door: 'Dit raakt ook [aangrenzend domein]; zie de [agent-naam] agent voor dat deel'. Als een vraag buiten alle bekende domeinen valt, zeg 'Deze vraag valt buiten mijn scope; check de mind-map [link] voor het juiste domein of vraag een mens'. Citeer bij elk antwoord de bron-documenten uit jouw Notebook.
Waarom werkt dit

De cross-verwijzings-regel is de architectuur-lijm. Zonder hem ontstaat eilanden-gedrag: elke agent werkt binnen zijn eigen scope maar gebruikers weten niet wanneer ze moeten switchen. Met hem ontstaat een geïntegreerd systeem waar agents elkaar naar de juiste expert routeren. Zet deze instructie in elke domein-agent, niet alleen een; symmetrie maakt het systeem herkenbaar.

Stap 4 : Quick Create onboarding-prompt 
Ik ben een nieuw-in-deze-kennisbank en heb de vraag: [vrije invoer]. Help me bepalen welk domein-Notebook en welke domein-agent het beste bij mijn vraag past. Presenteer een korte analyse (een zin over de vraag), een aanbeveling (dit domein met agent-naam), en een alternatief (tweede-beste optie met reden). Vraag zo nodig verhelderend door, maximaal een vraag, om ambiguiteit op te lossen.
Waarom werkt dit

Deze prompt plak je in een Quick Create-flow (Copilot Studio custom action of een declarative agent die speciaal de router-rol vervult). De output is navigatie, geen inhoudelijk antwoord. Belangrijk: de router-agent probeert niet de vraag zelf te beantwoorden, want dat ondermijnt de domein-specialisatie. Hij classificeert en verwijst.

ONTWERP EERST

Architectuur voor eigen kennisdomein

Eigen werkkennis · 15 minuten · drie varianten

Discovery · Oefening 01

Wat isoleer je?

Variabele: domein-grens

Draai de oefening eerst met de standaardwaarde. Wijzig dan alleen deze variabele en draai opnieuw. Leg beide outputs naast elkaar; benoem de delta in één zin.

Jouw principe
De kwaliteit van een kennis-architectuur staat of valt met de domein-grenzen, niet met de agent-instructies of Notebook-inhoud. Goede grenzen volgen gebruikers-intuitie; slechte grenzen volgen organisatie-structuur. De test: kan een nieuwe collega zonder hulp het juiste domein kiezen binnen tien seconden. Zo ja, grens werkt. Zo nee, grens is onduidelijk en cross-verwijzingen gaan dat niet compenseren.

Gebruik stap 1 om drie domein-varianten te genereren voor jouw werk-kennis. Kies er een. Teken de gekozen variant uit als mind-map op papier of in een Copilot Page: per domein een naam, welke drie kern-documenten, welke agent-naam, hoe deze naar de andere verwijst. Dit is het ontwerp-artifact; bouwen volgt.

Opdracht
Gebruik prompt 1 (domein-grenzen-vraag) met jouw eigen werk-kennis ingevuld. Genereer drie varianten. Kies er een op basis van gebruikers-perspectief. Teken de gekozen variant uit: per domein naam plus drie kern-documenten plus agent-naam plus cross-verwijzingsrichting. Scenario A: organisatiebreed kennis-landschap met vijf domeinen (HR-regelingen, inkoop, IT-support, product, onboarding). Scenario B: vraag-categorieën van het operationele team (klant-retour, leverancier-klacht, contract-escalatie, interne-procedure).

Hint: Als bij het tekenen twijfel ontstaat over een onderwerp ('hoort het bij A of B'), is dat signaal dat het onderwerp op de grens ligt. Twee oplossingen: maak het een cross-verwijzing (het staat in domein A maar de agent van A verwijst naar B als vraag er neigt naar B), of maak het een apart mini-domein. Vermijd om het in beide Notebooks te zetten; dan hallucineren beide agents soms vanuit niet-synchroon-materiaal.

Pak uit je ontwerp de twee best-afgebakende domeinen. Bouw voor elk een Copilot Notebook met drie kern-documenten. Bouw voor elk een declarative agent in Agent Builder met het Notebook als knowledge source, de cross-verwijzings-instructie uit stap 3 en bronvermelding-eis. Test met drie vragen waarvan minstens een bewust op de grens tussen de domeinen valt en zie of de agent correct doorverwijst in plaats van zelf-hallucineren.

Opdracht
Stap 1: kies de twee best-afgebakende domeinen uit je ontwerp. Stap 2: maak per domein een Copilot Notebook aan met drie kern-documenten. Stap 3: bouw per domein een declarative agent via Agent Builder met Notebook als knowledge source en prompt 2 als instructies-basis. Stap 4: test met drie vragen waarvan een op de grens ligt; check of cross-verwijzing werkt.

Hint: Bij de grens-vraag let op twee failure-modes: eerste is dat agent-A het niet doorverwijst omdat hij denkt dat hij genoeg weet (instructie te ruim); tweede is dat agent-A naar agent-B verwijst terwijl B ook niet het juiste antwoord heeft (grens-onderwerp hoort eigenlijk als mini-domein erbij). Beide zijn leermomenten. Pas de instructies plus architectuur aan en probeer opnieuw; drie iteraties is normaal.

Waarom dit werkt

Waarom architectuur, niet meer agents

Een enkele kennisbank-agent is een lineaire oplossing voor een lineaire kennisstructuur. Zodra de kennis groeit en gebruikers niet meer weten waar te beginnen, faalt die aanpak op twee fronten tegelijk: de antwoord-kwaliteit daalt door context-verdunning, en de gebruiker verdwaalt zonder navigatielaag. Architectuur lost beide tegelijk op.

  • Splitsing per domein-Notebook Drie tot acht scherp geselecteerde documenten geven coherentere grounding dan dertig gemengde; antwoord-kwaliteit stijgt per domein
  • Cross-verwijzings-instructie per domein-agent Agents routeren naar elkaar in plaats van buiten hun scope te antwoorden; het systeem gedraagt zich als één geïntegreerde kennisbank
  • Mind Map als navigatie-entry-point Gebruikers hoeven de architectuur niet te kennen; de kaart vertelt welk domein bij welke vraag hoort. Onboarding van nieuwe collega's duurt minuten, niet dagen
  • Quick Create als router voor niet-ingewijden Een nieuwe medewerker typt zijn vraag, wordt naar het juiste Notebook gestuurd. De architectuur werkt voor mensen die er niets van weten

Vier stappen, een middag voor ontwerp plus proof-of-concept met twee domeinen. De iteratie zit in de domein-grenzen-keuze, niet in de technische bouw: goede grenzen maken de rest makkelijk.

Een kennisbank die niemand vindt is geen kennisbank, maar een museum. Een architectuur zonder mind-map is een kennisbank die niemand vindt.

Vier stappen, een middag voor ontwerp plus proof-of-concept met twee domeinen. De iteratie zit in de domein-grenzen-keuze, niet in de technische bouw: goede grenzen maken de rest makkelijk.

Tips

Tips die het verschil maken

Probeer: splits per duidelijke onderwerp-grens, niet per afdeling. De reflex is om domeinen te knippen langs organisatie-lijnen (HR, IT, Sales). Dat is vaak fout: een medewerker met vraag 'wanneer krijg ik mijn nieuwe laptop' denkt niet HR-vs-IT maar 'nieuwe-laptop'. Knip op onderwerp-grenzen die vanuit de gebruiker logisch zijn, niet vanuit de interne organisatie. Een goede domein-grens is waar de gebruiker geen twijfel heeft bij welk Notebook zijn vraag hoort.

Probeer: elke domein-agent verwijst expliciet naar anderen. In de instructies van elke domein-agent neem je letterlijk op: 'Als de vraag over onderwerp X, Y of Z gaat, verwijs door naar de respectievelijke agent met naam'. Dat is geen nice-to-have, dat is het verschil tussen een versnipperd systeem en een geïntegreerd systeem. Zonder cross-verwijzing ontdekken gebruikers de andere agents niet, en je mind-map is een statische poster in plaats van een actief navigatie-systeem.

Probeer: Mind Map als entry-point, niet als interne ontwerp-artifact. De Mind Map-visualisatie bestaat niet voor jou als ontwerper, maar voor de eindgebruiker die voor de eerste keer vraagt 'waar vind ik info'. Maak hem klikbaar: elke node linkt direct naar het bijbehorende Notebook of start de bijbehorende agent. Een mind-map in een verborgen SharePoint-map wordt door niemand gevonden en dus niet gebruikt.

Probeer: Quick Create als meerderjarige-onboarding, niet als enige pad. Bouw een Quick Create-flow voor nieuw-in-organisatie of nieuw-met-kennisbank: een invoer-veld 'beschrijf je vraag', een kort classificatie-moment, dan een voorstel 'dit is je Notebook plus dit is je agent'. Routineuze gebruikers gaan na twee weken direct naar het Notebook; prima. Quick Create is schulp-en-ladder voor de eerste veertien dagen, niet een verplicht kanaal voor altijd.

Let op

Wat vaak misgaat bij autonome agents

Morgen anders

Teken op een A3 vier tot zes domeinen voor je eigen werk

Teken op een A3 vier tot zes domeinen voor je eigen werk. Ieder domein een naam, drie key-documenten en een zin over wanneer een collega hier hoort. Begin met tekenen, niet met bouwen.

  1. Domein-namen: vier tot zes namen vanuit gebruikers-perspectief, niet vanuit afdelingsstructuur.
  2. Drie key-documenten per domein: niet alles, de documenten die negentig procent van de vragen dekken.
  3. Wanneer hoort een collega hier: één zin per domein die de gebruikers-heuristiek beschrijft.
  4. Cross-verwijzingen tekenen: welke domeinen raken elkaar, en welke vragen stuur je door?

Gebruik het getekende ontwerp als input voor de proof-of-concept in oefening 2. Het tekenen is de architectuur-keuze; de bouw volgt het ontwerp.

Check jezelf
Kernboodschap

Domein-splitsing volgens gebruikers-perspectief, domein-agents met cross-verwijzing, mind-map als entry-point, Quick Create voor onboarding. Orkestratie is ontwerp voor navigatie.

Volgende les
MW-44: Agent-governance: toegang, audit en beheer op schaal
Je architectuur werkt. Nu schaalt hij op. Wie beheert welke agent, hoe audit je gebruik, en hoe zorg je dat de architectuur niet vervuilt. De governance-laag die een proof-of-concept productie-klaar maakt.
Inleveren

Lever je werk in

Kies wat je wil inleveren voor MW-43.

Rubric
Output
Reflectie
Morgen
Rubric

Werkt het bij jou?

Drie korte vragen op je eigen output.