# LLM Frameworks: Raw SDK, LangChain, LangGraph and Agent SDKs

> What each layer of the LLM tooling stack gives you, what it costs in complexity, and how to choose for a project.

- Source: https://akshaythakare.com/notes/ai-tools/llm-frameworks-landscape
- Topic: AI Tools
- Level: intermediate
- Reading time: 2 min
- Tags: ai-tools, langchain, langgraph, agents, architecture
- Updated: 2026-10-11

## The layers

| Layer | Gives you | Cost |
| --- | --- | --- |
| **Provider SDK** (direct API) | Full control, fewest surprises | You write retries, tool loops and state yourself |
| **Component libraries** (e.g. LangChain) | Integrations: loaders, vector stores, model wrappers | Abstractions to learn; version churn |
| **Graph / workflow frameworks** (e.g. LangGraph) | Explicit state machines, checkpoints, human-in-the-loop | More structure to design |
| **Agent SDKs** from model providers | Tool loops, handoffs, tracing out of the box | Tied to one ecosystem's conventions |

## How to choose

- A single call or a simple RAG endpoint: the **provider SDK** is often clearest.
- Many integrations (loaders, stores) you would otherwise write: a **component library**.
- Multi-step workflows that must resume, branch and pause for approval: a **graph framework**.
- Tool-using agents where built-in tracing and handoffs fit your needs: an **agent SDK**.

## Keep your core logic portable

Put prompts, tool functions and business rules in your own modules. Let the framework call them. Then switching frameworks, or removing one, is a contained change.

```python
# your code: framework-independent
def lookup_order(order_id: str) -> dict: ...

# thin adapter for whichever framework you use
tools = [as_framework_tool(lookup_order)]
```

> **Tip: Interview framing**
>
> "I start with the plainest option that works, add a framework when it removes real code I would otherwise write, and keep tools and prompts in framework-independent modules."