Agent frameworks & orchestration: the landscape, conceptually.
This entry maps the framework and orchestration layer — LangChain, LlamaIndex, provider agent SDKs, and the broader category — at the level of what problems they solve rather than API tutorials. You will leave able to reason about whether you need a framework at all, what category a given tool belongs to, and what stays true even as specific libraries rise and fall.
What a framework is actually for.
Calling a model API is a few lines of code. The hard parts of an agentic system are everything around the call: managing the multi-step loop, wiring tools and validating their arguments, assembling and trimming context, retrieval, persisting memory, retries and error handling, streaming, tracing, and evaluation. A framework is a set of pre-built abstractions for some subset of these. It does not give the model new capabilities — it manages the plumbing so you do not rebuild it per project.
The honest baseline: for a simple single-step or short-loop application, a thin layer of your own code over the raw API is often clearer, easier to debug, and has fewer moving parts than any framework. Frameworks earn their keep when the orchestration genuinely gets complex. "Do I even need one?" is a legitimate first question, not a heresy.
The categories, not the brands.
Specific libraries churn fast; the categories are stable. Place any tool you encounter into one of these.
General agent / orchestration frameworks
Broad toolkits for chaining model calls, tools, memory, and control flow into agents and multi-agent systems. LangChain (with its graph-based orchestration companion) is the most widely known; others in this space offer multi-agent role abstractions or lower-level composability. They are most valuable when you have a complex, branching, stateful workflow and want batteries-included building blocks plus an ecosystem of integrations.
Data / retrieval-centric frameworks
LlamaIndex is the prototypical example: the center of gravity is connecting models to your data — ingestion, indexing, retrieval, and retrieval-augmented generation — with agent features built around that core. Reach for this category when your problem is fundamentally "answer over my documents/knowledge," not "run a long autonomous loop."
Provider / first-party agent SDKs
Model providers ship their own lighter-weight agent SDKs and tool/loop primitives, tightly aligned with their API features (tool use, structured output, reasoning controls). These minimize abstraction distance from the model and track provider features closely, at the cost of being provider-flavored.
Cross-cutting infrastructure
Observability/tracing, evaluation, prompt management, and gateways are a separate layer that complements any framework. Plus emerging interop standards for connecting models to tools and other agents — increasingly the substrate frameworks build on rather than reinvent. (Protocols are covered in the Deep-Dives section.)
How to evaluate one without the hype.
- Abstraction tax. Every abstraction you do not need is a layer to learn, debug, and work around when it does not fit. Favor frameworks whose abstractions match your actual control flow.
- Escape hatches. Can you drop to the raw model call when the framework's path is wrong? Frameworks without a clean escape hatch become a ceiling.
- Observability. Multi-step agents fail in non-obvious ways. First-class tracing of every step, prompt, and tool call is not optional at production scale.
- Lock-in surface. How much of your code would change to swap the framework or the underlying model? Keep that surface small and explicit.
- Maturity vs churn. This layer moves faster than the model layer. APIs break between versions; pin versions and budget for migration.
Adopting a framework does not de-risk an agent — it relocates the risk into a dependency that moves faster than your model provider. The reliability of an agent comes from its evaluation harness and its control-flow design, not from which framework wraps the model call.
The durable takeaway.
Frameworks are accelerants, not architecture. The decisions that determine whether your agent works — what the loop looks like, how context is managed, how tools are validated, how you evaluate it — are yours regardless of the library. Choose the lightest tool that removes real plumbing you would otherwise hand-write, keep the model call and your control flow inspectable, and treat the framework as swappable. Teams that stay productive across the churn are the ones who kept their architecture independent of any single framework's worldview.