Azure AI Foundry: Automatically Provision With A Default Project

In the first post of this series, Origin shared our initial thoughts on the paradigm shift Azure AI Foundry is experiencing: the introduction of projects and a reorganization around agents. We are very excited about the possibilities of taking everything we’ve learned and achieved from building AI-powered apps on LangChain and other platforms and using Foundry to evolve our chatbots into enterprise digital assistants.

Introduction

Out here on the vanguard of Microsoft AI technology, where preview APIs of beta services leave little for Internet search results to pontificate about, we wanted to make sure that this “Agent-First” approach can be fully leveraged in a custom application as a backend and not just anAI configuration tool.

After playing with the enhanced Foundry UI and creating ecosystems of agents, our next thought more than likely was the same as yours:now how do we actually use this? With APIs for both Python and C#, we are really excited to dust off our Visual Studio licenses and put our curly braces back to work in the Foundry.

As part of every set of new Azure tires that I kick, I start with Azure CLI deployments instead of Hello World code. Provisioning PaaS components via the portal often applies default configurations not exposed through the UI, leaving developers in the dark when it comes time to script infrastructures for production. Therefore, I highly recommend a deployment-first approach so that your app’s launch is a click of a button instead of a weekend of error messages.

Therefore, this post will focus on some of the nuances we encountered when attempting to treat Foundry as a proper PaaS resource by automatically provisioning it along with the rest of the app’s resource group.The project I’m referencing heretofore uses GitHub + Actions instead of AzureDevOps, meaning the scripting language you’ll see is Bash on Linux instead of my typical comfort zone of PowerShell on Windows.

Part 1: Create a Foundry

In the spirit of brevity, I’m going to gloss over all theGitHub customizations (custom actions, Entra Id apps, parent/child workflows, etc.) and focus on the Azure CLI bits. The scripting snippets below live within a Bash utility .sh file that is called by the deployment script which is orchestrated via a GitHub action.

Let me make a few general callouts for the code in this article before jumping into Part 1:

• Any variables I don’t explicitly mention are relatively banal ($name, $resourceGroupName, $region, $sku, etc.) are common parameters required by most Azure CLI commands.
• I use semicolons because I was raised on C-style code and simply can’t live without them.
• Any _echo statements ending in _>&2; allow logging to the GitHub deployment output from the utility script functions so that Bash doesn’t interpret them as return values to the calling script.

Here’s the meat of the script for Part 1; the other sections below can be layered in via corresponding comments in the code:

We get off to a pretty standard start: check if the resource already exists, and politely move on if so. As part of our Foundry ramp up, we were delighted to learn that older deployment scripts which provisioned Azure OpenAI instances directly only needed a few tweaks:

• The _--kind parameter value changes to“AIServices” to create a top-level Foundry instance.
• The _{--custom-domain} property needs to be set(which can just be the name of the resource itself; no DNS or other network configuration is required).
• Sometimes PaaS resources will create a system-managed identity by default, but I like to be explicit and include _{--assign-identity} as part of each command that accepts this (or a similar) switch parameter.
• My native Chicagoian northcentralus _$region value won’t work here; new Azure resources seem to incubate in eastus or eastus2, so to be safe, use one of those for now.

After executing that first bit, let’s go to the new Foundry instance and start molding some serious agent metal…

So the first new lesson is that even though the goal is to use Foundry projects, we didn’t realize they were required to use agents. While this is easy enough to overcome manually, my aim is to create a fully-fledged Foundry ready to crank out agents. The fix is to manually set a “private” value on the PaaS instance to allow project creation. I imagine Microsoft will change this shortly, as I can’t think of a reason to default Foundry’s project creation setting to _false when there’s no easy way to change it.

Part 2: Allow Project Creation

The foresaid fix is to use the Azure ManagementAPI to nudge this setting into place. The Azure Foundry CLI documentation doesn’t list _{allowProjectManagement} as a command parameter nor is it present in the resulting JSON manifest of a Foundry resource. I simply file realizations like this under “have fun with beta tech” and move on:

A “feature” of Bash that I personally prefer over PowerShell is that it is more forgiving in terms of crafting JSON literals inline. There are no separate JSON files to manage or cryptic data structures to create; just use outer double quotes and inner single quotes to allow your string variables to be evaluated correctly as the JSON payload is parsed and sent to Azure.

However, I do recommend that you pay attention to spacing between braces and ticks and colons in your JSON, as the Azure management API can be a bit cantankerous in my experience. Far too often have I misinterpreted an Azure CLI error as bad syntax when the issue turned out to be “cosmetic JSON” that apparently (and anecdotally) wasn’t pretty enough for the REST API.

Part 3: Wait for it…

Despite invoking the management API via the _{az rest} CLI command (and not as a raw HTTP request), we don’t have the convenience of the _{-- wait} parameter that’s useful in handling long-running operations. Instead, we need to manually poll the resource and let the script move on only when the provisioning is completed.

While this isn’t novel in terms of Azure CLI usage or bleeding edge Foundry configuration, it’s important to state that your script could fail and potentially leave zombie Foundry instances out there stuck in a “failed” provisioning state if you don’t wait for the management API to do its thing.

Stash this reusablemethod somewhere in your script, and then call it as follows after invoking therequest from Part 2:

Part 4: Create A Project

Now that the Foundry instance explicitly supports project creation, we’re ready to finally create our project. This concept also isn’t part of the Azure CLI _{cognitiveservices} commands, so the management API once again comes to our rescue:

Fortunately, in this case, we don’t have to wait for this operation to complete (unless you are taking additional action against your new project instance). The things I want to do in the final part are all against the Foundry resource, so we’re good to go. One additional learning to point out is that Foundry projects appear in the resource group as separate PaaS components, which is a nice touch allowing more granular configuration.

Part 5: Lock It Down

With all these exciting updates to Azure AI Foundry come new RBAC roles to be aware of. Again, with the goal of full end-to-end automation, my deployment scripts also make sure that resources don’t just work, but work under the principle of least permissions. My deployment script accepts a _principalId which is the object id of an Entra app registration (in my case…it could be a user, a management identity, etc.).

Next, the code below assigns several roles to the given principal per our security requirements. However, from our experience playing with this, the following two are required to create and configurate agents in the Foundry UI against a project.

• Azure AI User
• Azure AI Developer

Another nuance we experienced is some inconsistency around these Foundry permission levels. While Azure AI Developer is required for project functionality, it is interestingly absent from what is listed in the Microsoft article linked above (which details distinguished yet unneeded roles such as “Azure AI Project Manager” and “Azure AI Account Owner”). Finally, if you go spelunking through all Azure role assignments, you’ll also find “Azure AI Administrator” and others. This could be anything from a simple documentation omission to an indication that the Foundry infrastructure is continually maturing.

Conclusion

As previously stated, I imagine Foundry project PaaS components will find their way into Azure CLI proper to make these deployments a bit simpler. When exploring any cutting edge technology, Origin Digital doesn’t just throw admin rights at a Hello World POC and call it day; we make sure that everything works in an automated, repeatable, and secure manner so that as Microsoft takes its next stride in AI, we are literally in lock step to leverage the latest models, agents, and features for our clients.