> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/nl/ai/ai-whitepaper/agentic-search.md).
# Agentische zoekfunctie
## **Wat is Agentic Search?**
#### Agentic Search is een uniforme, op Toestemming gebaseerde contextlaag die zich uitstrekt over Zoom-inhoud en verbonden gegevensbronnen van de Onderneming
Agentic Search is een Onderneming-grade mogelijkheden voor het ophalen van kennis die relevante informatie verzamelt, indexeert en correleert over Zoom-native content en gekoppelde gegevensbronnen van derden, waardoor één geheel van organisatorische kennis ontstaat waar een query tegen wordt afgehandeld. Wat het onderscheidt van conventioneel zoeken is de breedte van waar één query op kan terugvallen: een vergadering transcript, een Team Chat-bericht en een document dat in een corporate Cloud-drive staat kunnen allemaal bijdragen aan hetzelfde resultaat. De vorm van dat resultaat hangt af van het ingangepunt — een gesynthetiseerd antwoord in natuurlijke taal, of een gerangschikte set aan onderbouwd bronmateriaal waarover een andere model redeneert — maar de bronnen die worden overspannen en de machtigingen die erop worden toegepast, veranderen niet.
Binnen Zoom beslaat het ophalen het opnemen van het werk dat al wordt opgebouwd op het Platform — vergaderingopnamen en transcripties, samenvattingen van vergaderingen, Team Chat-gesprekken, en de documenten, notities en andere artefacten die samen met hen worden gemaakt. Buiten Zoom strekt het ophalen zich uit tot gekoppelde systemen voor opnemen en contentopslagplaatsen, die services kunnen omvatten zoals Salesforce, Google Drive, OneDrive, SharePoint, Confluence, Box, ServiceNow, Workday, Zendesk en Seismic. Wanneer indexering wordt ondersteund en ingeschakeld, wordt content uit deze systemen ingelezen in de Zoom-ophaal-laag naast Zoom-native informatie, zodat een vraag wordt opgelost op basis van één geheel van organisatorische kennis in plaats van een verzameling geïsoleerde opslagplaatsen die elk op hun eigen voorwaarden moeten worden doorzocht.
Opvraging is overal Toestemming-bewust. Access-controls van elk bronsysteem worden overgenomen en afgedwongen, zodat informatie die wordt getoond — Zoom-native of van derden — beperkt is op basis van de van toepassing zijnde Toestemming van de aanvragende gebruiker of agent. Het uitbreiden van de set doorzoekbare bronnen vergroot iemands Access daartoe niet.
#### "Agentic Search" beschrijft een mogelijkheid, niet een interface
Agentic Search kan het best worden begrepen als een onderliggende mogelijkheid in plaats van een specifiek Scherm of een knop. Dezelfde mogelijkheid wordt op meer dan één manier bereikt: via de ZoomMate-interface voor dagelijkse gebruikers, en via de Search en Ask API's en het Model Context Protocol (MCP) voor applicaties en AI-agenten. Welke ingang ook wordt gebruikt, de term verwijst naar dezelfde kernfunctie: het ophalen en samenvoegen van relevante informatie uit verschillende bronnen.
#### ZoomMate gebruikt Agentic Search om geïndexeerde gegevens op te halen uit verbonden kennis van de organisatie en synthetiseert vervolgens de resultaten tot een antwoord in natuurlijke taal
Voor dagelijkse gebruikers is ZoomMate de plek waar Agentic Search routine wordt. Ter voorbereiding op een aanstaande vergadering, het herinneren van een beslissing die in meerdere eerdere vergaderingen is genomen, of het vinden van een document dat aan een open actiepunt is gekoppeld, kan elk met één enkele vraag worden opgelost, in plaats van dat afzonderlijke zoekopdrachten nodig zijn in vergaderingen, chats, documenten, Cloudopslag en CRM- of ticketsystemen.
#### MCP en de Search- en Ask-API's breiden dezelfde retrieval uit naar applicaties en externe AI-agenten
Applicaties en externe AI-agenten, waaronder die gebouwd op LLM's van derden, bellen Agentic Search aan als hulpmiddel via MCP. Access-controles gaan mee met de bellen, zodat een agent informatie ophaalt die consistent is met de machtigingen van zijn geverifieerde gebruiker.
De **Zoek-API** geeft een gerangschikte set relevante resultaten terug en laat de generatie over aan het eigen model van de aanroeper, wat geschikt is voor gevallen waarin onbewerkte, gegronde bronmaterialen de gewenste output zijn.
De **Vraag-API** voert zowel ophalen als generatie uit binnen Zoom en geeft een gesynthetiseerd, geciteerd antwoord terug in natuurlijke taal.
#### Een vaste index en ophalen op aanvraag houden vaak veranderende gegevens actueel
Agentic Search is niet beperkt tot een statische index. Content wordt gevectoriseerd, geïndexeerd en voorzien van trefwoorden, waarbij goedgekeurde content van derden via incrementele synchronisatie op beheerderniveau wordt opgenomen voor efficiënte latere opvraging. Gegevens die vaak veranderen, of die profiteren van actualiteit op aanvraag, kunnen in plaats daarvan rechtstreeks worden opgevraagd via MCP of gelijkwaardige realtimeverbindingen in plaats van uit de index te worden geleverd.
Samen betekenen de vaste index en ophalen op aanvraag dat de contextlaag de huidige toestand van verbonden systemen weerspiegelt in plaats van hun toestand bij de laatste synchronisatie.
## **Gegevensbronnen en indexering**
#### Zooms indexeringsarchitectuur is Speciaal gebouwd voor het ophalen van conversationele AI
Zooms indexeringsarchitectuur is Speciaal gebouwd voor conversationele AI, met vector search, contentchunking en een schema dat is ontworpen rond de manier waarop conversationele systemen context ophalen. Veel zoek- en graftechnologieën voor de Onderneming waren oorspronkelijk ontworpen rond een ander doel: het Verbinden van documenten, mensen, metadata en andere entiteiten binnen een productiviteitsomgeving. Dit architecturale verschil is belangrijk omdat conversationele AI de specifieke stukken informatie moet identificeren en ophalen die semantisch relevant zijn voor een vraag van een gebruiker, in plaats van vooral relaties tussen documenten of entiteiten te navigeren. Zooms aanpak structureert en indexeert content rond dat ophaalmodel, waardoor gebruiksscenario's voor conversationele AI een kernarchitecturale overweging worden in plaats van een mogelijkheid die bovenop een systeem is gelegd dat voor een ander doel is ontworpen.
Met andere woorden: het is het verschil tussen een bibliotheek indexeren op afzonderlijke boeken en deze indexeren op de passages die iemand daadwerkelijk nodig heeft om een vraag te beantwoorden.
#### Connectoren van derden breiden Zooms contextlaag uit naar geautoriseerde systemen van derden, onder voorbehoud van inschakeling door beheerder
Agentic Search ondersteunt indexering vanuit geautoriseerde Connectoren van derden, waaronder Google Drive, OneDrive, Box, Salesforce, ServiceNow, Zendesk, Seismic, Confluence en SharePoint, met extra Connectoren die Beschikbaar zijn afhankelijk van de huidige releasestatus. Dat een Connector Beschikbaar is betekent niet dat de inhoud automatisch doorzoekbaar is — elke bron moet door een beheerder worden ingeschakeld voordat Agentic Search ermee kan beginnen te werken. Dit model waarbij de toegang door een beheerder wordt afgeschermd is opzettelijk: het is ontworpen om de indexeringsscope afgestemd te houden op wat een Organisatie daadwerkelijk heeft geautoriseerd, in plaats van elk verbindbaar systeem Standaard bloot te stellen.
#### Hoe indexering werkt: van opname tot een doorzoekbare index
Wanneer een Connector is ingeschakeld, bouwt Agentic Search een doorzoekbare index van goedgekeurde content in plaats van de bronsystemen opnieuw te bevragen voor elk verzoek. Het proces verloopt in verschillende fasen:
1. **Ingestie** — Goedgekeurde content wordt opgehaald uit de verbonden bron, onder voorbehoud van de scope die een beheerder heeft geautoriseerd en de machtigingen van de Verbinden-gebruikers. Voor op bestanden gebaseerde bronnen zoals Cloud-drives wordt de documentinhoud opgehaald voor verwerking in plaats van alleen maar gelinkt.
2. **Segmentatie** — Opgehaalde content wordt opgesplitst in kleinere passages, zodat ophalen het specifieke deel van een document dat relevant is voor een zoekopdracht kan teruggeven, in plaats van hele bestanden.
3. **Vectorisatie** — Elke passage wordt omgezet in een numerieke embedding met behulp van een embeddingmodel, waardoor ophalen kan matchen op betekenis en niet alleen op exacte bewoording.
4. **Trefwoordindexering** — Content wordt ook geïndexeerd voor trefwoordovereenkomst. Zowel de Search- als de Ask-functionaliteit is afhankelijk van trefwoordovereenkomsten naast vectorovereenkomst, zodat de twee benaderingen samen werken in plaats van als alternatieven.
5. **Toestemming-metadata-indexering** — Informatie over gebruikerstoegang wordt samen met de content geïndexeerd, afgeleid van de eigen native Toestemming van het bronsysteem, zodat filtering die rekening houdt met Toestemming kan worden toegepast op het moment van de query.
Het resultaat is een klantspecifieke retrieval-index — content uit een bron wordt opgeslagen in een vorm die is beperkt tot die klant en wordt beheerst door de Toestemming van die klant, in plaats van in een gedeelde of cross-tenant opslag.
#### Diagrammen en datastromen zijn Beschikbaar ter referentie
Diagrammen die illustreren hoe Zoom's Agentic Search verbinding maakt met toepassingen, services en databronnen van derden — inclusief gegevensstromen voor verbinding en indexering — zijn Beschikbaar in de [Zoom AI-whitepaper](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### Wat wordt geïndexeerd, wordt bepaald door de reikwijdte die een beheerder autoriseert voor de Connector
De inhoud die wordt geïndexeerd, wordt bepaald door de reikwijdte die een beheerder autoriseert voor de Connector. Zodra een bron is gekoppeld, wordt de index onderhouden via doorlopende updates in plaats van eenmalige ingestie:
1. **Eerste Synchroniseren**: Bij de eerste configuratie voert de Connector een volledige synchronisatie uit van de inhoud binnen de reikwijdte, inclusief bestaande historische inhoud.
2. **Dagelijkse indexeringsupdate**: Voor sommige bronnen vernieuwt de Connector de inhoud binnen de reikwijdte één keer per dag.
3. **Incrementeel Synchroniseren**: Voor andere bronnen voert de Connector gedurende de dag periodieke Synchroniseren uit die alleen inhoud verwerken die is toegevoegd, gewijzigd of aangepast sinds de laatste Synchroniseren, in plaats van telkens de volledige opslagplaats opnieuw te verwerken.
#### Op basis van index ophalen en realtime ophalen werken samen
Agentic Search gebruikt twee ophaalpaden, en welk pad van toepassing is, wordt bepaald door hoe een bron is verbonden en welk soort data deze bevat — niet door een instelling per query of per map die een gebruiker of beheerder inschakelt.
Content die is verbonden als een **gegevensbron op accountniveau** in het beheerderspanel wordt opgenomen in een klantspecifieke index en van daaruit doorzocht. Dit is het standaardpad voor ongestructureerde content — documenten, kennisartikelen en bestanden — omdat een vooraf gebouwde index het ophalen snel en efficiënt maakt op het moment van de query, en omdat het een doorzoekbare index oplevert die gedeeld wordt binnen de Organisatie.
Content wordt benaderd **rechtstreeks, in realtime, via MCP of een API** in de andere gevallen: persoonlijke connectors die een individuele gebruiker autoriseert (zoals hun eigen E-mail, agenda of persoonlijke Cloudopslag), gestructureerde records zoals CRM-objectdata, en andere content die vaak genoeg verandert om te profiteren van versheid op aanvraag. Een persoonlijke Connector haalt alleen de documenten op waartoe de verbindende gebruiker toegang heeft, en verbindingen voor gestructureerde data hebben hun eigen gebruikersauthenticatie en -autorisatie in plaats van vanuit de index te worden geleverd.
Omdat het pad de verbinding volgt, kan dezelfde onderliggende applicatie op beide manieren worden benaderd, afhankelijk van hoe deze is ingesteld. Een Cloudopslagdienst die is verbonden als een door beheerder beheerde gegevensbron, wordt geïndexeerd voor zoeken binnen de hele Organisatie, terwijl dezelfde dienst die is verbonden als de persoonlijke Connector van een individu rechtstreeks wordt bevraagd en wordt beperkt tot de eigen toegang van die gebruiker.
#### Externe Agentic Search-verbindingen zijn gebouwd op het Model Context Protocol (MCP)
Verbindingen tussen Zoom en externe modellen, tools en gegevensbronnen zijn gebouwd op het Model Context Protocol (MCP), een open client-serverstandaard voor het koppelen van modellen aan tools en data. MCP-servers draaien aan de rand van Zoom en bieden een consistent interface via welke opvraagverzoeken worden gedaan — zowel voor realtime ophalen uit verbonden systemen als voor externe agents die Agentic Search als tool benaderen. Dit gestandaardiseerde transport vervangt eenmalige, bron-voor-bronintegraties door een algemeen verbindingsmodel.
#### Indexeringsduur varieert per klant, datavolume en datatype
Er is geen vaste tijdlijn voor hoe lang het duurt voordat een bepaalde connector volledig is geïndexeerd. De benodigde tijd varieert per klant, afhankelijk van de hoeveelheid data die wordt geïndexeerd en het type data dat betrokken is. Snelheidslimieten die worden opgelegd door het platform van derden dat wordt geïndexeerd, zijn een bijkomende factor — elk bronsysteem beperkt hoeveel data er in een bepaalde periode kan worden opgehaald, en die beperking verschilt per platform, abonnementsniveau en API-ontwerp. Klanten die een eerste indexeringsinspanning plannen voor een grote of zwaargebruikte repository, moeten rekening houden met een periode van meerdere weken in plaats van met een resultaat op dezelfde dag of in dezelfde week.
#### Capaciteit voor indexering schaalt mee met de licentielaag van ZoomMate en wordt gebundeld op Organisatieniveau
Capaciteit voor indexering is een functie van de licentielaag in plaats van van een vaste universele toewijzing. Elke gebruiker met licentie draagt per stoel een hoeveelheid capaciteit bij op basis van hun laag, en die hoeveelheden worden samengevoegd tot één organisatiebrede pool die binnen de hele Organisatie wordt gedeeld in plaats van per individuele gebruiker te worden toegewezen.
De totale geïndexeerde content uit alle verbonden bronnen en van alle gebruikers moet binnen de gecombineerde pool van de Organisatie blijven — wat betekent dat één gebruiker die een grote repository indexeert, put uit dezelfde gedeelde capaciteit die voor iedereen beschikbaar is. Omdat de pool groeit met elke licentieplaats met licentie, is de totale capaciteit van een Organisatie de som van wat al haar gebruikers met licentie bijdragen.
Als een licentie bijvoorbeeld 1 GB opslag geeft, heeft het account bij 25 licenties in totaal 25 GB opslag. Bij 100 gebruikers: 100 GB.
Organisaties die grote repositories willen indexeren (een volledige Confluence-ruimte, een grote SharePoint-locatie, een volwassen CRM-instantie) moeten hun licentielaag en aantal licentieplaatsen afstemmen op het verwachte totale contentvolume, niet op gebruikspatronen per gebruiker. Extra indexeringscapaciteit is beschikbaar — neem contact op met uw Zoom-accountteam voor meer informatie.
#### Bestandsgrootte en bestandstype beïnvloeden beide wat er wordt geïndexeerd
Er gelden twee afzonderlijke groottebeperkingen, en ze gedragen zich verschillend:
* **Limiet van 64 MB voor het oorspronkelijke bestand (download):** Als de oorspronkelijke bestandsgrootte van een bronbestand groter is dan 64 MB, wordt het overgeslagen en niet gedownload voor verwerking.
* **Limiet van 16 MB voor verwerkte content (indexering):** Gedownloade bestanden worden omgezet naar een uniform verwerkingsformaat. Als het resulterende verwerkte bestand groter is dan 16 MB, wordt alleen de eerste 16 MB van de content geïndexeerd; de rest niet.
De twee limieten falen verschillend: een te groot origineel wordt volledig overgeslagen, terwijl een te groot verwerkt bestand wordt afgekapt in plaats van uitgesloten, zodat de openingscontent nog steeds in de resultaten verschijnt, terwijl latere content dat niet doet.
Daarnaast is indexering afhankelijk van het bestandstype, los van de grootte. Multimediacontent — audio, video en afbeeldingen — wordt niet geïndexeerd, ongeacht de grootte. Deze wordt tijdens de conversie naar het uniforme verwerkingsformaat verwijderd, voordat een van beide groottebeperkingen wordt geëvalueerd. Metadata wordt voor alle documenten geïndexeerd, maar de volledige content wordt alleen geïndexeerd voor ondersteunde, niet-media-bestandstypen. Voor niet-ondersteunde typen is het document nog steeds vindbaar via de metadata, maar de inhoud is niet doorzoekbaar.
#### Beheerders kunnen momenteel niet de volgorde bepalen waarin content wordt geïndexeerd
Er is tegenwoordig geen mechanisme waarmee een beheerder specifieke mappen, ruimten of contenttypes voorrang kan geven om vóór andere te worden geïndexeerd binnen een verbonden bron. Indexering verloopt over in aanmerking komende content in een ingeschakelde Connector zonder dat er een volgorde aan kan worden gegeven, wat betekent dat organisaties de indexering van hun meest waardevolle content niet naar voren kunnen halen en moeten verwachten dat de indexeringsdekking zich geleidelijk opbouwt over de volledige repository in plaats van eerst te beginnen met het meest bedrijfskritische materiaal.
Indexering kan ook niet worden gepland om op een gekozen tijdstip of ritme te draaien. Zodra een bron is ingeschakeld, draait indexering volgens zijn eigen timing in plaats van volgens een Planning die een beheerder instelt, dus het is het beste om het te beschouwen als een achtergrondproces dat voltooit wanneer het voltooit, in plaats van als iets dat rond een specifiek venster kan worden getimed.
## **Beheer, Toestemming en governance**
#### Beheerders kunnen bepalen welke bronnen worden verbonden, en gebruikers authenticeren hun eigen toegang
Connectors worden ingeschakeld door een beheerder, die bepaalt welke systemen van derden beschikbaar zijn voor indexering en zoeken binnen de Organisatie. Het inschakelen van een Connector maakt een bron beschikbaar voor de Organisatie, maar verleent niet automatisch toegang tot de inhoud ervan. Elke gebruiker moet zijn toegang tot de bron afzonderlijk authenticeren — zodra dat is gebeurd, sluiten de ophaaltoestemmingen aan op de bestaande Toestemming in het bronsysteem, zodat zij alleen kunnen ophalen wat zij daar al konden benaderen.
#### Ophalen houdt rekening met Toestemming en is alleen-lezen
Agentic Search is ontworpen om de toegangscontroles van elk bronsysteem toe te passen, zodat antwoorden alleen de content weergeven die die gebruiker al mag zien; twee gebruikers die dezelfde vraag stellen, kunnen verschillende resultaten ontvangen op basis van hun respectieve Toestemming in de externe gegevensbron. Ophalen is alleen-lezen en volgt het bewaarbeleid van elke bron — zo volgt Zoom-vergadercontent de toepasselijke bewaartermijn in plaats van afzonderlijk te worden bewaard door de zoeklaag. Omdat ophalen op het moment van de query wordt beheerd en Toestemming-bewust is, biedt het ook een alternatief voor het in bulk exporteren van ruwe transcripties of records, waarbij de toegang in lijn blijft met de oorspronkelijke bron van derden.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://library.zoom.com/technical-library/nl/ai/ai-whitepaper/agentic-search.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.