Introduction

At Microsoft Build 2025 Azure Foundry was front and center with multiple sessions. Foundry was advertised as the PaaS offering for those wanting leverage Agentic AI in their application. This was in comparison to RAG and Semantic Kernel which were described as aligning more to IaaS.

Another recent development was my wife was diagnosed with cancer. For those who have either gone through this process or been there while a loved one does can observe first hand how confusing and information overload this process can be. From finding the latest information around treatment and trials to knowing when to call a doctor while undergoing treatment.

I decided this was a good opportunity to dive in and learn Azure Foundry and leverage it’s capabilities by grounding it in my wife’s diagnosis and treatment plan. For those that have worked with me previously developing a single purpose solution is not my style nor do I find it beneficial for others who are learning.

This blog post is a grounding, pun intended, post on my experience with developing an “ai-in-a-box” solution where anyone can update a simple .yaml and deploy a working instance of Azure Foundry as a chat bot. The full repository can be found: https://github.com/JFolberth/ai-in-a-box

To achieve just this “basic” functionality we will need to stand up a Static Website for our front end, an Azure Function for our API calls, Azure Foundry Instance and required components: a workspace, project, model and lastly an agent.

To help achieve this I leaned in heavy on topics around developer productivity. This means A LOT of GitHub Copilot, GitHub CoPilot Coding Agent, Azure Deployment Environments, and Azure DevBoxes just to collapse and incorporate a lot of my demos into one.

To help accommodate that this post will be referenced as an introduction to additional posts deep diving into each of these topics. On reversal, this post will continue to be updated and grow after each additional section is published.

Architecture Overview

This blog post outlines the architecture behind the AI In A Box quick start solution, focusing on secure, least-privileged integration across multiple Azure services. It breaks down the deployment into four main areas: a front end using Azure Static Web Apps, a backend using Azure Functions with system-assigned managed identity, a Foundry instance built on Azure Cognitive Services, and centralized logging using Log Analytics.

• The frontend is a public JavaScript app hosted on a free-tier Static Web App, secured via a backend Azure Function that acts as a gateway to Foundry services.
• The backend is a C# Azure Function on the Flex Consumption plan, using managed identity to securely access blob storage, Event Grid, and the Foundry agent. The function is granted Cognitive Services User and Blob Data Owner roles to ensure proper access.
• The Foundry resource includes a Cognitive Services account, a scoped project, and a GPT model. It is integrated with Application Insights for telemetry.
• The logging layer uses a centralized Log Analytics instance for consolidated observability across all components.

The post also includes a visual architecture diagram that maps out the request flow and logging paths. It concludes by emphasizing the multi-tier, secure, and scalable nature of the solution.

Deploying an Azure Foundry Agent

Azure Foundry is defined as:

“Create the future of AI using prebuilt and customizable models, tools, and safeguards available in popular developer workspaces.”

This sounds awesome. Even more so if you saw some of the incredible demos where presenters were able to quickly spin up agents and connected them all in the blink of the eye….via the portal. This left the question how could we tap into this power without leveraging the portal. This is a requirement for well built and maintained CI/CD processes.

In addition to configuring and deploying these agents via the Azure portal, several demonstrations showcased creating Foundry Agents directly from application code. Again, is this a best practice? It’s hard to definitively say, as this area is rapidly evolving. In my experience, however, most enterprise customers hesitate to let languages like Python, JavaScript, or C# directly create Azure resources.

Is there another way? The answer is yes.

Future Topics to Include

• Leveraging Azure Deployment Environments within the CI/CD Process
• Creating Developer Workstations via Azure Dev Box
• Grounding the Agent via Bing Search
• Building the Infrastructure via Azure Verified Modules
• Unlocking MCP Servers w/ GitHub CoPilot and Coding Agent