AI and search over SharePoint data
Agents, Copilot Studio, text-to-SQL chat and retrieval over SharePoint lists and library metadata, all reading one replicated copy, with what each tool can see set by the database role and row-level security you grant.
Someone in the business has built an assistant over a SharePoint list, and it gives a confident wrong answer to a simple question. Microsoft Learn, checked on 20 October 2026, says Copilot Studio list queries only return data from the first 2,048 rows, so a count or a total over a larger list comes from part of it.
Retrieval jobs that call Graph directly go wrong in a different way. Every question pages through the same lists again, each agent shares the tenant's throttling budget with every other integration, and an embedding index built from a one-off export goes stale the week an item changes.
A replica gives every tool one copy to read. SPSync copies list items and library metadata into a database with a normalised schema, keeps it current with delta reads, and holds the only Graph connection. A text-to-SQL tool gets typed columns and join keys to reason over. An agent connects with a database login, through a Postgres or SQL Server MCP server you already run, or through spsync mcp serve, SPSync's own read-only MCP server over the copy. SPSync ships no agent of its own. For questions about wording, SPSync generates embeddings on each sync for pgvector and Azure AI Search, and re-embeds only the rows that changed.
Some limits shape the design. File contents are not replicated, so an assistant can find a contract by supplier and expiry date and then hand a person the link in SharePoint, but it cannot quote the PDF. SharePoint item permissions are not carried into the copy, which means what an agent may see is set by a read-only role, views and row-level security on the database. There is no path from the copy back to SharePoint, so an agent cannot change a list item. Approved write-back is a design on the roadmap and has not shipped.
If the topic is new to you, read the start-here posts in order. The AI page puts the routes for agents, Copilot Studio and search side by side.
Start here
- Why your agent should not query SharePoint live
Read this before the others, because it settles when a live Graph read is right and when an agent should read a copy.
- One SQL copy of SharePoint for every agent you run
The cost of one cross-list question through Graph, set against one SQL join, shows why a single copy pays off.
- Text-to-SQL on SharePoint data depends on the schema
Once agents read SQL, the schema decides whether their queries come back right, so text-to-SQL follows.
- Copilot Studio and SharePoint lists: four routes compared
Copilot Studio makers can compare list knowledge, a flow, Dataverse and a SQL replica here before building anything.
- Keeping a SharePoint vector index current as items change
Embedding drift shows up months after a vector index goes live, so read this one before you build.
All posts on this topic
- Azure AI Foundry agents and SharePoint list rows
The Foundry SharePoint tool (preview) retrieves text from documents, not list rows. What each Foundry tool reads today, and how to query a list replica.
- SharePoint lists in Foundry IQ after On Your Data retired
Azure OpenAI On Your Data retired on 14 October 2026. How to ground answers on a SharePoint list in Foundry IQ, through an Azure AI Search index kept current.
- Copilot Studio says it cannot find the item at row 3,000
Your agent answers about some list items and says others do not exist. The 2,048-row read and search ranking explain it, with a test to show what it sees.
- Keeping SharePoint data in region for AI: where prompts, embeddings and indexes go
Your data protection officer asks whether AI on a SharePoint list sends it abroad. Four hops decide it: the model, the embedding call, the index and the logs.
- Agents on SharePoint data without a Graph app registration
Your request for a Graph app registration for an AI loader was refused. One read-only Sites.Selected grant to a replica, then a database role per tool, is easier to approve.
- Copilot Studio and SharePoint lists: four routes compared
A Copilot Studio maker with a 9,000-item list has four ways to answer from it. What list knowledge, a flow, Dataverse and a SQL replica each cost.
- Supabase and SharePoint lists for an app and an AI agent
A field-ops app on Supabase and an AI agent reading the same replicated SharePoint lists, with row-level security per team and a read-only role for the agent.
- Human-in-the-loop AI agents over SharePoint evidence
An agent checks contractor certificates for each job against a SQL replica of SharePoint, writes the gaps to a review table, and a person approves the packet.
- One SQL copy of SharePoint for every agent you run
What a cross-list question costs an AI agent through Graph, worked for three real-sized lists, and the same question as one SQL join on a replica.
- Why your agent should not query SharePoint live
Agent tools that call Microsoft Graph share SharePoint's throttling budgets with every other integration. When a live read is right, and when to use a replica.
- Four ways to embed SharePoint list text, compared
A facilities incident list embedded four ways, from a Power Automate flow to embedding on sync into pgvector, with the upkeep each one brings.
- Running a local AI model over SharePoint data in DuckDB
A law firm that cannot send client data to a public AI service replicates its Matters list into DuckDB on a laptop and queries it with Ollama.
- Library metadata is the catalogue an AI assistant needs
A policy assistant quoted a withdrawn document because it only read file text. A replicated metadata table lets it pick documents by status first.
- Read SharePoint once and let the AI pipeline query the copy
A finance assistant hit 429s every month-end. The resource-unit arithmetic behind Graph throttling, and how one delta reader and a replica fix it.
- Keeping a SharePoint vector index current as items change
An HR assistant kept quoting a carry-over rule that changed in March. The four kinds of embedding drift, and re-embedding only rows that changed.
- Training and evaluation sets from SharePoint records
A service desk scores a ticket-type assistant against three years of SharePoint tickets, with SQL over a replica and snapshots that can be rebuilt.
- An MCP server for SharePoint data that queries SQL
Claude, ChatGPT or Cursor reading a read-only SQL replica of SharePoint lists through a database MCP server, with no Graph permission of its own.
- Why Copilot cannot count the rows in your SharePoint list
Copilot Studio reads the first 2,048 rows of a list and counts what search returns. Here are the documented limits and what a SQL replica changes.
- Text-to-SQL on SharePoint data depends on the schema
A project office asked a chat box which clients had projects at risk and got ids and claims strings back. The schema fixes that make the SQL right.
Other topics on the blog
Frequently asked questions
What can an agent see, and can it change SharePoint?
It sees whatever its database role is granted, and nothing in SharePoint. SharePoint item permissions are not copied into the replica, so you scope the agent with a read-only role, views and row-level security on the database. There is no write path from the copy to SharePoint, because SPSync never writes to it. Write-back is designed around changes a person approves.
Can the agent read the files in a document library?
It can read a library's columns as rows, including the ones your team added. File contents are not replicated today, so the agent can find a contract by its supplier and expiry date and then hand a person the link in SharePoint.
Where does Azure AI Search fit?
Beside the SQL copy, for questions about wording. SPSync can write the same lists to Azure AI Search or pgvector with embeddings generated on each sync; see retrieval over list data. Keep exact questions, such as counts and joins, on the relational copy.