The Framework Landscape

Picture building a house. Pouring a single room's slab is a weekend job. Wiring the whole house to code, plumbing it, and making it pass inspection is the part that takes months. Agent frameworks are about that second part — not the room, the rest of the house.

You already know the four parts of an agent: a model, tools, memory, and a loop toward a goal. You can wire those together yourself in about 40 lines of Python. So why does anyone use a framework? Because those 40 lines are the easy part. The hard part is everything around them: managing message history as it grows, orchestrating tool calls and retries when they fail, persisting state so a crashed run can resume, pausing for human approval, emitting traces you can debug, and connecting to a deployment target. Building that plumbing robustly — for even a basic multi-agent system — can take weeks.

A framework gives you those pieces off the shelf:

• A built-in agent loop and message-history management
• Tool orchestration with retry and error handling
• State persistence and checkpointing
• Human-in-the-loop interrupts
• Observability hooks and deployment connectors

The key insight: every major framework solves the same core plumbing — message passing, state checkpointing, handoff protocols, failure recovery. They differ mainly in their opinions about how you should express your agent. Choosing one is choosing whose opinions fit your problem.

Most frameworks hand you a loop and hide the wiring. LangGraph does the opposite: it makes you draw the wiring yourself — and that is exactly the point when real money or safety is on the line.

If your agent is going to production with real stakes — audit trails, rollback, resuming after a crash — LangGraph is the default answer in 2026. It reached v1.0 in October 2025 (MIT license, maintained by LangChain Inc.) and runs in production at Klarna, LinkedIn, Uber, Cloudflare, and Elastic.

Its core abstraction is the StateGraph: a directed graph where nodes are operations and edges encode routing, including conditional edges that branch on the current state. (Think of it as a flowchart you can execute, where a shared state object is passed from node to node.) You are not handed a black-box loop — you draw the control flow explicitly. That buys durable execution, checkpointing, streaming, and fine-grained control over every transition.

The cost is the steepest learning curve of the major frameworks. You think in graphs and state, not in a quick script.

from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class State(TypedDict):
    query: str
    answer: str

def plan(state: State) -> State:
    return {"answer": f"Plan for: {state['query']}"}

graph = StateGraph(State)
graph.add_node("plan", plan)
graph.add_edge(START, "plan")
graph.add_edge("plan", END)
app = graph.compile()

Note: LangChain and LangGraph are not the same thing. LangChain is the older chain-based library; LangGraph is a separate, graph-based orchestration framework and the recommended path for stateful production agents.

Sometimes one agent isn't enough — you want a team. Two frameworks specialize in multiple agents working together, but they answer two different questions. CrewAI asks "who plays which role, in what order?" AutoGen asks "how do these agents talk to each other?"

CrewAI uses a role-based DSL (a small, purpose-built vocabulary): you define agents with a role, give a crew a list of tasks, and let it run. A minimal agent is ~20-35 lines, and it has the lowest learning curve of the bunch — best for sequential, linear workflows where you want fast time-to-value and readable agent definitions. It sat at ~15,200 GitHub stars in January 2026.

from crewai import Agent, Task, Crew

researcher = Agent(role="Researcher", goal="Find facts", backstory="Diligent analyst")
task = Task(description="Research 2026 agent frameworks", agent=researcher,
            expected_output="A short brief")
crew = Crew(agents=[researcher], tasks=[task])
result = crew.kickoff()

AutoGen targets conversational, event-driven multi-agent systems — agents that exchange messages and react, rather than march through a fixed task list. But here a critical fact trips people up: "AutoGen" is no longer one project. In late 2024 it split:

• Microsoft AutoGen 0.4+ (January 2025): a complete architectural reimagination using an actor model (independent components that communicate only by passing messages) for async, distributed messaging, with a layered Core + AgentChat design. ~28,400 stars in January 2026.
• AG2: a community fork by the original creators (Chi Wang and Qingyun Wu) that maintains 0.2.x backward compatibility.

Reports indicate Microsoft's heaviest investment has shifted toward Semantic Kernel and the broader Azure AI platform, so check the project's direction before committing.

If you've already committed to one provider — OpenAI, Anthropic, or Google — the fastest path is often the toolkit that vendor ships itself. Less glue code, batteries included, tuned for that model.

If you're staying inside one provider's ecosystem and want minimal boilerplate, the provider SDKs are the fastest on-ramp.

OpenAI Agents SDK (launched March 2025, actively maintained through 2026) is the production-ready successor to the experimental Swarm project — not just a rebrand. It has three primitives: Agents (LLM + instructions + tools), Handoffs (one agent delegating to another), and Guardrails (input/output validation). It supports Python and TypeScript/JS with feature parity, plus built-in tracing, MCP tool integration, sandbox execution, and Realtime Agents for voice.

from agents import Agent, Runner

agent = Agent(name="Assistant", instructions="Answer concisely.")
result = Runner.run_sync(agent, "Summarize the 2026 framework landscape.")
print(result.final_output)

Claude Agent SDK (renamed from Claude Code SDK on September 29, 2025) ships 14+ built-in tools (Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, …), subagents with isolated context windows, lifecycle hooks, a Skills system, and MCP integrations. It is not the same as calling the Anthropic Messages API directly — it is a higher-level agent harness on top. Notably, it lacks built-in observability, durable execution, and cross-session state persistence — you add those yourself.

Google ADK (Agent Development Kit, open-sourced April 9, 2025 at Google Cloud NEXT) is code-first and multi-language (Python, TypeScript, Go, Java, Kotlin). It integrates Gemini and, via LiteLLM (a library that gives one uniform interface to many model providers), third-party models — and can even use LangGraph, CrewAI, and LlamaIndex agents as sub-tools. It deploys to Vertex AI Agent Engine or any container.

Some projects don't really have a control-flow problem or a teamwork problem — they have a document problem. Thousands of contracts, messy PDFs, tables that text extractors butcher. That is LlamaIndex's home turf.

LlamaIndex began life as a RAG library (RAG = retrieval-augmented generation: fetching relevant text and feeding it to the model), and many engineers still file it there. That's outdated. In 2025 it repositioned as an agentic document-processing platform. On January 22, 2025 it introduced AgentWorkflow, a high-level multi-agent orchestration layer built on its Workflows 1.0 abstraction (now a standalone package: pip install llama-index-workflows).

The reason to pick LlamaIndex is when your primary challenge is document-centric: contracts, compliance, knowledge extraction, retrieval over messy enterprise corpora. LlamaParse handles complex documents — tables, hierarchical structures — that naive text extraction mangles, and AgentWorkflow lets agents reason over the parsed results.

Think of the distinction this way: LangGraph asks "how should control flow?"; CrewAI asks "who does what?"; LlamaIndex asks "what do these documents actually say, and how do I get an agent to use them reliably?" If your hardest problem is the last one, LlamaIndex is purpose-built for it — while still giving you real multi-agent orchestration on top, not just retrieval.

Here is the honest shortcut to the whole landscape: don't pick by popularity or by what's trending. Pick by your task, your team's experience, and how much control you need over the flow. The table below collapses everything above into one lookup.

And sometimes the answer is no framework at all. From-scratch is justified when the workflow is linear and simple, the domain is highly specific, you need to iterate fast without fighting framework conventions, or framework overhead exceeds its benefit. A minimal agent loop with tool calling is ~40 lines of plain Python over the model API.

The honest rule: frameworks add value primarily for production requirements — persistence, observability, human-in-the-loop, retry logic, multi-agent coordination. They do not add much value for a basic prototype. Start with the least machinery that solves your problem, and adopt a framework when a production need — not curiosity — demands it.