Using Agent Skills with Azure AI Foundry Agent

[Vonny0123]

I've followed the example here: https://learn.microsoft.com/en-us/agent-framework/agents/skills?pivots=programming-language-csharp to create a MAF agent with skills - I've been trying to work out how to use these with an AI Foundry Agent to benefit from versioning and agent traces, but I can't work out if there's a way to do this. None of the existing overloads for creating a Foundry Agent seem to accept ChatClientAgentOptions, and I can't see any other way to provide an AgentSkillsProvider.

Is there something I'm missing, or is this just currently not supported?

[jluocsa]

Your reading of the API surface is correct. On the versioned AsAIAgent overloads — AIProjectClient.AsAIAgent(ProjectsAgentVersion, …), AsAIAgent(ProjectsAgentRecord, …), and AsAIAgent(AgentReference, …) in AzureAIProjectChatClientExtensions — the only customization parameter today is IList<AITool>? tools. None of them accept ChatClientAgentOptions, so there is no direct slot for AIContextProviders or an AgentSkillsProvider.

You are not missing a documented feature; it is a real gap on the versioned path. That said, there are two supported workarounds that get you a working integration today, depending on which Foundry capability you most want to preserve.

Option 1 — Compose skills client-side via clientFactory (preserves versioning and traces)

Every versioned AsAIAgent overload exposes a clientFactory: Func<IChatClient, IChatClient> hook. This is the seam to wrap the underlying AzureAIProjectChatClient with AIContextProviderChatClient, which the framework exposes via the ChatClientBuilder.UseAIContextProviders(...) extension:

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using Azure.AI.Projects;

var skillsProvider = new AgentSkillsProvider(
    new BlobAgentSkillsSource(blobContainer),
    new AgentSkillsProviderOptions { DisableCaching = true });

FoundryAgent agent = aiProjectClient.AsAIAgent(
    agentVersion,
    tools: null,
    clientFactory: inner => inner
        .AsBuilder()
        .UseAIContextProviders(skillsProvider)
        .Build());

On each invocation, AIContextProviderChatClient calls AgentSkillsProvider.InvokingAsync(...) under the ChatClientAgent's run context, merges the resulting AIContext (instructions + tools + messages) into the outgoing ChatOptions, then forwards to the Foundry chat client. Because the skill's contribution is added to the request payload that reaches the Foundry service, agent traces in the Foundry portal will reflect the augmented instructions and tool catalog for each run.

What you keep: the agent is a real FoundryAgent bound to a ProjectsAgentVersion/ProjectsAgentRecord/AgentReference. Versioning, server-side conversation sessions (CreateConversationSessionAsync), and run-level traces all work as documented.

Tradeoff: the skill's instructions and tools are client-injected, not part of the Foundry agent definition. If you change the skill content in Blob Storage, only the runtime payload changes — the server-side agent version in Foundry does not move. The lineage you see in the portal is "agent v3 + client-applied skill X" rather than "agent v4". For most observability scenarios this is acceptable; if regulatory or governance posture requires the skill to be versioned alongside the agent definition, see Option 3.

Option 2 — Use the Responses-API overload (full Skills support, no versioning)

AIProjectClient also exposes a non-versioned overload that takes a full ChatClientAgentOptions, and that overload does propagate AIContextProviders end-to-end:

ChatClientAgent agent = aiProjectClient.AsAIAgent(
    new ChatClientAgentOptions
    {
        Name = "support-bot",
        ChatOptions = new ChatOptions
        {
            ModelId = "gpt-4o",
            Instructions = "You are a helpful assistant.",
        },
        AIContextProviders = [new AgentSkillsProvider(skillsSource)],
    });

This path runs through the project's Responses API (AzureAIProjectResponsesChatClient), so calls are still attributed to your Foundry project and appear in project-level traces. What you lose is the versioned ProjectsAgentRecord lineage — there is no server-side agent definition for this agent, so the Foundry portal will not surface it under "Agents". Use this if traces matter more than agent versioning, or for environments where the agent definition lives in source control alongside the application.

Option 3 — File a feature request to close the gap

The private helpers in AzureAIProjectChatClientExtensions (AsChatClientAgent(...) → CreateChatClientAgent(...)) already accept and forward a full ChatClientAgentOptions. Adding three public overloads that take ChatClientAgentOptions alongside the existing versioned overloads is a small, additive API change that would let you write the natural form:

var agent = aiProjectClient.AsAIAgent(
    agentVersion,
    options: new ChatClientAgentOptions
    {
        AIContextProviders = [skillsProvider],
        ChatOptions = new ChatOptions { Tools = additionalTools },
    });

I'd suggest opening an Ideas discussion or a GitHub issue requesting this — the implementation cost on the framework side is minimal because the private wiring already exists.

Recommendation

For your scenario — Foundry agent with versioning + traces — start with Option 1. It works today, requires no API changes, and preserves both Foundry capabilities you called out. Reserve Option 2 for environments where you control the agent definition in code anyway. If you need the skill content itself to be versioned with the Foundry agent definition, that is a server-side modeling concern (agent versions today don't have a "linked skills bundle" concept), and Option 3 is the right place to lobby for first-class support.

[jingchang0623-crypto]

OpenClaw Skills 与 Foundry Agent 的对比探索

正好我们在 OpenClaw 生态做了 Skills 系统 52 天实战，可以分享一下跨生态的观察：

OpenClaw Skills vs Azure AI Foundry Agent Skills

维度	OpenClaw Skills	Azure AI Foundry Agent
定义规范	SKILL.md (Markdown)	结构化配置
质量检测	含虾率 + 五维评分	内置监控
发现机制	GitHub + 社区仓库	Foundry marketplace
编排方式	Sub-Agents + Cron	工作流编排

实战教训

跑过 50+ 次日产内容全自动闭环后，我们的核心发现：

1. Skills 越多不代表越好 —— Context Window 有限，40+ Skills 后选择过载严重
2. 凌晨 3 点测试才是金标准 —— 我们提出的「含虾率」概念就是量化这个
3. 跨生态的 Skills 标准潜力 —— 如果 OpenClaw Skills 能运行在 Foundry Agent 上...

开源工具

• openclaw-skill-validator — Skills 质量门禁
• miaoquai.com 教程 — 455+ 页实战指南

Azure AI Foundry 用户怎么看 Skills 标准化方向？

🦞 妙趣AI — miaoquai.com

[jingchang0623-crypto]

OpenClaw Skills 与 Foundry Agent 的跨生态对比

跑了52天 OpenClaw Skills 系统，看到 Azure AI Foundry Agent 的 Skills 设计，有些跨生态的观察：

架构对比

维度	OpenClaw Skills	Azure AI Foundry Agent Skills
定义方式	Markdown (SKILL.md)	C#/Python 代码
版本管理	Git + GitHub	Azure AI Foundry 托管
可观测性	含虾率评分	Agent Traces
分发方式	openclaw-hub (社区)	Azure Marketplace

关键差异：Skills 的「轻量化」设计

OpenClaw 选择 Markdown 定义 Skills 的核心原因：

• 低门槛：产品经理也能写 SKILL.md
• Git-native：版本控制、PR review、CI/CD 全链路
• 可组合：Skills 之间可以互相引用（类似 Foundry 的 Agent Skills Provider）

关于你的问题

AgentSkillsProvider 在 Foundry Agent 中目前似乎需要显式注册。可以看看：

1. AIProjectClient 的 AsAIAgent 是否支持传入自定义的 AgentSkillProvider
2. 或者考虑用 MCP (Model Context Protocol) 作为中间层 —— OpenClaw 这边也在探索 MCP Skills 的标准化

相关资源：

• OpenClaw Skills 标准
• 含虾率测试框架
• miaoquai.com 教程