AgentSkillsProvider + Azure BlobStorage

[kpobb1989]

Is there a way to load skills from azure blob storage using AgentSkillsProvider in .NET?

The best workaround I found is to download skill files from blob storage locally at startup and then use the standard AgentSkillsProvider pointed at that local directory. The main problem is keeping those local files in sync when a skill file is updated in blob storage - it's unclear what the cleanest approach is to trigger a re-sync without restarting the whole application.

[jluocsa]

You do not need to stage skills on local disk for this scenario. AgentSkillsProvider is built around a pluggable AgentSkillsSource abstraction, which is the supported extension point for backing skills with a remote store such as Azure Blob Storage.

Extension point

AgentSkillsSource is a single asynchronous method, and the XML documentation explicitly calls out remote backends as a supported origin:

public abstract class AgentSkillsSource
{
    public abstract Task<IList<AgentSkill>> GetSkillsAsync(CancellationToken cancellationToken = default);
}

AgentSkillsProvider accepts a source directly via its constructor:

public AgentSkillsProvider(
    AgentSkillsSource source,
    AgentSkillsProviderOptions? options = null,
    ILoggerFactory? loggerFactory = null);

For each SKILL.md retrieved from Blob Storage, return an AgentInlineSkill instance constructed from the in-memory string content:

public sealed class BlobAgentSkillsSource(BlobContainerClient container) : AgentSkillsSource
{
    public override async Task<IList<AgentSkill>> GetSkillsAsync(CancellationToken ct = default)
    {
        var skills = new List<AgentSkill>();
        await foreach (BlobItem item in container.GetBlobsAsync(prefix: "skills/", cancellationToken: ct))
        {
            if (!item.Name.EndsWith("/SKILL.md", StringComparison.OrdinalIgnoreCase))
            {
                continue;
            }

            BlobClient blob = container.GetBlobClient(item.Name);
            string content = (await blob.DownloadContentAsync(ct)).Value.Content.ToString();

            (string name, string description, string instructions) = ParseSkillMd(content);
            skills.Add(new AgentInlineSkill(name, description, instructions));
        }
        return skills;
    }
}

This is the same shape as the in-tree AgentFileSkillsSource; the only difference is the I/O backend.

Refresh behavior

By default, AgentSkillsProvider resolves the AIContext once on first invocation and caches it for the lifetime of the provider (_contextTask in AgentSkillsProvider.cs). The single supported override is AgentSkillsProviderOptions.DisableCaching, which forces a rebuild on every invocation. There is no public Invalidate() API today.

For production workloads I recommend the following options, in order of preference:

Option 1 — Cache inside the source (recommended)

Disable provider caching and own the freshness policy inside BlobAgentSkillsSource:

services.AddSingleton(_ => new AgentSkillsProvider(
    new BlobAgentSkillsSource(container, ttl: TimeSpan.FromMinutes(5)),
    new AgentSkillsProviderOptions { DisableCaching = true }));

Inside the source, hold a (DateTimeOffset expiresAt, IList<AgentSkill> snapshot) tuple and re-list / conditionally re-download (ETag / If-None-Match) only when the TTL elapses. This pattern keeps per-invocation overhead bounded, propagates blob updates within a known SLA, and avoids any change-feed infrastructure.

Option 2 — Event-driven invalidation

If your refresh SLA is tighter than a TTL allows, subscribe to Blob Storage events via Event Grid → an HTTP-triggered handler that resets the in-source cache (Interlocked.Exchange(ref _cache, null)). The next agent invocation re-fetches. This adds an Event Grid subscription and a webhook surface to operate but provides near-real-time propagation.

Option 3 — Rebuild the provider

Register AgentSkillsProvider as Scoped, or rebuild it from an IOptionsMonitor<T> change callback. This drops every cache the framework holds, at the cost of higher per-rebuild overhead. Use only if Options 1 and 2 do not meet your requirements.

Recommendation

Start with Option 1. It is the lowest-operational-cost pattern, gives you explicit control over both caching layers, and is approximately 30 lines of code. Move to Option 2 if and when your business requirements demand sub-minute propagation of skill changes. I would avoid stacking BlobFuse2 under the existing file-based source — you inherit BlobFuse's caching semantics on top of AgentSkillsProvider's, and the change-notification story for FUSE mounts is not production-grade for this use case.

[kpobb1989]

@jluocsa Thank you, it is very useful guidance.