Configure and manage agents in Visual Studio Code
Unit 6 of 10 · Module 7: Develop AI agents with Microsoft Foundry and Visual Studio Code
Read this lesson
Designer and YAML
Once you have a declarative agent, created in the portal or with the SDK, the real work is configuring it to match your requirements. This applies to prompt agents; hosted agents are configured in code. Foundry Toolkit gives you two ways to configure: the visual Agent Builder, and direct YAML editing. Here's the key idea: they're two views of the same settings. Change a value in Agent Builder, and the YAML updates; edit the YAML, and Agent Builder follows. In Agent Builder, you set the agent's name, a descriptive one that appears in lists and logs, and that teammates will see. You select the model deployment; the dropdown only shows models you've already deployed in your project. You add a description, so teammates understand the agent's purpose without reading its instructions. You write the system instructions, which define its behavior, personality, and response style. And every time you save, Foundry records a new version of the agent. Think of it this way: the name is what your code calls, through an agent reference, so keep it unique and stable, while each version's ID lets you point at one exact version.
Tuning and reading YAML
You can also tune the model. Temperature controls creativity and randomness: values from 0.1 to 0.3 give consistent, focused answers, and 0.7 to 1.0 give more creative, varied ones. For business agents doing structured tasks, 0.3 to 0.7 usually works well. Top p limits which words the model chooses from; the default of 1.0 suits most scenarios, and you can lower it for more constrained, predictable output. Now, the YAML file. YAML is plain text made of key, colon, value pairs, and indentation shows what belongs inside what. The first line is a comment that points to a schema, so the editor can check the file as you type. Then come the basics: version, name, description, and id. Metadata holds authors and tags, and each item in a list starts with a dash. The model section has the deployment id, and options for temperature and top p, indented underneath. Instructions start with a pipe symbol, which keeps several lines of text together, like the assistant's responsibilities and guidelines. And tools is an empty list, for now. So the file has four natural sections: metadata, model configuration, instructions, and tools.
Why YAML, and good habits
Editing YAML directly brings real advantages. Version control: track changes in Git, next to your application code. Bulk updates: change several settings at once, with confidence. Templates: reuse agent configurations for consistency. Code review: include agent changes in your normal reviews. And automation: scripts can generate or modify agent configurations. The extension also validates the YAML as you type, highlighting errors and suggesting fixes. A few habits keep agents reliable. Commit your YAML files to Git, so you can roll back, review, and track changes. Use descriptive names and tags, so agents are easy to find as your collection grows. Add comments that explain why you chose certain instructions or settings. Test in the playground after every change, because small changes can have unexpected effects. Start simple and iterate, since overly complex first drafts are hard to debug. And keep each agent focused on one clear purpose; agents that try to do too much behave inconsistently.
Facts from Microsoft's documentation: Microsoft Foundry Toolkit for Visual Studio Code overview; What is Microsoft Foundry Agent Service? (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.