The short version: if you need enterprise breadth, cross-runtime protocol support, and Azure-native hosting, Microsoft Agent Framework is the default. If you want typed, testable, composable agent behavior with the smallest surface area, Pydantic AI V2 is the bet. If your problem is fundamentally data- and RAG-shaped — documents, retrieval, multi-step pipelines — LlamaIndex Workflows is the most production-hardened choice, having quietly reached its own 1.0 a full year before the other two. None of these are wrong answers; they're answers to different questions.
Three launches, three timelines#
Microsoft Agent Framework hit 1.0 GA on April 3, 2026, merging Semantic Kernel and AutoGen — two projects that together carried more than 75,000 GitHub stars — into one MIT-licensed SDK shipping first-class .NET and Python. Pydantic AI V2.0.0 went stable on June 23, 2026 after seven betas, rebuilding its abstraction around a "capability" primitive (see our earlier breakdown of what that actually changes). LlamaIndex Workflows, by contrast, reached its standalone 1.0 on June 25, 2025 — a year before the other two — and by June 30, 2026 was already past version 2.22, meaning it has had more than a year of real production mileage while Microsoft and Pydantic are still hardening fresh 1.0s.
That timeline gap matters for risk tolerance as much as features do. If you can't afford to be an early adopter of an orchestration layer, LlamaIndex's runtime has simply eaten more edge cases by now.
Microsoft: protocol breadth as the product#
Microsoft Agent Framework's whole pitch is interoperability. MCP and A2A ship native at 1.0, not as bolt-ons — the framework assumes your agents will need to call external tools over MCP and talk to agents running in other frameworks over A2A, and it wants to be the connective tissue rather than a silo. It supports six model providers out of the box (Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama), and Microsoft built migration assistants specifically to pull Semantic Kernel and AutoGen codebases forward, which tells you who this is really for: teams already inside the Microsoft ecosystem who need one supported, long-term-support SDK instead of two half-merged ones.
The framework kept building past 1.0. At Build 2026, Microsoft added an "Agent Harness" — a loop wired with tools, planning, memory, approvals, and observability — plus CodeAct, which lets a model write one short program to call several tools instead of round-tripping per call, and Hosted Agents in Foundry Agent Service, which scale to zero and resume with filesystem state intact.
Microsoft calling its batteries layer an "Agent Harness" and Pydantic calling its equivalent the "Harness" is not a coincidence — it's the same idea, arrived at independently, by teams optimizing for very different customers.
Pydantic AI: the smallest core that could work#
Where Microsoft optimizes for breadth, Pydantic AI V2 optimizes for restraint. The core stays deliberately small — the agent loop, providers, and the capability API — while everything else (memory, guardrails, context management, filesystem access, and CodeMode, its own version of "let the model write code instead of calling tools one at a time") lives in a separate, faster-moving Harness package. A capability bundles an agent's tools, hooks, instructions, and model settings into one typed, testable, reusable unit, so an agent stops being a pile of settings assembled at construction time and becomes a composition you can name and unit-test.
This is a harness-first design, not a graph-first one — there's no explicit node-and-edge state machine to wire up, which is the same shape the OpenAI and Anthropic agent SDKs took. If your team values Python's type system catching mistakes before runtime and wants to add orchestration complexity only when a use case actually demands it, this is the leanest of the three starting points.
LlamaIndex: the workflow model built for data#
LlamaIndex Workflows models an agent as steps — async functions — reacting to events pulled off a queue and emitting new events for downstream steps, with a shared Context object carrying state across the run. It's explicit, event-driven, and was carved out of the core llama_index package into its own standalone package precisely so it could be used as a general-purpose orchestration layer, not just a RAG plumbing detail — though RAG and document pipelines are still where it's most battle-tested, backed by the surrounding LlamaParse and LlamaHub data ecosystem and a production runtime (llama-deploy) that runs workflows as distributed services.
Because the event/step model makes control flow explicit, it reads closer to Microsoft's orchestration mindset than to Pydantic AI's loop-and-capabilities approach — the difference is that LlamaIndex's graph is built for data movement first, agents second.
The decision#
- If you optimize for enterprise breadth, protocol interoperability, and Azure-native hosting → pick Microsoft Agent Framework.
- If you optimize for typed, testable, minimal-surface-area agent code you can unit-test in isolation → pick Pydantic AI V2.
- If you optimize for data-heavy, document- or retrieval-centric pipelines with the most production mileage already on the clock → pick LlamaIndex Workflows.
- If you're not sure yet and want to keep switching costs low → build your tools and prompts as portable units and pick whichever runtime's default posture annoys you least — all three are MIT-licensed, and the orchestration layer is the part you'll actually be replacing later, not the model calls underneath it.



