Agentic Data Engineering Resources

Resource

LLM Agent Frameworks Explained

Compare major LLM agent frameworks and see why data infrastructure often matters more than framework choice in production.

Pedro Lopez

June 8, 2026

Last updated September 3, 2026

Summarize with AI:

Framework choice shapes control flow, retrieval design, and multi-agent coordination, but in production the harder problem is usually giving an agent reliable access to the right data. Authentication, access control, freshness, and connector reliability decide whether an agent ships.

Choosing between graph-based execution, conversation-driven coordination, or role-based abstractions is the easier half of the work.

TL;DR

LangGraph, LlamaIndex, CrewAI, AutoGen, OpenAI Agents SDK, and Google ADK each make different tradeoffs in orchestration, retrieval, multi-agent coordination, and ecosystem fit.
LangGraph provides the most control for complex stateful workflows, while LlamaIndex is strongest for retrieval-heavy and knowledge-intensive use cases.
Simpler chatbot or tool-calling applications often do not need a framework at all; raw LLM APIs may be sufficient.
In production, authentication, schema discovery, freshness, and access control often outweigh framework choice alone.

What Are LLM Agent Frameworks and Why Do They Exist?

LLM agent frameworks exist because a raw LLM API call is stateless. You send a prompt, you get a response, and the model forgets everything. The next call starts from scratch. Once an application needs to remember previous steps, decide which tool to call, and act on the result, a single stateless call falls short.

These frameworks wrap the model in four core components: the agent core, the memory module, the tool set, and the planning module.

The agent core is the LLM itself, responsible for reasoning and generating text.
The memory module persists information across calls, including conversation history, learned facts, or task state.
The tool set gives the agent capabilities beyond text generation, such as database queries, API calls, file operations, and code execution.
The planning module breaks complex goals into steps and determines execution order.

Frameworks manage the loop between reasoning and action. They serialize state between steps, route tool results back into context, and handle failures.

Both Anthropic and HuggingFace explicitly recommend starting without a framework. Frameworks make sense when you need persistent state, complex tool orchestration, or multi-agent coordination.

What Are the Major LLM Agent Frameworks?

LangGraph Offers Graph-Based Stateful Control

LangGraph models agent workflows as directed graphs built from different primitives. State is a shared TypedDict passed to every node. Nodes are Python functions that receive state and return partial updates. Edges are functions that inspect state and determine which node runs next. Execution uses message passing inspired by Google's Pregel system and proceeds in discrete super-steps.

It does well when teams need full control over execution order, branching, and cycles. State is explicitly and statically typed, conditional routing is Python code rather than an LLM call, and checkpointing supports replay, fork, and restart from prior steps.

It breaks down when teams want looser state handling. Practitioners in the roadmap thread describe state management friction, some memory leak issues have been reported, and the LangChain ecosystem carries a heavy dependency tree.

Best fit: complex agent workflows where deterministic execution paths and explicit state management are critical.

LlamaIndex Centers Retrieval and Knowledge Access

LlamaIndex is retrieval-first. Its architecture is built on two foundational primitives. Documents are containers around any data source. Nodes are atomic chunks of a source document and carry metadata relating them to parent documents and sibling nodes. Everything flows through a retrieval-augmented generation (RAG) pipeline.

It does well on knowledge-intensive tasks. LlamaIndex offers multiple index types, advanced chunking strategies, configurable response synthesis, and a query engine abstraction that separates retrieval, post-processing, and synthesis.

It breaks down when the application needs a declarative state machine. Control flow relies on imperative Python if/else, so conditional branching, cycles, and retry logic require manual implementation. Reported issues include a planner agent with a single-task bug and a visualization bug that returns blank HTML.

Best fit: data retrieval and knowledge-intensive agent use cases where the main challenge is querying and synthesizing information across large document sets.

CrewAI Uses Role-Based Multi-Agent Abstractions

CrewAI's architecture is built around Agents, which are defined by role, goal, and backstory, along with Tasks, Crews, and a Flows layer for orchestration. The backstory field influences agent behavior. Role identity comes from prompt design rather than code-level routing. Crews run either sequentially or in hierarchical mode where a manager LLM delegates to workers.

It does well as a fast path to multi-agent prototypes. The role-based mental model is intuitive for teams not comfortable with graph programming, and teams can deploy multi-agent setups quickly for straightforward use cases.

It breaks down when developers need full prompt visibility or lighter dependencies. The abstraction layer can hide final prompts from developers. CrewAI supports native provider integrations and ways to inspect generated prompts. One issue thread cites a dependency footprint of roughly 1 GB. Telemetry can be disabled via environment variables.

Best fit: fast multi-agent systems prototyping where team-based collaboration metaphors match the problem domain and prompt-level debugging is not a requirement.

AutoGen / AG2 Focuses on Conversation-Driven Coordination

AutoGen is built around ConversableAgent, agents that communicate by exchanging messages in structured conversations. The fundamental execution primitive is a conversational turn. Tools can return a target field that specifies which agent receives control next, making tool execution a first-class flow control mechanism. AutoGen v0.4 added a redesigned layered architecture with asynchronous message-passing and event-driven workflows.

It does well in flexible conversation-driven workflows with human-in-the-loop as a first-class participant. It supports both deterministic patterns and LLM-evaluated conditions.

It breaks down when termination is unclear. Infinite loops are documented in a confirmed bug. Practitioners have also reported direction drift over extended conversations. No official managed deployment infrastructure exists, and although AutoGen v0.4 is described in a Microsoft paper, its long-term trajectory remains unclear.

Best fit: conversational multi-agent scenarios with human oversight, especially where iterative agent-to-agent dialogue is the core interaction pattern.

OpenAI Agents SDK Keeps Orchestration Lightweight

The OpenAI Agents SDK provides core building blocks such as agents, handoffs, guardrails, tracing, and support for built-in and custom tools. Agent primitives include agents, handoffs, tools, and guardrails, along with auto-generated tool schemas via Pydantic, a built-in agent loop, and tracing.

It does well when teams want low abstraction overhead. It is straightforward for teams already on OpenAI models.

It breaks down around vendor dependencies. At the model level, the SDK works with non-OpenAI providers via LiteLLM, though official documentation and examples center on OpenAI models. At the ecosystem level, the Responses API and hosted tools can create operational dependencies. Some critics have argued that the Responses API makes provider switching less straightforward. One reported issue describes tool calls missing in tracing.

Best fit: teams building on OpenAI models who want lightweight orchestration without the cognitive overhead of a full framework.

Google ADK Connects Agent Workflows to Google Cloud

Google's Agent Development Kit (ADK) uses a BaseAgent class with three extension types: LLM Agents, Workflow Agents (SequentialAgent, ParallelAgent, LoopAgent), and Custom Agents. Agents write output via output_key to shared session state, and topology is defined at construction time via the sub_agents parameter.

It does well for teams already in the Google Cloud ecosystem. ADK includes Model Context Protocol (MCP) support across SDK languages, both MCP client and server patterns, and the A2A protocol for cross-framework agent communication. Deployment paths include Vertex AI Agentic Data Platform, Cloud Run, and GKE.

It breaks down in some current multi-agent patterns. Some developers have noted challenges and tradeoffs in Google ADK's current multi-agent patterns, including reported resource exhaustion.

Best fit: teams already operating within the Google Cloud ecosystem who want native integration with Gemini models and Google services.

What Architecture Patterns Do These Frameworks Use?

Most frameworks build on the ReAct (Reason + Act) pattern, introduced by Yao et al. at ICLR 2023. ReAct interleaves three elements in a repeating cycle. The model produces a Thought, selects an Action, and receives an Observation from the tool result before continuing to the next cycle. The loop continues until the agent reaches a final answer.

ReAct improved performance over baselines on ALFWorld and reduced hallucination on knowledge tasks, but the pattern comes with a token cost. Tool schemas are injected directly into the context window as input tokens, and tool result messages can account for a large share of total trajectory tokens.

LangGraph was graph-native from the start. AutoGen later added DiGraphBuilder as a GraphFlow API, and Google ADK introduced graph workflows. That convergence is limited. ADK's graph workflows are suited to static process structures but not recommended for complex branching logic. AutoGen's broader architecture includes conversation-based and event-driven patterns.

How Do the Major Frameworks Compare At A Glance?

Architecture style, multi-agent support, Model Context Protocol (MCP) compatibility, and primary use case are usually the clearest first-pass differences when a team is narrowing options.

Framework	Primary Strength	Architecture Style	Multi-Agent Support	MCP Support
LangGraph	Graph-based stateful orchestration	Directed graph, nodes are functions, edges define execution flow	Yes, subgraphs, shared state	Yes
LlamaIndex	Data retrieval and indexing for knowledge-intensive tasks	Retrieval-first, built around data indexing pipelines and query engines	Limited	Yes (native)
CrewAI	Role-based collaboration; fastest initial setup	Role/persona-based, agents with defined roles coordinate through a manager	Yes, core design pattern	Yes
AutoGen / AG2	Conversational multi-agent coordination; human-in-the-loop	Conversation-based, agents communicate through message passing	Yes, core design pattern	Yes
OpenAI Agents SDK	Agent framework with built-in orchestration patterns and MCP support	Provides agents, handoffs, guardrails, tracing, and tool support, with manager and handoff coordination patterns	Limited	Yes
Google ADK	Google ecosystem integration; workflow graphs	Graph-based workflows with Google ecosystem integration	Yes	Yes (native)

In production, framework choice interacts with data access, authentication, and permissioning in ways that feature-level differences rarely capture.

How Do LLM Agent Frameworks Connect To Data?

Frameworks handle orchestration: deciding what to do next, managing state, and calling tools. Data connectivity usually sits outside that layer. When your agent needs to query a customer relationship management system, search a document store, or pull records from a software-as-a-service tool, the framework assumes that connection already exists and works.

Model Context Protocol (MCP) is emerging as a standard protocol for bridging this gap. The MCP architecture uses a client-host-server model. Hosts such as Claude or VS Code connect to Servers that expose tools, resources, and prompts. Communication uses JSON-RPC 2.0 over stdio or Streamable HTTP transports.

The Anthropic donation put MCP under the Agentic AI Foundation (AAIF). MCP support is common across major frameworks and has become an important evaluation criterion, even if it is not always a clear differentiator.

MCP standardizes tool communication, while authentication, schema discovery, data freshness, and access control still require separate data infrastructure. Each MCP server still needs to handle authentication, schema discovery, data freshness, and access controls for its specific data source. Proliferating MCP tool definitions also has a context window cost because every tool schema consumes input tokens.

Why Does The Data Layer Matter For Framework Selection?

The data layer matters because production blockers usually arise in data access and only secondarily in orchestration. Engineers often compare graph versus role-based coordination, memory implementations, and debugging features. In production, getting the agent reliable access to the right data is often harder.

The recurring failure cases are consistent across frameworks:

Authentication and credential management. Frameworks assume credentials exist and are valid at tool invocation time. A LangServe maintainer confirmed that passing auth tokens through to tools is not supported by default.
Schema discovery and normalization. Google Research characterizes integrating agents with disparate enterprise systems as a people, process, and ecosystem challenge, not a model capability problem.
Structured and unstructured data together. Agents need both database records and PDF documents.
Data freshness. Frameworks operate on whatever is in the index regardless of when it was put there.
Row-level and user-level access controls. Frameworks often default to broad access, which is a core concern for context engineering.

Compliance concerns surface at the same layer. When agents touch customer data, healthcare data, or payment data, teams usually need permission-aware infrastructure that aligns with controls discussed alongside SOC 2, HIPAA, and PCI DSS requirements. The framework may manage orchestration, but the data layer is where auditability, scoped access, and policy enforcement are handled.

How Should You Choose The Right LLM Agent Framework And Data Infrastructure?

Choose based on your primary requirement, then check the tradeoffs that come with it. The framework should match the orchestration pattern, but the data layer should match the operational risk.

Primary Requirement	Recommended Framework	Why	Watch Out For
Explicit control over execution flow	LangGraph	Graph-based state machines with strong debugging and observability support	Steeper learning curve; requires graph thinking
Data-intensive retrieval and knowledge tasks	LlamaIndex	Purpose-built for indexing, querying, and retrieving data	Not a full orchestration engine; limited multi-agent capabilities
Fast multi-agent prototyping	CrewAI	Role-based, team-oriented mental model	Dependency footprint and prompt visibility details are not well-documented
Conversational multi-agent with human oversight	AutoGen / AG2	Flexible conversation-driven workflows with human-in-the-loop	Non-deterministic execution; risk of infinite loops without explicit termination
Minimal framework abstraction	OpenAI Agents SDK or raw LLM APIs	Lowest overhead; start without a framework when possible	Vendor lock-in risk with OpenAI SDK; raw APIs require manual state management
Enterprise data source connectivity at scale	Framework + purpose-built data infrastructure	No single framework handles authentication, schema management, and access controls across dozens of SaaS sources	Requires an infrastructure layer beneath the framework

Choose the framework for orchestration, then evaluate the data layer with the same rigor. Otherwise, teams end up with agents that can plan well but cannot reach the right systems with the right permissions.

What Matters Most When Moving An Agent Into Production?

Choose the framework that matches how your agent needs to operate, whether that means graph-based control, retrieval-heavy querying, conversational coordination, or minimal abstraction. Then evaluate the data layer with the same rigor, because authentication, schema discovery, freshness, and access control are where many production blockers actually appear.

Airbyte's agentic platform provides infrastructure beneath any framework. It offers open-source Python agent connectors, Managed Auth, and row-level and user-level access controls, with connectors designed for direct API access in AI workflows rather than batch replication for warehouse-bound data movement. It exposes connected sources through Agent MCP, so it plugs into whichever framework you choose.

Get a demo to see how Airbyte's agentic platform powers production AI agents with reliable, permission-aware data, or try Airbyte's agentic platform today.

Frequently Asked Questions

Can you use multiple LLM agent frameworks together?

Enterprise architectures can combine frameworks, for example, using LangGraph for complex orchestration workflows and LlamaIndex for data retrieval tasks within the same system. MCP provides a standardized protocol layer that makes multi-framework interoperability more practical, though no structured cross-framework interoperability evaluation exists yet.

When are LLM agent frameworks not required?

Anthropic recommends starting with raw LLM APIs because many patterns can be implemented in a few lines of code. Frameworks add value when you need persistent state, complex tool orchestration, or multi-agent coordination.

How does MCP affect framework selection?

MCP standardizes how agents connect to external tools and data sources. MCP compatibility is becoming more common across major frameworks, which makes it useful as a screening criterion but not enough on its own to choose a framework.

How does LangChain compare with LangGraph?

LangChain is a broad ecosystem for building LLM-powered applications, including chains, retrievers, and tool integrations. LangGraph is a specific library within that ecosystem adding graph-based stateful orchestration with directed graphs and explicit state management, so teams usually choose between breadth of integrations and tighter workflow control.

How do memory and state persistence vary across frameworks?

Frameworks support different memory types that align with the CoALA taxonomy: working memory, episodic memory, semantic memory, and procedural memory. LangGraph uses explicit, typed state objects with reducer functions defined on each state key, CrewAI consolidates memory into a unified Memory class, and AutoGen uses ListMemory injected into agents with external integrations for long-term storage. Those differences matter when recovery, auditability, and long-running agent behavior are important.