Agentic frameworks turn a raw LLM into a dependable agent. Here we look at the frameworks, platforms, and protocols you actually install and ship on AWS: LangChain, Strands Agents, CrewAI, AutoGen, MCP, and A2A.

- Agentic Frameworks: What You’ll Learn
- Agentic Frameworks: Why You Need One
- How Agentic Frameworks Reduce Undifferentiated Heavy Lifting
- Comparing the Leading Agentic AI Frameworks
- Agentic AI Platforms on AWS
- Choosing Among Agentic Frameworks: A Decision Framework
- The Model Context Protocol (MCP): Universal Tool Integration
- Agent-to-Agent (A2A) Protocol
- Building Your Tool Ecosystem
- Agentic Frameworks in Practice: A Worked Example
- Agentic Frameworks: Common Mistakes to Avoid
- Agentic Frameworks: Best Practices
- Agentic Frameworks: Frequently Asked Questions
- Agentic Frameworks: Key Takeaways
- Continue Learning
Agentic Frameworks: What You’ll Learn
Agentic frameworks encode the critical plumbing — prompt assembly, tool calling, retry loops, memory, tracing — so you focus on agent purpose, not plumbing. You will leave with a mental model of where LangChain, Strands Agents, CrewAI, AutoGen, MCP, and A2A fit, how Bedrock AgentCore glues them together, and which trade-offs matter in production.
Agentic Frameworks: Why You Need One
Building an agent without a framework is like building a web app without a router — weeks rewriting boilerplate that is not your competitive advantage. A modern agentic framework gives you four things: a tool-calling contract (Python/TypeScript to JSON Schema), a memory layer, an orchestration loop (ReAct, plan-and-solve, or custom), and observability hooks (CloudWatch, Langfuse, Datadog).
The AWS Prescriptive Guidance guide puts it bluntly: frameworks “reduce undifferentiated heavy lifting across patterns, protocols, and tools.” A mature framework also standardizes prompt versioning, tool authorization, and audit trails.
In practice, standardized prompt versioning means every change to a system prompt is stored alongside the code that calls it, so a regression in agent behavior can be traced to the exact prompt revision that shipped it — the same discipline teams already apply to application code, now extended to the instructions an LLM receives.
Standardized tool authorization means each tool call carries a scoped credential rather than a single all-powerful API key, so a compromised or misbehaving agent cannot silently escalate its own permissions.
And audit trails mean every tool invocation, its arguments, and its result are logged in a structured, queryable form, which is what lets a security team reconstruct exactly what an agent did after the fact rather than guessing from application logs never designed for that purpose.
How Agentic Frameworks Reduce Undifferentiated Heavy Lifting
Undifferentiated heavy lifting — work that doesn’t differentiate you from competitors (identity plumbing, retry logic, schema validation). Frameworks absorb it three ways: stable model clients (swap Claude for Nova), normalized tool definitions (one MCP server across Bedrock, Vertex, Azure), and framework-level hooks for cross-cutting concerns.
Consider retry logic: without a framework you write exponential backoff and hope tests match reality; with one, retry is a property of the tool wrapper — configured once. The evaluation criterion is not “most features?” but “which removes the most heavy lifting for my team?” A framework with 200 features you never use is heavier than one with 30 you live in.
The same logic applies to schema validation and identity plumbing. Without a framework, every tool integration needs its own hand-written JSON Schema, its own error-handling branch for malformed model output, and its own retry-with-backoff loop copied and slightly modified from the last project.
With a framework, the tool decorator generates the schema from type hints, a shared exception handler catches malformed calls and feeds a corrective message back to the model, and retry is a keyword argument on the tool wrapper rather than a block of code someone has to remember to write correctly every time.
That consistency is what makes a team of five engineers able to ship a dozen tools in the time it used to take to ship three.
Comparing the Leading Agentic AI Frameworks
Four frameworks dominate production AWS deployments in 2026: LangChain/LangGraph (maximum flexibility, steep curve), Strands Agents (open-sourced by AWS in May 2025, model-driven, native Bedrock), CrewAI (role-based multi-agent crews, easy), and AutoGen (conversational multi-agent, moderate).
| Framework | Best for | Language(s) | AWS integration | Learning curve |
|---|---|---|---|---|
| LangChain + LangGraph | Maximum flexibility; stateful cyclic agent graphs | Python, TypeScript | Deep — native Bedrock, S3, Lambda integrations | Steep |
| Strands Agents | Model-driven orchestration; native Bedrock AgentCore | Python | First-class — built by AWS, powers AgentCore SDK | Gentle |
| CrewAI | Role-based multi-agent crews; rapid prototyping | Python | Good — runs on Bedrock via LiteLLM or direct | Easy |
| AutoGen | Conversational multi-agent; round-table discussion | Python, .NET | Good — Bedrock via custom model clients | Moderate |
Rule of thumb: agents calling tools one-at-a-time inside AWS — start with Strands Agents. Complex state machines with cycles — LangGraph. Small teams wanting multi-agent collaboration — CrewAI. Agentic debate or self-improving agent societies — AutoGen.
LangChain and LangGraph
LangChain’s core abstraction is the chain; LangGraph extends it to a stateful graph with conditional edges and shared state — right for agents that loop until a stopping condition. The trade-off is complexity: the surface area is enormous. For greenfield AWS work in 2026, prefer LangGraph over plain LangChain.
Concretely, this means modeling the agent as nodes and edges: a node calls the model, a conditional edge inspects the model’s output and decides whether to call a tool, loop back for another reasoning pass, or exit to the user.
That explicit graph is what makes LangGraph debuggable at scale — you can render it, breakpoint on a specific node, and replay a failed run from the state that existed just before the failure, rather than re-running the entire conversation from scratch.
Strands Agents
Open-sourced by AWS in May 2025, Strands Agents takes a model-driven approach — the LLM decides when to call tools, the framework executes. This produces short agent definitions (often under 30 lines) and tight integration with Bedrock Guardrails, Knowledge Bases, and Converse API.
Model-driven means the framework does not hard-code a fixed sequence of steps; instead, on each turn the model itself decides — based on the tools it has been given and the conversation so far — whether to call a tool, ask a clarifying question, or return a final answer.
Strands simply executes whatever the model decides and feeds the result back in. That is why a Strands agent definition reads like a declaration (model, tools, system prompt) rather than a procedure: the control flow lives in the model’s reasoning, not in your code.
CrewAI
CrewAI’s signature is the crew: agents with role, goal, backstory plus tasks to complete. Its API is unusually small (a working multi-agent system in 50 lines). Where it struggles is fine-grained control — conditional branching, complex state machines. For those, layer in LangGraph or Strands Agents.
Role, goal, and backstory are not decorative — they are injected into each agent’s system prompt, which is what makes a “Senior Customer Researcher” agent behave differently from a “Quantitative Analyst” agent even when both run on the same underlying model.
Tasks are assigned to specific agents and executed in the order the crew’s process defines, which is why CrewAI reads more like an org chart than a state machine — a useful mental model when the workload genuinely maps to distinct human-like roles, and a limiting one when it does not.
AutoGen
AutoGen (Microsoft, v0.4) is the conversational multi-agent framework. Its core pattern is a group chat where a manager agent decides who speaks next — ideal for agentic debate, multi-specialist code review, or problems needing diverse perspectives.
Because the manager agent — not a fixed script — chooses the next speaker, AutoGen conversations can branch in ways a linear chain cannot: a code-review manager might route a security concern to a specialist agent mid-conversation, then bring the original reviewer back in once that concern is resolved.
The trade-off is predictability — a group chat can run longer and cost more tokens than a fixed pipeline, so AutoGen tends to fit exploratory or adversarial workloads better than high-volume production paths with tight latency budgets.

Agentic AI Platforms on AWS
A framework is something you install; a platform is something you log into — bundling framework with managed runtime, identity, observability, and connectors. Three buckets: managed (Amazon Bedrock Agents and Amazon Bedrock AgentCore), open source orchestration (LangGraph Cloud, CrewAI Enterprise, self-hosted AutoGen Studio — more control, more toil), and hybrid (managed control plane, customer-managed agent runtime on AgentCore microVMs or your own ECS behind a VPC).
Managed wins for speed-to-market. Open source wins for strong DevOps culture with unusual requirements. Hybrid — the enterprise default on Bedrock AgentCore — wins for regulated industries needing isolation without giving up managed convenience.
The practical difference shows up at incident-response time. On a fully managed platform, AWS handles patching, scaling, and the underlying runtime, and you concentrate on the agent’s prompt and tools — but you have less control over exactly how a request is executed.
On self-hosted open source orchestration, you own the deployment, which means you can pin exact library versions and inspect every layer, at the cost of also owning the on-call rotation for that infrastructure.
The hybrid model on Bedrock AgentCore splits the difference: AWS manages the control plane and the microVM runtime that isolates each tenant’s agent execution, while you still own the agent code, the tool definitions, and the business logic that runs inside that isolated runtime.
Choosing Among Agentic Frameworks: A Decision Framework
Five questions collapse the shortlist for most AWS teams.
1. Skill set? Python-native teams narrow to Strands Agents, LangChain, CrewAI, AutoGen. TypeScript teams lean on LangChain.js.
2. How many agents? Single-agent: Strands Agents on Bedrock AgentCore. Two-to-five with role separation: CrewAI. Five+ in a complex topology: LangGraph or AutoGen.
3. Isolation requirements? Regulated industries need tenant isolation at the runtime level — Bedrock AgentCore’s microVM runtime handles it natively.
4. Operational maturity? Low DevOps capacity: default to managed Bedrock AgentCore. Strong platform engineering: extract value from open source on ECS/Lambda.
5. Time horizon? Prototypes favor CrewAI; multi-year production favors LangGraph or Strands Agents. Avoid single-maintainer frameworks for anything long-term.
These five answers rarely point in the same direction, which is the point — the decision framework exists to surface the tension explicitly rather than let a default choice go unexamined.
A Python team building a single agent for a six-month pilot with no regulatory constraint lands on Strands Agents almost by elimination; a cross-functional team building a five-agent system for a multi-year regulated workload will usually end up combining LangGraph or Strands Agents for orchestration with Bedrock AgentCore for the isolation and operational maturity that a small platform team cannot realistically build and maintain themselves.
The Model Context Protocol (MCP): Universal Tool Integration
MCP is the most important protocol story since tool-calling JSON Schema. Anthropic open-sourced it in November 2024; by mid-2025, Bedrock AgentCore, Claude Desktop, Cursor, LangChain, and Strands Agents had native support.
The simplest mental model: MCP is USB-C for AI tools — one tool server works for any agent. MCP is JSON-RPC with three roles: host (user-facing app), client (one connection), and server (exposing tools, resources, prompts). Servers run local (stdio) or remote (HTTP+SSE).
The transport choice matters operationally. A stdio server runs as a subprocess of the host application — simple to develop and debug locally, but it lives and dies with that process, so it suits desktop tools like Claude Desktop or a developer’s IDE integration.
An HTTP+SSE server runs independently, can be shared by many agents and many hosts at once, and can sit behind normal AWS infrastructure — a load balancer, an API Gateway, IAM authentication — which is why production deployments on Bedrock AgentCore standardize on the remote transport rather than stdio.
A minimal MCP server exposing a get_customer tool:
from mcp.server import Server
from mcp.types import Tool, TextContent
import httpx
server = Server("customer-lookup")
@server.list_tools()
async def list_tools() -> list[Tool]:
return [Tool(
name="get_customer",
description="Look up a customer record by ID",
inputSchema={
"type": "object",
"properties": {"customer_id": {"type": "string"}},
"required": ["customer_id"],
},
)]
@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
if name == "get_customer":
async with httpx.AsyncClient() as client:
r = await client.get(
f"https://api.internal/customers/{arguments['customer_id']}",
headers={"Authorization": "Bearer " + os.environ["API_TOKEN"]},
)
return [TextContent(type="text", text=r.text)]
if __name__ == "__main__":
import asyncio
from mcp.server.stdio import stdio_server
asyncio.run(stdio_server(server))
Any MCP-aware agent — Bedrock AgentCore, Claude Desktop, LangChain’s MCP adapter — can now call get_customer without knowing your internal API.
A typical tools/call JSON-RPC 2.0 exchange:
// Request from agent to server
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "get_customer",
"arguments": { "customer_id": "cus_4f2a8b" }
}
}
// Response from server to agent
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [
{
"type": "text",
"text": "{"id":"cus_4f2a8b","name":"Acme Corp","arr":240000,...}"
}
],
"isError": false
}
}
This wire format makes MCP servers interchangeable across language, runtime, and vendor.
Bedrock AgentCore supports MCP natively: register a server URL as a gateway target and every agent in your tenant discovers its tools, with authentication, retry, and observability handled on the wire.
Concretely, that means an individual agent developer never writes an HTTP client, never handles a 401 response, and never wires up a CloudWatch metric by hand for a registered tool.
The gateway terminates authentication against the caller’s IAM role, retries a transient failure before the agent ever sees it, and emits a standard set of latency and error metrics for every tool call, whether that tool was written by your team last week or inherited from a vendor.

Agent-to-Agent (A2A) Protocol
Google open-sourced A2A in April 2025 (Salesforce, SAP, Atlassian, Box adopted early). It addresses how two independently-built agents, possibly from different vendors, delegate work to each other.
The A2A model uses agent cards — JSON documents describing what an agent can do, how to authenticate, and which modalities it accepts. An agent discovers another by fetching its card, submits a task worked on asynchronously, and receives status via callbacks or polling.
The card is deliberately minimal — it does not expose the remote agent’s internal prompts or tools, only the interface contract needed to invoke it — so two organizations can integrate their agents without either side reading the other’s implementation.
Because a task is asynchronous, the calling agent does not block waiting for a slow multi-step task to finish; it can check back later or register a callback URL, which matters when the remote agent might take minutes to research and compile an answer rather than milliseconds.
Bedrock AgentCore’s gateway can expose Bedrock Agents as A2A endpoints.
MCP and A2A are complementary: MCP standardizes agent-to-tool (one agent, many tools); A2A standardizes agent-to-agent (many agents, one task). A well-designed production system uses both.

Building Your Tool Ecosystem
Tools give agents the ability to act. Three categories: MCP-based tools (most reusable; default for new integrations), framework-native tools (LangChain’s @tool, Strands’ @tool, CrewAI’s BaseTool — fast but don’t port; use for one-off glue), and meta-tools (code execution like Strands’ python_repl — powerful but dangerous; gate behind strong guardrails).
Structure tools in layers: MCP servers at the bottom (one per internal system), framework-native composition tools in the middle, meta-tools at the top with strict access control and dedicated audit logging.
The reason meta-tools sit at the top of that stack rather than being used freely is that a tool like code execution has no fixed boundary — a well-scoped MCP tool can only do what its handler explicitly implements, but a code-execution tool can do anything the underlying runtime permits.
That is exactly what makes it powerful for genuinely open-ended tasks and exactly why it needs the strictest guardrails, network egress restrictions, and its own audit log separate from ordinary tool calls.
Agentic Frameworks in Practice: A Worked Example
Suppose you build an internal “research analyst” agent that decides whether to query CRM, search wikis, or pull warehouse analytics, then synthesizes a report. With Strands Agents on Bedrock AgentCore, the definition is short — declare a model, declare tools, let the model-driven loop handle the rest:
from strands import Agent, tool
from strands_tools import http_request
import boto3
# Bedrock-powered model
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
@tool
def summarize_report(text: str) -> str:
"""Summarize a long analytics report into 5 bullet points."""
# calls Bedrock Claude under the hood
... @tool
def query_warehouse(sql: str) -> str:
"""Run a read-only SQL query against the Redshift warehouse."""
...
analyst = Agent(
model="anthropic.claude-3-5-sonnet",
tools=[http_request, summarize_report, query_warehouse],
system_prompt="You are a careful research analyst. Always cite sources."
)
result = analyst("Which enterprise customers had the highest usage growth last quarter, and why?")
print(result)
The framework handled the tool-calling loop, memory, JSON Schema generation, retry, and trace emission to CloudWatch. Notice what is absent from that definition: there is no explicit “if the model wants to call a tool, then…” branch anywhere in the code.
That branch exists inside Strands itself — the framework inspects the model’s response, detects a tool-call request, executes the matching Python function, and feeds the result back to the model automatically, looping until the model returns a final answer instead of another tool call.
With CrewAI, the same workload becomes a crew with researcher, analyst, and writer roles:
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool, DirectoryReadTool
researcher = Agent(
role="Senior Customer Researcher",
goal="Find the customers with highest usage growth last quarter",
backstory="You are meticulous, you cite your sources, you distrust gut feel.",
tools=[SerperDevTool(), DirectoryReadTool(directory="./internal_docs")],
llm="anthropic/claude-3-5-sonnet",
)
analyst = Agent(
role="Quantitative Analyst",
goal="Compute growth rates from the warehouse and flag anomalies",
backstory="You think in SQL and confidence intervals.",
tools=[query_warehouse_tool],
llm="anthropic/claude-3-5-sonnet",
)
writer = Agent(
role="Report Writer",
goal="Turn findings into a 5-bullet executive summary",
backstory="You write like a McKinsey consultant, with evidence on every line.",
llm="anthropic/claude-3-5-sonnet",
)
crew = Crew(
agents=[researcher, analyst, writer],
process=Process.sequential,
tasks=[research_task, analysis_task, writing_task],
)
result = crew.kickoff()
Strands describes one agent with tools; CrewAI describes three agents with coordinated roles.
The CrewAI version also introduces a decision the Strands version does not need to make: task ordering. Because Process.sequential runs the researcher, analyst, and writer tasks one after another, each agent’s output becomes the next agent’s input by construction — the writer never sees raw warehouse data, only the analyst’s conclusions.
A hierarchical process, by contrast, would introduce a manager agent that assigns tasks dynamically rather than following a fixed order — useful when the right next step genuinely depends on what the previous agent found, at the cost of the predictable, replayable execution order sequential mode gives you.
Pick the model that fits your problem.
Agentic Frameworks: Common Mistakes to Avoid
- Picking the framework before the workload — sketch the workload first; a single-tool agent is ten lines of Strands code, not a LangChain project.
- Ignoring MCP until it is too late — default to MCP for anything you will reuse across teams or frameworks.
- One mega-agent with thirty tools — above ~10 tools, model performance degrades; split into orchestrator-with-subagents.
- Trusting defaults on observability — tracing works only if you wire hooks to CloudWatch, Langfuse, or Datadog.
The first two mistakes on this list compound each other: a team that picks LangGraph before sketching the workload often ends up building a mega-agent inside it simply because the framework makes it easy to keep adding tools to the same graph.
Treating MCP as an afterthought has the same shape — teams that wire tools directly into one framework’s native decorator save a day of setup now and spend a week rewriting those same tools as MCP servers later, once a second framework or a second team needs the same capability.

Agentic Frameworks: Best Practices
- Start with Strands Agents on Bedrock AgentCore for greenfield AWS projects.
- Standardize on MCP for reusable tools; reserve framework-native tools for one-off glue.
- Cap each agent’s tool count at 8–12; above that, split into orchestrator-with-subagents.
- Wire tracing hooks to CloudWatch or Langfuse from day one.
- Version agent definitions in source control the same way you version Lambda functions.
That last point deserves emphasis: an agent’s behavior is defined by its system prompt, its tool list, and its model version just as much as by any code around it, so a change to any of the three should go through the same pull-request review and rollback process as a change to a Lambda function’s code.
Teams that treat the prompt as a string constant edited in place, outside version control, lose the ability to answer “what changed?” the first time an agent’s behavior regresses in production.

Agentic Frameworks: Frequently Asked Questions
What is the difference between LangChain and LangGraph?
LangChain executes chains of prompts and tools linearly; LangGraph models agents as stateful directed graphs with cycles — essential for agents that loop, branch, and revisit steps. In practice, most teams starting new agentic work on AWS in 2026 reach for LangGraph directly rather than plain LangChain, since almost any agent that calls tools more than once benefits from the explicit loop LangGraph provides.
Is MCP an AWS protocol or an Anthropic protocol?
MCP was created by Anthropic, open-sourced in November 2024, and is vendor-neutral. AWS adopted it natively in Bedrock AgentCore; both companies collaborate on the spec. That vendor-neutral status is exactly why an MCP server you write once can be called by Claude Desktop, a LangChain agent, and a Strands agent without modification — the protocol, not any single company, defines the contract.
Do agentic frameworks work with non-AWS models?
Yes. LangChain, CrewAI, AutoGen, and Strands Agents all support OpenAI, Gemini, Anthropic direct, and open models via Ollama or vLLM. Swapping providers is usually a one-line change to the model identifier passed into the agent constructor, since the framework — not your application code — handles the differences in each provider’s request and response format.
What is the difference between Bedrock Agents and Bedrock AgentCore?
Bedrock Agents (2023) is the managed agent service. AgentCore (2025) adds MCP-native tool integration, an A2A gateway, long-term memory, and a serverless microVM runtime — the strategic platform for new projects. Existing Bedrock Agents workloads are not forced to migrate immediately, but new projects should default to AgentCore given the added protocol support and isolation model.
Can I use multiple agentic frameworks together?
Yes. A common pattern: Strands Agents for the primary loop, LangChain for a specialized retrieval sub-pipeline, CrewAI for a research crew exposed as a single MCP server. MCP and A2A standardize the boundaries, which is what makes mixing frameworks practical rather than a maintenance liability — each framework only needs to speak the protocol, not know anything about the internals of the framework on the other side.
Agentic Frameworks: Key Takeaways
- Frameworks absorb undifferentiated heavy lifting — tool-calling loops, memory, tracing, retries.
- LangChain, Strands Agents, CrewAI, AutoGen — match the framework to the workload, not the reverse.
- MCP is the universal tool protocol — default for reusable tools.
- A2A is the universal agent protocol — complementary to MCP.
- Bedrock AgentCore is the strategic AWS platform for new projects.
Agentic frameworks on AWS let you ship dependable agents without rebuilding plumbing every project. Match framework to workload, default to MCP for tools, lean on Bedrock AgentCore. Agentic AI frameworks on AWS collapse boilerplate code into a few decorator lines without locking you out of native boto3. Choosing among agentic AI frameworks on AWS means matching the framework to the team: Strands for SDK-native, LangChain for chains, CrewAI for role play.
Continue Learning
- Lab: Building with Strands and LangChain
- AWS Agentic AI Patterns — the design patterns frameworks implement
- AWS Serverless Agentic AI — how frameworks deploy on Lambda, Bedrock, AgentCore
- AWS RAG Writing Best Practices — making your knowledge base retrieval-friendly