- Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust
- Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series)
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
On April 2, 2026, Microsoft shipped Agent Framework 1.0 and, in the same announcement, moved AutoGen into maintenance mode. Semantic Kernel went with it. VentureBeat covered it under the headline "Microsoft retires AutoGen and debuts Agent Framework to unify and govern". If you had an AutoGen project that morning, you now have a migration.
That is the loudest event in a year of framework churn, and it is a good reason to stop thinking about frameworks by brand name. The names change. The mental models underneath them do not. There are three, and once you can see them, picking a framework gets much easier.
Three mental models, not ten frameworks
Every multi-agent framework in 2026 hands you one of three ways to think about coordination.
Roles and crews. You describe agents as if you were hiring people. Each one has a role, a goal, a backstory. You hand them tasks and pick a process. CrewAI is the clearest version of this.
Conversational agents. Agents talk to each other in turns until a stopping condition fires, or they hand work off with a labeled transfer. This is the AutoGen lineage, now living in Microsoft Agent Framework, and it is also the primitive the OpenAI Agents SDK calls a handoff.
Graphs. You draw the flow up front. Nodes are steps, edges are transitions, and the framework walks the graph. LangGraph is the reference here, and Pydantic AI's graph API is the same idea with types bolted on.
Pick the model that matches how you already describe the problem out loud. If you say "it's a team," reach for crews. If you say "it's a pipeline with branches," reach for a graph.
Roles and crews: CrewAI
CrewAI is the framework non-ML engineers reach for first, and the reason is the abstraction. You do not write state machines. You describe who you would hire.
from crewai import Agent, Task, Crew, Process, LLM
llm = LLM(model="anthropic/claude-opus-4-8")
researcher = Agent(
role="Senior Research Analyst",
goal="Find 2026 trends in {topic}",
backstory="You work at a tech think tank.",
llm=llm,
allow_delegation=False,
)
writer = Agent(
role="Tech Content Writer",
goal="Draft a 500-word article",
backstory="You turn research into prose.",
llm=llm,
)
Two agents, two roles. Now give them work and a process to run it under.
research = Task(
description="Research 2026 trends in {topic}",
agent=researcher,
expected_output="Five sourced findings",
)
draft = Task(
description="Write a 500-word article",
agent=writer,
expected_output="Markdown draft",
context=[research],
)
crew = Crew(
agents=[researcher, writer],
tasks=[research, draft],
process=Process.sequential,
)
print(crew.kickoff(inputs={"topic": "agentic AI"}))
Process.sequential runs the tasks in order and pipes each output into the next task's context. It is deterministic and easy to debug. Process.hierarchical adds an ambient manager agent that decides which worker runs when, which is where the non-determinism gets worse, because now two layers of LLM make routing decisions instead of one. Start sequential. Promote only when the sequential version is visibly the wrong shape.
The cost of the role/backstory abstraction is the same as its benefit: a lot of prompting happens behind the scenes. When something goes wrong, you end up reading the CrewAI source to work out what was actually sent to the model.
Pick it when the product owner describes the system as a team and means it, and the work decomposes cleanly into specialists.
Conversational agents: AutoGen's successor
The AutoGen model was a group chat. Agents spoke in turn until a termination condition fired. That loop, GroupChat, is gone in Microsoft Agent Framework. The new Workflow API is graph-based, which tells you something: even the conversational lineage is drifting toward drawing the flow up front.
What survives is the handoff, a labeled transfer from one agent to a specialist. A router reads an incoming message, decides the lane, and passes the work along. The migration itself is the catch. AutoGen 0.2 to 0.4 to Agent Framework is three breaking APIs in eighteen months, and the code that used GroupChat does not port mechanically. You rewrite it.
Pick it when your infrastructure is Azure, you need .NET and Python parity in one codebase, or you want first-class OpenTelemetry spans you can hand to an auditor. For anyone outside that world, the migration tax is real and the wedge is narrow.
Graphs: LangGraph and Pydantic AI
Graphs ask for more up front and give you durability in return. LangGraph is where you go when a workflow has to crash at step seven and resume at step seven, not step one. It backs that with Postgres or SQLite checkpointers and human-in-the-loop interrupts.
from langchain_anthropic import ChatAnthropic
from langgraph.prebuilt import create_react_agent
def get_weather(city: str) -> str:
"""Return the weather for a city."""
return {"Lisbon": "18C clear"}[city]
model = ChatAnthropic(model="claude-opus-4-8")
agent = create_react_agent(model, tools=[get_weather])
result = agent.invoke(
{"messages": [("user", "weather in Lisbon?")]}
)
print(result["messages"][-1].content)
Pydantic AI reaches the same territory from a different angle: types as the contract. Every program is an Agent parameterized by its output type, and the model's response is validated against that type or retried.
from pydantic import BaseModel
from pydantic_ai import Agent
class Triage(BaseModel):
lane: str
reason: str
agent = Agent(
"anthropic:claude-opus-4-8",
output_type=Triage,
system_prompt="Classify email as 'refund' or 'bug'.",
)
result = agent.run_sync("Checkout charged me twice.")
print(result.output.lane)
output_type is the part that earns the install. The model returns a validated object or a clean exception, and your IDE flags a shape mismatch before you run anything. The trade-off is ecosystem size. Pydantic AI's graph API is younger than LangGraph's for checkpointing and interrupts, so if you need durable Postgres-backed state today, LangGraph is still the safer pick.
Pick a graph when the honest description of your system is a pipeline with branches and failure points you need to resume from.
The honest verdicts
| Model | Framework | Wedge | Weak spot |
|---|---|---|---|
| Roles | CrewAI | Fastest to a "team" mental model | Hidden prompting, high non-determinism |
| Conversations | MS Agent Framework | Azure and .NET parity, native OTel | Migration churn, Python and .NET only |
| Graphs | LangGraph | Durable state, human-in-the-loop | Steeper up-front modeling |
| Types | Pydantic AI | Validation at write-time | Smaller ecosystem |
One thing they all agree on now: MCP for tools and A2A for cross-framework handoffs. Build an agent in CrewAI, hand work to one in Pydantic AI over A2A, and neither framework needs to know about the other. The framework you pick matters less than it did a year ago, because it no longer locks you out of the ones you skipped.
When multi-agent is overkill
Here is the part the vendor decks skip. Most systems labeled "multi-agent" are one agent with role prompts, wearing a costume. Anthropic and Cognition have argued about this publicly since June 2025, and both sides are right. The decision is whether your problem decomposes into genuinely parallel specialists that cannot share a context window. For most production systems, the honest answer is no.
Ask three questions. Do your agents have different tools, or just different instructions? Do they run in parallel on separate context windows? Would one well-prompted agent with everyone's tools get the same answer? If the third answer is yes, you have one agent.
And one agent is often a bare provider SDK and a loop:
import anthropic
client = anthropic.Anthropic()
messages = [{"role": "user", "content": user_input}]
while True:
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=16000,
tools=tools,
messages=messages,
)
if resp.stop_reason != "tool_use":
break
messages.append(
{"role": "assistant", "content": resp.content}
)
results = run_tools(resp.content)
messages.append({"role": "user", "content": results})
That is enough for more production systems than the framework vendors would like you to believe. Reach for a framework only when you need durable state across restarts, you are building on an ecosystem the framework is already glued into, or your team cannot hold the loop in its head and needs shared vocabulary. If none of those are true, close the tab and write the loop. You will ship faster and debug cheaper.
The framework is not the decision. The shape of the work is.
Frameworks come and go, but the questions stay the same: which model fits the problem, and how do you know it is working once it ships. Agents in Production is the build-and-ship half of that answer, from tool design to handoffs to the trade-offs above. Observability for LLM Applications is the other half, on tracing, evals, and cost accounting so you can see whether the crew or the single loop is actually doing its job. Both books make up The AI Engineer's Library.
Top comments (0)