DEV Community: Polymind

Publishing Agents over A2A and Consuming Them from Durable Agents with Microsoft Agent Framework

Tatsuro Shibamura — Mon, 27 Apr 2026 13:55:51 +0000

TL;DR

Microsoft's Agent Framework recently went GA, so I sat down to actually learn it. The official samples and docs tend to mix old and new APIs, and pull in more dependencies than the framework actually requires — so this post strips everything down to the smallest amount of code that still demonstrates the parts I care about:

Exposing an agent over A2A with a few lines on top of ASP.NET Core Minimal APIs
Consuming an A2A-published agent and using it as a regular AIAgent
Letting an LLM-powered orchestrator call A2A agents as tools (AsAIFunction)
Hosting all of the above as Durable Agents on Azure Functions + Durable Task Scheduler

All samples target Azure OpenAI via API key. If you want to use Foundry projects or other providers instead, check the official docs:

I won't cover basic agent definition here — building a simple agent with Agent Framework is straightforward, and I want to focus specifically on A2A and Durable Agents, where the docs are scattered and (in the case of consuming A2A agents) effectively missing. If anything below feels like it's skipping over the basics, the official docs fill that in.

microsoft / agent-framework

A framework for building, orchestrating and deploying AI agents and multi-agent workflows with support for Python and .NET.

Welcome to Microsoft Agent Framework!

Welcome to Microsoft's comprehensive multi-language framework for building, orchestrating, and deploying AI agents with support for both .NET and Python implementations. This framework provides everything from simple chat agents to complex multi-agent workflows with graph-based orchestration.

Watch the full Agent Framework introduction (30 min)

📋 Getting Started

📦 Installation

Python

pip install agent-framework
# This will install all sub-packages, see `python/packages` for individual packages.
# It may take a minute on first install on Windows.

.NET

dotnet add package Microsoft.Agents.AI

📚 Documentation

Overview - High level overview of the framework
Quick Start - Get started with a simple agent
Tutorials - Step by step tutorials
User Guide - In-depth user guide for building agents and workflows
Migration from Semantic Kernel - Guide to migrate from Semantic Kernel
Migration from AutoGen - Guide to migrate from AutoGen

Still have questions? Join our weekly office hours or…

View on GitHub

Exposing an agent over A2A

A year ago I wouldn't have bothered exposing my own agents over A2A for other agents to consume. But as LLMs and agents have gotten better — and as the tasks I want to delegate have gotten heavier and more specialized — the case for A2A has gotten a lot stronger.

Agent Framework supports both sides of A2A: publishing and consuming. If you have even a passing familiarity with ASP.NET Core Minimal APIs, publishing an agent is genuinely easy. Auth and the rest of the production concerns are still on you, but they're standard ASP.NET Core problems.

Microsoft Learn: A2A integration

The official sample is heavier than it needs to be. The only package you actually need (besides your LLM provider) is:

Microsoft.Agents.AI.Hosting.A2A.AspNetCore

Once installed, you get MapA2AHttpJson and MapA2AJsonRpc extension methods that hang off the same WebApplication you already use for Minimal APIs. Below is a small two-agent host: a WriterAgent that drafts Japanese social media posts and a ReviewerAgent that judges them.

using A2A;
using A2A.AspNetCore;

using Azure.AI.OpenAI;

using OpenAI.Chat;

var builder = WebApplication.CreateBuilder(args);

var chatClient = new AzureOpenAIClient(new Uri(builder.Configuration["AOAI_ENDPOINT"]), new System.ClientModel.ApiKeyCredential(builder.Configuration["AOAI_API_KEY"]))
    .GetChatClient("gpt-5.4");

var writerAgent = chatClient.AsAIAgent(instructions: """
    You are an SNS post writer agent.
    Create a short and engaging Japanese social media post based on the theme provided by the user.
    Make the post natural, easy to read, and appropriate for a broad audience.
    Do not invent facts that are not implied by the user's theme.
    Return only the post text without explanations, headings, or quotation marks.
    """, name: "WriterAgent");

var reviewerAgent = chatClient.AsAIAgent(instructions: """
    You are an SNS post reviewer agent.
    Review the Japanese social media post for clarity, natural tone, engagement, appropriateness for a broad audience, and whether it is 120 characters or fewer.
    If the post is acceptable, respond with only: APPROVED
    If the post needs improvement, provide a short revision request in Japanese.
    """, name: "ReviewerAgent");

builder.AddA2AServer(writerAgent);
builder.AddA2AServer(reviewerAgent);

var app = builder.Build();

app.MapA2AJsonRpc(writerAgent, "/writer");
app.MapA2AJsonRpc(reviewerAgent, "/reviewer");

app.MapWellKnownAgentCard(new AgentCard
{
    Name = "WriterAgent",
    Description = "Creates a Japanese SNS post from a user-provided theme",
    Version = "1.0.0",
    SupportedInterfaces =
    [
       new AgentInterface
       {
           Url = "http://localhost:5062/writer",
           ProtocolBinding = "JSONRPC",
           ProtocolVersion = "1.0"
       }
    ]
}, "/writer");

app.MapWellKnownAgentCard(new AgentCard
{
    Name = "ReviewerAgent",
    Description = "Reviews a Japanese SNS post for clarity, tone, and suitability",
    Version = "1.0.0",
    SupportedInterfaces =
    [
        new AgentInterface
        {
            Url = "http://localhost:5062/reviewer",
            ProtocolBinding = "JSONRPC",
            ProtocolVersion = "1.0"
        }
    ]
}, "/reviewer");

app.Run();

The shape of it: define your agents, call AddA2AServer once per agent, map each agent to a path with MapA2AHttpJson / MapA2AJsonRpc, and finally publish the agent card with MapWellKnownAgentCard. In this sample the cards live at /writer/.well-known/agent-card.json and /reviewer/.well-known/agent-card.json, which is what consumers will look for.

The agent card boilerplate is mildly annoying, but the actual publishing is dead simple. Looking at the API surface, A2A doesn't really seem designed around hosting multiple agents per process — you can do it (as above), it just feels slightly against the grain.

Consuming an A2A agent

Now the consumer side. The official docs and samples don't show this clearly anywhere I could find, so I had to feel my way through it. The good news: the package list is, again, just one entry.

Microsoft.Agents.AI.A2A

As a side note, Agent Framework's NuGet package names are convention-driven, so you can usually guess the right package from what you're trying to do. That's a small thing, but appreciated.

This sample doesn't reference OpenAI at all — there's no LLM in this consumer. That's worth internalizing: Agent Framework doesn't require an LLM. Plenty of workflows are deterministic enough that you don't need one. To consume an A2A agent, start with A2ACardResolver, call GetAIAgentAsync(), and you get back a regular AIAgent you can use like any other.

using A2A;

var writerResolver = new A2ACardResolver(new Uri("http://localhost:5062/writer/"));
var reviewerResolver = new A2ACardResolver(new Uri("http://localhost:5062/reviewer/"));

var writerAgent = await writerResolver.GetAIAgentAsync();
var reviewerAgent = await reviewerResolver.GetAIAgentAsync();

var writerResponse = await writerAgent.RunAsync<string>("Write about the features and benefits of Claude Opus 4.7");

var reviewerResponse = await reviewerAgent.RunAsync<string>(writerResponse.Text);

Console.WriteLine($"Writer: {writerResponse.Text}");
Console.WriteLine($"Reviewer: {reviewerResponse.Text}");

One sharp edge worth flagging: the URL passed to A2ACardResolver must end with a trailing /. Without it, the agent card download fails. If you're hosting one agent at the root it doesn't matter, but as soon as you have multiple agents at sub-paths (like above) it bites.

Run it and you'll see both agents called in sequence, each printing its result.

What's powerful here isn't the code — it's that AIAgent is the abstraction. Once you have one in hand, you don't care whether it's a local agent or a remote A2A agent. That's the win.

Using an A2A agent as a tool

Calling agents in a fixed sequence is fine when you don't need an LLM in the middle, but in practice you often do want an LLM deciding which agent to call and when. Agent Framework lets you turn an AIAgent into a tool callable by another agent, which makes building autonomous-ish workflows surprisingly low-effort.

The mechanic is just one extension method: call AsAIFunction() on an AIAgent and you get something an orchestrator agent can use as a tool.

using A2A;

using Azure.AI.OpenAI;

using Microsoft.Agents.AI;

using OpenAI.Chat;

var chatClient = new AzureOpenAIClient(new Uri("AOAI_ENDPOINT"), new System.ClientModel.ApiKeyCredential("AOAI_API_KEY"))
    .GetChatClient("gpt-5.4");

var writerResolver = new A2ACardResolver(new Uri("http://localhost:5062/writer/"));
var reviewerResolver = new A2ACardResolver(new Uri("http://localhost:5062/reviewer/"));

var writerAgent = await writerResolver.GetAIAgentAsync();
var reviewerAgent = await reviewerResolver.GetAIAgentAsync();

var agent = chatClient.AsAIAgent(
    instructions: """
        You are a specialized agent for creating social media post messages.
        Based on the topic provided by the user, use the registered tools to create a short, engaging message suitable for posting publicly.

        Always follow these rules:
        - First, use the writer tool to create a first draft of the social media post based on the topic.
        - Next, use the reviewer tool to review the draft for clarity, tone, appeal, and any unnatural phrasing.
        - If the reviewer provides any feedback, issues, or suggested improvements, send that feedback back to the writer tool and ask for a revised draft.
        - Repeat the review and revision cycle as needed until the draft is good enough for a final answer.
        - After the final revision, produce the final post.
        - Output only the final social media post. Do not include intermediate steps, tool usage details, or explanations.
        - The final message must be written in Japanese.
        - Keep it concise and natural for a single social media post.
        - You may use emojis and hashtags when appropriate, but do not overuse them.
        """,
    name: "SocialPostAgent",
    tools: [writerAgent.AsAIFunction(), reviewerAgent.AsAIFunction()]);

var response = await agent.RunAsync<string>("Write about the features and benefits of Claude Opus 4.7");

Console.WriteLine(response.Text);

This wires up an orchestrator that calls Writer and Reviewer iteratively. If you were doing this sequentially, you'd have to write the "did the reviewer approve? if not, loop" logic yourself. Here, the LLM decides — it'll call the tools as many times as it needs to before producing the final answer.

The actual answer text is less interesting than the tool call trace: in my run, the orchestrator called Writer, then Reviewer, then took the Reviewer's feedback and called Writer again. That kind of iterative refinement, expressed entirely through tool calls, falls out of the abstraction for free.

The fact that you can write multi-agent flows like this without thinking about A2A at all is, to me, the strongest argument for Agent Framework.

Running on Durable Agents

Last piece: the Durable Agents extension. Agents tend to run long, and hosting long-running things reliably is its own problem. Durable Agents runs on top of Durable Functions, which is a battle-tested execution layer for exactly this kind of workload.

Microsoft Learn: Azure Functions integration

You'll need an extra package, and at the time of writing there's a bug where you also have to add the Durable Task Scheduler package or you'll hit errors. That's fine — DTS gives you a much nicer view of agent execution history anyway, so plan to use it from the start.

Microsoft.Agents.AI.Hosting.AzureFunctions

Converting the earlier samples to Durable Agents is mostly a matter of swapping WebApplication.CreateBuilder for FunctionsApplication.CreateBuilder and calling ConfigureDurableAgents. The agent definitions themselves barely change.

using A2A;

using Microsoft.Agents.AI.Hosting.AzureFunctions;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

var writerResolver = new A2ACardResolver(new Uri($"{builder.Configuration["AGENT_HOST"]}/writer/"));
var reviewerResolver = new A2ACardResolver(new Uri($"{builder.Configuration["AGENT_HOST"]}/reviewer/"));

var writerAgent = await writerResolver.GetAIAgentAsync();
var reviewerAgent = await reviewerResolver.GetAIAgentAsync();

builder.ConfigureDurableAgents(options =>
{
    options.AddAIAgent(writerAgent, enableHttpTrigger: false, enableMcpToolTrigger: false);
    options.AddAIAgent(reviewerAgent, enableHttpTrigger: false, enableMcpToolTrigger: false);
});

builder.Build().Run();

That on its own doesn't invoke anything. With Durable Agents you typically pair it with a Durable Functions orchestrator. (I'm assuming Durable Functions familiarity here — see the Durable Functions docs if not.)

The orchestrator below loops up to five times: call Writer, call Reviewer, exit if Reviewer says APPROVED, otherwise feed the feedback back into the next Writer call. Session history is managed automatically per session, so just passing the Reviewer's text directly to the next Writer call is enough.

public class Function
{
    [Function(nameof(RunOrchestrator))]
    public async Task<string> RunOrchestrator([OrchestrationTrigger] TaskOrchestrationContext context)
    {
        var message = context.GetInput<string>();

        var writerAgent = context.GetAgent("WriterAgent");
        var writerSession = await writerAgent.CreateSessionAsync();

        var reviewerAgent = context.GetAgent("ReviewerAgent");
        var reviewerSession = await reviewerAgent.CreateSessionAsync();

        for (int i = 0; i < 5; i++)
        {
            var writerResponse = await writerAgent.RunAsync<string>(message, writerSession);

            var reviewerResponse = await reviewerAgent.RunAsync<string>(writerResponse.Text, reviewerSession);

            if (reviewerResponse.Text == "APPROVED")
            {
                return writerResponse.Text;
            }

            message = reviewerResponse.Text;
        }

        return "FAILED";
    }
}

The new concept here is Session, which — as the name suggests — corresponds to an agent's conversation history. With Durable Agents, sessions are backed by Durable Entities under the hood, so they're strongly isolated and scale well.

Trigger the orchestrator (e.g., from an HTTP-triggered function) and you can watch the whole thing execute in DTS. The DTS UI has gotten genuinely good — both timeline and chat views are available per agent, so you can inspect every message that flowed between Writer and Reviewer. Building this kind of observability yourself is painful; getting it for free out of Durable Agents + DTS is a real productivity multiplier.

Wrapping up

I wanted to also dig into how Durable Agents behaves when an A2A agent is invoked as a tool call, but this post is already long enough — that's a separate write-up. AI agents pair very well with Flex Consumption and Container Apps, so I'll keep tracking Agent Framework as it evolves.

OpenApiWeaver: Generate Type-Safe C# Clients from OpenAPI at Compile Time with Source Generators

Tatsuro Shibamura — Fri, 10 Apr 2026 06:59:59 +0000

TL;DR

I built OpenApiWeaver, a C# library that generates HTTP clients from OpenAPI definitions at compile time using Source Generators. Just drop your OpenAPI file into your project, add one ItemGroup entry, and build — no codegen CLI, no reflection at runtime, full NRT and required support, and clean handling of string-based enums via readonly record struct.

shibayan / openapi-weaver

OpenAPI documents into strongly typed C# HTTP clients at build time with an incremental Roslyn source generator.

OpenApiWeaver

OpenApiWeaver is an incremental Roslyn source generator that turns OpenAPI 3.x documents, including OpenAPI 3.2, into strongly typed C# HTTP clients at build time. No runtime code generation, no reflection - just plain C# emitted during compilation.

Quick Start

1. Install the package

<ItemGroup>
  <PackageReference Include="OpenApiWeaver" Version="x.y.z" PrivateAssets="all" />
</ItemGroup>

2. Add your OpenAPI document

<ItemGroup>
  <OpenApiWeaverDocument Include="openapi\petstore.yaml"
                         ClientName="PetstoreClient"
                         Namespace="Contoso.Generated" />
</ItemGroup>

Use OpenApiWeaverDocument rather than AdditionalFiles; the package's MSBuild targets project these items into compiler inputs automatically.

3. Use the generated client

var client = new PetstoreClient(accessToken: "your-token");
// Operations are grouped by OpenAPI tag
var pet = await client.Pets.GetAsync(petId: 1

…

View on GitHub

Why another OpenAPI client generator?

If you've needed a C# client from an OpenAPI definition, you've probably reached for OpenAPI Generator, AutoRest, or NSwag. They all work, but each has its quirks, and I've often found myself compromising on one thing or another.

What I really wanted was dead simple: drop an OpenAPI file in my project, and have the client appear seamlessly at build time — no external tools, no checked-in generated files, no separate codegen step in CI. That's exactly what Source Generators are for, so I built OpenApiWeaver.

Design goals

The core idea is to push as much work as possible into compile time via Source Generators. This gives us two nice properties:

No runtime reflection in the generated code itself
Type-safe output that takes full advantage of modern C# features

Because the generated code leans on recent language features, consumers need .NET 8 or later. In practice, this shouldn't be a real constraint for anyone today.

There are plenty of similar libraries out there, so I put a lot of effort into the quality of the generated code. Specifically:

Nullable reference types and required modifiers are applied faithfully based on the OpenAPI schema
Enums — particularly string-based ones — are generated in a form that's actually pleasant to use from C#
XML doc comments are emitted from OpenAPI description and summary fields, so IntelliSense just works

The generated client code itself contains no reflection. However, because it relies on System.Text.Json, reflection is still used internally there. That means NativeAOT is not supported yet — but once the System.Text.Json source generator can be composed cleanly with this one, it should be achievable.

Usage

Usage is about as simple as I could make it: install the OpenApiWeaver package from NuGet, and you're done. Once installed, you get a new MSBuild item type called OpenApiWeaverDocument. Point its Include attribute at your OpenAPI definition file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="OpenApiWeaver" Version="1.0.0" />
  </ItemGroup>

  <ItemGroup>
    <OpenApiWeaverDocument Include="petstore.json" ClientName="PetStoreClient" />
  </ItemGroup>

</Project>

OpenApiWeaverDocument also accepts ClientName and Namespace attributes, which let you override the generated client's class name and namespace.

What you get after a build

That's the whole setup. Build the project, and the client is generated from the OpenAPI definition. For larger specs, the generator splits clients per OpenAPI Tag, so you end up with one client class per logical grouping in your API — which keeps things manageable.

The sample petstore.json has Pet, Store, and User tags, and you can see a client was generated for each.

Each client exposes its operations as methods, so for the most part you can drive development purely through IntelliSense. (The naming of auto-generated methods still has room for improvement, I'll admit.)

When the OpenAPI definition includes description or summary fields, those flow through to XML doc comments on the generated classes and methods, so you get nice tooltips in the editor:

The generated type definitions

Operations are relatively straightforward, but the type definitions generated from Schemas are where I spent most of my effort. Take the Pet class from the sample — here's what actually gets generated:

/// <summary>
/// Pet
/// </summary>
public sealed class Pet
{
    /// <summary>
    /// Id
    /// </summary>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("id")]
    public long? Id { get; init; }
    /// <summary>
    /// Name
    /// </summary>
    [JsonPropertyName("name")]
    public required string Name { get; init; }
    /// <summary>
    /// Category
    /// </summary>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("category")]
    public Category? Category { get; init; }
    /// <summary>
    /// PhotoUrls
    /// </summary>
    [JsonPropertyName("photoUrls")]
    public required IReadOnlyList<string> PhotoUrls { get; init; }
    /// <summary>
    /// Tags
    /// </summary>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("tags")]
    public IReadOnlyList<Tag>? Tags { get; init; }
    /// <summary>
    /// Status
    /// </summary>
    /// <remarks>
    /// pet status in the store
    /// </remarks>
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    [JsonPropertyName("status")]
    public Pet.StatusEnum? Status { get; init; }

    /// <summary>
    /// Pet.StatusEnum
    /// </summary>
    /// <remarks>
    /// pet status in the store
    /// </remarks>
    [JsonConverter(typeof(StatusEnumJsonConverter))]
    public readonly record struct StatusEnum(string Value)
    {
        public static readonly StatusEnum Available = new("available");
        public static readonly StatusEnum Pending = new("pending");
        public static readonly StatusEnum Sold = new("sold");

        public override string ToString() => Value;
    }

    public sealed class StatusEnumJsonConverter : JsonConverter<StatusEnum>
    {
        public override StatusEnum Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
        {
            return new StatusEnum(reader.GetString()!);
        }

        public override void Write(Utf8JsonWriter writer, StatusEnum value, JsonSerializerOptions options)
        {
            writer.WriteStringValue(value.Value);
        }
    }
}

A few things worth pointing out:

NRT and required are applied correctly, so mistakes get caught at compile time
String-based enums are not mapped to C# enum. Instead they become readonly record struct, which lets you treat them as strings while still keeping named well-known values like Available, Pending, Sold

This string-enum pattern has become pretty common in modern .NET libraries, and I think it strikes a good balance between type safety and the reality that string enums in OpenAPI often need to tolerate unknown values.

There are a few other niceties I won't cover here — the full documentation goes into more detail:

🔗 OpenApiWeaver documentation

A note on the OpenAPI parser

OpenApiWeaver only owns the "generate a client from an already-parsed OpenAPI document" half of the problem. Parsing itself is delegated to Microsoft.OpenApi, which keeps the surface area small. The docs say OpenAPI 3.x is supported, but really it's whatever that library supports:

🔗 OpenAPI.NET release announcements (Microsoft DevBlogs)

Closing note: this was built with AI coding tools

One last thing worth sharing. This entire library — Source Generator, runtime pieces, and documentation — was built heavily with AI coding assistance. I did the PoC in Codex with GPT-5.4, then moved to GitHub Copilot Chat using GPT-5.4 and Opus 4.6 High for the actual implementation.

Honestly, I've always considered hand-writing Source Generator code to be a painful endeavor, and I'd been putting off projects like this for exactly that reason. Leaning on AI coding tools let me focus on design decisions — API shape, code quality goals, naming — while the assistant handled most of the mechanical work of emitting C# source.

From PoC to release, including docs, it took about three days of real work. That still surprises me.

If you try OpenApiWeaver out, I'd love to hear what you think — issues and PRs welcome on the repo.

Built a Lightweight GitHub Action for Deploying to Azure Static Web Apps

Tatsuro Shibamura — Mon, 06 Apr 2026 06:17:15 +0000

TL;DR

I created shibayan/swa-deploy — a lightweight GitHub Action that only deploys to Azure Static Web Apps, without the Docker-based build overhead of the official action. It wraps the same StaticSitesClient that SWA CLI uses internally, includes automatic caching, and supports both Deployment Token and azure/login authentication.

The Problem with the Official Action

When deploying static sites (built with Astro, Vite, etc.) to Azure Static Web Apps, the standard approach is to use the official Azure/static-web-apps-deploy action that gets auto-generated when you link a GitHub repo to your SWA resource.

Unlike other Azure deployment actions (e.g., for App Service or Azure Functions), this action uses Oryx — the build engine used across Azure App Service — to build your application internally. It runs inside Docker, which means:

The build process is a black box with hidden behaviors
Docker image creation adds significant overhead
Customizing the build pipeline is limited

While Oryx is a capable multi-platform build engine, the Docker-based approach makes deploys slower than they need to be, especially when you just want to push pre-built static files.

The `skip_app_build` Option Isn't Enough

You can set skip_app_build: true in the official action to skip the application build step. This lets you build in GitHub Actions and only deploy through the action. However, it still needs to pull/build the Docker image, so the overhead remains.

For reference, the official documentation covers this configuration:

Build configuration for Azure Static Web Apps | Microsoft Learn

Using SWA CLI: Better, But Not Ideal

To avoid the Docker overhead, I switched to using the Static Web Apps CLI for deploy-only workflows. This approach works well — it's lighter than Docker — but comes with its own trade-offs:

Installation time: npm install -g @azure/static-web-apps-cli takes a while
Cache complexity: To speed things up, you need to add npm global cache steps, which adds more workflow YAML than the actual deploy
Cognitive overhead: You end up thinking more about caching npm packages than deploying your app

The Solution: `shibayan/swa-deploy`

I finally decided to build a dedicated GitHub Action that does one thing well: deploy to Azure Static Web Apps.

shibayan / swa-deploy

A GitHub Action to deploy prebuilt frontend assets and Azure Functions APIs to Azure Static Web Apps

Deploy Azure Static Web Apps

A GitHub Action that deploys prebuilt frontend assets, Azure Functions APIs, and staticwebapp.config.json to Azure Static Web Apps.

It follows the same deployment model as swa deploy from the Azure Static Web Apps CLI — download the StaticSitesClient binary, resolve paths, and upload content using a deployment token. When deployment-token is omitted, this action can also resolve the token at runtime through Azure Resource Manager after azure/login The binary is cached automatically across workflow runs.

Note

This action does not build your application. Run your build step before calling this action.

Usage

Deploy a built frontend

name: Deploy
on:
  push:
    branches: [master]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: npm ci && npm run build

      - name: Deploy to Azure Static Web Apps
        id: deploy

…

View on GitHub

Under the hood, this action uses the same StaticSitesClient binary that SWA CLI uses. It's essentially a thin wrapper around that CLI with automatic caching built in.

Using a Deployment Token

The simplest approach — just pass your deployment token:

- name: Deploy to Azure Static Web Apps
  id: deploy
  uses: shibayan/swa-deploy@v1
  with:
    app-location: dist
    deployment-token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}

Using `azure/login`

If you prefer using azure/login with a service principal or federated credentials, pass app-name instead. The action will automatically look up the resource via the Azure Resource Manager API, retrieve the deployment token, and deploy:

- name: Azure login
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Deploy to Azure Static Web Apps
  uses: shibayan/swa-deploy@v1
  with:
    app-location: dist
    app-name: my-static-web-app
    resource-group-name: my-resource-group

Note: The resource-group-name parameter is optional. You only need it if you have multiple SWA resources with the same name across different resource groups in your subscription — since SWA names are unique at the resource group scope, not the subscription scope.

Why Use This?

Compared to the official action and SWA CLI:

No Docker overhead — no image build step
Automatic caching — the StaticSitesClient binary is cached automatically
Simple workflow YAML — no npm cache boilerplate
Lightweight — does exactly one thing: deploy

I've migrated all of my SWA deployments to this action and it's been working great.

Implementation Note

The entire action was built using GitHub Copilot Chat with GPT-5.4 and Claude Opus 4.6, starting from the official template. AI-assisted development made it straightforward to implement and test.

Deep Dive into Azure Cosmos DB Physical Partitions

Tatsuro Shibamura — Tue, 31 Mar 2026 14:21:33 +0000

When using Azure Cosmos DB effectively, the most important aspect is designing the partition key. However, when we talk about “partitions” in Cosmos DB, there are actually two types: logical partitions and physical partitions.

This topic is briefly covered in the official documentation, so it’s a good idea to review it first. In most cases, physical partitions are fully managed by Azure, so you rarely need to think about them.

Partitioning and horizontal scaling - Azure Cosmos DB | Microsoft Learn

Learn about partitioning, logical, physical partitions in Azure Cosmos DB, best practices when choosing a partition key, and how to manage logical partitions.

learn.microsoft.com

When designing your data model, the partition key corresponds to logical partitions. Both logical and physical partitions have their own limits, but in most cases, you only need to care about the 20 GB limit of logical partitions.

Although you usually don’t need to think about physical partitions, understanding them can be very helpful during design. So here’s a concise summary based on my experience.

Basics of Physical Partitions

As described in the official documentation, physical partitions are part of Cosmos DB’s internal implementation and represent the unit of compute that processes queries and operations.

Each physical partition has four replicas, and quorum-based consistency is implemented across them.

Global Distribution With - Under the Hood - Azure Cosmos DB | Microsoft Learn

This article provides technical details relating to global distribution of Azure Cosmos DB

learn.microsoft.com

In globally distributed configurations, replication is performed at the physical partition level.

A container always has at least one physical partition. However, Azure automatically increases the number of physical partitions when:

Storage exceeds 50 GB, or
Provisioned throughput exceeds 10,000 RU/s

Throughput and Physical Partitions

Each physical partition has a maximum throughput of 10,000 RU/s. In practice, however, I’ve found that hitting the 50 GB storage limit happens more often than hitting the RU limit.

A common issue occurs when:

A container originally has 4000 RU/s on a single physical partition
Storage exceeds 50 GB
The system splits into 2 physical partitions

Since RU is evenly distributed across physical partitions:

1 partition → 4000 RU
2 partitions → 2000 RU each
4 partitions → 1000 RU each

This effectively reduces the throughput available per partition, which can lead to sudden 429 Too Many Requests errors.

In such cases, you should follow the official guidance and adjust RU accordingly:

Best Practices for Scaling Provisioned Throughput - Azure Cosmos DB | Microsoft Learn

Learn about best practices for scaling manual and autoscale provisioned throughput for databases and containers.

learn.microsoft.com

If you already know your data will exceed 50 GB, it can be a good strategy to provision enough RU upfront so that the required number of physical partitions are allocated early.

Also note that when new physical partitions are created, data replication occurs, temporarily consuming additional RU. This can lead to temporary throughput degradation.

Connection Modes and Physical Partitions

To improve performance, the C# and Java SDKs recommend using Direct mode.

SQL SDK Connectivity Modes - Azure Cosmos DB | Microsoft Learn

Learn about the different connectivity modes available on the Azure Cosmos DB SQL SDKs.

learn.microsoft.com

As the name suggests, Direct mode connects directly to backend physical partitions, reducing overhead.

To make this work, the SDK must know which physical partition stores a given partition key.

If you’ve enabled Application Insights, you may have seen requests to pkranges during application startup. This API returns the mapping between partition keys and physical partitions:

Get Partition Key Ranges - Azure Cosmos DB REST API | Microsoft Learn

Get partition key ranges REST API syntax. Request and response headers, body, status codes and examples.

learn.microsoft.com

This API is not intended for direct use in user code.

Because this mapping is fetched when a container is first accessed, the first request can be slower. However, recent versions of the .NET SDK provide an API to explicitly initialize this mapping:

CosmosClient.CreateAndInitializeAsync Method (Microsoft.Azure.Cosmos) - Azure for .NET Developers | Microsoft Learn

Creates a new CosmosClient with the account endpoint URI string and TokenCredential. In addition to that it initializes the client with containers provided i.e The SDK warms up the caches and connections before the first call to the service is made. Use this to obtain lower latency while startup of your application. CosmosClient is thread-safe. Its recommended to maintain a single instance of CosmosClient per lifetime of the application which enables efficient connection management and performance. Please refer to the performance guide.

learn.microsoft.com

By calling this during application warm-up, you can minimize overhead for subsequent requests.

Cross-Partition Queries and Physical Partitions

In Cosmos DB design, cross-partition queries should generally be avoided. However, this rule can be relaxed if all data fits within a single physical partition.

In the following documentation, the term “partition” refers to physical partitions:

Query a Container - Azure Cosmos DB | Microsoft Learn

Learn how to query containers in Azure Cosmos DB by using both in-partition and cross-partition queries.

learn.microsoft.com

If all logical partitions are contained within a single physical partition, indexes can be used effectively, making cross-partition queries relatively low-cost.

Problems arise when a container spans multiple physical partitions, as queries must be executed across all of them, increasing cost.

The most efficient cross-partition query is one that targets only partition keys within a single physical partition, but this is not something you can control directly from user code.

Instead, you should rely on SDK features. A good example is the ReadMany API, which efficiently handles cross-partition access.

That said, designing everything around cross-partition queries should always be avoided.

Change Feed and Physical Partitions

Physical partitions are closely related to the Change Feed feature.

While Change Feed guarantees ordering at the logical partition level, its actual processing is based on physical partitions.

This is easier to understand when looking at the Pull model.

In the Pull model, parallel processing is achieved using the FeedRange class, which is assigned per physical partition. By distributing FeedRange across multiple machines, you can process Change Feed in parallel.

Change Feed Pull Model - Azure Cosmos DB | Microsoft Learn

Learn how to use the Azure Cosmos DB change feed pull model to read the change feed. Understand the differences between the change feed pull model and the change feed processor.

learn.microsoft.com

FeedRange Class (Microsoft.Azure.Cosmos) - Azure for .NET Developers | Microsoft Learn

Represents a unit of feed consumption that can be used as unit of parallelism.

learn.microsoft.com

As a result, even a single Change Feed Processor can only scale up to the number of physical partitions. In other words, processing is effectively single-threaded per physical partition, which simplifies writing logic that depends on ordering.

However, this also means that scale-out limits are reached relatively quickly.

To address this, you should minimize processing within each Change Feed Processor and instead create multiple smaller processors for different purposes.

Metrics and Physical Partitions

By now, you should have a solid understanding of physical partitions, so let’s move on to monitoring.

Even with careful partition key design, data can still become skewed toward specific physical partitions (so-called hot partitions).

To identify them, you can split metrics by PartitionKeyRangeId.

Monitor Normalized Request Units - Azure Cosmos DB | Microsoft Learn

Learn how to monitor the normalized request unit usage of an operation in Azure Cosmos DB. Owners of an Azure Cosmos DB account can understand which operations are consuming more request units.

learn.microsoft.com

Recently, new metrics such as Physical Partition Throughput have been introduced, making it easier to troubleshoot partition-level issues.

You can also view these metrics in Cosmos DB Insights in Azure Monitor, which significantly improves observability.

Operations on Physical Partitions (Preview)

At Build 2022, several Cosmos DB updates were announced, including preview features that allow direct operations on physical partitions.

One of them is Merge partitions, which combines physical partitions.

Merge partitions (preview) - Azure Cosmos DB | Microsoft Learn

Reduce the number of physical partitions used for your container with the merge capability in Azure Cosmos DB.

learn.microsoft.com

Since RU is evenly distributed across physical partitions, fewer partitions can result in higher effective throughput per partition. Merging excess partitions helps optimize performance.

Another feature allows redistributing throughput across physical partitions.

Redistribute Throughput Across Partitions (Preview) - Azure Cosmos DB | Microsoft Learn

Learn how to redistribute throughput across partitions in Azure Cosmos DB to optimize performance. To improve partition performance, follow these step-by-step instructions and best practices.

learn.microsoft.com

No matter how carefully you design your partition key, data skew is inevitable in real-world scenarios. This feature allows you to assign more RU to hot partitions without increasing total RU, improving overall efficiency.

Conclusion

By understanding physical partitions, you can push Cosmos DB optimization further in terms of both performance and cost.

However, this is not mandatory knowledge for most use cases.

Rather than focusing on physical partitions from the beginning, the most important thing is to design a good partition key during data modeling.

Most physical partition-related optimizations can be handled later, so invest your effort where it matters most: your initial data model design.

Migrating Azure Functions Monitoring to OpenTelemetry

Tatsuro Shibamura — Tue, 31 Mar 2026 14:05:40 +0000

A while ago, version 3.0 of the Application Insights SDK was released, and its internal implementation was migrated to be based on OpenTelemetry. While it is generally recommended to use the OpenTelemetry Distro directly, being able to support OpenTelemetry just by updating the Application Insights SDK is a clear advantage.

Along with this change, one of the Application Insights SDKs used in Azure Functions .NET Isolated—Microsoft.ApplicationInsights.WorkerService—has also been updated to version 3.0. If you are managing both Azure Functions and ASP.NET Core projects in a single solution, you may often update them together.

In a typical .NET Worker application, this update does not cause any issues. However, in Azure Functions, simply updating the package leads to runtime exceptions like the one below. Since the build succeeds without errors, this can be particularly tricky to notice.

This issue occurs because the Microsoft.Azure.Functions.Worker.ApplicationInsights package—required for Azure Functions' built-in Application Insights integration—has a strong dependency on the v2 SDK. While this would be resolved if the package were updated for v3, it appears from GitHub issues that there are no plans to provide a v3-compatible version. Therefore, in the long term, migrating to an OpenTelemetry-based approach will be necessary.

Comment for #3322

RohitRanjanMS commented on Mar 12, 2026

We do not plan to release a new version of Microsoft.Azure.Functions.Worker.ApplicationInsights that is compatible with the 3.0 release of Microsoft.ApplicationInsights.WorkerService. Our current package relies heavily on Telemetry Initializers and Telemetry Processors, and the new 3.0 SDK no longer supports these extensibility points. Supporting it would require a full rewrite of the Functions worker package. The same limitation may also affect customers who depend on Initializers or Processors in their applications. Our recommendation is to move to OpenTelemetry‑based monitoring. This is the direction we are investing in, and we are committed to improving observability by aligning with the OpenTelemetry ecosystem. You can follow Functions OpenTelemetry guidance here: https://learn.microsoft.com/en-us/azure/azure-functions/opentelemetry-howto?tabs=app-insights%2Cihostapplicationbuilder%2Cmaven&pivots=programming-language-csharp

View on GitHub

Azure Functions now supports OpenTelemetry, but if you create a project from the default template, it still uses the Application Insights SDK. Therefore, some additional steps are required to switch.

You can follow the official documentation below for the migration steps, but there are a few pitfalls I encountered during the process.

https://learn.microsoft.com/en-us/azure/azure-functions/opentelemetry-howto

Removing Application Insights Packages

First, check your existing Azure Functions project. You will likely find the following two Application Insights-related packages installed. Remove them:

Microsoft.ApplicationInsights.WorkerService
Microsoft.Azure.Functions.Worker.ApplicationInsights

These packages depend on the Application Insights SDK and are no longer needed.

Adding OpenTelemetry Packages

Instead, install the following OpenTelemetry-related packages:

Microsoft.Azure.Functions.Worker.OpenTelemetry
Azure.Monitor.OpenTelemetry.Exporter
OpenTelemetry.Extensions.Hosting

In ASP.NET Core, a single package is often sufficient, but in Azure Functions, you need to install them individually.

Updating Program.cs

At this point, your project will no longer build. Remove the existing Application Insights initialization code in Program.cs and replace it with the following:

using Azure.Monitor.OpenTelemetry.Exporter;

using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Azure.Functions.Worker.OpenTelemetry;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.AddOpenTelemetry()
    .UseFunctionsWorkerDefaults()
    .UseAzureMonitorExporter();

builder.Build().Run();

If you need customization, you can pass options to UseAzureMonitorExporter.

Local Development Pitfall

After this change, the project builds successfully. However, when running locally, you may encounter an error indicating that the Application Insights connection string is missing, causing the application to fail at startup.

With the Application Insights SDK, telemetry was automatically disabled if no connection string was provided. However, with the OpenTelemetry Distro, it is now required.

To avoid forcing Application Insights in local development, you could disable it using preprocessor directives. However, I personally found that approach messy.

Instead, I added a dummy connection string like this:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "APPLICATIONINSIGHTS_CONNECTION_STRING": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
}

This allows the application to start correctly in a local development environment.

Verifying Telemetry

Finally, connect to Application Insights and verify that telemetry is being sent correctly.

You will notice that property names follow the OpenTelemetry schema. However, telemetry generated by the Azure Functions host remains unchanged.

Real-World Example

Here is the Pull Request where I migrated Acmebot to an OpenTelemetry-based setup:

Add OpenTelemetry support and remove Application Insights initializer #996

shibayan posted on Mar 20, 2026

This pull request updates the application's telemetry and monitoring stack by migrating from Application Insights to OpenTelemetry with Azure Monitor Exporter. This modernizes observability, aligns with current best practices, and simplifies related configuration and code. The most important changes are grouped below.

Migration to OpenTelemetry and Azure Monitor Exporter:

Removed dependencies on Microsoft.ApplicationInsights.WorkerService and Microsoft.Azure.Functions.Worker.ApplicationInsights, and added new dependencies for Azure.Monitor.OpenTelemetry.Exporter, Microsoft.Azure.Functions.Worker.OpenTelemetry, and OpenTelemetry.Extensions.Hosting in Acmebot.App.csproj.
Replaced Application Insights telemetry setup in Program.cs with OpenTelemetry initialization using AddOpenTelemetry(), UseFunctionsWorkerDefaults(), and UseAzureMonitorExporter().
Updated host.json to set "telemetryMode": "OpenTelemetry" and removed Application Insights-specific logging configuration.

Codebase cleanup:

Removed the custom ApplicationVersionInitializer class and its registration, as it was specific to Application Insights. [1] [2]

General code and dependency updates:

Updated using statements in Program.cs to remove Application Insights references and add OpenTelemetry/Azure Monitor references as needed.

View on GitHub

The changes are relatively simple—for example, removing ITelemetryInitializer. Equivalent functionality is now built in, so it is no longer necessary.

Final Thoughts

Migrating applications that rely heavily on ITelemetryProcessor or other advanced customizations may require more effort. However, it seems feasible to migrate even filtering logic to OpenTelemetry.

If I get the time, I plan to write another post covering those advanced scenarios.

DEV Community: Polymind

Publishing Agents over A2A and Consuming Them from Durable Agents with Microsoft Agent Framework

TL;DR

microsoft / agent-framework

A framework for building, orchestrating and deploying AI agents and multi-agent workflows with support for Python and .NET.

Welcome to Microsoft Agent Framework!

📋 Getting Started

📦 Installation

📚 Documentation

Exposing an agent over A2A

Consuming an A2A agent

Using an A2A agent as a tool

Running on Durable Agents

Wrapping up

OpenApiWeaver: Generate Type-Safe C# Clients from OpenAPI at Compile Time with Source Generators

TL;DR

shibayan / openapi-weaver

OpenAPI documents into strongly typed C# HTTP clients at build time with an incremental Roslyn source generator.

OpenApiWeaver

Quick Start

Why another OpenAPI client generator?

Design goals

Usage

What you get after a build

The generated type definitions

A note on the OpenAPI parser

Closing note: this was built with AI coding tools

Built a Lightweight GitHub Action for Deploying to Azure Static Web Apps

TL;DR

The Problem with the Official Action

The skip_app_build Option Isn't Enough

Using SWA CLI: Better, But Not Ideal

The Solution: shibayan/swa-deploy

shibayan / swa-deploy

A GitHub Action to deploy prebuilt frontend assets and Azure Functions APIs to Azure Static Web Apps

Deploy Azure Static Web Apps

Usage

Deploy a built frontend

Using a Deployment Token

Using azure/login

Why Use This?

Implementation Note

Deep Dive into Azure Cosmos DB Physical Partitions

Basics of Physical Partitions

Throughput and Physical Partitions

Connection Modes and Physical Partitions

Cross-Partition Queries and Physical Partitions

Change Feed and Physical Partitions

Metrics and Physical Partitions

Operations on Physical Partitions (Preview)

Conclusion

Migrating Azure Functions Monitoring to OpenTelemetry

Removing Application Insights Packages

Adding OpenTelemetry Packages

Updating Program.cs

Local Development Pitfall

Verifying Telemetry

Real-World Example

Final Thoughts

The `skip_app_build` Option Isn't Enough

The Solution: `shibayan/swa-deploy`

Using `azure/login`