Six months ago, picking an agent framework felt like choosing a JavaScript framework in 2016 – new options every week, each claiming to be the production-ready one, none with enough real-world mileage to prove it. That changed faster than expected. LangGraph reached 1.0 in October 2025, CrewAI passed 450 million processed workflows, Amazon Bedrock AgentCore launched as a managed deployment platform, and the Model Context Protocol became the de facto standard for tool integration. The landscape didn’t just mature – it stratified into distinct categories solving different problems.
The question for teams building agent systems is no longer “which framework exists” but “which layer of the stack does my problem live in.” Orchestration frameworks, deployment platforms, and integration protocols serve different concerns. Conflating them leads to over-engineering. Understanding the boundaries leads to systems that actually work.
The Framework Layer: Orchestration and Control Flow
Three frameworks dominate production agent orchestration, each with a distinct philosophy about how agents should be structured.
LangGraph: Graphs as First-Class Control Flow
LangGraph 1.0.8 (as of February 2026) treats agent behavior as a graph of nodes and edges where state flows between steps. Its core value proposition is durable execution – agents persist through failures and resume from exact stopping points rather than restarting from scratch. This matters less for simple chat agents and critically for long-running workflows that coordinate multiple tools across minutes or hours.
The framework supports single-agent, multi-agent, hierarchical, and sequential architectures through the same graph abstraction. State “time-travel” lets you roll back to any previous decision point, which transforms debugging from log archaeology into interactive replay. Human-in-the-loop workflows plug into the graph as interrupt nodes where execution pauses, surfaces context to a human, and resumes based on their input.
LangGraph’s strength is its flexibility. The graph model can represent nearly any agent architecture. That flexibility is also its primary cost – you need to design the graph, which requires understanding your agent’s control flow well enough to express it as nodes and edges. For teams that know their workflow structure, this is an advantage. For teams still discovering what their agent should do, the upfront design requirement can slow iteration.
Adoption signals are strong: Rakuten, GitLab, Elastic, and Cisco run LangGraph in production. LangSmith provides the observability layer for debugging traces and monitoring production behavior.
CrewAI: Teams of Specialized Agents
CrewAI 1.9.3 takes a different approach. Instead of defining graphs, you define agents with roles, goals, and backstories, then organize them into Crews that collaborate on tasks. The mental model is closer to assembling a team than programming a workflow. A dual architecture combines Crews (autonomous agent teams) with Flows (event-driven workflows) for situations requiring precise control alongside autonomous behavior.
The framework claims complete independence from LangChain, built from scratch rather than layered on top. At 450 million monthly processed workflows and adoption by 60% of Fortune 500 companies (per CrewAI’s published numbers), the scale is substantial. The enterprise AMP Suite adds unified control planes, real-time observability, and security features.
CrewAI works best when your problem naturally decomposes into distinct roles – a researcher, an analyst, a writer, a reviewer – each with clear responsibilities. Where it struggles is when agent interactions are highly dynamic and unpredictable. The role-based abstraction assumes you can pre-define agent specializations, which works for structured business processes but constrains more exploratory agent behavior.
OpenAI Agents SDK: Lightweight Handoffs
The OpenAI Agents SDK (0.9.2, released February 2026) is the most lightweight of the three. Agents are LLMs configured with instructions, tools, guardrails, and handoff targets. The key primitive is the handoff – a specialized tool call that transfers control from one agent to another based on task requirements. Language routing, triage, and domain-specific processing all happen through handoffs rather than centralized orchestration.
Despite the name, the SDK supports over 100 LLM providers beyond
OpenAI. Built-in tracing integrates with Logfire, AgentOps, Braintrust,
and other observability platforms. The decorator-based tool system
(@function_tool) keeps tool definitions close to
implementation code rather than in separate configuration.
The SDK’s simplicity is intentional. It doesn’t provide durable execution, persistent memory, or complex orchestration out of the box. For agents that handle a request, potentially hand off to a specialist, and return a result within a single session, this simplicity is a feature. For agents that need to survive process restarts or maintain state across days of interaction, you need additional infrastructure.
The Deployment Layer: Amazon Bedrock AgentCore
AgentCore fills a gap that framework authors acknowledge but don’t solve: running agents in production with enterprise-grade operational requirements. It’s a managed platform for deploying and operating agents at scale, deliberately framework-agnostic and model-agnostic.
The build capabilities include persistent memory systems that maintain agent knowledge across interactions, a gateway service that converts existing APIs and Lambda functions into agent-compatible tools with minimal code, a secure browser runtime for web-based workflows, and a code interpreter for secure execution. The gateway service is particularly valuable because it lets you expose your existing service mesh to agents without rebuilding APIs in a framework-specific format.
Deployment runs on serverless infrastructure with complete session isolation, supporting workloads lasting up to 8 hours. Native VPC connectivity and AWS PrivateLink support mean agents can access internal services without exposing them to the public internet. This addresses a real production concern – most enterprise data lives behind private networks, and agents that can’t reach it aren’t useful regardless of how sophisticated their reasoning is.
The operations layer provides real-time CloudWatch dashboards, quality evaluation metrics (correctness, helpfulness, safety, goal success rates), and OpenTelemetry integration for teams already using Datadog, Splunk, or other observability platforms. Audit trails trace agent decisions through their full execution path.
Managed Bedrock Agents vs. AgentCore
AWS now offers two distinct agent services that target different use cases. Managed Bedrock Agents provide a higher-level abstraction – you define agent instructions, attach knowledge bases and tools, and AWS handles the orchestration. Multi-agent collaboration uses a supervisor pattern where one agent coordinates specialists. This is the fastest path to a working agent for teams that don’t need custom orchestration logic.
AgentCore operates one level lower. You bring your own framework (LangGraph, CrewAI, custom code) and AgentCore provides the deployment, scaling, security, and monitoring infrastructure. The trade-off is more control for more complexity. If your agent logic fits within Bedrock Agents’ orchestration model, start there. If you need custom control flow, multi-framework deployments, or specific state management patterns, AgentCore gives you the infrastructure without the orchestration opinions.
The Integration Layer: Model Context Protocol
The Model Context Protocol (MCP) has become the standard for connecting agents to external tools and data sources. The specification (version 2025-11-25) defines a client-host-server architecture using JSON-RPC 2.0 that lets any agent framework integrate with any tool server through a common protocol.
The architecture works as follows: a host application (Claude Desktop, VS Code, Claude Code, or your custom application) coordinates multiple MCP clients. Each client maintains a stateful session with one MCP server. Servers expose three primitive types: tools (executable functions), resources (data sources providing context), and prompts (reusable templates for structuring interactions). Transport runs over either stdio for local processes or streamable HTTP with optional Server-Sent Events for remote servers.
MCP servers exist for file systems, databases, Sentry, Figma, Google Calendar, Notion, Blender, and dozens of other services. The protocol also defines client primitives that servers can invoke: sampling (requesting LLM completions from the host), elicitation (requesting information from users), and logging. An experimental Tasks primitive supports durable execution for batch processing and multi-step operations.
Why MCP Matters More Than It Seems
The proliferation of MCP servers means agents built against MCP can access a growing tool ecosystem without framework-specific integrations. A LangGraph agent and a CrewAI agent can both use the same MCP server for database access. This is a significant shift from the previous model where each framework maintained its own tool integration layer, duplicating effort and fragmenting the ecosystem.
MCP also standardizes how tools describe themselves to agents. The input schema format is consistent across servers, which means agents can discover and use tools they weren’t specifically programmed for. This emergent capability becomes more valuable as the number of available MCP servers grows.
The security implications need attention. MCP servers running locally have access to whatever the host process can access. Remote MCP servers authenticate through OAuth, but the authorization model – what a server should be allowed to do on behalf of an agent – is still evolving. Teams deploying MCP in production should treat server permissions like they treat IAM roles: least privilege, scoped to specific resources, monitored for anomalous access patterns.
Production Patterns That Work
After reviewing dozens of agent deployments across enterprises, several patterns consistently separate successful production systems from demos that never ship.
Start with Deterministic Scaffolding
The agents that reach production fastest use LLM reasoning for genuinely ambiguous decisions and deterministic code for everything else. Input validation, output formatting, API call construction, error handling – these don’t benefit from LLM flexibility and actively suffer from LLM non-determinism. The most common architecture I see working is: deterministic routing decides which agent handles a request, the agent uses LLM reasoning for its core task, and deterministic post-processing validates and formats the output.
Instrument Before You Scale
Every production agent system I’ve seen fail at scale had the same root cause: insufficient observability. LangSmith, AgentCore’s CloudWatch integration, and OpenAI’s tracing support all exist because teams learned this lesson the hard way. You need to see every tool call, every handoff, every LLM invocation, and the full state at each step. Without this, debugging a failed agent interaction is impossible once you’re past a single-agent, single-tool architecture.
Memory Is a Design Decision, Not a Feature Toggle
Agent memory systems range from simple conversation history (OpenAI Agents SDK sessions) through persistent cross-session memory (AgentCore, LangGraph checkpoints) to sophisticated retrieval systems with recency, importance, and relevance scoring. The right choice depends on whether your agent handles independent requests, maintains context within a session, or builds long-term knowledge about users and domains. Most production agents I encounter need less memory than their designers initially assume. A customer support agent that retrieves the customer’s recent tickets on each interaction often outperforms one that tries to maintain a persistent memory of all past interactions.
Human-in-the-Loop Is Non-Negotiable for High-Stakes Decisions
LangGraph’s interrupt nodes, Bedrock Agents’ human approval steps, and custom confirmation flows all serve the same purpose: ensuring a human reviews agent decisions before they become irreversible. For internal tools and low-stakes automation, fully autonomous agents work fine. For customer-facing actions, financial transactions, or anything with compliance implications, the human-in-the-loop pattern isn’t optional. The design challenge is making the interruption informative enough that the human can make a good decision quickly rather than rubber-stamping every action.
Choosing Your Stack
The decision tree for agent architecture in 2026 has fewer branches than it did a year ago, which is progress.
If your agent system fits a supervisor-delegates pattern with Bedrock-hosted models, start with managed Bedrock Agents. It’s the lowest-friction path to production on AWS and handles the common case well.
If you need custom orchestration logic, pick LangGraph for graph-structured workflows or CrewAI for role-based agent teams. Deploy on AgentCore for managed infrastructure, or self-host if you have the operational capacity.
If you’re building tool integrations, build them as MCP servers regardless of your framework choice. The ecosystem interoperability pays for itself as you add agents or switch frameworks.
If you’re evaluating and unsure, the question that most reliably guides the decision is: “Can I draw my agent’s control flow as a flowchart?” If yes, LangGraph maps directly to that flowchart. If your agent’s behavior is better described as “these roles collaborate toward a goal,” CrewAI’s abstraction fits better. If your agent makes a decision and hands off to a specialist, the OpenAI Agents SDK’s handoff pattern is the simplest implementation.
The frameworks have matured enough that the wrong choice among these three is recoverable. The deployment and integration layers – AgentCore and MCP – are more consequential long-term decisions because they determine how your agents connect to your organization’s data and services. Invest your architecture time there.