Top open-source agent framework for AWS-native shops

I've been deep in the weeds for the last two months evaluating agent frameworks for a new project, and I need to get this community's take. My team is all-in on AWS (ECS/EKS, Lambda, Bedrock, S3 for artifacts, etc.), and we're trying to build a reliable, observable agent system for internal DevOps automation—think incident triage, cost report generation, and security scan analysis.

Given that context, **I'm leaning heavily towards LangGraph for our AWS-native stack, not CrewAI.** Here's my detailed reasoning from weeks of prototyping, focusing on the integration points that actually matter in production:

**Why LangGraph Feels More "AWS-Native"**

1. **Core Architecture:** LangGraph's explicit state machine model (`StateGraph`) maps beautifully to Step Functions. I can prototype a complex agent workflow in Python, and the mental model translates directly to a robust, serverless state machine for production. CrewAI's `Crew` and `Task` abstractions are great for quick starts but feel more opaque when you need to debug or instrument a specific step in a pipeline.
2. **Bedrock & SDK Integration:** Both frameworks support Amazon Bedrock, but LangGraph's more primitive composition meant I could use the standard `boto3` Bedrock runtime client directly within a node or tool. This gave me finer control over retries, error handling, and model parameters. CrewAI's LLM abstraction layer is convenient but added a hop I didn't always want.
3. **Observability & Tracing:** This was the clincher for me. With LangGraph, I could instrument each node and edge using AWS X-Ray directly. Since our entire observability pipeline (metrics, logs, traces) lives in CloudWatch and X-Ray, having those fine-grained traces was non-negotiable for incident response. I found it harder to get that same level of granular, AWS-integrated telemetry out of CrewAI's orchestration layer.

Here's a tiny snippet from my prototype that shows how clean the Bedrock integration can be for a tool-calling node:

```python
import boto3
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolExecutor
from langchain_aws import ChatBedrock

# Use the standard AWS-suggested client config
client = boto3.client('bedrock-runtime', region_name='us-east-1')
model = ChatBedrock(model_id="anthropic.claude-3-haiku-20240307-v1:0", client=client)

# Define your graph nodes...
def analyze_node(state):
# Direct, low-level tool calls if needed, or use the LCEL layer
response = client.converse(...)
# Log to CloudWatch Logs with a structured JSON payload
logger.info({"node": "analyze", "state_snapshot": state.keys()})
return {"analysis": response}

workflow = StateGraph(dict)
workflow.add_node("analyzer", analyze_node)
workflow.add_edge("analyzer", END)
app = workflow.compile()
```

My open question to you all is about **long-running, persistent agents**. If we move an agent graph to a Step Function for durability, we need to checkpoint the state (messages, intermediate data) to something like DynamoDB. LangGraph's checkpointing adapters are promising, but I haven't stress-tested this with AWS persistence backends.

Has anyone successfully deployed a persistent LangGraph agent on ECS Fargate or as a Step Function, using DynamoDB for state? I'm particularly curious about the patterns for handling human-in-the-loop approvals (e.g., sending an SNS message and pausing the graph until a Lambda processes a response).

I'll share my benchmarking setup and cost comparisons in a follow-up post if there's interest!

— francesc