Why AWS and Microsoft Are Both Betting on AG-UI

Two rivals just agreed on something, and that almost never happens

AWS and Microsoft agree on almost nothing. Different clouds, different consoles, different philosophies about how you should build software, different everything. So when both of them quietly shipped support for the exact same open-source protocol within about six weeks of each other in early 2026, that wasn’t a coincidence worth skimming past — it was a signal worth stopping for.

The protocol is AG-UI. If you’re new to it: AG-UI (Agent-User Interaction Protocol) is an open, event-based standard that governs how an AI agent’s backend talks to the interface a human is actually looking at — the streaming text, the “thinking” indicators, the approval prompts, the state that stays in sync between your server and your screen. It was built by a small open-source team called CopilotKit in early 2025, not by either cloud giant.

And yet: in March 2026, Amazon Bedrock’s AgentCore Runtime added native AG-UI support. In April 2026, Microsoft’s Agent Framework followed with its own official integration. Two of the largest cloud platforms on Earth, both betting on infrastructure they didn’t build, within weeks of each other.

The short version: AWS and Microsoft didn’t build a proprietary “agent talks to user” protocol of their own — and that decision tells you more about where AI agent infrastructure is heading than any keynote slide could.

This piece digs into what each company actually shipped, why an open community protocol won out over a proprietary one at two companies famous for building their own everything, and what that means for you if you’re building AI agent products in 2026.

A Fast Recap: What AG-UI Actually Does

If you’ve read the field guide on this publication comparing AG-UI, MCP, A2A, and A2UI, skip ahead — you know this part. If you’re landing here fresh, here’s the one-paragraph version.

Every AI agent that talks to a real user eventually needs to solve the same handful of problems: stream partial responses instead of making people wait for a full answer, show what the agent is currently doing (“checking flights…”, “waiting for approval”), keep shared state in sync between backend and frontend, and pause to ask a human before doing anything risky. Before AG-UI, every team solved this by hand-rolling WebSockets or Server-Sent Events from scratch. AG-UI standardizes that entire layer into one shared event vocabulary, so frontend and backend frameworks — even ones built by completely different companies — can plug into the same stream without custom glue code.

That’s the layer AWS and Microsoft just both decided to support natively.

What AWS Actually Shipped

In March 2026, Amazon Bedrock’s AgentCore Runtime — AWS’s managed hosting environment for AI agents — added native AG-UI support. Here’s what that means in practice, beginner-friendly version first.

Before this, if you wanted to deploy an agent on AWS that streamed responses to a real frontend, you had to build and manage that streaming layer yourself: authentication, session handling, scaling, all of it, on top of whatever agent logic you’d already written. Now, AgentCore Runtime handles that plumbing for you. You deploy your agent as a container, flag it as an AG-UI server, and AWS takes care of authentication, session isolation, and scaling around it — leaving you to focus on the frontend experience itself.

Concretely, deploying an AG-UI-compatible agent on AWS looks something like this (simplified for clarity — check AWS’s own docs for the full setup):

# Illustrative — deploying an AG-UI server on AgentCore Runtime
# Your container listens on port 8080 and exposes /invocations
agentcore deploy \
  --protocol AG-UI \
  --container my-agent:latest \
  --port 8080

Once deployed, AWS’s AgentCore Runtime acts as a proxy in front of your container — handling the authentication handshake, streaming responses back over Server-Sent Events, and managing session state — so a request coming from your frontend flows straight through to your agent code without you writing any of that infrastructure yourself.

A few things stand out about how AWS positioned this:

• It complements, not replaces, protocols they already supported. AgentCore Runtime already had MCP (for tools) and A2A (for agent-to-agent coordination) support before this. AG-UI slots in as the third leg — the one that was missing — rather than competing with anything AWS had already built.
• It’s live across fourteen AWS regions from day one — this wasn’t a limited preview. AWS treated it as core infrastructure, not an experiment.
• It ships with a real starter template. AWS’s Fullstack AgentCore Solution Template (FAST) includes ready-to-deploy AG-UI patterns for popular agent frameworks like Strands Agents and LangGraph, plus a version that swaps in CopilotKit’s frontend components — meaning you can go from zero to a working streaming agent UI without piecing it together from scratch.

What Microsoft Actually Shipped

Microsoft’s move landed about a month later, in April 2026, as part of its Agent Framework — the unified successor to Semantic Kernel and AutoGen, Microsoft’s two previous (and now merged) agent-building toolkits. Agent Framework supports both .NET and Python; here’s what the Python side looks like, since that’s the more common entry point for most AI agent builders.

Getting started is a single install:

pip install agent-framework-ag-ui

That package includes everything needed to expose an existing agent over AG-UI using FastAPI — Python’s popular web framework for building APIs. Once it’s installed, wiring your agent up to an AG-UI endpoint is mostly a matter of registering it:

# Illustrative — exposing an Agent Framework agent over AG-UI with FastAPI
from fastapi import FastAPI
from agent_framework.ag_ui import add_agent_framework_fastapi_endpoint

app = FastAPI()
# my_agent is any agent you've already built with Microsoft Agent Framework
add_agent_framework_fastapi_endpoint(app, agent=my_agent, path="/agent")

add_agent_framework_fastapi_endpoint handles the request/response cycle and the Server-Sent Events streaming automatically — the same category of plumbing AWS's AgentCore Runtime handles on its side, just wired into Microsoft's own hosting stack instead. Once your server is running, any AG-UI-compatible frontend can connect to it exactly the same way it would connect to an agent hosted on AWS.

What’s notable about Microsoft’s framing is how directly they described the problem AG-UI solved for them. As their team put it when announcing the integration, this connects Microsoft’s reasoning and orchestration layer directly to real-time interfaces “without custom socket code, polling loops, or one-off APIs” — which is a fairly blunt admission that, before this, Microsoft’s own customers were doing exactly that: hand-building the same plumbing AWS’s customers were.

Microsoft also leaned into the interoperability angle. Their own materials pointed out that AG-UI already had support across other popular frameworks — LangGraph, CrewAI, Mastra, Google’s ADK — before Microsoft joined. Framing Agent Framework’s AG-UI support as joining an existing ecosystem, rather than launching a new one, was a deliberate choice.

Why Two Rivals Both Chose the Same Outside Protocol

Here’s the part worth sitting with: both AWS and Microsoft are companies that, historically, love building their own version of everything. AWS has its own everything-as-a-service. Microsoft has decades of proprietary protocols behind it. Neither company is shy about building infrastructure in-house when it serves their platform.

So why did both of them, independently, choose to adopt someone else’s open protocol for one of the most important layers in the entire AI agent stack — rather than building their own?

A few forces explain it:

It’s Happened Before — Just Not in AI

This isn’t the first time rival tech giants have converged on someone else’s standard instead of building their own. USB-C started as an open connector spec, not an Apple or Samsung invention — and today, even companies that spent a decade defending proprietary charging ports support it, because fighting an already-adopted open standard costs more than it’s worth. REST APIs won over a decade of competing proprietary web-service formats for the same reason: developers had already voted with their code, and holding out just meant becoming harder to integrate with.

AG-UI is following the same arc, just compressed into months instead of years — which itself says something about how fast the AI agent space is moving.

1. The ecosystem had already voted. By the time AWS and Microsoft made their moves, AG-UI already had adoption across LangGraph, CrewAI, Mastra, Google’s Agent Development Kit, and more. Building a competing proprietary protocol at that point wouldn’t have created a new standard — it would have created a fragmented island that developers actively avoid, because nobody wants to relearn a new event format for every cloud they deploy to.

2. Developers, not clouds, choose protocols. Cloud platforms compete on compute, pricing, and managed services — not, generally, on inventing the plumbing developers use to talk to their own frontends. Supporting an existing open standard costs a cloud provider far less than trying to convince an entire developer ecosystem to switch to something proprietary, and it removes a real barrier to adoption: teams that already built on AG-UI elsewhere can move their agents to AWS or Azure without rewriting their frontend integration.

3. It completes a stack they’d already bought into. Both AWS and Microsoft had already adopted MCP (Anthropic’s tool-connection protocol) and A2A (Google’s agent-to-agent protocol) before this. AG-UI was the missing third leg of a stack they were already committed to. Refusing to support it would have left an obvious gap in an otherwise coherent story.

4. Interoperability is the actual product now. For enterprise buyers evaluating “should we build on AWS or Azure for our AI agents,” the ability to plug into the same open protocols regardless of cloud is a selling point, not a risk. Locking developers into a proprietary interface layer would cut against exactly the kind of flexibility large customers now expect.

A Beginner-Friendly Way to Think About It

If the technical detail above feels like a lot, here’s the plain-language version: imagine two rival phone manufacturers who’ve spent a decade building incompatible chargers, suddenly both agreeing to support the exact same charging cable — not because a regulator forced them to, but because customers had already started buying that cable in bulk, and it would’ve been bad business to make them buy a different one for each brand. That’s roughly what just happened here, except the cable is AG-UI and the customers are the developers building the next generation of AI products.

What Could Still Go Wrong

It’s worth being honest about the other side of this, because “two giants adopted it” isn’t the same as “it’s finished and risk-free.”

Microsoft’s own documentation carries a plain warning on this: the AG-UI protocol is still under active development and subject to change, and both companies’ integrations are recent enough that rough edges are expected. Early adopters of any fast-moving open standard should expect some breaking changes as the spec matures — that’s the normal cost of building on the leading edge rather than waiting for a settled 1.0.

There’s also a subtler risk worth naming: broad adoption by major platforms doesn’t guarantee AG-UI stays the single winner forever. A2UI, the declarative UI layer that can ride on top of AG-UI’s event stream, is still finding its footing, and it’s not impossible that some future consolidation reshuffles how these pieces fit together. What today’s AWS and Microsoft support really guarantees is that the event-stream layer itself has enough institutional backing to be worth learning now — not that every detail of the surrounding ecosystem is locked in.

Quick Questions, Answered

Does using AG-UI lock me into AWS or Azure? No — that’s actually the opposite of the point. Because it’s an open protocol rather than a proprietary one, an agent built around AG-UI’s event format can move between AWS, Azure, and any other AG-UI-compatible platform (or no cloud platform at all — you can self-host) with far less frontend rework than a proprietary alternative would require.

Do I need to pick AWS or Microsoft to use AG-UI? No. AG-UI is an open standard maintained outside either company, with adoption across independent frameworks like LangGraph, CrewAI, and Mastra. AWS and Microsoft’s support just means you now get managed infrastructure (auth, scaling, session handling) around it if you choose either cloud — not that you need either to use the protocol itself.

Is this the same AG-UI covered in the earlier field guide on this publication? Yes — same protocol, this piece just zooms in on why two major cloud platforms adopted it and what their specific integrations look like.

Practical Takeaways

• AWS added native AG-UI support to Bedrock AgentCore Runtime in March 2026 — live across fourteen regions, complementing existing MCP and A2A support, with a ready-made starter template (FAST) to build from.
• Microsoft added native AG-UI support to Agent Framework in April 2026 — a single pip install for Python (also available for .NET), positioned explicitly as joining an existing multi-framework ecosystem.
• Neither company built their own competing protocol. That’s the real headline — it signals AG-UI has moved past “promising open-source project” into “infrastructure too useful to reinvent.”
• If you’re choosing a cloud for an AI agent product, this reduces lock-in risk. An agent built with AG-UI in mind can move between AWS and Azure (and other AG-UI-compatible platforms) with far less frontend rework than a proprietary alternative would require.
• This is a strong signal for where to invest your own learning time. Protocols that get picked up by rival cloud giants independently, within weeks of each other, tend to stick around longer than ones that don’t.

Where This Leaves You

Rival companies rarely agree on infrastructure by accident. When AWS and Microsoft — two platforms that compete on almost every axis — both quietly conclude that the smartest move is supporting the same open, third-party protocol rather than building their own, that’s the clearest signal available that AG-UI has crossed from “interesting open-source project” into “layer the entire industry is going to build on.”

If you’ve been on the fence about whether AG-UI is worth learning versus waiting to see what wins, this is about as strong a market signal as you’re going to get before it’s simply assumed knowledge.

If this kind of “here’s what the news actually means” breakdown is useful, that’s exactly what Think in AI Agents does every week — cutting through the protocol overload one field guide at a time. Follow the publication so the next breakdown lands in your feed before the next big platform announcement does, and drop a comment below: which cloud are you building your next agent project on?

Level up your skills with my Amazon eBooks

Get the The AI Agent Builder’s Playbook : Why AI Agent Projects Die in Production on Amazon.

Get the Copilot Studio for Architects: When to Use It, What It Really Costs, and How to Combine It with Pro-Code AI Agents on Amazon.