I'm on the Python advocacy team at Microsoft, so I've been experimenting a bit with the new framework. It works pretty well, and is comparable to Langchainv1 and Pydantic-AI, but has tighter integrations with Microsoft-specific technologies. All the frameworks have very similar Agent() interfaces as well as graph-based approaches (Workflow, Langgraph, Graph).
I can flesh that out if it's helpful. I find it fascinating to see where agent frameworks converge and diverge. Generally, the frameworks are converging, which is great for developers, since we can learn a concept in one framework and apply it to another, but there are definitely differences as you get into the edge cases and production-level sophistication.
Curious what people see in these frameworks in 202(6). My experience has been that an agent is a simple while loop over tools/instructions/dialog. More complex integrations generally lie in the tools/context retrieval - but those have so far been so domain specific that it’s not worth pulling in a framework.
> Agent Framework offers two primary categories of capabilities:
> AI agents: Individual agents that use LLMs to process user inputs, call tools and MCP servers to perform actions, and generate responses. Agents support model providers including Azure OpenAI, OpenAI, and Azure AI.
> Workflows: Graph-based workflows that connect multiple agents and functions to perform complex, multi-step tasks. Workflows support type-based routing, nesting, checkpointing, and request/response patterns for human-in-the-loop scenarios.
You can do specialized SLMs with different roles working on problems. Also deterministic workflows. That is what I gathered its use. I know last year, multi-agent scenarios were topping to benchmarks but I don't know if 2025 has been the same.
Anything beyond this is usually a play to trap you into an ecosystem. No reason to adopt any of these frameworks, especially if you already have a mature workflow system.
I have used this in a “beta” feature for an enterprise app and really like it. In ~100 lines of code I have a secured OpenAI compatible endpoint that I can chat with, and write tools for in .NET. I have it doing natural language query over some data and it works quite well.
You can also expose the agents as MCP, AGUI and so it can be a tool you integrate with other AI platforms.
Certainly not better… it’s a one person project after all… but I have a workflow in typescript solution, not quite ready for prime time at workglow.dev. I’ll have AI agent stuff both in the framework and the UI (it’s feature flagged off at the moment) in January/February time frame.
The site above only runs local in browser models and uses a local user account. So it’s easy for infinite people to play with and costs me nothing to host.
It’s still a ways away from a Show HN post, and is more capable with remote frontier models, or with gguf over onnx (maybe?) whenever I get the local app out.
One of my grips with C#, Java,... is pushing runtime logic inside the type system. This leads to a huge standard library where there are multiple classes that are barely different than other other than implementation details.
I prefer Go's approach on preferring interfaces instead of inheritance. But what I like is Clojure and Lisp where the semantics of algorithms and data structure is not so diffuse.
I remember when "Microsoft Agent" meant the APIs that gave rise to Clippy, Rover, and (regrettably) even Bonzi Buddy.
The bitter irony is, Microsoft has since embrace-extend-extinguished Bonzi Buddy spyware tech, building it right into Windows 11. So... they're moving onward to the future I guess?
I've toyed with the idea of hooking up something like Copilot to Clippy to make an "agent" using the Microsoft Agents API.
Unfortunately, the API died in Windows Vista, and was only widely available in Windows XP at the latest.
API documentation seems rather sparse too, though it looks like an LLM somewhere found a pirated book or something with example code because generated code seems to understand the API and its restrictions decently well. Writing the kind of C++ that still compiles on old versions of Windows is what broke my will to finish the project, though.
I remember writing a Delphi application that spawned and used an agent, and even creating my own character when I was a teenager, so it surely wasn't that sparse.
I'm on the Python advocacy team at Microsoft, so I've been experimenting a bit with the new framework. It works pretty well, and is comparable to Langchainv1 and Pydantic-AI, but has tighter integrations with Microsoft-specific technologies. All the frameworks have very similar Agent() interfaces as well as graph-based approaches (Workflow, Langgraph, Graph).
I have a repository here with similar examples across all those frameworks: https://github.com/Azure-Samples/python-ai-agent-frameworks-...
I started comparing their features in more details in a gist, but it's WIP: https://gist.github.com/pamelafox/c6318cb5d367731ce7ec01340e...
I can flesh that out if it's helpful. I find it fascinating to see where agent frameworks converge and diverge. Generally, the frameworks are converging, which is great for developers, since we can learn a concept in one framework and apply it to another, but there are definitely differences as you get into the edge cases and production-level sophistication.
Given Microsoft’s track record, come back in a few years and see if it still lives.
> It brings together and extends ideas from Semantic Kernel and AutoGen projects, combining their strengths while adding new capabilities
… and giving a hint what will happen to the aforementioned projects.
—
It’s a shame when someone’s promotion is tied to how many new things they ship.
—
> To learn more about migrating from either Semantic Kernel or AutoGen, see the Migration Guide from Semantic Kernel and Migration Guide from AutoGen.
It seems the motto of Microsoft for the last 15 years: “You won’t have time for new features — all you’ll do is migrations.”
Fire and motion: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Curious what people see in these frameworks in 202(6). My experience has been that an agent is a simple while loop over tools/instructions/dialog. More complex integrations generally lie in the tools/context retrieval - but those have so far been so domain specific that it’s not worth pulling in a framework.
OpenAI agent sdk makes it extremely simple to get started with function calling and subagent-as-tools delegations.
If you use it with OpenAI responses api, there’s not even any need to store input items in your own DB
> Agent Framework offers two primary categories of capabilities:
> AI agents: Individual agents that use LLMs to process user inputs, call tools and MCP servers to perform actions, and generate responses. Agents support model providers including Azure OpenAI, OpenAI, and Azure AI.
> Workflows: Graph-based workflows that connect multiple agents and functions to perform complex, multi-step tasks. Workflows support type-based routing, nesting, checkpointing, and request/response patterns for human-in-the-loop scenarios.
You can do specialized SLMs with different roles working on problems. Also deterministic workflows. That is what I gathered its use. I know last year, multi-agent scenarios were topping to benchmarks but I don't know if 2025 has been the same.
Anything beyond this is usually a play to trap you into an ecosystem. No reason to adopt any of these frameworks, especially if you already have a mature workflow system.
I have used this in a “beta” feature for an enterprise app and really like it. In ~100 lines of code I have a secured OpenAI compatible endpoint that I can chat with, and write tools for in .NET. I have it doing natural language query over some data and it works quite well.
You can also expose the agents as MCP, AGUI and so it can be a tool you integrate with other AI platforms.
> Semantic Kernel and AutoGen pioneered the concepts of AI agents and multi-agent orchestration
Said nobody?
nice, are there other frameworks that are similar or better?
I use Google's Agent Development Kit (adk)[0] at work and enjoy using it quite a bit.
[0]: https://google.github.io/adk-docs/
Certainly not better… it’s a one person project after all… but I have a workflow in typescript solution, not quite ready for prime time at workglow.dev. I’ll have AI agent stuff both in the framework and the UI (it’s feature flagged off at the moment) in January/February time frame.
The site above only runs local in browser models and uses a local user account. So it’s easy for infinite people to play with and costs me nothing to host.
It’s still a ways away from a Show HN post, and is more capable with remote frontier models, or with gguf over onnx (maybe?) whenever I get the local app out.
TanStack AI is open source and almost ready for production: https://tanstack.com/ai/latest
I have a friend who works at Mastra[0].
Got part way through their tutorial, seemed okay. Haven't used it in prod, though.
0: https://mastra.ai/
Why throw in .net in the mix? That alone could squish all interest.
What’s the issue with net?
It’s a modern cross platform open source language with very good performance
One of my grips with C#, Java,... is pushing runtime logic inside the type system. This leads to a huge standard library where there are multiple classes that are barely different than other other than implementation details.
I prefer Go's approach on preferring interfaces instead of inheritance. But what I like is Clojure and Lisp where the semantics of algorithms and data structure is not so diffuse.
Let's say I want to use the agent on Linux/Mac.
Then I'll need to install .NET runtime first, which I know I won't ever use for anything else.
Then it's a hard no, unless I really don't have a choice (e.g. a different agent).
You don’t need to install the runtime (this has been true for years now).
There is self-contained publish option (with trimming).
And there is ahead-of-time compilation option to produce a fully native binary.
Though the latter is not for every API as of right now.
.Net has never been something most of HN cares about.
.Net is better fit for this than Python for sure?
I remember when "Microsoft Agent" meant the APIs that gave rise to Clippy, Rover, and (regrettably) even Bonzi Buddy.
The bitter irony is, Microsoft has since embrace-extend-extinguished Bonzi Buddy spyware tech, building it right into Windows 11. So... they're moving onward to the future I guess?
I've toyed with the idea of hooking up something like Copilot to Clippy to make an "agent" using the Microsoft Agents API.
Unfortunately, the API died in Windows Vista, and was only widely available in Windows XP at the latest.
API documentation seems rather sparse too, though it looks like an LLM somewhere found a pirated book or something with example code because generated code seems to understand the API and its restrictions decently well. Writing the kind of C++ that still compiles on old versions of Windows is what broke my will to finish the project, though.
I remember writing a Delphi application that spawned and used an agent, and even creating my own character when I was a teenager, so it surely wasn't that sparse.
Reimplementations exist too: https://mklab.eu.org/clippy/
> I remember when "Microsoft Agent" meant the APIs that gave rise to Clippy, Rover, and (regrettably) even Bonzi Buddy.
I remember Microsoft Agents as the enforcement arm of the Business Software Association.
They'd perform copyright raids on small biz, typically after some disgruntled employee phoned in an infringement tip.
Haven't used Microsoft Agent in decades. Nice to hear they're reviving it.