It is mid-2026, and do you even need a framework to build agents? Yes and no. It depends on what you want to build.
If your application only needs simple generative responses and short tool calls, you can work directly with the Claude API or OpenAI API. You do not have to install a large framework.
If you want to automate personal workflows, such as Gmail triage, Jira ticket resolution, or pull request reviews, a harness can be a better fit. You can connect MCP servers like Composio and command-line tools to Claude Code, Codex, or a Hermes-like harness. The harness gives the agent an environment where it can inspect information, use tools, and complete tasks.
However, you may be building an AI application that requires custom workflows, persistent state, memory, retries, approvals, evaluation, or several agents working together. In this case, an agent framework can save a large amount of engineering work.
A framework gives your application a reusable structure. It gives you maximum control over how the agent makes decisions, calls tools, stores context, handles failures, and reports what it did.
But the difficult part is choosing the right one. Agent frameworks often use similar terms, but they make different choices about control, flexibility, deployment, and developer experience.
This guide explains what AI agent frameworks are, when you need one, how they differ from agent harnesses, and how to choose between options such as Mastra, Claude Agent SDK, Vercel AI SDK, LangGraph, OpenAI Agents SDK, and Google ADK.
What Are AI Agent Frameworks?
An AI agent can use a model, make decisions, call tools, and complete a task. A simple agent can answer a question or call one API. A more advanced agent can plan work, use several tools, check results, and try again after an error.
As the agent becomes more capable, its software also becomes more complex. You must manage prompts, tools, memory, errors, and task state. You must also understand what the agent does during each run.
An AI agent framework helps you manage this work.
A framework is a set of software components for developing AI agents. It gives you common building blocks and a clear structure. You can use these parts to connect a model to tools, data, memory, and other agents.
Most agent frameworks include support for:
Model calls
Tool definitions
Workflow steps
Memory and task state
Error handling
Human approval
Logs and traces
Multiple agents
The exact features depend on the framework. Some frameworks focus on simple tool use. Others support long workflows, persistent state, or teams of agents.
Why and When Do You Need a Framework?
You do not always need a framework.
A direct model API can be sufficient for a small application. For example, your application can send a prompt, receive an answer, and show it to the user. This design is easy to build and understand.
A framework becomes useful when your agent has more responsibilities.
The agent uses several tools
An agent can search a database, call an API, read a file, or send a message. A framework can define these tools consistently. It can also validate the input and output of each tool.
The task has several steps
Some tasks need a fixed sequence. Other tasks change according to earlier results.
For example, a customer support agent can:
Read a customer request.
Find the customer account.
Check recent orders.
Select a suitable action.
Ask for approval.
Update the order.
Send a reply.
A framework can control this sequence. It can also support branches, loops, and retries.
The agent must remember its progress
Long tasks can continue for several minutes or hours. The agent must know which steps are complete. It must also save important results.
A framework can store this state. Some frameworks can restart a task from the last successful step after an interruption.
You need human approval
An agent can perform actions that have cost or risk. It can send an email, change an account, place an order, or delete data.
A framework can pause the workflow before these actions. A person can review the plan and approve or reject it.
You need to understand failures
Agent failures can be difficult to investigate. The model can select an incorrect tool. A tool can return invalid data. A workflow can enter a repeated loop.
A framework can record model calls, tool calls, decisions, errors, and execution time. These records help you find the cause of a problem.
You have several agents
Some applications use agents with different roles. One agent can collect information. Another agent can review it. A third agent can prepare the final result.
A framework can pass work between these agents and track their shared state.
Multiple agents add cost and complexity. Use them when separate roles give a clear benefit.
How to Pick an AI Agent Framework
There is no single best framework for every agent. The right choice depends on your task, team, and production needs.
Start with the work that the agent must complete.
1. Describe the real workflow
Write down the main steps of the task.
Include:
The required inputs
The expected result
The tools and data sources
The decisions that the agent must make
The actions that need human approval
The possible errors
The expected task duration
This description helps you find the features that you need.
2. Start with the simplest design
A small amount of code and a direct model API can support many use cases. Add a framework when the workflow needs more structure.
Each new component adds maintenance work. A simple design is easier to test, operate, and change.
3. Check tool support
Confirm that the framework can connect to your required tools and services.
Look at:
Tool input validation
Tool output validation
Authentication support
Timeouts
Retries
Error messages
Support for asynchronous operations
A long list of integrations can be useful. Clear and reliable tool behavior is more important.
4. Check state and recovery
Find out how the framework stores task progress.
Ask these questions:
Can it save the state after each step?
Can it restart an interrupted task?
Can it prevent duplicate actions?
Can it support tasks that run for a long time?
Can developers inspect and change saved state?
These features become important when the agent performs real actions.
5. Check observability
You must be able to understand each agent run.
The framework should show:
Model requests and responses
Tool calls and results
Workflow steps
Errors and retries
Token use
Cost
Execution time
Good traces reduce the time that you need to find and correct a problem.
6. Check safety controls
Review how the framework handles permissions and approvals.
Check for:
Limited tool access
Credential protection
Approval steps
Input and output validation
Execution limits
Protection against repeated loops
Audit records
The required controls depend on the actions that the agent can perform.
7. Check model flexibility
Your model requirements can change. You can need a faster model, a lower-cost model, or a model from another provider.
Check whether the framework makes model changes easy. Also check whether its main features work with all supported models.
8. Test failure cases
A successful demo gives limited information. Test situations in which a part of the system fails.
For example:
A tool takes too long.
An API returns invalid data.
The model selects an unsuitable tool.
A person rejects an approval request.
The task stops before completion.
The same action starts twice.
The agent repeats a step many times.
Observe how the framework reports and handles each problem.
9. Review developer experience
Your team must use and maintain the framework.
Review:
Documentation
API design
Type support
Testing tools
Debugging tools
Release frequency
Upgrade process
Community support
A framework with many features can still slow your team if its behavior is difficult to understand.
10. Measure cost and performance
Run a realistic test and measure:
Task completion rate
Response time
Model and tool cost
Number of model calls
Number of failed runs
Time required to investigate a failure
These results give you better evidence than a feature list.
A Practical Rule
Select the simplest framework that can complete your most difficult realistic workflow.
Test it with real tools, real errors, and real approval steps. Confirm that your team can understand each run and recover from failures.
The framework helps you build the agent’s work process. The harness gives the agent a controlled place to work. Together, they help you move from a useful demonstration to a reliable agent system.
Best AI agent frameworks to try in 2026
1. Mastra
Mastra is a TypeScript framework for building AI agents and workflows. It includes tools for memory, evaluations, observability, and deployment. 1
Best suited for
Mastra is a good fit for applications that combine AI decisions with controlled business logic. You can use agents for open tasks and workflows for processes that have known steps.
Common use cases include:
Customer support
Document review
Research pipelines
Content production
Business automation
Multi-agent applications
Workflow and tool support
Mastra workflows use steps with defined input and output schemas. A step can run application code or call an agent, tool, or external API.
This short example shows the structure:
import { createStep, createWorkflow } from "@mastra/core/workflows";
import { z } from "zod";
const reviewOrder = createStep({
id: "review-order",
inputSchema: z.object({
orderId: z.string(),
}),
outputSchema: z.object({
approved: z.boolean(),
}),
execute: async ({ inputData }) => {
const approved = await checkOrder(inputData.orderId);
return { approved };
},
});
export const orderWorkflow = createWorkflow({
id: "order-workflow",
inputSchema: z.object({
orderId: z.string(),
}),
outputSchema: z.object({
approved: z.boolean(),
}),
})
.then(reviewOrder)
.commit();The code makes the workflow and its data types clear. This improves control and makes each step easier to test. The trade-off is that developers must define the steps and schemas before the workflow runs. 2
Mastra also supports parallel paths, branches, loops, suspension, and resumption. It can use custom tools and MCP servers. 3
Reliability and recovery
Mastra can save workflow state and resume a workflow from the step where it paused. Typed schemas can find invalid data before it moves to another step.
This structure works well for long processes and tasks that need approval at a defined point. It can feel heavy for a short task with only one model call. 4
Memory and state
Mastra can store message history and information from earlier conversations. It can also use semantic search to find relevant information.
Memory processors can filter, trim, or prioritise content when the context becomes large. These options provide flexibility, but they also require storage and memory configuration. 5
Observability
Mastra can trace agent runs, workflow steps, model calls, and tool calls. Traces can include inputs, outputs, token use, cost, and execution time.
It can also connect logs, metrics, and human feedback to the same trace. This gives teams a broad view of production activity. It also adds more services and configuration to the application. 6
Safety and human approval
A Mastra workflow can pause before a sensitive action. It can explain why human input is required and continue after approval.
This works well when approval is a known part of the process. Developers must define where the workflow pauses and how it handles the response. 4
Model support
Mastra supports models from several providers. Its model router uses a simple provider/model format.
This gives teams more choice when they select models for cost, speed, or quality. A team must still test how each model behaves inside the same workflow. 1
Testing and evaluation
Mastra provides scorers for areas such as response quality, classification, and prompt evaluation.
Scorers can run during development, in a CI pipeline, or during live operation. This reduces the need to build an evaluation system from the beginning. The additional scoring calls can increase cost and processing time. 7
Deployment
Mastra applications can run as Node.js services. Teams can deploy them in their own infrastructure or on a supported cloud platform.
This gives teams several deployment choices. Teams with a Python-based system may need to operate Mastra as a separate service. 8
Main strengths
Structured workflows
Support for several model providers
Persistent memory
Built-in traces and metrics
Built-in evaluation scorers
Human approval steps
Multi-agent support
Main trade-offs
Mastra is mainly for JavaScript and TypeScript teams.
Structured workflows require design work at the start.
Teams must configure schemas, storage, and tool controls.
Some features require additional packages.
When to choose Mastra
Choose Mastra when you need a complete TypeScript framework for an agent application. It is useful when your application needs structured workflows, model choice, memory, evaluations, and planned approval steps.
A Mastra agent with Composio
Composio can give a Mastra agent access to services such as Gmail, GitHub, Slack, and Notion. Each session connects the tools to one application user.
import { Composio } from "@composio/core";
import { MastraProvider } from "@composio/mastra";
import { Agent } from "@mastra/core/agent";
import { openai } from "@ai-sdk/openai";
const composio = new Composio({
provider: new MastraProvider(),
});
const session = await composio.create("user_123");
const tools = await session.tools();
const agent = new Agent({
id: "email-agent",
name: "Email Agent",
instructions: "Use the available tools to help the user.",
model: openai("gpt-5.6-sol"),
tools,
});
const result = await agent.generate([
{
role: "user",
content: "Summarize my emails from today.",
},
]);
console.log(result.text);The Composio provider converts its tools into Mastra’s tool format. Mastra can then validate tool input and output through schemas. 15
The main advantage is simple integration with Mastra agents and workflows. The same tools can become part of a larger controlled process.
The trade-off is added setup. The application must manage Composio sessions, user connections, and the Mastra runtime.
2. Claude Agent SDK
The Claude Agent SDK is a Python and TypeScript library from Anthropic. It gives applications access to the agent loop, tools, and context management that power Claude Code. 9
Best suited for
The Claude Agent SDK is a good fit for open tasks where Claude must decide which actions to take.
Common use cases include:
Coding agents
Code review
Repository maintenance
File analysis
Technical research
Development automation
Workflow and tool support
Claude reviews the task, selects a tool, checks the result, and decides what to do next.
The following example gives Claude a goal and a limited set of approved tools:
import { query } from "@anthropic-ai/claude-agent-sdk";
for await (const message of query({
prompt: "Review utils.py, find bugs, and fix them.",
options: {
allowedTools: ["Read", "Edit", "Glob"],
permissionMode: "acceptEdits",
},
})) {
if (message.type === "result") {
console.log(message.result);
}
}The developer defines the goal and permissions. Claude decides which files to inspect and which steps to take. This keeps the application code small and gives the agent room to adapt.
The trade-off is lower control over the exact path. Two runs can use different steps or tools. Strong tests and permission rules become important. 9
The SDK also supports custom tools, MCP servers, and specialist subagents.
Reliability and recovery
A session stores prompts, responses, tool calls, and tool results. The application can continue the latest session or resume an earlier session.
It can also fork a session to test another approach. This is useful for long and exploratory tasks. The application must manage session storage when it runs across several machines. 10
File checkpointing can track file changes and restore files to an earlier state. Session history and file state remain separate. 11
Memory and state
The main form of state is the session. A resumed session includes the context from the agent’s earlier work.
The SDK can also load project instructions, skills, commands, plugins, and memory files. This works well for project-based agents. Applications that need customer memory across several products may need a separate memory system. 9
Observability
The SDK can expose messages, tool activity, session events, token use, and cost data. It also supports OpenTelemetry.
Hooks can record tool calls, audit agent activity, track subagents, and respond to session events. This works well for teams that already have a monitoring platform. Teams without one must add and configure it. 12
Safety and human approval
Developers can allow or deny tools, restrict commands, limit file access, and request approval during a run.
The permission settings in the earlier example automatically approve file edits:
options: {
allowedTools: ["Read", "Edit", "Glob"],
permissionMode: "acceptEdits",
}This is useful in a trusted development environment. A production agent may need a stricter mode, scoped rules, or a user approval callback.
Permission controls are detailed and flexible. They also need careful design because a broad rule can give the agent more access than the task requires. 13
Model support
The Claude Agent SDK uses Claude models. This gives it close access to Claude-specific agent features.
The close integration can reduce setup work for teams that already use Claude. Teams that need several model providers may need another model layer or a broader framework. 9
Testing and evaluation
Applications can inspect structured output, tool calls, permission decisions, and session events. Hooks can add fixed checks at important points in the agent lifecycle.
This gives teams control over their tests. A separate evaluation platform can be useful when the application needs large test sets, scoring dashboards, or live quality monitoring.
Deployment
The Claude Agent SDK runs in infrastructure that your team manages. Your team controls hosting, scaling, isolation, credentials, storage, and network access.
This provides strong control over the environment. It also gives the team more operational work. Anthropic offers Managed Agents as a separate hosted service. 14
Main strengths
A flexible agent loop
Built-in file, command, and web tools
Detailed permission controls
Lifecycle hooks
Session resume and fork
File checkpointing
Python and TypeScript support
Custom tools, MCP, and subagents
Main trade-offs
The SDK uses Claude models.
Your team manages the runtime.
Agent runs can follow different paths.
Fixed business workflows require additional application logic.
A separate evaluation system can be useful.
File and command access requires careful permission design.
When to choose the Claude Agent SDK
Choose the Claude Agent SDK when Claude must decide how to complete an open task. It is useful for work that involves code, files, commands, web search, and subagents.
It is also a strong option when you need detailed permission controls and want to run the Claude agent loop inside a Python or TypeScript application.
A Claude Agent SDK agent with Composio
Composio can expose its tools to the Claude Agent SDK through an in-process MCP server. The Claude Agent SDK then manages the agent loop.
import { Composio } from "@composio/core";
import { ClaudeAgentSDKProvider } from "@composio/claude-agent-sdk";
import {
createSdkMcpServer,
query,
} from "@anthropic-ai/claude-agent-sdk";
const composio = new Composio({
provider: new ClaudeAgentSDKProvider(),
});
const session = await composio.create("user_123");
const tools = await session.tools();
const composioServer = createSdkMcpServer({
name: "composio",
version: "1.0.0",
tools,
});
for await (const message of query({
prompt: "Summarize my emails from today.",
options: {
mcpServers: {
composio: composioServer,
},
permissionMode: "bypassPermissions",
},
})) {
if (message.type === "result") {
console.log(message.result);
}
}The provider converts Composio tools into MCP tools. They run in the same process, so the application does not need to operate a separate MCP server. 16
The main advantage is that Claude can select and use Composio tools inside its existing agent loop. This works well for open tasks that can involve several applications.
The trade-off is permission risk. The example uses bypassPermissions to keep the setup short. Use narrower permission rules or approval controls in a production application.
3. Vercel AI SDK
The Vercel AI SDK is a TypeScript toolkit for building AI applications and agents. It provides a common interface for models, tools, structured output, streaming, and chat interfaces.
Its ToolLoopAgent class lets a model call tools over several steps. The SDK manages the loop until the model completes the task or reaches a stopping condition. 16
Best suited for
The Vercel AI SDK is a good fit for TypeScript applications that need AI features in a web interface.
Common use cases include:
AI chat applications
Customer-facing assistants
Tool-using agents
Generative user interfaces
Structured data generation
Streaming AI applications
Agents inside Next.js applications
Workflow and tool support
The SDK provides generateText, streamText, and ToolLoopAgent. These APIs can call tools and return their results to the model.
A tool contains:
A description
An input schema
An optional execution function
An optional approval rule
The input schema validates the arguments produced by the model. The execution function performs the action. 17
ToolLoopAgent is useful for open tasks where the model selects the next action. Standard TypeScript functions and conditions can control processes that need fixed steps.
This gives developers a flexible middle ground between a direct model call and a larger workflow framework. The application team must build advanced workflow state, recovery, and orchestration.
Reliability and recovery
Developers can limit an agent with stopping conditions such as stepCountIs. They can also set timeouts and cancel a run with an abort signal. 16
These controls help prevent long or repeated agent loops. The SDK does not provide the same durable workflow engine as Mastra. Long tasks can require a database, queue, or external workflow service.
Memory and state
The AI SDK can work with message history, but the application is responsible for persistent memory.
For a chat application, developers usually store messages in a database and load them when the user returns. The SDK provides message types and helpers for this process. 18
This gives teams control over their data model. It also means that memory, user profiles, and long-term recall require additional application code.
Observability
The AI SDK supports OpenTelemetry for model calls and tool activity. Developers can attach metadata and connect traces to an observability platform.
Telemetry support is currently marked as experimental, so its API can change. 19
Safety and human approval
A tool can use needsApproval: true when a person must approve the action before execution.
Approval can also depend on the tool input. For example, an application can request approval only when a payment exceeds a set amount. 17
This makes approval easy to add to chat interfaces. The application must still define the approval rules and store the user’s response.
Model support
The Vercel AI SDK uses a standard model interface across providers. Teams can connect models from providers such as Anthropic, OpenAI, Google, and others.
This reduces the code changes required when a team tests or replaces a model. Provider-specific features can still behave differently. 20
Testing and evaluation
The SDK includes mock models and test helpers. These tools let developers test model responses and streams without making a live model call. 21
This is useful for unit tests and interface tests. Teams that need quality scoring, large evaluation sets, or production evaluation dashboards may need a separate evaluation system.
Deployment
The Vercel AI SDK works well with Next.js and Vercel. AI SDK Core can also run in other TypeScript server environments.
Its streaming and UI packages make it especially useful for applications that send live model and tool updates to a browser.
Main strengths
Simple TypeScript APIs
Vercel ecosystem and deployment support
Support for several model providers
Strong streaming support
React and other UI integrations
Main trade-offs
Persistent memory requires application storage.
Durable workflows require additional infrastructure.
Broad evaluation systems require other tools.
Some observability features are experimental.
Provider features can behave differently.
It is mainly designed for JavaScript and TypeScript applications.
When to choose the Vercel AI SDK
Choose the Vercel AI SDK when you need to add AI agents to a TypeScript web application.
It is a strong choice when streaming, user interfaces, model flexibility, and simple tool calling are more important than durable workflow orchestration.
A simple Vercel AI SDK agent with Composio
Composio can convert its tools into the Vercel AI SDK tool format. Each tool includes an execution function, so the SDK can call it without a manual tool loop.
import { anthropic } from "@ai-sdk/anthropic";
import { Composio } from "@composio/core";
import { VercelProvider } from "@composio/vercel";
import { generateText, stepCountIs } from "ai";
const composio = new Composio({
provider: new VercelProvider(),
});
const session = await composio.create("user_123");
const tools = await session.tools();
const result = await generateText({
model: anthropic("claude-opus-4-6"),
tools,
prompt: "Summarize my emails from today.",
stopWhen: stepCountIs(10),
});
console.log(result.text);The Composio session connects the tools to one application user. The Vercel provider converts the tool schemas and handles their execution. 22
The main advantage is the small amount of integration code. The agent can use Composio tools through the same AI SDK interface as local tools.
The trade-off is that the agent can call several external services. The application should restrict the available Composio toolkits and require approval for sensitive actions.
4. LangGraph
LangGraph is a low-level framework and runtime for building long-running, stateful agents. It focuses on orchestration, durable execution, persistence, streaming, and human oversight. 23
LangGraph is available for Python and TypeScript. You can use it with LangChain components or connect your own models and tools.
Best suited for
LangGraph is a good fit when an agent needs a custom workflow and must keep state across several steps.
Common use cases include:
Long-running agents
Research workflows
Customer support processes
Multi-agent systems
Human approval flows
Agents with complex branching
Workflows that must recover from failures
Workflow and tool support
A LangGraph application has three main parts:
State: The information shared across the workflow
Nodes: Functions that perform work
Edges: Rules that select the next node
Nodes can call models, tools, APIs, databases, or standard application code. Edges can create fixed routes, branches, loops, and parallel paths. 24
This structure gives developers detailed control over agent behavior. The trade-off is more setup code. Teams must design the graph, state, nodes, and routing rules.
Teams that need a standard tool-calling agent can start with LangChain’s higher-level agent APIs. LangGraph is more useful when the standard agent loop does not provide enough control. 23
Reliability and recovery
LangGraph can save graph state as checkpoints. If execution stops, the graph can continue from a saved step.
Checkpointing supports:
Failure recovery
Workflow resumption
Human approval
Conversation memory
Time-travel debugging
Alternative branches from an earlier state
A production application needs a persistent checkpointer, such as a database-backed implementation. 25
Durable execution is one of LangGraph’s main strengths. It also requires developers to understand which work can safely run again after a failure.
Memory and state
LangGraph supports short-term and long-term memory.
Short-term memory belongs to a thread. It can store messages and other state for one conversation.
Long-term memory can store user or application information across several threads. Applications can organize this information with custom namespaces. 26
This gives teams control over memory design. Teams must still decide what to store, when to update it, and how to keep the model context within a useful size.
Observability
LangGraph can integrate with LangSmith for traces, state transitions, tool calls, errors, and runtime metrics.
This is useful when a graph has several branches or repeated loops. Developers can inspect the path that the agent followed and the state available at each step. 23
LangSmith is a separate platform. Teams can also connect other monitoring tools through their application code.
Safety and human approval
LangGraph can interrupt execution before a sensitive action. The graph saves its state while it waits for a human decision.
A reviewer can:
Approve the action
Change the proposed action
Reject the action
Add feedback
The graph can then continue from the saved point. A persistent checkpointer is required for production approval flows. 27
This provides strong control for sensitive workflows. Developers must define which nodes or tools require review.
Model support
LangGraph does not require one model provider. Nodes can use LangChain model integrations or other model clients.
This gives teams flexibility to use different models in different parts of the graph. It also means that teams must handle differences in model features, tool calling, and response formats.
Testing and evaluation
Developers can test a complete graph, an individual node, or part of an execution path.
LangGraph’s checkpoint system can create a test state and run only selected parts of the graph. 28
LangSmith can evaluate final responses, individual steps, and complete agent paths. It supports offline tests and live production evaluations. 29
LangGraph gives teams detailed test access. A full evaluation setup can require LangSmith or another evaluation platform.
Deployment
LangGraph applications can run inside an existing Python or TypeScript service.
LangSmith Deployment provides managed infrastructure for stateful and long-running graphs. The LangGraph server also provides APIs for runs, threads, assistants, and stored state. 30
Self-hosting gives teams more infrastructure control. Managed deployment reduces operational work but adds a platform dependency.
Main strengths
Detailed workflow control
Durable execution
Persistent graph state
Failure recovery
Human approval
Short-term and long-term memory
Streaming
Python and TypeScript support
Strong support for complex and multi-agent systems
Main trade-offs
Graph design requires more code.
The framework has a steeper learning curve.
Teams must define state and routing rules.
Production persistence requires a database.
LangSmith features use a separate platform.
Simple agents may need less infrastructure.
When to choose LangGraph
Choose LangGraph when you need detailed control over a long-running or stateful agent.
It is a strong choice when the workflow has branches, loops, approval steps, persistent memory, or strict recovery requirements.
A simple LangGraph agent with Composio
Composio can convert its tools into the LangChain tool format used by LangGraph. A ToolNode executes the selected tool, while the graph controls the loop between the model and the tools.
import { Composio } from "@composio/core";
import { LangchainProvider } from "@composio/langchain";
import { ChatOpenAI } from "@langchain/openai";
import { HumanMessage, AIMessage } from "@langchain/core/messages";
import { StateGraph, MessagesAnnotation } from "@langchain/langgraph";
import { ToolNode } from "@langchain/langgraph/prebuilt";
const composio = new Composio({
provider: new LangchainProvider(),
});
const session = await composio.create("user_123");
const tools = await session.tools();
const model = new ChatOpenAI({
model: "gpt-5.2",
}).bindTools(tools);
async function callModel(
state: typeof MessagesAnnotation.State,
) {
const response = await model.invoke(state.messages);
return { messages: [response] };
}
function chooseNext(
state: typeof MessagesAnnotation.State,
) {
const lastMessage = state.messages.at(-1) as AIMessage;
return lastMessage.tool_calls?.length
? "tools"
: "__end__";
}
const agent = new StateGraph(MessagesAnnotation)
.addNode("model", callModel)
.addNode("tools", new ToolNode(tools))
.addEdge("__start__", "model")
.addConditionalEdges("model", chooseNext)
.addEdge("tools", "model")
.compile();
const result = await agent.invoke({
messages: [
new HumanMessage("Summarize my emails from today."),
],
});
console.log(result.messages.at(-1)?.content);The Composio session connects tools to one application user. Its LangChain provider converts the tools into objects that LangGraph’s ToolNode can execute. 31
The main advantage is control. You can add approval nodes, retry paths, memory, and other business steps around the Composio tools.
The trade-off is the amount of code. A basic tool loop needs explicit model, tool, and routing nodes. This added structure becomes more valuable as the workflow grows.
6. Google ADK
Google Agent Development Kit, or Google ADK, is an open-source framework for building, testing, and deploying AI agents. It supports Python, TypeScript, Go, Java, and Kotlin.41
ADK works well for agents that use tools, manage long conversations, or divide work between multiple specialized agents.
Best suited for
Google ADK is a good choice for:
Agents that use Gemini or Google Cloud
Multi-agent systems
Structured business workflows
Long-running and stateful tasks
Voice, video, and real-time agents
Teams that need deployment and evaluation tools
Agents and workflows
A basic ADK agent has a model, instructions, and optional tools. You can later divide a large agent into smaller agents that work together.42
ADK supports several workflow styles:
Sequential workflows for ordered steps
Parallel workflows for tasks that can run together
Loop workflows for repeated work
Graph workflows for complex routes and conditions
Multi-agent workflows for specialist agents
Graph workflows let you combine model decisions with fixed program logic. This gives you more control over important processes.
Tool support
ADK agents can use:
Python or TypeScript functions
Built-in Google tools
OpenAPI tools
MCP servers
Other agents
External services through integrations such as Composio
ADK manages the tool-calling loop. The runner sends tool results back to the model and continues until the agent produces a final response.
Reliability and recovery
ADK provides sessions, events, and managed run controls. It also supports operations such as cancelling and resuming agent runs.
For workflows that need predictable behavior, you can keep important steps in code or graph routes. You can then use the model only for tasks that need judgment.
This is useful for payment flows, support processes, approvals, and other tasks where the order of operations matters.
Memory and state
ADK separates conversational data into three parts:
A session holds one conversation
State holds temporary data for that session
Memory stores searchable information across sessions
ADK provides services for managing both sessions and long-term memory. Its in-memory services are useful during development, but their data disappears when the application restarts. Production applications need a persistent storage service.43
Observability
ADK includes support for logs, metrics, traces, and execution events. Its development interface also helps you inspect messages, tool calls, and agent activity.
Callbacks let you add custom logging or monitoring at different points in an agent run.
Google Cloud deployments can use services such as Cloud Trace for production monitoring.
Safety and approval
ADK supports action confirmation for sensitive tool calls. You can pause an action and ask the user to approve it before the tool continues.
Callbacks also let you check model requests, tool arguments, and tool results. This helps you apply application rules around the agent.
You still need to define permissions carefully. A tool that can send an email, delete a file, or update a record must receive only the access it needs.
Model support
ADK has strong support for Gemini, but it is not limited to Google models. Its documentation includes adapters for Claude, OpenAI models, Ollama, vLLM, and LiteLLM.41
Some features can depend on the selected model. For example, tool calling, structured output, and streaming support can differ between providers.
Testing and evaluation
ADK can evaluate both the final answer and the path that the agent followed. This includes the tools it selected and the order in which it used them.
You can run evaluations through code, the command line, or the development interface. ADK also supports evaluation sets and custom criteria.44
The main evaluation system currently has stronger support in Python. Teams using another ADK language should check feature support before they make a decision.
Deployment
You can deploy an ADK agent to:
Google Cloud Agent Runtime
Cloud Run
Google Kubernetes Engine
Your own container platform
Local or disconnected infrastructure
Google Cloud gives ADK its most complete managed deployment path. However, ADK agents do not have to run on Google Cloud.45
Strengths
Strong support for multi-agent systems
Fixed and model-driven workflows
Built-in sessions, state, and memory
Support for several programming languages
Good integration with Gemini and Google Cloud
Built-in development and evaluation tools
Support for streaming and multimodal agents
Model and deployment flexibility
Trade-offs
ADK has many concepts, so the learning curve can be larger than with a small SDK.
Feature support can differ between programming languages.
Some of its best managed features are tied to Google Cloud.
Production memory and sessions need a persistent storage service.
Complex multi-agent systems can become difficult to debug.
The current Composio integration for ADK is Python-only.
When to choose Google ADK
Choose Google ADK when your agent needs structured workflows, several specialist agents, or close integration with Gemini and Google Cloud.
It is also a strong option when you need one framework for local development, evaluation, monitoring, and production deployment.
A smaller SDK may be easier when you only need a short tool-calling loop or a simple chat interface.
Simple Google ADK agent with Composio
Composio converts its tools into ADK FunctionTool objects. ADK’s runner then manages the tool calls and continues the agent loop.46
Install the required packages:
pip install composio composio-google-adk google-adkCreate an agent that can work with connected applications:
from composio import Composio
from composio_google_adk import GoogleAdkProvider
from google.adk.agents import Agent
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from google.genai import types
composio = Composio(provider=GoogleAdkProvider())
# Use a separate Composio session for each application user.
composio_session = composio.create(user_id="user_123")
tools = composio_session.tools()
agent = Agent(
name="work_assistant",
model="gemini-flash-latest",
instruction=(
"Help the user complete tasks in connected applications. "
"Ask for confirmation before sensitive actions."
),
tools=tools,
)
session_service = InMemorySessionService()
session_service.create_session_sync(
app_name="work_assistant",
user_id="user_123",
session_id="session_1",
)
runner = Runner(
agent=agent,
app_name="work_assistant",
session_service=session_service,
)
message = types.Content(
role="user",
parts=[
types.Part(
text="Find my unread Gmail messages and summarize them."
)
],
)
events = runner.run(
user_id="user_123",
session_id="session_1",
new_message=message,
)
for event in events:
if event.is_final_response() and event.content:
print(event.content.parts[0].text)Before this example can access Gmail, the user must connect their Gmail account through Composio.
The example uses in-memory session storage to keep the setup short. Use persistent session storage in a production application. Reuse the Composio session ID for later requests from the same user.
Other Frameworks
The frameworks above cover many common agent projects. However, several other frameworks can be a better fit for specific teams and use cases.
CrewAI
CrewAI is a Python framework for building teams of agents with different roles, goals, and tools.
It provides two main concepts:
Crews for collaborative agent teams
Flows for structured and event-driven workflows
Choose CrewAI when you want to model a process as a team of specialists, such as a researcher, analyst, and writer. Flows can add state, conditions, and more control when a crew becomes part of a larger business process.47
CrewAI is easy to understand because its concepts resemble a human team. However, role-based designs can add unnecessary complexity when one agent and a few tools can complete the task.
Microsoft AutoGen
AutoGen is a Python framework for conversational and event-driven agent systems.
AgentChat provides ready-made agents and team patterns. AutoGen Core provides lower-level control for distributed and event-driven systems.48
Choose AutoGen when you want to experiment with:
Agents that discuss a task
Agent handoffs
Human participation
Code execution
Distributed multi-agent systems
AutoGen is flexible, but this flexibility can make production architecture harder to design. Teams also need to understand the difference between AgentChat, Core, Studio, and extensions.
LlamaIndex
LlamaIndex is best known for connecting language models to documents, databases, and other private data. It also provides tool-using agents and multi-agent workflows.49
Choose LlamaIndex when retrieval is a central part of the agent. Common examples include:
Document research agents
Internal knowledge assistants
Database agents
Agents that work with large document collections
Its data connectors, indexes, and retrieval features are a major advantage. A more focused agent framework may be easier when the application does not need retrieval or data indexing.
Pydantic AI
Pydantic AI is a Python agent framework from the team behind Pydantic. It places strong attention on type safety, data validation, dependency injection, and structured output.50
Choose Pydantic AI when you want agent code that feels similar to a typed Python web application. It is especially useful when the agent must return data that matches a fixed schema.
Pydantic AI also supports multiple model providers, tool approval, evaluations, graph workflows, and durable execution integrations.
Its type system can catch many problems early. However, it is mainly suited to Python teams, and some advanced features require additional services or integrations.
Microsoft Semantic Kernel
Semantic Kernel is an AI application framework from Microsoft. It supports Python, .NET, and Java. Its agent framework can connect models with plugins, application services, and multi-agent workflows.51
Choose Semantic Kernel when:
Your application already uses .NET or Microsoft services
You need strong dependency injection and plugin patterns
Agents must work with existing enterprise code
You want support for several programming languages
Semantic Kernel fits well into traditional application architecture. However, it has a broad API surface, and some multi-agent orchestration features remain experimental.
Conclusion
The best framework depends on your application:
Start with the programming languages your team already uses.
Check support for your preferred models and tools.
Decide how much workflow control you need.
Review memory, safety, testing, and monitoring features.
Confirm that you can deploy it in your chosen environment.
Build a small test with one real task before you commit.
A simple agent may only need a model and a few tools. A complex business process may need persistent state, approvals, evaluation, and reliable recovery.
Start with the smallest setup that meets your current needs. Add more structure as the agent gains responsibility. This approach keeps development clear and makes it easier to change direction as agent frameworks continue to develop.
