← Back to Autonomy

Field Monograph · Agentic Systems

The Frameworks
Behind the Agents

A practical tour of LlamaIndex, AutoGen / AG2, Pydantic AI, Semantic Kernel, LangGraph and CrewAI — what they are, how they're shaped, the protocols binding them, and where the field is actually heading.

By Majid MazouchiEST. 20266 FRAMEWORKS · 2 PROTOCOLSDIAGRAMS · CODE · NOTES · REFS

Contents

  1. Orientation
  2. LlamaIndex — data & retrieval
  3. AutoGen / AG2 — multi-agent
  4. Pydantic AI — type-safe
  5. Semantic Kernel — enterprise SDK
  6. LangChain / LangGraph — stateful graphs
  7. CrewAI — role-based crews
  8. MCP & A2A — the protocols
  9. At a glance (comparison)
  10. Decision flowchart
  11. Where the field is going
  12. Three-tier reference architecture
  13. Gated OTA skill-deployment loop
  14. Evaluation appendix
  15. Version / last-verified table
  16. References
§ 0 — ORIENTATION

These tools all answer one question — how do I wrap a language model in enough structure to do useful, repeatable work? — but each answers it from a different starting point. LlamaIndex starts from your data. AutoGen / AG2 and CrewAI start from agents working together. Pydantic AI starts from type-safe contracts. Semantic Kernel starts from enterprise plumbing. LangGraph starts from an explicit state machine.

Worth saying up front, because it reframes everything below: the framework you pick matters less than the field once believed. The dominant trend is engineers assembling their own lightweight harness and treating the hard problems as cross-cutting concerns — evaluation (is it actually working?), observability (what did it do and why?), and memory (what carries forward?). As one practitioner put it bluntly, the gap between a good agent system and a bad one is almost never the framework — it's the eval pipeline, the observability setup, and the failure-recovery logic[32]. The frameworks below are increasingly judged by how cleanly they expose those seams. We return to this in §D–G.

01 · Data & Retrieval

LlamaIndex

The data framework that grew into agentic document processing.

LlamaIndex began as the connective tissue between an LLM and your corpus. Its identity is the retrieval pipeline: ingest, chunk, embed, index, and serve the right context at query time. The team has been explicit that they moved beyond being "just a RAG framework" toward best-in-class agentic document processing — OCR, structured extraction, and orchestration over documents[5].

Two pieces anchor the modern stack. LlamaParse handles hard real-world documents (tables, charts, mixed layouts) where naive OCR produces garbage. Workflows 1.0, released mid-2025, is a lightweight event-driven framework for agentic systems[2] — prebuilt agents for speed, or hand-authored workflows for full control[7]. The flagship pattern, Agentic Document Workflows (ADW), fuses parsing, retrieval, structured output and agent loops into end-to-end knowledge work, a step past both classic IDP and plain RAG[4].

PDFs · DBsAPIs · docs LlamaParse /Ingestion Chunk +Embed Index /Vector store Retriever +Query Engine Workflows 1.0 · Agent loop (ADW)reason · call tools · self-correct · emit structured output → Answer
Fig. 1 — Data flows left-to-right into the index; the agent loop pulls context back through the retriever.

// minimal shape

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

docs  = SimpleDirectoryReader("./service_manuals").load_data()
index = VectorStoreIndex.from_documents(docs)        # ingest → embed → index
engine = index.as_query_engine()
print(engine.query("What torque spec applies to the rotor bolt?"))

Practical notes

Gotchas
  • LlamaParse and managed indexing sit behind a cloud/paid tier — costs scale with document volume, easy to under-budget.
  • Default chunking is rarely optimal for technical docs; tables and figures need tuned parsing or they fragment.
  • It is not an orchestration platform — for elaborate multi-agent control you'll bolt on another tool anyway.
↑ top
02 · Multi-Agent

AutoGen / AG2

Agents that solve problems by talking to each other — and a fork you need to understand.

AutoGen came out of Microsoft Research as a framework for conversable agents: compose specialized agents (plus an optional human proxy) into a group chat where they collaborate, debate, reflect, and execute code to reach a goal[11]. Group chat, sequential conversation, reflection, parallel execution — those patterns made it popular.

The thing to internalize is the governance split. The original authors (Chi Wang, Qingyun Wu) left Microsoft in late 2024 and forked the project as AG2, keeping the proven v0.2 architecture, the original PyPI packages (autogen, pyautogen, ag2) and independent governance under Apache 2.0[9][12]. Microsoft rewrote AutoGen as v0.4+ (async actor model), then in October 2025 folded it together with Semantic Kernel into the new Microsoft Agent Framework (MAF), leaving the classic line in maintenance[10].

GroupChatManager / orchestrator UserProxy(human / exec) Planner agentdecompose task Coder / Toolexecute + verify AG2 (community fork)v0.2 lineage · original PyPI pkgs Microsoft Agent Framework+ Semantic Kernel · 1.0 (2026)
Fig. 2 — A group chat orchestrates specialists; the project itself forked into AG2 and the MAF successor.

// AG2 / v0.2-style shape

from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager

planner = AssistantAgent("planner", llm_config=cfg)
coder   = AssistantAgent("coder",   llm_config=cfg)
user    = UserProxyAgent("user", human_input_mode="NEVER", code_execution_config={...})

chat = GroupChat(agents=[user, planner, coder], messages=[], max_round=12)
mgr  = GroupChatManager(groupchat=chat, llm_config=cfg)
user.initiate_chat(mgr, message="Diagnose the 3000 RPM trip from this log...")

Practical notes

Gotchas
  • Three architectural shifts in under two years (0.2 → 0.4 → MAF). Production code carries a migration plan whether you want one or not[9].
  • Package-name confusion (autogen vs pyautogen vs Microsoft's repo) trips up dependency pinning — read which project you're installing.
  • Free-flowing conversation is harder to constrain in production; without round caps and tight tool boundaries, agents loop or wander.
↑ top
03 · Type-Safe

Pydantic AI

"The FastAPI feeling" for agents — validation as a first-class citizen.

Built by the Pydantic team (Samuel Colvin and collaborators), Pydantic AI starts from a sharp observation: nearly every Python agent library already uses Pydantic for validation, yet none delivered the ergonomic, type-safe experience FastAPI brought to web work[20]. So the agent's output is a Pydantic model, its tools are validated functions, and its dependencies are typed and injected — pushing whole classes of error from runtime to write-time[17].

It's model-agnostic and ships the surrounding production machinery: Logfire for OpenTelemetry-native observability, Pydantic Evals for systematic testing, a graph layer, durable execution, plus MCP and A2A support[16][17]. If the schema fails to validate, the framework re-prompts the model in a self-correction loop[21]. It reached a stable 1.x in late 2025 and iterates roughly weekly[18].

Agent · typed Deps in / typed Output out Instructions (system prompt) @tool — validated fns Output schemaBaseModelvalidate → retry Model interface (agnostic)OpenAI · Anthropic · Bedrock · … validation loop Logfire — observability Pydantic Evals — testing MCP · A2A · durable exec
Fig. 3 — Type-safe boundaries on every edge; the validation loop re-prompts until the output fits the schema.

// the whole idea

from pydantic import BaseModel
from pydantic_ai import Agent

class Fault(BaseModel):
    component: str
    severity: int           # constrain 0..10 and it's enforced
    rationale: str

agent  = Agent('anthropic:claude-opus-4-8', output_type=Fault)
result = agent.run_sync("Triage this CAN log: ...")
fault  = result.output      # a typed Fault, guaranteed-shaped

Practical notes

Gotchas
  • Weekly releases mean a fast-moving surface; pin versions and read changelogs even though the 1.x API is stable.
  • Single-agent first — multi-agent orchestration exists (graph layer) but is less battle-tested than AutoGen/LangGraph for complex topologies.
  • The retry-on-invalid loop can quietly multiply token cost on poorly-constrained schemas; watch Logfire traces.
↑ top
04 · Enterprise SDK

Semantic Kernel

Microsoft's model-agnostic SDK for putting LLM reasoning inside real applications.

Semantic Kernel (SK) launched in early 2023 as Microsoft's answer to "how do I integrate an LLM into a production app safely and repeatably?" Its mental model is three parts[25]: the Kernel is a dependency-injection container that orchestrates everything; Plugins (formerly "skills") are the typed tools you give an agent; and a Planner inspects the request and available plugins to build a step-by-step plan. It also carries early memory abstractions and runs with C#, Python and Java parity — its enterprise calling card[30].

Current reality: SK has been folded into Microsoft Agent Framework, which reached 1.0 in 2026 and unifies SK's enterprise foundations with AutoGen's orchestration[23][29]. Notably, MAF drops the explicit planner — modern reasoning models plan natively given the right tools — and makes MCP a first-class way to attach tool servers[26]. Microsoft has committed to supporting SK v1.x for at least a year past MAF's GA[28].

KernelDI container · orchestrator Plugins / skills[KernelFunction] tools Plannerplan over plugins Memoryembeddings / recall AI servicesOpenAI / Azure / HF → Microsoft Agent Framework 1.0workflows · MCP · A2A · planner now optional
Fig. 4 — Kernel as the hub for plugins, planner and memory; the whole thing now flows into MAF.

// C# — the enterprise calling card

var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(deployment, endpoint, apiKey);
builder.Plugins.AddFromType<DiagnosticsPlugin>();   // [KernelFunction] tools
var kernel = builder.Build();

var reply = await kernel.InvokePromptAsync(
    "Summarize the fault codes and recommend next steps.");

Practical notes

Gotchas
  • You're adopting a framework mid-transition — building fresh on legacy SK risks an avoidable migration to MAF later.
  • Historically verbose vs. Python-first frameworks; expect more boilerplate to reach the same behavior.
  • The classic Planner pattern is being retired — don't over-invest in bespoke planner logic that strong models now do natively[26].
↑ top
05 · Stateful Graphs

LangChain / LangGraph

From chaining LLM calls to an explicit, auditable state machine.

LangChain began as the framework for chaining LLM calls and grew into a sprawling platform — LangSmith for observability, LangServe for deployment, and LangGraph for stateful agent workflows — with one of the largest ecosystems in the space[37]. The LangChain team now explicitly steers people to LangGraph for agents and keeps LangChain itself for RAG and document Q&A[39].

LangGraph models a workflow as a directed (often cyclic) graph: nodes execute actions, edges define transitions, and state flows through and persists at checkpoints — giving explicit control over every decision point, retry and branch[31]. Production patterns that used to be community recipes — checkpointing, durable execution, human-in-the-loop approvals — are now first-class[14], with a stable Postgres checkpointer and first-class TypeScript support[38][35]. It's the default pick for regulated, auditable production where deterministic control matters[36].

Shared State (persisted at every checkpoint ●) START Agent nodereason + tools Routerconditional edge Tool node HITL approvehuman-in-loop END cycle back (loop until done)
Fig. 5 — Nodes and conditional edges over a persisted state; cycles, retries and human approvals are explicit.

// graph shape

from langgraph.graph import StateGraph, START, END

g = StateGraph(DiagState)
g.add_node("triage", triage_fn)
g.add_node("tools",  tool_fn)
g.add_edge(START, "triage")
g.add_conditional_edges("triage", route, {"call": "tools", "done": END})
g.add_edge("tools", "triage")        # cycle back
app = g.compile(checkpointer=PostgresSaver(...))   # durable state

Practical notes

Gotchas
  • The graph paradigm has a real learning curve — it clicks for some immediately and confuses others for weeks[35].
  • Overkill for a simple linear workflow; don't reach for a state machine when a single typed agent call would do.
  • No native MCP/A2A protocol support yet — it leans on community integrations, where CrewAI ships them in-box[33].
↑ top
06 · Role-Based Crews

CrewAI

The fastest path from idea to a working multi-agent demo.

CrewAI orchestrates teams of role-based agents. You give each agent a role, goal and backstory, assign it tasks, and assemble them into a crew that runs under a process type — sequential, hierarchical or consensual[31]. The team metaphor is intuitive and fast: most teams get a working multi-agent setup running in a few hours[35]. It's been the fastest-growing framework in the category, with ~45k GitHub stars, version 1.x, hundreds of millions of monthly workflow executions, and adoption across a large share of the Fortune 500[33][36].

Crucially for interoperability, CrewAI shipped native MCP and A2A support — making it a strong choice when your agents must reach external tool servers and talk to agents built on other frameworks[33][37].

Crewprocess: sequential / hierarchical Researcherrole · goal · backstorytask → gather evidence Analystrole · goal · backstorytask → diagnose Writerrole · goal · backstorytask → report native MCP (tools) + A2A (other agents)
Fig. 6 — Specialists with roles pass tasks down the crew; MCP and A2A connect outward.

// crew shape

from crewai import Agent, Task, Crew, Process

analyst = Agent(role="VHM Analyst", goal="diagnose the fault",
                backstory="20 yrs in powertrain prognostics")
task = Task(description="Classify this bearing signature", agent=analyst)

crew = Crew(agents=[analyst], tasks=[task], process=Process.sequential)
result = crew.kickoff()

Practical notes

Gotchas
  • The well-documented 6–12 month ceiling: teams move fast, then need non-linear flows or dynamic agent spawning, hit the opinionated design, and rewrite[39].
  • Debugging inside task execution is awkward — ordinary prints/logging don't surface well[39].
  • Python-centric; no help if you need agents in other languages[39].
↑ top
§ A — THE PROTOCOLS

MCP & A2A

Every framework above now cites these two acronyms. They're not competing — they sit on perpendicular axes and are designed to work together[44].

MCP (Model Context Protocol) is an open standard from Anthropic — think "USB for AI." It standardizes the vertical link: how a single agent connects to external tools and data (APIs, databases, file systems) through one consistent interface, over JSON-RPC, so you stop writing bespoke glue for every tool and every model[40][45].

A2A (Agent-to-Agent) is an open standard introduced by Google (April 2025, 50+ partners). It standardizes the horizontal link: how agents discover and collaborate with each other across vendors and frameworks. Agents advertise capabilities via an Agent Card (a JSON resume), and it's intentionally stateful — a Task object moves through states like submitted → working → input-required so both sides share one view of long-running work[41][42][47].

Agent A Agent B A2AAgent Card · stateful Task MCP MCP Tools / dataDB · API · files Tools / datasupplier systems MCP = agent ↔ tools (vertical) · A2A = agent ↔ agent (horizontal)
Fig. 7 — Perpendicular and complementary: MCP wires an agent to its tools; A2A wires agents to each other.
Why this matters for fleets

If you're designing agents that must outlive any single framework choice, build to the protocols, not the SDK. An MCP server you write once (say, a CAN/UDS query tool) is reusable by any MCP-aware framework; an A2A-exposed edge agent can be coordinated by a cloud orchestrator regardless of what either is built on. That's the cleanest hedge against the migration churn the framework sections keep flagging.

↑ top
§ B — AT A GLANCE

Side by side

The six frameworks reduced to the axes that actually drive a choice. "Status" reflects the field as of early-to-mid 2026; treat star counts and versions as directional (see §H).

FrameworkStarts fromSweet spotLanguagesStatus / caution
LlamaIndexYour dataRAG, document parsing, agentic doc workflowsPython, TSActive; cloud tiers cost money; local path for edge
AutoGen / AG2Agents conversingMulti-agent collaboration, code-gen, debatePythonForked: AG2 vs MAF — pick deliberately
Pydantic AIType-safe contractsStructured outputs, lightweight typed harnessPythonStable 1.x; weekly releases; Logfire/Evals
Semantic KernelApp plumbingEnterprise / .NET / Azure integrationC#, Python, JavaSuperseded by MAF 1.0; SK v1.x supported ~1yr past GA
LangGraphExplicit state machineAuditable, stateful production; HITL; retriesPython, TSMature; steeper curve; no native MCP/A2A yet
CrewAIRole-based crewsFast prototyping; native MCP + A2APythonHuge adoption; 6–12mo ceiling on complex flows
↑ top
§ C — DECISION FLOWCHART

Which one?

A rough triage, not a verdict. The honest first question is whether you need a framework at all — for a single typed call, a thin harness plus the protocols often wins.

Is the hard part the documents/data?parsing, retrieval, large corpus yes LlamaIndex no Do you just need typed outputfrom one agent? yes Pydantic AI no On .NET / Azure or needC#/Java parity? yes Semantic Kernel→ MAF for new work no Need audit trails, retries,human-in-the-loop? yes LangGraph no Want a fast multi-agentprototype / cross-vendor? yes CrewAI AutoGen / AG2 or MAFconversational multi-agent
Fig. 8 — Walk top-to-bottom; the first "yes" is your strong default, not a rule.
↑ top
§ D — WHERE THE FIELD IS GOING

Past the framework wars

Notice what every project converged toward in 2025–26: native MCP for tools, native observability, built-in evaluation, explicit memory — while clever orchestration DSLs receded (MAF even dropped the planner). That convergence is the signal. The differentiating problems moved out of the framework into three cross-cutting concerns.

Your harnessthin loop · any framework underneath Evaluationis it actually working?test sets · regression · scoring Observabilitywhat did it do, and why?traces · tokens · latency (OTel) Memorywhat carries forward?short-term · long-term · context
Fig. 9 — The framework is interchangeable; the three concerns below it are where the engineering effort now lives.
↑ top
§ E — REFERENCE ARCHITECTURE

Mapping it onto a three-tier system

For a constrained compute hierarchy (a safety-critical controller, a high-compute edge node, a cloud backend) the lens shifts usefully. The rule of thumb: no framework belongs on the safety-critical tier — that stays deterministic. The edge earns a thin typed harness; the heavy orchestration lives in the cloud where compute and observability are cheap.

TIER 1 · Safety-critical ECUdeterministic control · ASIL-rated · fixed-point · hard real-time NO LLM / NO framework hereemits signals / DTCs only TIER 2 · High-compute edge nodethin typed harness · runs intermittently · bandwidth-constrained uplink Triagekeep / drop / flag Context enrichlocal retrieval Weak-labelat the source Pydantic AI / LlamaIndex (local)typed output · A2A-exposed TIER 3 · Cloud backendheavy multi-agent orchestration · fleet view · eval + observability LangGraph / MAF adaptive acquisitioncampaigns signals up enriched payload up campaigns / skills down
Fig. 10 — Triage and enrich at the edge before the bandwidth-limited uplink; orchestrate and learn in the cloud.
Unifying rule

The same lesson MAF stumbled into applies at every tier: give good tools and tight schemas first; build bespoke orchestration last. Pydantic AI's "never emit an unparseable blob" discipline is exactly what you want feeding a Tier-1 boundary; LangGraph's auditable state machine is what you want when a cloud decision must be reconstructable months later.

↑ top
§ F — GATED OTA SKILL DEPLOYMENT

The deployment loop, gated by eval

This is where §D's three concerns become a control loop. A new or updated "skill" (a tool, a prompt, a sub-agent) should never ship to a fleet on author confidence alone. Evaluation and observability are the gates; telemetry from the field closes the loop and produces the next batch of training/eval data.

Skill candidatetool / prompt / agent Eval gategolden set · regressionscore ≥ threshold? Shadow / canaryobserve on live trafficno actions taken Human approvesign-off + audit OTA → fleetstaged rollout Field telemetrytraces · outcomes · drift New eval dataweak labels → golden set pass feeds next candidate fail → back to author
Fig. 11 — Two gates (automated eval, then human sign-off after a shadow run), then staged OTA; field telemetry regenerates eval data.
↑ top
§ G — EVALUATION APPENDIX

Building the eval harness the frameworks punt on

Every framework now ships some eval hook (Pydantic Evals, LangSmith datasets, CrewAI's observability), but the substance is yours to build. A workable shape:

1 · A golden set with teeth

Start small and adversarial: 30–100 cases that each pin one behavior, with a known-good answer or an assertable property. For diagnostic work that's often a property, not a string — "severity is within ±1 of ground truth," "names the correct subsystem," "never fabricates a DTC." Grow it from field failures (§F's flywheel), not from cases the system already passes.

2 · Scoring that isn't just string-match

Layer three kinds of check: deterministic assertions (schema valid, value in range — Pydantic does this for free), reference metrics where a gold answer exists, and an LLM-as-judge for open-ended quality with a tight rubric. Keep judge prompts versioned; a drifting judge silently moves your bar.

3 · Regression discipline

Run the whole set on every skill candidate and store scores per version. The gate is relative, not absolute: block anything that drops a previously-passing case, even if aggregate score rises. Aggregate improvements routinely hide specific regressions.

4 · Cost and latency as first-class metrics

Score tokens and wall-clock alongside quality — a skill that's 2% better and 3× slower may be a net loss at the edge. Observability traces (OTel via Logfire/LangSmith) give you these for free if wired early.

# sketch: property-based eval over a golden set
for case in golden_set:
    out = agent.run_sync(case.input).output      # typed → already schema-valid
    record(case.id, version,
        in_range = abs(out.severity - case.truth.severity) <= 1,
        subsystem_ok = out.component == case.truth.component,
        no_fabricated_dtc = out.dtc in KNOWN_DTCS,
        tokens = trace.tokens, latency_ms = trace.ms)
gate_pass = no_regressions(version) and aggregate(version) >= THRESHOLD
↑ top
§ H — VERSION / LAST VERIFIED

Snapshot — treat as directional

Star counts and versions move weekly and vary by source; these are representative figures verified June 2026, not authoritative. Always check the primary docs in §R before pinning anything.

FrameworkRepr. version≈ GitHub starsNoteAs of
LlamaIndexWorkflows 1.0shifting toward agentic doc processing2026-Q1
AutoGen1.0 GA (v2 API)~56k (MS repo)classic line in maintenance2026-02
AG2 (fork)v0.2 lineage~4–5kcommunity-governed2026-Q1
Pydantic AI1.8x~17kweekly releases, stable 1.x API2026-04
Semantic Kernelv1.x (→ MAF)~27ksuperseded by MAF 1.02026-Q1
MS Agent Framework1.0 GASK + AutoGen merger2026-04
LangGraphv0.4+~24kLangChain ~97k stars overall2026-Q1
CrewAI1.10.x~45knative MCP + A2A2026-03
MCPopen standardAnthropic; JSON-RPC; widely adopted2026-Q1
A2Aopen standardGoogle + 50 partners (Apr 2025)2026-Q1
↑ top
§ R — REFERENCES

Sources & further reading

Primary docs and project pages first; analyst/comparison pieces where they clarify the cross-framework picture. Accessed June 2026.

  1. LlamaIndex — "Announcing Workflows 1.0." llamaindex.ai/workflows
  2. LlamaIndex — "Introducing Agentic Document Workflows." llamaindex.ai/blog · ADW
  3. LlamaIndex — "LlamaIndex is more than a RAG framework." llamaindex.ai/blog · beyond-RAG
  4. LlamaIndex — engineering blog (filesystem tools vs RAG). llamaindex.ai/blog
  5. LlamaIndex — Agents use-case docs. developers.llamaindex.ai · agents
  6. Nexus — "AutoGen vs CrewAI" (AG2 lineage, migration risk). agent.nexus · autogen-vs-crewai
  7. Nexus — "Microsoft Agent Framework Alternatives" (AutoGen/AG2/MAF split). agent.nexus · MAF alternatives
  8. "Architecting Resilient LLM Agents" — AutoGen patterns (arXiv 2509.08646). arxiv.org/pdf/2509.08646
  9. Nexus — Nexus vs AutoGen/AG2 (PyPI control, MAF timeline). agent.nexus · nexus-vs-autogen
  10. alicelabs — "Best AI Agent Frameworks 2026" (LangGraph production patterns; AutoGen/AG2 split). alicelabs.ai · best-frameworks-2026
  11. Pydantic — Pydantic AI product page. pydantic.dev/pydantic-ai
  12. Agent Wiki — Pydantic AI (type safety, DI, Evals, A2A). agentwiki.org/pydantic_ai
  13. DEV — "Pydantic AI Tutorial" (release cadence, Bedrock). dev.to · pydantic-ai-tutorial
  14. Pydantic — official Pydantic AI docs. ai.pydantic.dev
  15. "Pydantic AI: Type-Safe AI Agent Framework" (self-correction loop). decisioncrafters.com · pydantic-ai
  16. Visual Studio Magazine — "Microsoft Ships Agent Framework 1.0." visualstudiomagazine.com · MAF 1.0
  17. A. Belablotski — "Semantic Kernel and AutoGen" (Kernel/Plugins/Planner). belablotski.github.io · multi_agent
  18. DEV — "Migrating from Semantic Kernel to MAF" (planner now optional, MCP-native). dev.to · SK → MAF
  19. orchestrator.dev — Semantic Kernel guide (SK v1.x support window). orchestrator.dev · SK guide
  20. GitHub — microsoft/semantic-kernel ("now Microsoft Agent Framework"). github.com/microsoft/semantic-kernel
  21. S. Bhattacharyya — "MAF: the next evolution beyond SK and AutoGen." medium.com · MAF evolution
  22. Fastio — "LangGraph vs CrewAI: Honest Comparison 2026" (graph model; crew roles/process types). fast.io · langgraph-vs-crewai
  23. Tensoria — "LangGraph vs CrewAI vs AutoGen vs Custom [2026 Benchmark]." tensoria.fr · orchestration comparison
  24. Redwerk — "LangGraph vs CrewAI in 2026" (CrewAI MCP+A2A, workflow volume; LangGraph no native protocol). redwerk.com · langgraph-vs-crewai
  25. agentsindex — "CrewAI vs LangGraph" (versions, MCP/A2A, TS support, learning curve). agentsindex.ai · crewai-vs-langgraph
  26. Uvik — "Agentic AI Frameworks 2026" (LangGraph for regulated/auditable; CrewAI adoption). uvik.net · agentic-ai-frameworks
  27. NxCode — "CrewAI vs LangChain 2026" (LangChain ecosystem/stars; CrewAI MCP+A2A). nxcode.io · crewai-vs-langchain
  28. PE Collective — "AI Agent Frameworks Compared 2026" (LangGraph v0.4 checkpointer; CrewAI/AutoGen versions). pecollective.com · frameworks compared
  29. Stencilwash — "AI Agent Framework Comparison 2026" (LangChain→LangGraph steer; CrewAI 6–12mo ceiling, debugging). stencilwash.com · framework comparison
  30. Composio — "MCP vs A2A" (MCP = Anthropic open standard, USB-for-AI; complementary). composio.dev · mcp-vs-a2a
  31. TrueFoundry — "MCP vs A2A" (A2A announced Google Cloud Apr 2025, 50+ partners). truefoundry.com · mcp-vs-a2a
  32. Tahir (Medium) — "A2A vs MCP" (Agent Card, HTTP/JSON-RPC, vertical vs horizontal). medium.com · a2a-vs-mcp
  33. Auth0 — "MCP vs A2A" (complementary building blocks, not competing). auth0.com/blog/mcp-vs-a2a
  34. Boomi — "What is MCP, ACP, and A2A?" (MCP JSON-RPC 2.0; Anthropic origin; OpenAI adoption). boomi.com · mcp-acp-a2a
  35. Stride — "A2A vs MCP: when to use which" (A2A stateful Task object + states; Agent Card discovery). stride.build · a2a-vs-mcp