Series Overview
Welcome to the second post in this series, where we will ride the ski lift up AI mountain and leverage out of the box Microsoft Foundry capabilities to consume and reason over our SharePoint data. Additionally, I use this opportunity to discuss how the new Foundry experience differs from (and greatly improves upon) the AI user experience. Use the table of contents below in case you want to explore other posts in this series.
- Tradeoffs Between the Two Approaches
- SharePoint Knowledge Connections to Foundry Agents the Easy Way
- SharePoint Knowledge Connections to Foundry Agents the Hard Way
- Deep Dive: Extracting SharePoint Content with Power Automate
- Deep Dive: A Custom API to Sync SharePoint Content with Azure Storage
- Deep Dive: Configuring and Deploying Azure AI Search with C#
- Azure AI Search Knowledge Connections to Foundry Agents
SharePoint Knowledge Connections to Foundry Agents the Easy Way
This post is being written during Ignite 2025, where Azure AI Foundry has just been rebranded to Microsoft Foundry, paradigmatically positioning it as a more enterprise-facing experience rather than merely a technical tool. This “New Foundry” is in preview, so screenshots and other content might not match what you see when you read this; the velocity of AI innovation doesn’t tend to decelerate…
This procedure assumes that you already have the following infrastructure in place:
- A Microsoft Foundry project (not a Hub) instance in Azure
- A user account with the following entitlements
- An M365 Copilot license
- At least read access to the targeted SharePoint content
- Membership in the “Azure AI User” role of the Foundry project’s IAM in Azure
- An M365 Copilot license
- A modern SharePoint site collection located at https://<tenant>.sharepoint.com/teams/<site> with some files uploaded to the default “Documents” library
Let’s climb!
1. Log into your Foundry project. The easiest way to get there, assuming you spend a lot of time in the clouds, is to click on the corresponding PaaS component from a resource group or the Azure home page…
…and then portal hop into Foundry…
2. The new interface is stunning, providing a welcome screen instead of throwing you directly into the tooling. The arrows below call out the preview status of the “New Foundry” interface and how to opt into it.
3. Choose “Create agent” from the “Start building” dropdown.
Note that while any models deployed to or knowledge and data sources configurated in the previous Foundry experience will be available here, agents will not; these now “classic” agents need to be migrated or rebuilt. While exploring the new “Build” section, you’ll see a nice callout to start this upgrade process if needed.
4. Give your agent a name (I’m using “sharepoint-agent”) and then click “Create.”
5. The new interface feels more aligned to conventional AI terminology vis-à-vis having “Workflows” atop the left-hand navigation and knowledge connections now explicitly referred to as “tools” once created. Give your agent some instructions and then under “Knowledge” select “Set up a data source via tools” from the “Add” dropdown.
6. Select “SharePoint” in the modal and click “Add Tool” – notice this is no longer in preview!
7. In the next screen, create a connection to your site. During the preview of SharePoint Foundry knowledge, this was required to be under the /teams managed path. This should still be the case, but I did experiment with changing this connection to point to an older /sites URL in our tenant. Upon updating, the setting simply reverted back to the original /teams site collection. This could be a missing error message, or a bug in the preview experience; we will proceed with the /teams convention.
8. Your SharePoint connection will be added as a new tool for the agent on the left. Next click “Save” in the upper right-hand corner, and then use the “Preview” dropdown to get into the new chat experience. Looking at the additional “Publish” option, it seems Foundry is taking a page out of SharePoint’s CMS book, allowing you to do proper agent testing and tuning before formally releasing them to the enterprise.
9. The preview experience is much more streamlined, allowing you to test your agent without all the clutter, and then return to Foundry to start tuning before you publish.
The results were then immediately available!
And there it is! Without a single line of code or needing any knowledge of RAG techniques, we have an AI agent reasoning over SharePoint content. The old interface had some cryptic steps (such as having to mark the site collection URL as a secret), but this process was faster and more intuitive; it was fun in a new kind of way.
The main difference from Azure AI Foundry, in my opinion, is that this new experience is much cleaner and more organized around operationalizing AI for your organization instead of providing a basement lab for engineers to build agents. But that doesn’t mean it’s any less technical! As you can see from the screenshot of step #8 above, code samples and IDE connections are now front and center.
This is more than just a facelift. The old interface intimidated me a bit, seemingly throwing every aspect of AI at me at once; I found it hard to get my footings to start climbing. But in the new experience, you just sort of flow through the process step by step, adding in more capabilities as you fine tune your agent.
It’s the difference between free soloing up the mountain without any ropes and wearing a harness adorned with carabiners. While this is of course a subjective point, looking at the left-hand navigation of each side-by-side, it’s clear to me that Microsoft is really taking strides to make AI accessible enterprise-wide without slowing down engineers.
.svg)