> 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/ai/ai-whitepaper/agentic-search.md).
# Agentic Search
## **What is Agentic Search?**
#### Agentic Search is a unified, permission-aware context layer that spans Zoom content and connected enterprise data sources
Agentic Search is an enterprise-grade knowledge retrieval capability that gathers, indexes, and correlates relevant information across Zoom-native content and connected third-party data sources, forming a single body of organizational knowledge that a query resolves against. What separates it from conventional search is the breadth of what one query can draw on: a meeting transcript, a Team Chat message, and a document sitting in a corporate cloud drive can all contribute to the same result. The shape of that result depends on the entry point — a synthesized answer in natural language, or a ranked set of grounded source material for another model to reason over — but the sources spanned, and the permissions enforced against them, do not change.
Within Zoom, retrieval spans the record of work that already accumulates on the platform — meeting recordings and transcripts, meeting summaries, Team Chat conversations, and the documents, notes, and other artifacts created alongside them. Beyond Zoom, retrieval extends to connected systems of record and content repositories, which can include services such as Salesforce, Google Drive, OneDrive, SharePoint, Confluence, Box, ServiceNow, Workday, Zendesk, and Seismic. Where indexing is supported and enabled, content from these systems is ingested into Zoom's retrieval layer alongside Zoom-native information, so a question resolves against one body of organizational knowledge instead of a set of isolated repositories that each have to be searched on their own terms.
Retrieval is permission-aware throughout. Access controls from each source system are inherited and enforced, so information surfaced — Zoom-native or third-party — is limited based on the requesting user’s or agent’s is applicable permissions. Broadening the set of searchable sources does not broaden any individual's access to them.
#### "Agentic Search" describes a capability, not an interface
Agentic Search is best understood as an underlying capability rather than a specific screen or button. The same capability is reached in more than one way: through the ZoomMate interface for everyday users, and through the Search and Ask APIs and the Model Context Protocol (MCP) for applications and AI agents. Whichever entry point is used, the term refers to the same core function: retrieving and synthesizing relevant information across sources.
#### ZoomMate uses Agentic Search to retrieve indexed data from connected organizational knowledge, then synthesizes the results into a natural language response
For everyday users, ZoomMate is where Agentic Search becomes routine. Preparing for an upcoming meeting, recalling a decision made across several past meetings, or locating a document tied to an open action item each can be resolved in a single request, rather than requiring separate searches across meetings, chats, documents, cloud storage, and CRM or ticketing systems.
#### MCP and the Search and Ask APIs extend the same retrieval to applications and external AI agents
Applications and external AI agents, including those built on third-party LLMs, call Agentic Search as a tool through MCP. Access controls travel with the call, so an agent retrieves information consistent with its authenticated user’s permissions.
The **Search API** returns a ranked set of relevant results and leaves generation to the caller's own model, which suits cases where raw, grounded source material is the desired output.
The **Ask API** performs both retrieval and generation within Zoom, returning a synthesized, cited answer in natural language.
#### A standing index and request-time retrieval keep frequently changing data current
Agentic Search is not limited to a static index. Content is vectorized, indexed, and keyworded, with approved third-party content incorporated through admin-scoped, incremental synchronization for efficient later retrieval. Data that changes frequently, or that benefits from request-time freshness, can instead be queried directly through MCP or equivalent real-time connections rather than served from the index.
Together, the standing index and request-time retrieval mean the context layer reflects the current state of connected systems rather than their state at last synchronization.
## **Data Sources and Indexing**
#### Zoom's indexing architecture is purpose-built for conversational AI retrieval
Zoom's indexing architecture is purpose-built for conversational AI, using vector search, content chunking, and a schema designed around the way conversational systems retrieve context. Many enterprise search and graph technologies were originally designed around a different goal: connecting documents, people, metadata, and other entities across a productivity environment. This architectural difference matters because conversational AI needs to identify and retrieve the specific pieces of information that are semantically relevant to a user's question, rather than primarily navigating relationships between documents or entities. Zoom's approach structures and indexes content around that retrieval model, making conversational use cases a core architectural consideration rather than a capability layered onto a system designed for a different purpose.
Put another way: it is the difference between indexing a library by individual books and indexing it by the passages someone might actually need to answer a question.
#### Third-party connectors extend Zoom's context layer to authorized third-party systems, subject to admin enablement
Agentic Search supports indexing from authorized third-party connectors, including Google Drive, OneDrive, Box, Salesforce, ServiceNow, Zendesk, Seismic, Confluence, and SharePoint, with additional connectors available depending on current release status. A connector being available does not mean its content is automatically searchable — each source must be enabled by an administrator before Agentic Search can begin ingesting it. This admin-gated model is deliberate: it is designed to keep indexing scope aligned with what an organization has actually authorized, rather than exposing every connectable system by default.
#### How indexing works: from ingestion to a queryable index
When a connector is enabled, Agentic Search builds a searchable index of approved content rather than querying the source system anew for every request. The process moves through several stages:
1. **Ingestion** — Approved content is fetched from the connected source, subject to the scope an administrator has authorized and the permissions of the connecting users. For file-based sources such as cloud drives, the document content is retrieved for processing rather than merely linked.
2. **Segmentation** — Retrieved content is broken into smaller passages so that retrieval can return the specific portion of a document relevant to a query, rather than whole files.
3. **Vectorization** — Each passage is converted into a numerical embedding using an embedding model, allowing retrieval to match on meaning and not only exact wording.
4. **Keyword indexing** — Content is also indexed for keyword matching. Both the Search and Ask capabilities depend on keyword matches alongside vector similarity, so the two approaches operate together rather than as alternatives.
5. **Permission-metadata indexing** — User access information is indexed alongside the content, derived from the source system's own native permissions, so that permission-aware filtering can be applied at query time.
The result is a customer-specific retrieval index — content from a source is stored in a form scoped to that customer and governed by that customer's permissions, rather than in a shared or cross-tenant store.
#### Diagrams and data flows are available for reference
Diagrams illustrating how Zoom's Agentic Search connects to third-party applications, services, and data sources — including connection and indexing data flows — are available in the [Zoom AI Whitepaper](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### What is indexed is governed by the scope an administrator authorizes for the connector
The content that gets indexed is governed by the scope an administrator authorizes for the connector. Once a source is connected, the index is maintained through ongoing updates rather than one-time ingestion:
1. **Initial sync**: On first configuration, the connector performs a full synchronization of the in-scope content, including existing historical content.
2. **Daily indexing update**: For some sources, the connector refreshes the in-scope content once per day.
3. **Incremental sync**: For others, the connector runs periodic syncs throughout each day that process only content added, modified, or changed since the last sync, rather than reprocessing the full repository each time.
#### Indexed retrieval and real-time retrieval work together
Agentic Search uses two retrieval paths, and which one applies is determined by how a source is connected and what kind of data it holds — not by a per-query or per-folder setting that a user or admin toggles.
Content connected as an **account-level data source** in the admin panel is ingested into a customer-specific index and searched from there. This is the default path for unstructured content — documents, knowledge articles, and files — because a pre-built index makes retrieval fast and efficient at query time, and it produces a searchable index shared across the organization.
Content is reached **directly, in real time, through MCP or an API** in the other cases: personal connectors that an individual user authorizes (such as their own email, calendar, or personal cloud storage), structured records like CRM object data, and other content that changes frequently enough to benefit from request-time freshness. A personal connector retrieves only the documents the connecting user can access, and structured-data connections carry their own user authentication and authorization rather than being served from the index.
Because the path follows the connection, the same underlying application can be reached either way depending on how it is set up. A cloud storage service connected as an admin-managed data source is indexed for organization-wide search, while the same service connected as an individual's personal connector is queried directly and scoped to that user's own access.
#### External Agentic Search connections are built on the Model Context Protocol (MCP)
Connections between Zoom and external models, tools, and data sources are built on the Model Context Protocol (MCP), an open client–server standard for linking models to tools and data. MCP servers operate at the edge of Zoom, providing a consistent interface through which retrieval requests are made — both for real-time retrieval from connected systems and for external agents reaching Agentic Search as a tool. This standardized transport replaces one-off, source-by-source integrations with a common connection model.
#### Indexing duration varies by customer, data volume, and data type
There is no fixed timeline for how long a given connector takes to fully index. The time required varies by each customer, depending on the amount of data being indexed and the type of data involved. Rate limits imposed by the third-party platform being indexed are a contributing factor — each source system throttles how much data can be pulled in a given window, and that throttling varies by platform, plan tier, and API design. Customers planning a first-time indexing effort for a large or heavily-used repository should expect a multi-week timeframe rather than a same-day or same-week outcome.
#### Indexing capacity scales with ZoomMate license tier and is pooled at the organization level
Indexing capacity is a function of license tier rather than a fixed universal allotment. Each licensed user contributes a per-seat capacity amount based on their tier, and those amounts combine into a single organization-wide pool that is shared across the organization as a whole rather than allocated to each individual user.
Total indexed content across all connected sources and all users must stay within the org's combined pool — meaning one user indexing a large repository draws from the same shared capacity available to everyone else. Because the pool grows with each licensed seat, an organization's total capacity is the sum of what all of its licensed users contribute.
For example, if a license grants 1GB of storage, at 25 licenses, the account has a total of 25GB of storage. At 100 users, 100GB.
Organizations planning to index large repositories (a full Confluence space, a large SharePoint site, a mature CRM instance) should size their license tier and seat count against expected total content volume, not against per-user usage patterns. Additional index capacity is available—speak with your Zoom account team for more information.
#### File size and file type both affect what gets indexed
Two separate size limits apply, and they behave differently:
* **64 MB original-file limit (download):** If a source file's original size exceeds 64 MB, it is skipped and not downloaded for processing.
* **16 MB processed-content limit (indexing):** Downloaded files are converted into a unified processing format. If the resulting processed file exceeds 16 MB, only the first 16 MB of its content is indexed; the remainder is not.
The two limits fail differently: an oversized original is skipped entirely, while an oversized processed file is truncated rather than excluded, so its opening content still appears in retrieval while later content does not.
Separately, indexing depends on file type, independent of size. Multimedia content — audio, video, and images — is not indexed, at any size. It is removed during conversion to the unified processing format, before either size limit is evaluated. Metadata is indexed for all documents, but full content is indexed only for supported, non-media file types. For unsupported types, the document is still discoverable by its metadata, but its contents are not searchable.
#### Admins cannot currently control the order in which content is indexed
There is no mechanism today for an administrator to prioritize specific folders, spaces, or content types to be indexed ahead of others within a connected source. Indexing proceeds across eligible content in an enabled connector without a way to sequence it, which means organizations cannot front-load indexing of their highest-value content and should expect indexing coverage to build out gradually across the full repository rather than starting with the most business-critical material first.
Indexing also cannot be scheduled to run at a chosen time or cadence. Once a source is enabled, indexing runs on its own timing rather than on a schedule an administrator sets, so it is best treated as a background process that completes when it completes rather than one that can be timed around a specific window.
## **Administration, Permissions, and Governance**
#### Administrators can control which sources are connected, and users authenticate their own access
Connectors are enabled by an administrator, who determines which third-party systems are available for indexing and search within the organization. Enabling a connector makes a source available to the organization, but it does not intrinsically grant access to its contents. Each user must authenticate their access to the source individually — once authenticated, their retrieval permissions align with their existing permissions in the source system, so they can only surface what they could already access there.
#### Retrieval is permission-aware and read-only
Agentic Search is designed to apply the access controls of each source system, so answers reflect only the content that user is already permitted to see; two users asking the same question may receive different results based on their respective permissions in the third-party data source. Retrieval is read-only and follows the retention policies of each source — for example, Zoom meeting content follows its applicable retention period rather than being retained separately by the search layer. Because retrieval is governed and permission-aware at query time, it also offers an alternative to exporting raw transcripts or records in bulk, keeping access aligned with the original third-party source.
---
# 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/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.