Test, deploy, and integrate agents
Unit 8 of 10 · Module 7: Develop AI agents with Microsoft Foundry and Visual Studio Code
Before you start
Short explainers for ideas this lesson builds on. Watch these first if they're new to you.
Go deeper
Unlocks when you've watched the lesson.
Read this lesson
Test before it ships
Getting an agent from your desk to real users takes three steps: test it, deploy it to your project, and publish it as an endpoint others can call. Testing comes first, and both the Foundry portal and the VS Code extension give you a playground for it. Think of it as a tasting table, with five kinds of tasting. Happy path testing checks the ordinary, expected requests. Edge case testing throws in the awkward ones: vague questions, missing details, unusual requests, to see how the agent copes with uncertainty. Boundary testing asks for things outside the agent's job, to confirm it stays within the limits its instructions set. Multi-turn testing holds a longer conversation, checking that the agent remembers earlier messages and builds on them. And tool invocation testing checks that the right tool is called at the right moment, and that its results are used correctly. Write your results down. That record shows whether changes help, and catches regressions: things that used to work but quietly broke.
Deploy versus publish
Once testing looks good, you deploy. Deploying saves the agent's configuration into your Foundry project, so you and your team can keep testing and improving it. In the portal, open the agent, check its configuration and test results, select Save, and confirm the version and deployment settings. In VS Code, open the agent in Foundry Toolkit's Agent Builder and select Save to Foundry. For a hosted agent, open the Build menu in the developer tools, choose Deploy to Microsoft Foundry, pick a container configuration, and confirm. Either way, the agent stays inside your project workspace. Publishing goes further, in the Agent Application model that many projects still use. It moves a specific agent version into a managed Azure resource called an Agent Application, so people outside your project can call it. Publishing creates two things. The Agent Application: its own invocation URL, its own authentication policy, and its own Microsoft Entra agent identity. And a deployment: a running instance of that agent version inside the application, which you can start and stop. So the difference is scope: deploying keeps the agent in your project's back room; publishing opens a shopfront with its own address, and callers don't need access to your project. In the portal, you pick the version and select Publish. For a hosted agent built in code, VS Code's Foundry Toolkit can deploy it: you run its deploy command, choose the workspace and container configuration, and confirm. And with Foundry's newer agent model, every agent gets a stable endpoint and its own identity the moment it's created, so publishing then just means sharing it to Microsoft 365 and Teams.
Address, keys, and updates
A published agent gets a stable endpoint that speaks the Responses API. The address includes your Foundry resource, your project, and the application's name, and it stays the same when you roll out new versions, so the apps that call it don't break. Callers sign in with Microsoft Entra ID, and they need the Foundry User role, which used to be called Azure AI User, on the Agent Application. API keys aren't supported here. Now the part that catches people out. When you publish an Agent Application, it gets its own new identity, separate from the project's shared identity, like a new staff badge. Permissions don't move across to that badge automatically. So you must assign roles again, for every resource the agent touches. Skip it, and tool calls that worked perfectly during development suddenly fail with authorization errors after you publish. To check the endpoint, get an access token with the Azure CLI, then send a small test request with curl, passing the token as a bearer header. A four oh three, Forbidden, response means the caller is missing the Foundry User role on the application. To ship a new version, test your changes, then select Publish Updates in the agent playground. All traffic moves to the new version automatically, and the endpoint address doesn't change.
Integrate and run in production
Now connect your apps. In Foundry Toolkit, select your agent under My Resources, choose View Code, and pick a folder. It generates sample code that authenticates, connects, sends messages, and handles the responses. Four patterns are common. Web applications send user messages to the endpoint, show the replies, and keep the conversation history on the client. API-driven workflows call the agent from backend services, triggered by events or schedules, and use the responses to drive the next steps. Chatbot interfaces map each user session to a conversation and exchange messages in real time. And background automation runs agents on a schedule for recurring tasks, feeding in system data and updating business systems with the results. In production, keep an eye on five areas. Monitoring: track response times, tool success rates, error patterns, and token use, with Application Insights. Security: use managed identities, grant the least access needed, and set data retention policies. Cost: watch token usage, limit response length, and add rate limiting to prevent sudden spikes. Error handling: validate inputs, and retry temporary failures with exponential backoff, which means waiting a little longer after each failed try. And conversations: a legacy Agent Application endpoint is stateless, so your client stores the history and sends it each time, while newer agent endpoints can keep a conversation for you, as you'll see in the lab. Test, deploy, publish, integrate, and watch it run: that's the path from prototype to production.
Facts from Microsoft's documentation: What is Microsoft Foundry Agent Service?; Agent applications in Microsoft Foundry; Microsoft Foundry Toolkit for Visual Studio Code overview (CC BY 4.0), rewritten in Loop's own words and examples. Narration, animation, and quiz by Loop. Microsoft, Azure, and Microsoft Foundry are trademarks of Microsoft. Loop is independent and not affiliated with or endorsed by Microsoft.