I’ve written about both Semantic Kernel and AutoGen on this blog before, and the split was always a bit awkward. Semantic Kernel was the .NET-first, enterprise-leaning option with kernels, plugins, filters and telemetry. AutoGen was the Python-friendly playground for multi-agent conversations. Two teams at Microsoft, two SDKs, two mental models for what was basically the same job.

That split is done. The two teams have shipped one framework, the Microsoft Agent Framework (MAF), and they’re calling it the direct successor to both. From the overview docs:

Agent Framework combines AutoGen’s simple agent abstractions with Semantic Kernel’s enterprise features (session-based state management, type safety, middleware, telemetry) and adds graph-based workflows for explicit multi-agent orchestration.

So: .NET and Python with the same API shape, a hosting story tied to Microsoft Foundry, model clients for most of the names you’d expect (Azure OpenAI, OpenAI, Anthropic, Ollama, GitHub Copilot, Google Gemini, ONNX, a few more), and a graph-based workflow engine that neither parent framework really had.

What follows is a tour of what MAF feels like once you start typing. Agents and workflows, the building blocks underneath them, the orchestration patterns, and the hosting story. Code in both Python and C#, because the framework treats them as peers and so should the post.

The mental model

Everything in MAF is either an agent or a workflow.

PrimitiveWhat it isAgentA single LLM-driven loop that can call tools and MCP servers. Use it when the task is open-ended or conversational.WorkflowA graph of executors (agents, functions, or custom nodes) connected by edges, with type-safe routing, checkpointing, and human-in-the-loop support. Use it when the process has well-defined steps.

The docs are also honest about when you should use neither:

If you can write a function to handle the task, do that instead of using an AI agent.

Which I appreciate. Half the agent posts I read in 2025 were people building agents for jobs a case statement could have done.

Underneath both pillars, the same five names keep coming up: ChatClient (the model abstraction), AgentSession (state), ContextProvider (memory and dynamic instructions), middleware (interception), and MCP clients (tool integration). Learn those and most of the framework stops being surprising.

Installing

Python:

bash

pip install agent-framework

.NET:

bash

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Foundry
dotnet add package Azure.AI.Projects
dotnet add package Azure.Identity

The Python install is one meta-package that pulls in subpackages for each provider. On .NET you pick the integration packages you need.

Hello agent

Smallest possible agent in C#, against Azure OpenAI:

csharp

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;

var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")
    ?? throw new InvalidOperationException("AZURE_OPENAI_ENDPOINT is not set.");
var deploymentName = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME") ?? "gpt-4o-mini";
AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
    .GetChatClient(deploymentName)
    .AsAIAgent(
        instructions: "You are good at telling jokes.",
        name: "Joker");
Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));
await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
    Console.WriteLine(update);
}

Pick a client, call .AsAIAgent(...), get an AIAgent. Run it or stream it.

The Python version of the same shape, this time against a Foundry project:

python

import asyncio
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

async def main() -> None:
    client = FoundryChatClient(
        project_endpoint="https://your-project.services.ai.azure.com",
        model="gpt-4o",
        credential=AzureCliCredential(),
    )
    agent = Agent(
        client=client,
        name="HelloAgent",
        instructions="You are a friendly assistant. Keep your answers brief.",
    )
    result = await agent.run("What is the capital of France?")
    print(f"Agent: {result}")
    print("Agent (streaming): ", end="", flush=True)
    async for chunk in agent.run("Tell me a one-sentence fun fact.", stream=True):
        if chunk.text:
            print(chunk.text, end="", flush=True)
    print()

if __name__ == "__main__":
    asyncio.run(main())

A couple of things you might miss on first read. stream=True is a flag on the same run call, not a separate API. And auth goes through azure-identity, so there's no API key sitting in the sample. Small choices, but the kind of small choice that tells you whether the people who built it have ever had to clean up after a hardcoded key getting committed.

Tools

Tools are how the agent does anything beyond producing tokens. In Python you decorate a function with @tool. In .NET you wrap a method with AIFunctionFactory.Create.

Python:

python

from random import randint
from typing import Annotated
from agent_framework import Agent, tool
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
from pydantic import Field

# NOTE: approval_mode="never_require" is fine for samples.
# Use "always_require" in production for human-in-the-loop confirmation.
@tool(approval_mode="never_require")
def get_weather(
    location: Annotated[str, Field(description="The location to get the weather for.")],
) -> str:
    """Get the weather for a given location."""
    conditions = ["sunny", "cloudy", "rainy", "stormy"]
    return f"The weather in {location} is {conditions[randint(0, 3)]} with a high of {randint(10, 30)}°C."

agent = Agent(
    client=FoundryChatClient(credential=AzureCliCredential()),
    name="WeatherAgent",
    instructions="You are a helpful weather agent. Use the get_weather tool to answer questions.",
    tools=[get_weather],
)

.NET:

csharp

using System.ComponentModel;
using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

[Description("Get the weather for a given location.")]
static string GetWeather([Description("The location to get the weather for.")] string location)
    => $"The weather in {location} is cloudy with a high of 15°C.";
AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
    .GetChatClient(deploymentName)
    .AsAIAgent(
        instructions: "You are a helpful assistant",
        tools: [AIFunctionFactory.Create(GetWeather)]);
Console.WriteLine(await agent.RunAsync("What is the weather like in Amsterdam?"));

The approval_mode argument is one I wish more frameworks shipped with. It lets the framework pause a run, surface the tool call to a human, and resume once someone clicks approve. Not a bolt-on, just a flag.

Tools can also come from MCP servers. MAF ships an MCP client, so you can pull in remote tool catalogues without wrapping anything yourself. That matters more in 2026 than it would have a year ago, because the useful tool surfaces (databases, internal APIs, SaaS connectors) are showing up as MCP servers now instead of per-framework adapters.

Sessions: state that carries across turns

A single run call is stateless. To keep conversation history around, create an AgentSession:

csharp

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));
Console.WriteLine(await agent.RunAsync(
    "Now add some emojis and tell it in the voice of a pirate's parrot.",
    session));

Python is the same shape:

python

session = agent.create_session()

result = await agent.run("My name is Alice and I love hiking.", session=session)
print(f"Agent: {result}\n")
result = await agent.run("What do you remember about me?", session=session)
print(f"Agent: {result}")

The session holds messages, tool call history, and arbitrary state that providers can read and write. This is the piece SK had and AutoGen mostly punted on, and it’s what makes MAF feel like an SDK you’d ship rather than a demo you’d show.

Context providers: memory you can actually reason about

If you’ve built agents the hard way, you know what “memory” usually means: injecting user preferences, retrieved knowledge, or dynamic instructions into every call without losing your mind. MAF formalises this with context providers. They’re objects with before_run and after_run hooks that can read and mutate the prompt and the session state.

python

from agent_framework import Agent, AgentSession, ContextProvider, SessionContext

class UserMemoryProvider(ContextProvider):
    """A context provider that remembers user info in session state."""
    DEFAULT_SOURCE_ID = "user_memory"
    def __init__(self):
        super().__init__(self.DEFAULT_SOURCE_ID)
    async def before_run(self, *, agent, session, context: SessionContext, state):
        user_name = state.get("user_name")
        if user_name:
            context.extend_instructions(
                self.source_id,
                f"The user's name is {user_name}. Always address them by name.",
            )
        else:
            context.extend_instructions(
                self.source_id,
                "You don't know the user's name yet. Ask for it politely.",
            )
    async def after_run(self, *, agent, session, context: SessionContext, state):
        for msg in context.input_messages:
            text = msg.text if hasattr(msg, "text") else ""
            if isinstance(text, str) and "my name is" in text.lower():
                state["user_name"] = text.lower().split("my name is")[-1].strip().split()[0].capitalize()

Attach it to the agent and it runs on every call:

python

agent = Agent(
    client=client,
    name="MemoryAgent",
    instructions="You are a friendly assistant.",
    context_providers=[UserMemoryProvider()],
)

I like this design. Anything you’d otherwise stitch in by hand (RAG retrieval, a user-preferences cache, a safety filter) is a context provider. They compose cleanly because each one only writes to its own source_id slice of state, so two providers can't quietly stomp on each other's keys.

Workflows: graphs of executors

This is the part of MAF I was most curious about. AutoGen had conversations between agents. SK had plan-and-execute. Neither could really say “run this graph deterministically, with checkpoints, with a human approval node sitting on this edge.” Workflows are the answer to that gap.

A workflow is built from executors (anything that processes an input and produces an output) connected by edges. Simplest possible workflow in C#:

csharp

using Microsoft.Agents.AI.Workflows;

Func<string, string> uppercaseFunc = s => s.ToUpperInvariant();
var uppercase = uppercaseFunc.BindAsExecutor("UppercaseExecutor");
var reverse = new ReverseTextExecutor();
WorkflowBuilder builder = new(uppercase);
builder.AddEdge(uppercase, reverse).WithOutputFrom(reverse);
var workflow = builder.Build();
await using Run run = await InProcessExecution.RunAsync(workflow, "Hello, World!");
foreach (WorkflowEvent evt in run.NewEvents)
{
    if (evt is ExecutorCompletedEvent executorComplete)
    {
        Console.WriteLine($"{executorComplete.ExecutorId}: {executorComplete.Data}");
    }
}
internal sealed class ReverseTextExecutor() : Executor<string, string>("ReverseTextExecutor")
{
    public override ValueTask<string> HandleAsync(string message, IWorkflowContext context, CancellationToken cancellationToken = default)
        => ValueTask.FromResult(string.Concat(message.Reverse()));
}

In Python it’s Executor classes or @executor-decorated functions, wired with a WorkflowBuilder:

python

from agent_framework import Executor, WorkflowBuilder, WorkflowContext, executor, handler
from typing_extensions import Never

class UpperCase(Executor):
    def __init__(self, id: str):
        super().__init__(id=id)
    @handler
    async def to_upper_case(self, text: str, ctx: WorkflowContext[str]) -> None:
        await ctx.send_message(text.upper())

@executor(id="reverse_text")
async def reverse_text(text: str, ctx: WorkflowContext[Never, str]) -> None:
    await ctx.yield_output(text[::-1])

upper = UpperCase(id="upper_case")
workflow = WorkflowBuilder(start_executor=upper).add_edge(upper, reverse_text).build()
events = await workflow.run("hello world")
print(events.get_outputs())  # ['DLROW OLLEH']py

The graph API gives you fan-out, fan-in, switch/case, loops, and superstep-based checkpointing. The framework can persist workflow state at each superstep boundary, so a crash mid-workflow doesn’t lose anything: restart the process and it picks up where it stopped. That’s the durability story SK never quite finished.

For lower-ceremony cases there’s a functional workflow API where the whole thing is one async function and the framework infers the graph:

python

from agent_framework import Agent, workflow

writer = Agent(name="WriterAgent", instructions="Write a short poem (4 lines max) about the given topic.", client=client)
reviewer = Agent(name="ReviewerAgent", instructions="Review the given poem in one sentence. Is it good?", client=client)

@workflow
async def poem_workflow(topic: str) -> str:
    poem = (await writer.run(f"Write a poem about: {topic}")).text
    review = (await reviewer.run(f"Review this poem: {poem}")).text
    return f"Poem:\n{poem}\n\nReview: {review}"

result = await poem_workflow.run("a cat learning to code")

Agents inside workflows are just function calls. No special wrappers, no message bus to learn. The workflow engine still sees the structure because each await boundary becomes an executor.

Orchestration patterns

On top of the workflow graph, MAF ships pre-built orchestration builders for the patterns you actually want.

BuilderTopologyUse whenSequentialBuilderA then B then CA pipeline of agents that each see the conversation so far.ConcurrentBuilderFan-out, fan-inSeveral agents work on the same input in parallel; an aggregator combines the results.HandoffBuilderMeshOne agent decides which other agent should take over. The framework auto-registers handoff tools, so the LLM literally calls transfer_to_refund_agent(...).GroupChatBuilderManager plus participantsRound-table conversation with a selector that picks who speaks next.MagenticBuilderManager-led plan and executeThe Magentic pattern from the AutoGen research: a planning manager that drives a team of specialist agents to solve a harder task.

Sequential workflow in five lines:

python

from agent_framework.orchestrations import SequentialBuilder

workflow = SequentialBuilder(participants=[writer, reviewer], output_from="all").build()
result = await workflow.run("Write a tagline for a budget-friendly eBike.")

A handoff workflow looks like a triage agent with three specialists wired into a mesh. The triage agent doesn’t call the specialists directly. It calls a handoff tool that the framework auto-generated, and the workflow engine routes the conversation to the chosen specialist while preserving the history:

python

from agent_framework.orchestrations import HandoffBuilder

triage, refund, order, returns = create_agents(client)
workflow = HandoffBuilder(
    coordinator=triage,
    participants=[refund, order, returns],
).build()

Magentic is the one I keep coming back to. You hand it a couple of specialist agents (a researcher and a coder in the sample) and a question like “estimate the energy efficiency of these ML models”. A manager LLM plans the work, decides who runs each step, and reconciles the outputs. It’s the AutoGen Magentic pattern, but now there’s checkpointing and an event stream around it, so you can actually see what happened when a run goes sideways at 2am.

Providers

MAF doesn’t pick a model vendor for you. The current set, straight from the samples directory:

• Microsoft Foundry, the new home for Azure-hosted agents
• Azure OpenAI, both chat completions and responses APIs
• OpenAI direct
• Anthropic
• Ollama for local models
• GitHub Copilot SDK
• Amazon Bedrock
• Google Gemini
• ONNX for on-device inference
• Copilot Studio
• Custom, for when you want to bring your own client

Switching providers is a constructor change. The AIAgent / Agent surface above doesn't move. That's the part I've been waiting on since SK and AutoGen split the world in two.

Middleware

Cross-cutting concerns (logging, retry, redaction, guardrails) are middleware. The pattern is the next delegate you'd expect from ASP.NET or Express. The samples include an auto_retry example that wraps an agent in exponential backoff without the agent code knowing anything about it. Middleware composes, and it works around a single agent or around a whole workflow node.

Hosting

A few of the hosting targets that ship out of the box:

• Foundry-hosted agents. Deploy an agent to Microsoft Foundry infrastructure with two extra lines of code. The agent runs on a managed runtime, you keep the same SDK shape.
• Azure Functions. Agents as serverless endpoints.
• Durable Task, Durable Agents, Durable Workflows. Long-running, checkpointed workflows on top of the Durable Task framework. Process crashes and machine reboots don’t kill the run.
• A2A. Expose any MAF agent over the A2A protocol so other agents (built on anything) can talk to it. I’ve written about A2A v1.0 separately; the fact that MAF speaks it natively is a real signal that Microsoft expects you to interop, not silo.
• Container. Plain Docker for everywhere else.

Observability

OpenTelemetry is built in. Spans for agent runs, tool calls, workflow executors, and model client calls all land in whatever tracing pipeline you already have. I’ve spent more hours than I want to admit retrofitting traces into SK and AutoGen, so this one matters more to me than it probably should.

Declarative agents and skills

Two smaller pieces worth a mention.

Declarative agents let you define an agent in YAML instead of code. Instructions, model, tools, context providers, all in a versionable file. Useful when product or compliance owns the prompt and devs own the runtime.

Agent skills let you build domain-specific knowledge bases (from files, inline code, or class libraries) that agents can discover and use at runtime. It’s a structured replacement for the “stuff everything into the system prompt” pattern: only the relevant skill gets pulled in for a given query.

There’s also a DevUI for poking at agent state and workflows during development, and an AF Labs subdirectory for experimental work like agent benchmarking and RL.

Where this leaves Semantic Kernel and AutoGen

Both repos are still up. The migration guides on Microsoft Learn are detailed enough that I think the team genuinely wants people to move, not just gesture at it. Kernels become chat clients, plugins become tools, AutoGen team chats become orchestration builders. None of that translation is particularly hard.

What I actually care about, more than the consolidation, is what it lets you do once everything lives in one place. The same agent code goes from agent.RunAsync("hello") on a laptop to a Magentic team running for hours inside a Durable workflow on Foundry, with OpenTelemetry traces and an MCP tool catalogue feeding everyone. SK couldn't really do the multi-agent half. AutoGen couldn't really do the production half. MAF is the first time I've looked at Microsoft's agent story and not had to mentally split it into two.

I’m going to build something real on it over the next month and write that up separately. There’ll be sharp edges (there always are), but the shape of the thing looks right.

Links

• Original Post: https://blog.tuhidulhossain.com/post/microsoft-agent-framework-the-successor-to-semantic-kernel-and-autogen-20260531
• Overview: learn.microsoft.com/en-us/agent-framework/overview
• Repo: github.com/microsoft/agent-framework
• Python samples: python/samples
• .NET samples: dotnet/samples

Most teams I’ve worked with don’t fail at branching because they picked the wrong model. They fail because nobody wrote the rules down. A new engineer joins, opens a PR straight into main, ships a hotfix that quietly clobbers someone's half-merged release, and a week disappears trying to figure out what happened.

This is the write-up I wish I’d handed to every team I joined. It’s a four-branch model that’s held up for me in larger orgs: long-lived main, develop, and prod, with feature/* , fix/* & hotfix/*for the actual work. Code promotes through a Staging pipeline (QC/Test, then PreProd) before anything touches Production, and every release loops back into main so the baseline doesn't quietly drift away from what's running.

The branching model

         feature/*   fix/*              hotfix/*
               \      /                   /
                \    /                   /
   main  ─────► develop ─────────────► prod ─────► (back-merge into main)
   ▲               │                    │
   │               ▼                    ▼
 baseline       Staging                Production
              (QC/Test → PreProd)

Four long-lived branches, two short-lived families:

• main is the baseline. It always mirrors what's currently running in Production. Nobody commits to it directly.
• develop is the integration branch. Every feature and fix lands here first. CI ships every push into Staging (QC/Test).
• prod is the release branch. When a release is cut from develop, it merges (or fast-forwards) into prod. CI deploys every push to Production.
• feature/* are short-lived branches for new work, cut from develop.
• fix/* are short-lived branches for bugs, also cut from develop. Hotfixes are different and get their own section below.
• hotfix/* are short‑lived branches for urgent production fixes.

After each Production release, prod gets back-merged into main so main keeps reflecting what's actually live.

Why three long-lived branches instead of one

Pure trunk-based development is great if you have feature flags everywhere, fast CI, and a culture that’s comfortable shipping on green. Most enterprises don’t. They have compliance reviews, change advisory boards, customer maintenance windows, and a QA team that needs something stable to test against. Pretending otherwise just pushes the complexity into Friday afternoons.

Three long-lived branches give you three stable answers:

BranchWhat it representsWho deploys itmainThe last thing successfully released to ProductionNobody, automateddevelopWhat QA is currently testingCI on every pushprodWhat's currently running in ProductionCI on every push

That’s the whole payoff. When a PM asks “what’s in QA right now,” the answer is git log develop. When a support engineer asks "what's actually running for customers," the answer is git log prod (or main, which mirrors it after every release).

Branch naming standard, with ticket references

Branch names aren’t decoration. They’re the link between a commit, a PR, a CI run, a deploy, and the ticket that justified the work in the first place. Keep them disciplined and your git log doubles as a searchable audit trail.

The standard:

<type>/<TICKET-ID>-<short-kebab-description>

Where:

• <type> is one of feature, fix, hotfix, chore, docs, refactor.
• <TICKET-ID> is your issue tracker key. Jira (PROJ-1234), Linear (ENG-87), GitHub issues (gh-512). This part is required. No exceptions.
• <short-kebab-description> is 3 to 6 words, lowercase, hyphenated, describing intent.

Examples that pass review:

feature/PROJ-1421-add-saml-login
feature/PROJ-1455-export-invoices-to-csv
fix/PROJ-1488-null-pointer-on-empty-cart
fix/gh-512-trim-whitespace-in-email-field
hotfix/PROJ-1502-payment-gateway-timeout
chore/PROJ-1499-bump-spring-boot-to-3-1

Examples that should get bounced at PR time:

feature/new-stuff                 no ticket, no scope
feature/khaled-experiment         owned by a person, not by a ticket
PROJ-1421                         missing the type prefix
feature/PROJ_1421_add_saml        underscores instead of hyphens

Why the ticket ID matters

When the ticket ID is in the branch name, it shows up everywhere for free:

• PR titles auto-populate from templates and link back to the ticket.
• Commit messages with PROJ-1421 in them get attached to the ticket automatically by Jira or Linear smart commits.
• Release notes can be assembled by grouping commits on ticket prefix.
• Anyone running git blame six months later can trace a line back to the reason it exists.

A small enforcement helper for .github/workflows/branch-name.yml:

name: Branch name check
on:
  pull_request:
    branches: [develop, prod]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Validate branch name
        run: |
          BRANCH="${{ github.head_ref }}"
          if [[ ! "$BRANCH" =~ ^(feature|fix|hotfix|chore|docs|refactor)/[A-Z]+-[0-9]+-[a-z0-9-]+$ ]] \
             && [[ ! "$BRANCH" =~ ^(feature|fix|hotfix|chore|docs|refactor)/gh-[0-9]+-[a-z0-9-]+$ ]]; then
            echo "Branch '$BRANCH' does not match required pattern:"
            echo "  <type>/<TICKET-ID>-<short-description>"
            exit 1
          fi

Pair it with a commit message check (Commitlint or a custom hook) that wants the same ticket ID inside the squashed commit, and the convention starts enforcing itself.

How developers actually work day to day

The flow is the same whether it’s a feature or a bug fix:

1. Pull develop and branch off it.

   git checkout develop
   git pull --ff-only
   git checkout -b feature/PROJ-1421-add-saml-login

2. Commit small, push often. Push early so CI runs against your branch and your team can see what you’re up to.

3. Open a PR into develop. The PR template should ask for.

• The ticket link (auto-filled from the branch name).
• A short “why,” not just “what.”
• Test evidence: screenshots, logs, or a link to the test run.
• A rollback note. “If this breaks Production, what do we do?”

4. Get a code review. At least one approving reviewer. All CI checks green: lint, unit, integration, security scan.

5. Squash-merge into develop. Squash, not merge-commit. The unit of history on develop is "one ticket, one commit." Delete the branch on merge.

6. Watch Staging. Within a few minutes your change is live on QC/Test and QA picks it up against the ticket.

That’s the loop. Nobody ever commits directly to develop, prod, or main. GitHub branch protection rules enforce it: required reviews, required status checks, no direct pushes, no force-pushes.

The Staging pipeline: QC/Test, then PreProd

Splitting “staging” into two stages is the single change that makes this model work for enterprise use, and it’s the one I see most often skipped. The two stages do completely different jobs. Don’t conflate them.

Stage 1: QC/Test

• Trigger: every push to develop.
• Data: synthetic or anonymized. Reset whenever. Cheap to break.
• Audience: QA engineers, devs verifying their own work, product owners doing UAT against tickets.
• Goal: does the change behave correctly? Does it pass functional acceptance?

QC/Test is allowed to be unstable. That’s its job. It should fail loudly while there’s still time to fix things.

Stage 2: PreProd

• Trigger: promotion from QC/Test once a release candidate is identified (usually a tag on develop, e.g. rc-2023.08.15).
• Data: sanitized, but production-shaped. Same database engine, same versions, similar scale.
• Audience: SRE, performance testers, security review, the change advisory board.
• Goal: does the change still behave correctly under conditions that actually look like Production? Migrations, integrations, load, secrets, networking.

PreProd is the dress rehearsal. If it’s green, the Production deploy is mechanical. If you’re nervous on Production deploy day, your PreProd isn’t doing its job.

Promotion in CI:

# .github/workflows/promote-to-preprod.yml
on:
  workflow_dispatch:
    inputs:
      release_tag:
        description: 'Release candidate tag on develop'
        required: true
jobs:
  promote:
    environment: preprod        # Requires reviewer approval
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ inputs.release_tag }}
      - run: ./deploy.sh preprod

GitHub Environments give you the approval gate for free. Configure the preprod environment with required reviewers and promotion is never accidental.

Releasing to Production

Once PreProd has signed off:

1. Open a release PR from develop into prod. No new commits in this PR. It's just promoting what's already been tested.
2. Get release approval. Usually the release manager and one engineering lead.
3. Merge. CI deploys prod to Production automatically.
4. Tag the release on prod:

git checkout prod
git pull --ff-only
git tag -a v2023.08.15 -m "Release 2023.08.15"
git push origin v2023.08.15 

5. Back-merge prod into main:

git checkout main
git pull --ff-only
git merge --ff-only prod    # if main was clean; otherwise open a back-merge PR
git push origin main

After step 5, main is identical to what's running in Production again. That property is what makes main useful as a baseline for hotfixes and for auditors.

Hotfixes, the one exception

Bugs found in Production can’t wait for the regular develop → prod cycle. The model handles this with a controlled exception:

1. Branch from main (or equivalently prod), not from develop. You want to fix exactly what's live, without dragging in unreleased changes.

git checkout prod
git pull --ff-only
git checkout -b hotfix/PROJ-1502-payment-gateway-timeout

2. Make the fix. Add a regression test. Open two PRs:

• One into prod, which deploys to Production after PreProd validation. PreProd can be fast-tracked, but it isn't optional.
• One into develop, so the fix isn't lost in the next regular release.

3. After the hotfix ships, back-merge prod into main as usual.

The “two PRs” rule looks like duplication. It’s actually the single biggest defense against a classic enterprise bug: a hotfix ships to Production, the next regular release accidentally reverts it, and the same bug reappears at the worst possible moment. Usually on a weekend.

Branch protection: the rules CI enforces

Configuration is half the strategy. On GitHub, set these for main, develop, and prod:

• Require a pull request before merging. No direct pushes.
• Require approvals. At least 1 for develop, at least 2 for prod and main.
• Require status checks to pass: branch name check, lint, unit, integration, security scan.
• Require branches to be up to date before merging.
• Require linear history on develop (squash merges only).
• Restrict who can push to main and prod (release managers only, even though merges still go through PR).
• No force pushes. No deletions.

I know this list looks like bureaucracy. It isn’t. It’s what turns a Confluence document into an actual process. Without enforcement, the document is just a document, and people will route around it the first time it’s inconvenient.

Common failure modes, and how this model handles them

“Someone merged a half-finished feature and now QA is blocked.” QC/Test is the right place for that to surface. Revert the PR on develop, redeploy, and you've lost minutes instead of days.

“A hotfix shipped to Production but the bug came back next sprint.” The hotfix wasn’t merged into develop. The two-PR rule prevents this. Branch protection enforcing it makes the rule real instead of aspirational.

“main and Production drifted apart." The back-merge step got skipped somewhere. Add a scheduled CI job that fails if main is more than N commits behind prod. You want this loud and early, not discovered during the next hotfix.

“Nobody knows what’s in this release.” Branch names weren’t referencing tickets, so the release notes can’t be auto-generated. The branch-name CI check fixes this at the source.

“PreProd passed but Production broke.” Almost always means PreProd doesn’t actually resemble Production. Different data shape, missing integration, smaller scale, secrets stubbed out. Spend the money on PreProd parity. It’s the cheapest incident prevention I know.

When this model isn’t the right fit

Worth being honest about:

• Trunk-based shops with mature feature-flag infrastructure and continuous deployment will find this heavy. They’re right for their context.
• Tiny teams (1 to 3 people) shipping a side project don’t need three long-lived branches. You’d just be paying overhead for fun.
• Libraries and SDKs, where “Production” means “whatever your users have installed,” need a release-train model instead.

This model earns its keep when you have multiple teams contributing to one codebase, a separate QA function, change-management requirements, and an SRE or platform team running Production. Outside of that, simpler is fine.

Wrapping up

The branches aren’t really the strategy. The discipline around them is. You can pick a different name for develop or prod and the model still works, but skip the back-merge into main for a couple of releases and the whole thing falls apart quietly.

To recap the loop: feature/* and fix/* come off develop and go back via PR. develop deploys automatically to QC/Test. Release candidates get promoted to PreProd behind an approval gate. Once PreProd is green, develop merges into prod, which deploys to Production. After every release, prod is back-merged into main so the baseline keeps mirroring what's live. Branch names always reference a ticket, so the trail from "why did we ship this" to "what code changed" is one git log away.

Write the rules down. Put them behind CI checks and branch protection. Then mostly forget about Git, and let everyone spend their energy on the actual product.

Originally published on [Blog](https://blog.tuhidulhossain.com/post/enterprise-github-branching-strategy-with-staging-and-production-20230815) on August 15, 2023.

Login attempts on ZephyPhone had gone from quiet to a few hundred a minute. All failing. All from different IPs all over the place. I sat up, grabbed the laptop, and honestly just watched the graph for a bit before I did anything useful.

By the time I’d made coffee we’d taken hundreds of thousands of bad requests in a day.

A botnet. Spread across a lot of countries, throwing leaked password dumps at us, hoping somebody had reused a password they shouldn’t have. Pretty standard stuff if you read security blogs. Less standard when it’s your platform on the receiving end.

Nobody using ZephyPhone noticed any of it.

I’m writing about this because founders go strangely quiet when it happens. We post when we ship things. We post when we raise. Somebody points a botnet at us and the timeline goes silent. I don’t really get it. So.

What the attack actually was:

Credential stuffing. The boring kind. A bot reads username/password pairs off some old breach list and throws them at your login until something opens. It’s not clever. It just doesn’t have to be.

The annoying part was the shape. Lots of IPs, each one going slowly enough to look like a regular user. Added together they were doing real volume. Tuned, basically, to look invisible to the kind of per-IP limit most apps have.

Ip Locations

It also came in two waves, which is the part that stuck with me. The first one ramped up fast, ran for about an hour, then went completely quiet. Long enough that I half-convinced myself that was it. Then the second wave hit, much bigger than the first, and just sat there for hours. Looking back, the first wave was almost certainly a probe — see what gets blocked, watch how the system reacts, then come back with the real thing. That’s changed how I’ll think about the early minutes of any future incident. Sometimes what you’re seeing isn’t the attack. It’s somebody knocking to find out where the doors are.

Total Actions Data ( Red: Total, Green : Allowed, Purple : Blocked)

The thing I re-learned: if you only have one layer and the attacker has more IPs than that layer cares about, you don’t really have a defense. You have a thing that makes you feel like you have one. I knew that. There’s still a difference between knowing it and watching it on a chart at 3 AM.

What actually saved us:

I’d put time into hardening the platform a few weeks earlier. I want to say that was foresight, but no, I’d just been reading too many post mortems from other companies and got nervous.

I’m not going to walk through what we did. Publishing the map of our defenses doesn’t help anyone except the next person who wants to poke at them. What I’ll say is the shape: several layers between the public internet and anything that touches a customer account, none of them sharing assumptions, monitoring sitting on top. Nothing fancy. Just done properly and done before we needed it.

The thing that worked wasn’t any single rule. It was that you’d have to beat several different things at once, and they don’t think alike. That’s the whole idea.

Most of the attack got handled before our code ever saw the request. App servers were cool. Database didn’t blink. Calls connected. Texts went out. New customers onboarded in the middle of it. The only ones having a stressful night were me and whatever was sending the alerts.

A few things I keep thinking about:

Rate limiting isn’t a thing, it’s a whole category. Per-IP, per-account, per-endpoint, at the edge or in the app — these solve different problems and I used to file them all under one mental folder. You often need a few of them going at the same time, and they shouldn’t look like each other.

Doing this work at the edge was cheaper than I expected. The bill is genuinely modest. The bigger saving is your app not having to politely say no to a million bad requests. Stuff that never gets to you costs you nothing.

The expensive part is choosing to do it. A week on security plumbing is a week I’m not shipping something a customer asked for. That trade hurts. I still think it was right. We’ll see how I feel after the next time.

I nearly didn’t post this. There’s a voice that says I’ll spook people, look weak, basically wave a flag at the next person looking for a target. I think that voice is wrong. Not totally sure. Talk to me in a month.

You don’t get the attack you planned for. I’d thought about a few categories. Hadn’t thought enough about this one. The defenses happened to be in the right place, which I’ll cop to being a bit lucky about, and now I trust them in a way I didn’t before. Watching something work is different from believing it works.

If you’re a ZephyPhone customer:

I want you to hear this from me, not from a help page.

We saw it. We stopped it. You didn’t have to think about it. That’s the whole deal.

You run your business. We keep the thing underneath running, including when somebody is actively trying to take it down. That’s why I started this. Communications that work — and that keep working on the bad days too.

We’ll keep spending on this. We’ll keep telling you when things happen. Trust shows up one ordinary day at a time, and I’m fine with ordinary.

Thanks for sticking with ZephyPhone.

P.S. If you’ve got questions, or you’re a founder dealing with your own version of a 3 AM alert, just message me. I read everything.

#CyberSecurity #SaaS #Startups #FounderJourney #Engineering #BuildInPublic #ZephyPhon

I’d been watching the Agent2Agent (A2A) Protocol since it first showed up, originally out of Google and eventually handed off to the Linux Foundation. The idea was always right: a neutral wire protocol so agents built on different frameworks could talk to each other. But every time I sat down to try it, the spec was still moving. v0.1, v0.2, v0.3, breaking changes between minor releases. Agent Cards weren’t cryptographically signed, so discovering a new agent was basically a handshake on faith. One endpoint, one agent, which ruled out every SaaS shape I cared about. JSON-RPC was the only binding, which locked out teams standardized on gRPC. And the one that really kept me out: no version negotiation, so any upgrade meant a flag-day cutover across every agent in a deployment.

Promising protocol, but not one you could bet on yet. So I waited.

Then on March 12, 2026, v1.0 shipped. The four headline changes happen to be the four things that had been keeping me out:

• Signed Agent Cards — the /.well-known/agent-card.json document now carries a cryptographic signature, so you can verify that a card was actually issued by the domain claiming it. Without this, decentralized discovery was always going to be a security footnote.
• Multi-tenancy — one endpoint can host many agents. SaaS providers can finally ship a per-tenant agent without running a fleet of processes behind a reverse proxy.
• Multi-protocol bindings — same logical agent, exposed over JSON-RPC or gRPC. Pick whichever fits your stack.
• Version negotiation — backward-compatible migration from v0.3 onward is now a spec-level guarantee. No more flag-day cutovers.

The v1.0 announcement keeps using the word maturity rather than reinvention, and I think that’s the right word. This isn’t a redesign. It’s the point where I stopped flinching every time a new version dropped.

So I built a small agent on top of the official a2a-sdk to actually use the thing.

One caveat up front: the Python SDK is still on 0.3.x. It accepts the v1.0 card fields (my sample declares protocol_version="1.0"), but the v1.0-specific features -- signed cards, the gRPC binding, version negotiation -- aren't wired up in the SDK yet. What works today is the core flow: discovery, message/send, streaming, cooperative cancellation, input-required multi-turn, and push-notification webhooks. That's most of what you need to write a working agent.

Repo: github.com/encryptedtouhid/a2a_protocol_sample — a small A2A reference agent in Python, built on the official a2a-sdk.

This post is what I wish someone had handed me when I started.
So what is A2A, really?

The elevator pitch: A2A is to agent-to-agent communication what HTTP is to browser-to-server communication. A neutral wire protocol that two systems, built by teams who don’t know each other and don’t share a stack, can both agree to speak.

That’s the whole value proposition.

Underneath, it’s JSON-RPC 2.0 with a Server-Sent Events layer for streaming and optional webhooks for push notifications. Nothing exotic on the wire — you can pretty-print any message and read it with your eyes.

The five objects you need to get comfortable with:

• Agent Card — a JSON document at /.well-known/agent-card.json that says who this agent is, what it can do, how to talk to it, and how to authenticate. Think business card, but for robots.
• Task — the unit of work. Has an id, a context, a status, a history of messages, and a list of artifacts it produced.
• Message — one turn in the conversation. Role is either user or agent. Inside, it carries Parts.
• Part — the atomic content container. One of: text, a file reference, or structured JSON data. That’s the entire content model.
• Artifact — something the agent produced. Messages are ephemeral chat turns; artifacts are deliverables that stick around.

The task state machine is small and pleasant to look at:

submitted -> working -> completed
                     \-> canceled / failed / rejected
                     \-> input-required (resumable)
                     \-> auth-required (resumable)

Notice the two resumable states. That’s where A2A gets more interesting than a plain request/response protocol, and I’ll get to that.

Only five RPC methods actually matter

The spec has a handful of methods. If you squint, five of them are doing all the real work:

message/sendSend a message, get a task back. Plain request/response.
message/streamSame idea, but the response is an SSE stream of events.
tasks/getFetch a task by id. Optionally trim the history.
tasks/cancelCooperatively ask a task to stop.
tasks/pushNotificationConfig/*Register a webhook so the agent can call you.

The rest — tasks/resubscribe and the authenticated extended card -- is quality of life. Nice to have, not what makes A2A work.

Inside the sample repo

The actual layout is much smaller than you’d guess:

src/a2a_sample/
  __init__.py    # re-exports, 3 lines
  auth.py        # bearer-token Starlette middleware, 31 lines
  executor.py    # AgentExecutor: routes the first word to a skill, 61 lines
  server.py      # agent card + A2AStarletteApplication wiring, 143 lines
  skills.py      # echo / summarize / count / form / debug, 118 lines

demos/
  run_server.py
  webhook_receiver.py
  _common.py
  01_discovery.py                # fetch the well-known card
  02_send_message.py             # plain message/send
  03_streaming.py                # message/stream over SSE
  04_multiturn_input_required.py # input-required, multi-turn
  05_cancel.py                   # tasks/cancel mid-stream
  06_push_notifications.py       # register a webhook and watch it fire
  07_extended_card.py            # authenticated extended card

About 356 lines of application code across five files. Three dependencies:

a2a-sdk[http-server]>=0.3.26
uvicorn[standard]>=0.30
httpx>=0.28

The SDK does most of the heavy lifting. Once you see what’s already in the box, the protocol gets a lot easier to reason about:

• Every Pydantic model — AgentCard, Task, Message, Part, Artifact, TaskState, TaskArtifactUpdateEvent, the lot.
• The JSON-RPC 2.0 transport and request routing.
• The SSE streaming event queue.
• InMemoryTaskStore -- the default task store.
• BasePushNotificationSender -- the webhook dispatcher.
• TaskUpdater -- a facade that lets a skill say updater.complete() or updater.requires_input() without hand-building status events.
• ClientFactory and AuthInterceptor on the client side.

What’s left for you to write:

• An AgentCard that describes your agent.
• An AgentExecutor that routes incoming messages to your logic.
• Whatever skills your agent actually does.
• Auth middleware, if you need any.

That’s the entire pattern. The SDK handles protocol correctness; you handle agent behavior.

The five skills

The sample exposes four public skills and one auth-gated skill, and each one pokes a different corner of the protocol:

• echo — the happy path. Text in, text out. Nothing fancy.
• summarize — returns a TextPart (the summary) plus a DataPart (word/character stats). Non-streaming, shows the structured content model.
• count N — streams numbers 1 to N with a 300ms delay between each. This is where you watch streaming and cancellation work.
• form — asks for a name, then an email, then returns a contact record. This is the input-required state in action.
• debug — only visible on the authenticated extended card. Shows how auth-gated capability discovery works.

The dispatcher in executor.py picks a skill based on the first word of the user's first message:

initial_text = skills.initial_user_text(task, context.message).strip()
head = initial_text.split(None, 1)[0].lower() if initial_text else ""

try:
    if head == "summarize":
        await skills.skill_summarize(initial_text, updater)
    elif head == "count":
        await skills.skill_count(initial_text, updater)
    elif head == "form":
        await skills.skill_form(updater, task, context.message)
    elif head == "debug":
        await skills.skill_debug(updater)
    else:
        await skills.skill_echo(initial_text, updater)

A str.split() and an if/elif. For a reference sample, that's the right amount of code.

Discovery: the well-known agent card

The first thing any A2A client does is ask the agent to introduce itself. A2A borrows RFC 8615’s well-known URI — you fetch a JSON document from a fixed path and read off everything you need. The SDK’s A2ACardResolver does the work:

python

async def fetch_public_card(http: httpx.AsyncClient) -> AgentCard:
    return await A2ACardResolver(http, base_url=BASE_URL).get_agent_card()

Run demo 01 and you get back the agent’s skills, its preferred transport, its security schemes, whether it supports streaming, all of it. No docs to read, no Slack message to ask “hey what’s the API look like” — the agent tells you itself.

It’s a boring design choice, which is usually a good sign in protocol work.

Sending a message

Everything JSON-RPC goes through the SDK’s client, built from the agent card plus an auth interceptor:

python

def build_client(http, card, *, streaming: bool = False) -> Client:
    factory = ClientFactory(
        ClientConfig(
            httpx_client=http,
            streaming=streaming,
            supported_transports=[TransportProtocol.jsonrpc],
        )
    )
    return factory.create(
        card,
        interceptors=[AuthInterceptor(StaticCredentialService(BEARER_TOKEN))],
    )

Sending a message is a one-liner on top:

async for event in client.send_message(_user("echo hello A2A")):
    if isinstance(event, Message):
        continue
    task, update = event
    if update is None:
        print(f"  task id={task.id} state={task.status.state.value}")

The task comes back already in the completed state because echo is instant. For anything slower, you'd want streaming.

Where streaming starts to earn its keep

Request/response is fine for echo. It’s not fine for an agent that spends fifteen seconds thinking and produces output incrementally. You don’t want to hold an HTTP connection open for fifteen seconds and dump everything at the end — the user would assume it crashed.

A2A’s answer is message/stream. Same message shape, but the response is an SSE stream of JSON-RPC envelopes. The client side dispatches on event type:

async for event in client.send_message(msg):
    if isinstance(event, Message):
        continue
    task, update = event
    if isinstance(update, TaskArtifactUpdateEvent):
        chunk = update.artifact.parts[0].root
        text = getattr(chunk, "text", "")
        print(f"[artifact] append={update.append} last={update.last_chunk} chunk={text!r}")
    elif isinstance(update, TaskStatusUpdateEvent):
        print(f"[status] state={update.status.state.value} final={update.final}")

The count skill on the server side emits each number as an appended chunk of the same artifact. append=True on chunks 2 through N, last_chunk=True on the last one:

async def skill_count(text: str, updater: TaskUpdater) -> None:
    target = max(1, min(int(match.group()) if match else 5, 100))
    artifact_id = f"count-{updater.task_id}"
    for i in range(1, target + 1):
        await updater.add_artifact(
            [Part(root=TextPart(text=f"{i}\n"))],
            artifact_id=artifact_id,
            name="count",
            append=i > 1,
            last_chunk=i == target,
        )
        await asyncio.sleep(0.3)
    await updater.complete(

That append=True, last_chunk=False pattern is how A2A says "glue these together until you see last_chunk=True." Same mental model as HTTP chunked transfer, just lifted up to the agent's output instead of the HTTP body.

First time I ran this, I left it running and just watched the chunks arrive. There’s something satisfying about watching a protocol do its thing in real time.

Cancellation done right: cooperative, not forced

This one I actually have opinions about.

A2A cancellation is cooperative. When you call tasks/cancel, the server doesn't hard-kill a coroutine -- the SDK raises asyncio.CancelledError inside the running skill, and the executor is expected to emit a terminal canceled status and return. It sounds like more work than a hard kill, but it's the right call. Forced termination is how you end up with half-written rows, partial files, and state that corrupts the next run.

The executor handles it with a try/except around the dispatch:

python

try:
    if head == "count":
        await skills.skill_count(initial_text, updater)
    # ... other skills
except asyncio.CancelledError:
    await updater.update_status(TaskState.canceled, final=True)
    raise

The cancel demo fires the cancel mid-stream:

if isinstance(update, TaskArtifactUpdateEvent):
    text = update.artifact.parts[0].root.text.strip()
    print(f"[chunk]   {text}")
    if not canceled and text == "3":
        await client.cancel_task(TaskIdParams(id=task_id))
        canceled = True

Run demo 05 and you see it: three chunks arrive, the cancel request goes out, one or two more chunks land in flight, then the stream closes with state=canceled final=True. No orphaned state.

The multi-turn trick: input-required

Okay, this is the feature I didn’t know I wanted until I used it.

In A2A, a task can pause and wait for more input without losing its place. The agent transitions to input-required, the client comes back with another message carrying the same task_id and context_id, and the task picks up where it left off. Same task id. Same artifacts. Same context. Just... paused.

The form skill demonstrates it. Three turns: ask for name, ask for email, complete with a contact record.

task = await _send(client, _user("form"))
print(f"[turn 1] state={task.status.state.value}")  # input-required

task = await _send(client, _user("Ada Lovelace", task.id, task.context_id))
print(f"[turn 2] state={task.status.state.value}")  # input-required

task = await _send(client, _user("ada@example.com", task.id, task.context_id))
print(f"[turn 3] state={task.status.state.value}")  # completed

Where the skill stashes the collected name between turns is the nice trick. It doesn’t need a database; it writes the data into the agent message’s metadata field on turn 2, then walks the task history on turn 3 to read it back:

if prior_agent_turns == 1:
    await updater.requires_input(
        updater.new_agent_message(
            [Part(root=TextPart(text=FORM_QUESTIONS[1]))],
            metadata={"name": incoming_text},
        ),
        final=True,
    )
    return

# later, on turn 3:
for m in task.history or []:
    if m.role == Role.agent and m.metadata and "name" in m.metadata:
        name = str(m.metadata["name"])
        break

The form demo looks trivial, but the same state machine handles any “agent waits for something external” case — a human approval, an auth challenge (via the defined-but-not-demoed auth-required state), a slow third-party service. One mental model covers all of them.

This is the bit I keep coming back to when I think about why A2A exists. Anyone can design a request/response protocol. Designing one that pauses cleanly and resumes without losing its mind — that’s the hard part, and A2A got it right.

Push notifications for the really long-running stuff

SSE is wonderful when the client can stay connected. But sometimes the task runs for an hour and the client is a mobile app that gets backgrounded, or a serverless function that already returned, or just a process that might die and come back. For that, A2A lets you register a webhook:

python

config = TaskPushNotificationConfig(
    task_id=task_id,
    push_notification_config=PushNotificationConfig(
        url=WEBHOOK_URL,
        token=SHARED_SECRET,
    ),
)
result = await client.set_task_callback(config)

The SDK’s BasePushNotificationSender POSTs every event to your webhook with an X-A2A-Notification-Token header carrying your shared secret. You can register multiple webhooks per task, list them, delete them -- standard CRUD.

Server-side wiring is about four lines:

python

push_store = InMemoryPushNotificationConfigStore()
push_sender = BasePushNotificationSender(
    httpx.AsyncClient(timeout=10.0),
    config_store=push_store,
)

For demo 06 you have to start a little webhook receiver in a third terminal. Watching the events land in the receiver while the task is still running is when the async design actually clicks.

One thing to call out: v1.0 also defines JWT-signed push payloads via the a2a-sdk[encryption] extra, but the sample uses only the shared-secret token. Fine for a demo on localhost, not fine for production cross-org setups. Don't ship this exact pattern past your own infrastructure without upgrading the verification.

Auth: a tiny Starlette middleware

The sample accepts one bearer token, demo-secret-token, declared in the card's securitySchemes and required on every non-discovery path. The middleware fits in about a dozen lines:

python

class BearerAuthMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        if request.url.path in PUBLIC_PATHS:
            return await call_next(request)
        header = request.headers.get("authorization", "")
        scheme, _, token = header.partition(" ")
        if scheme.lower() != "bearer" or token != BEARER_TOKEN:
            return JSONResponse(
                {"error": "invalid or missing bearer token"},
                status_code=401,
            )
        return await call_next(request)

Real production agents would wire in OAuth2, OIDC, or mTLS — the card supports declaring any of those. This is just the simplest thing that works so the rest of the demos have something to authenticate against.

What this sample deliberately doesn’t do

v1.0 shipped, but not all of it is in the SDK yet, and the sample doesn’t reach past what the SDK does. So here’s what’s missing:

• Signed Agent Cards — the v1.0 feature that makes cross-org discovery safe. Not in the SDK’s 0.3.x release yet; the sample’s card is unsigned.
• gRPC binding — the SDK has a gRPC transport, but the sample only exposes JSON-RPC.
• Version negotiation — the card hardcodes protocol_version="1.0"; there's no client-side version probing.
• auth-required state -- defined in the TaskState enum, but no skill currently triggers the flow. Good candidate for a follow-up demo.
• FilePart — the Part type exists but nothing in the sample produces or consumes one.
• OAuth2 / mTLS — only the HTTP bearer scheme is wired up.
• Batch JSON-RPC — allowed by the spec, not exercised here.
• Persistence — the default InMemoryTaskStore is used. A restart wipes the world.
• JWT-signed push payloads — the SDK has an [encryption] extra for this; the sample uses shared-secret tokens.

The core message flow is solid. The security and cross-stack features still need the ecosystem to catch up.

Running it yourself

Clone, set up, run the server in one terminal, fire demos from another:

git clone https://github.com/encryptedtouhid/a2a_protocol_sample.git
cd a2a_protocol_sample
./run.sh setup

# terminal 1
./run.sh server

# terminal 2
./run.sh demo 01   # fetch the agent card
./run.sh demo 03   # watch the streaming counter
./run.sh demo 04   # play with input-required

For push notifications (demo 06) you also need a webhook receiver in a third terminal:

./run.sh webhook

The run.sh script handles the venv and works on Linux, macOS, and Windows (Git Bash / WSL). ./run.sh list shows every demo. Go through them in order on the first pass; each one introduces one new concept and builds on the last.

Why I care about this one

We spent a decade learning that microservices only work when services agree on a wire protocol. Nobody ships a new microservice in 2026 and says “let’s invent our own transport.” Agents are walking the same path, just five years behind.

A2A is the lingua franca that lets a LangGraph orchestrator delegate to a Semantic Kernel agent, which hands off to a CrewAI team, without any of them importing each other’s SDKs. No adapters. No shared deployment. No “we need to agree on Python versions” meeting. Just JSON over HTTP with shapes everyone can parse.

And it pairs neatly with MCP:

• MCP — agent-to-tool. “Here’s a database, a filesystem, a GitHub API. Go use them.”
• A2A — agent-to-agent. “Here’s another agent with its own brain. Delegate to it.”

They’re both still young, and they’ll both change. The hard part of any protocol ecosystem is getting enough people to agree on one, and right now that’s A2A.

If you want to go deeper

• Clone the sample: github.com/encryptedtouhid/a2a_protocol_sample
• Read the spec: a2a-protocol.org
• Browse the SDK: a2a-sdk on PyPI
• Run the demos in order. Don’t skip around on the first pass.
• Once it makes sense, swap the echo skill for a real LLM call and watch the rest of the protocol keep working unchanged.

Honestly, the fastest way to learn a protocol is to build something on top of it. The repo’s ~360 lines are a reasonable starting sample if you’d rather read first and build second.

Happy to hear what you think. If something in the code confuses you, open an issue — that probably means I need to either fix the code or write better comments, and either way I’d want to know.

Original Post : https://blog.tuhidulhossain.com/post/the-agent2agent-a2a-protocol-a-complete-guide-to-ai-agent-interoperability-20260419

It was then that I felt the need for a CPU limitation tool. Instead of relying on IIS and server utilities, I decided to create my own middleware.

Introducing CpuGuard.NET, a middleware I developed to effortlessly manage CPU usage for ASP. NET Core applications. With CpuGuard.NET, you can:

1️⃣ Limit CPU usage for the entire application.

2️⃣ Control CPU usage for specific requests.

( * Stay tuned for the upcoming feature to limit CPU usage for specific controllers and methods! )

This powerful tool ensures your applications run smoothly, even under heavy loads. It’s easy to integrate and helps you maintain optimal performance.

Check it out on NuGet: [CpuGuard.NET]

(https://github.com/encryptedtouhid/CpuGuard.NET)

Installation

Install the NuGet package:

dotnet add package CpuGuard.NET

Usage

Whole Application CPU Limit Example:

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();

        // Use the whole application CPU limit middleware with 20% CPU limit and 1 second monitoring interval
        app.UseCpuLimitMiddleware(20.0, TimeSpan.FromMilliseconds(1000));

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllers();
        });
    }

Specific Request CPU Limit Example:

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();
        
        // Use the specific request CPU limit middleware with 15% CPU limit and 1 second monitoring interval
        app.UseCpuLimitRequestMiddleware(15.0, TimeSpan.FromMilliseconds(1000));

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllers();
        });
    }

Any kind of suggestions to improve it is highly appreciated.

Source Blog: https://blog.tuhidulhossain.com/post/2024/06/16/cpuguard-net-cpu-usage-control-for-asp-net-core-applications

#ASPNetCore #Middleware #CPULimit #PerformanceOptimization #DotNetDevelopment #CpuGuardNET

The main factor driving my preference for VS Code is its exceptional support for debugging JavaScript and Node.js code. Additionally, the abundance of free extensions in the Visual Studio Marketplace allows for effortless customization.

With thousands of extensions available in the marketplace, it can be challenging to determine the ones that best suit your needs.
And these are the extensions I use regular basis:
1.npm Intellisense
2. ESLint
3.Prettier — Code formatter
4.JavaScript (ES6) code snippets
5.DotENV
6.Better Comments
7.YAML
8.Code Spell Checker
9.Vscode-icons
10.GitLens

The process of re-configuring our development environment whenever we switch to a new device or environment can be quite exasperating and time-consuming. To save time and minimize effort, I devised a bash script that efficiently installs all the required VS Code extensions in one go.

#!/bin/bash

# Check if Visual Studio Code is installed
if ! [ -x "$(command -v code)" ]; then
  echo "Visual Studio Code is not installed. Please install it first."
  exit 1
fi

# Check if Node.js (npm) is installed
if ! [ -x "$(command -v npm)" ]; then
  echo "Node.js (npm) is not installed. Please install it first."
  exit 1
fi

# Replace 'EXTENSION_NAMES' with the list of extension names separated by commas
EXTENSION_NAMES="christian-kohler.npm-intellisense,dbaeumer.vscode-eslint,esbenp.prettier-vscode,eamodio.gitlens,xabikos.JavaScriptSnippets,mikestead.dotenv,aaron-bond.better-comments,redhat.vscode-yaml,streetsidesoftware.code-spell-checker,vscode-icons-team.vscode-icons"

# Split the extension names into an array using comma as the delimiter
IFS=',' read -ra EXTENSIONS <<< "$EXTENSION_NAMES"

# Loop through each extension name and install it
for EXTENSION_NAME in "${EXTENSIONS[@]}"; do
  # Trim leading and trailing whitespaces
  EXTENSION_NAME=$(echo "$EXTENSION_NAME" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')
  
  # Install the extension using the 'code' command-line interface
  code --install-extension "$EXTENSION_NAME"
  
  echo "The extension $EXTENSION_NAME has been installed successfully."
done

Here is how to run the `.sh` file on Ubuntu (Linux), Windows, and macOS.

**1. Ubuntu (Linux):**

To run the `.sh` file on Ubuntu or any Linux distribution, you need to use the terminal. Here’s the step-by-step process:

Step 1: Open the terminal by pressing `Ctrl + Alt + T` or by searching for “Terminal” in the applications.

Step 2: Navigate to the directory where you saved the `vsExtensions.sh` file using the `cd` command. For example, if the file is on your desktop, you can use the following command:

```bash
cd ~/Desktop
```

Step 3: Make sure the script is executable by running the following command:

```bash
chmod +x vsExtensions.sh
```

Step 4: Now, you can execute the script using the `./` command:

```bash
 bash ./vsExtensions.sh
```

The script will run, and if Visual Studio Code and Node.js (npm) are installed on your system, it will proceed to install the specified extensions.

**2. Windows:**

To run the `.sh` file on Windows, you can use one of the following methods:

**Git Bash**

You can use Git Bash, which is a Bash-compatible environment bundled with Git for Windows.

Step 1: Install Git for Windows (if you haven’t already) from the official website: https://gitforwindows.org/

Step 2: After installing Git for Windows, open “Git Bash” from the Start menu.

Step 3: Navigate to the directory where you saved the `vsExtensions.sh` file using the `cd` command. For example, if the file is on your desktop, you can use the following command:

```bash
cd ~/Desktop
```

Step 4: Make sure the script is executable by running the following command:

```bash
chmod +x vsExtensions.sh
```

Step 5: Now, you can execute the script using the `bash` command:

```bash
bash vsExtensions.sh
```

**3. macOS (Mac):**

To run the `.sh` file on macOS (Mac), you can use the built-in terminal, which provides a Bash shell.

Step 1: Open the Terminal application from the “Utilities” folder under “Applications” or use Spotlight to search for “Terminal.”

Step 2: Navigate to the directory where you saved the `vsExtensions.sh` file using the `cd` command. For example, if the file is on your desktop, you can use the following command:

```bash
cd ~/Desktop
```

Step 3: Make sure the script is executable by running the following command:

```bash
chmod +x vsExtensions.sh
```

Step 4: Now, you can execute the script using `./`:

```bash
./vsExtensions.sh
```

The script will run, and if Visual Studio Code and Node.js (npm) are installed on your system, it will proceed to install the specified extensions.

Now Enjoy :)

Anyone can create and train their own unique image recognition models using CustomVision.ai, a Microsoft cloud-based service. Users of this service can design a model specifically for their requirements, whether they be for object recognition, image classification, or even facial recognition. We’ll go over how to create your own model and train it in CustomVision.ai in this article.

Step 1: Register on CustomVision.ai

The first step to building your own model is to sign up for CustomVision.ai. This is a free tool provided by Microsoft that allows you to create custom image classifiers. Once you’ve signed up, you can access the CustomVision.ai portal and start building your own model.

Step 2: Create a new project

The next step after logging in to CustomVision.ai is to start a new project. The “New Project” button on the home page can be used to accomplish this. Prior to selecting the classification method you want to use, you must first give your project a name and a description. For instance, you might decide to categorize images based on whether or not they feature dogs or cats.

Step 3: Upload and Add Tag in images

The following step is to upload your images after creating your project. You can do this by selecting the desired images by clicking the “Add Images” button. CustomVision.ai allows you to upload multiple images at once, and it will automatically label them based on the file names.

Selecting the images and selecting the “Add Tag” button will allow you to make more precise labels. After giving the tag a name, it will be applied to all of the chosen pictures. I’ve created three type of Tags named “Cats”, “Dogs” & “Monkeys”.

Step 4: Train your model

The next step is to train your model after you’ve uploaded and labeled your images. To do this, select the training parameters by clicking the “Train” button. Automatic data splitting into training and validation sets is performed by CustomVision.ai before your model training process begins.

Depending on how complex your model is and how large your dataset is, the training process may take some time. The training status will be shown on the page by CustomVision.ai.

Step 5: Testing your model

The performance of your model can be tested after it has been trained. A testing interface is offered by CustomVision.ai where users can upload new images and check to see if the model correctly recognizes the objects or subjects in them. If the model is not performing as well as you would like, you can keep improving it by adding more images and tags or by changing the training parameters.

In conclusion, CustomVision.ai offers a simple platform for creating and refining unique image recognition models. You can build your own model and train it to recognize the things you need by following the procedures described in this article. The potential for image recognition and classification with this potent tool is limitless, and it creates avenues for numerous applications in numerous fields.

Original Post Link : https://www.linkedin.com/pulse/building-your-own-model-train-custom-vision-ai-part-khaled

Follow for more CustomVision.ai related content. ❤️