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.
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.