Agentic AI Frameworks: Patterns and Which Tool Fits

Agentic AI frameworks are code libraries for systems where a model chooses its next step, calls tools and repeats until a goal is met. The useful way to choose one is by pattern: a single agent with tools, handoffs, a graph, a role-based team, or an event-driven flow. As of 31 October 2026, active options include LangGraph, CrewAI, OpenAI Agents SDK, Microsoft Agent Framework and Google ADK.

Agentic, in plain words

"Agentic" describes software that works toward a goal in steps, deciding what to do as it goes. A normal program follows a fixed script. A chatbot answers once. An agentic system plans, acts, looks at the result and acts again. Our glossary entry on AI agents vs agentic AI draws the line more carefully.

A framework earns its place when that loop gets complicated. The model call is the easy part. The hard parts are what happens when a step fails, who approves a risky action, where the state lives and how you find out why the agent did what it did.

If you want the head-to-head table of libraries first, see AI agent frameworks. This page is organised by design pattern, because the pattern is what you are really choosing.

Five patterns

1. One agent with tools

The simplest pattern: one model, a list of tools, a loop. Most useful agents are this. The OpenAI Agents SDK, the Claude Agent SDK and Pydantic AI all start here. Pydantic AI's README describes "a typed, extensible agent loop with every model a string swap away". The Claude Agent SDK gives the loop Claude Code's own tools.

Use it when the task is one job in one domain: answering from a knowledge base, fixing a bug, drafting a reply. Do not leave this pattern before you have a reason.

2. Handoffs and routing

A front agent decides who should handle the request and passes it on. A support bot might route to billing, technical or sales agents, each with its own prompt and tools. The OpenAI Agents SDK lists handoffs among its core primitives. Microsoft Agent Framework names "handoff" among its graph patterns.

Use it when one prompt cannot hold all the rules. Each specialist is easier to test than one big agent.

3. Graphs and state machines

You draw the allowed paths. Nodes do work; edges decide what comes next, some of them chosen by the model. LangGraph is the clearest example, described as "a low-level orchestration framework for building, managing, and deploying long-running, stateful agents." Google ADK's README lists a graph-based runtime with "routing, fan-out/fan-in, loops, retry, state management" and human-in-the-loop. Microsoft Agent Framework also uses graph patterns.

Use it when order matters, when you need to pause for people, or when a run might last hours.

4. Role-based teams

You define agents as roles (researcher, writer, reviewer) and let them collaborate. CrewAI calls this a Crew, with "role-based AI agents" and "dynamic task delegation". The older AutoGen worked this way too, but it has been archived.

Use it when the work really does split into specialist views and the path is not known in advance. Beware the cost: every agent adds model calls.

5. Event-driven flows

Something happens (a message, a webhook, a file) and a workflow reacts. CrewAI Flows are "event-driven" with state, branching and loops. Workflow tools such as n8n do the same thing visually; see AI agent platforms.

Use it when the agent is one step in a business process with triggers and handoffs to existing systems.

Pattern to framework

Most frameworks can fake most patterns, so treat this as a statement of where each is strongest, not a limit.

What to look for beyond the pattern

Durability

Can a run survive a crash and resume? LangGraph lists "durable execution" first. Microsoft Agent Framework says it cares about "durability, restartability, observability, governance, or human-in-the-loop control". If your agent runs for minutes and a restart would cost money, this is a must.

Human approval

For anything that sends email, spends money or changes data, a person should confirm. Check that the framework lets you pause and resume cleanly. A bolted-on input() call is not that.

Observability

You will debug by reading traces. LangSmith, Logfire and CrewAI's control plane exist for this; the OpenAI SDK bundles tracing. Without a trace you are guessing.

Model freedom

Vendor SDKs favour their own models. Google ADK is "optimized for Gemini" but model-agnostic by its README. LangGraph, CrewAI and Pydantic AI are vendor neutral. Decide how much a model switch matters to you.

Language

Python dominates. TypeScript has Mastra and the OpenAI and Claude SDKs. .NET has Microsoft Agent Framework.

Upkeep

AutoGen's archive shows the risk. Check release dates and the maintainer.

Protocols: the part that outlasts a framework

Frameworks come and go. Protocols are what let you move. MCP gives an agent a standard way to use tools and data; see what are MCP servers and the MCP server list. A2A gives agents a standard way to talk to each other; see A2A protocol and MCP vs A2A.

Skills and subagents are the same idea at the coding-agent level: reusable instructions and delegated workers. See agent skills and subagents.

One task, five patterns

To see how the patterns differ, take a single task: handle an incoming refund request for an online shop. This is an illustration of design choices, not a product test.

Pattern one, one agent. A single agent gets the customer message and four tools: look up the order, check the refund policy, issue a refund, send a reply. It decides the order of calls. This works well until the policy grows to forty rules and the prompt becomes unreadable.

Pattern two, handoffs. A front agent reads the message and routes it: simple refund, damaged goods, fraud suspicion. Each specialist has a short prompt and fewer tools. The fraud agent cannot issue refunds at all, which is a safety gain, not only a tidiness gain.

Pattern three, a graph. The path is drawn: classify, look up order, check policy, then a branch. Under a set amount, refund automatically. Over it, pause and wait for a person to approve. After approval, issue the refund and send the reply. The pause can last overnight, and durable state means the run picks up in the morning. This is the shape that LangGraph, Google ADK and Microsoft Agent Framework are built for.

Pattern four, a role team. A policy analyst agent, a customer-tone agent and a reviewer agent work on the case together. It is more thorough and slower, and it costs several times the tokens. For a refund it is probably overkill, but for a complex dispute it might help.

Pattern five, an event flow. The refund request arrives as a webhook from the shop. A flow starts, calls the graph or the single agent for the hard part, writes to the accounting system and posts to Slack. Most real deployments end up here, because the agent is one step among ordinary software.

The usual outcome is a mix: an event flow at the edge, a graph in the middle for the approval, and a single agent with narrow tools at the core. That is also why frameworks that can combine patterns, such as CrewAI with Flows and Crews, get chosen for production.

Pick by team and project

Security for agentic systems

An agent that can act is also an agent that can be tricked into acting. Three risks come up in every framework.

• Prompt injection through tools. A tool that reads email, web pages or documents returns text that may contain instructions. The model may follow them. Mitigate by limiting what the agent can do after reading untrusted content, and by requiring approval for sensitive actions.
• Excess permissions. If the agent has a database credential, assume it can be made to misuse it. Use read-only credentials where you can, and per-agent scopes.
• Runaway cost. A loop with no cap can burn a budget overnight. Set a maximum number of steps and a spending alert.

Frameworks help with guardrails, approvals and tracing, but none of them makes an unsafe design safe. For company rules see AI agent governance and enterprise AI agents.

Mistakes teams make

1. Starting with a team of agents. Begin with one. Split only when a prompt becomes unmanageable.
2. No step limit. Loops can run away. Cap steps and cost.
3. Trusting tool output. A web page or email can contain instructions that hijack the agent. Treat tool results as untrusted data.
4. Broad permissions. Give each agent the narrowest tool set it needs.
5. No tests. Keep a fixed set of tasks and re-run them after every change.
6. Ignoring cost. Track tokens per run from the first day.
7. Choosing on stars. Check the last release and the maintainer.

A selection checklist by pattern

If the docs cannot answer these in a few minutes, treat that as a finding. A framework you cannot reason about is hard to run in production.

Our take

This is an editorial reading of project READMEs and docs, not a hands-on test.

The pattern view saves time because it separates the decision from the brand. Most real systems are pattern one with a bit of pattern two. A framework earns its place only when you add durability, approvals or many steps, at which point the graph pattern is the safe default. Role-based teams are good for demos and some real research and content jobs, but they are the pattern most likely to be overused.

If you are unsure, build the single-agent version with a vendor SDK, add tracing, and run it on thirty real inputs. What breaks will tell you which pattern to move to. Keep prompts and tools in your own files, so the move is cheap.

For coding work you do not need to build any of this; a ready tool like Claude Code or OpenCode already contains the loop. See AI coding agents.

Checklist

• Name the pattern you need before naming a framework
• Try the one-agent version first
• Decide on durability and human approval needs
• Pick for language, model freedom and maintainer
• Set step and cost limits
• Trace every run
• Keep a fixed test set