What LangChain Actually Automates Once You've Built an Agent Loop

By this point you have assembled an entire agent from raw materials — the loop, memory, tools, sub-agents, hooks — using nothing but the plain Anthropic SDK. No framework in sight.

This is exactly the moment to talk about frameworks, because now something useful happens: since you built the whole mechanism yourself, no framework will ever look mysterious to you again.

The names you keep hearing

LangChain. LangGraph. LlamaIndex. CrewAI. AutoGen. The OpenAI Agents SDK.

Each one comes with its own terminology and its own way of packaging what appears to be the same underlying task. If you are new to this space, the sheer number of options feels overwhelming.

There is one insight that dissolves that confusion:

Every single one of these frameworks is wrapping the same loop you already built earlier in this series.

That's really the entire secret. None of them contain hidden magic. Underneath, they are all running the same sequence: send messages, inspect the stop reason, execute tools, feed the results back in. It's the identical loop you already understand from the inside out.

Picture it like cooking. Once you have learned to prepare a dish starting from raw ingredients, you know every single step, you can taste and adjust along the way, and if something tastes off you know precisely what to change. A framework is closer to a meal kit — the vegetables are already chopped, the sauce is pre-mixed, and you just assemble everything in a few minutes. It's faster, sure. But if that sauce turns out wrong, you have no way to fix it, because you never made it yourself and you don't know what went into it.

That's the bargain every framework offers: you trade some control for extra speed.

Seeing it with your own eyes

Let's look at the same agent implemented twice — once by hand, once through a framework.

Here is roughly what your agent looks like using the raw SDK, the version you now fully understand:

messages = [{"role": "user", "content": user_message}]

while True:
    # call the API — this runs again every time the model asks for a tool
    response = client.messages.create(
        model="claude-sonnet-4-6",
        tools=tools,
        messages=messages,
    )    # if the model is done, stop
    if response.stop_reason == "end_turn":
        break    # otherwise it asked for a tool: run it, append the result, loop again
    messages.append(response_as_message)
    messages.append(tool_result_message)

This is precisely the loop introduced earlier in the series. The API call lives inside a while loop because it fires repeatedly — once for the initial response, then again after every tool result comes back — until the model signals it's finished.

Now compare that with roughly the same agent built in LangChain:

from langchain.agents import create_agent

agent = create_agent(model="claude-sonnet-4-6", tools=tools)
result = agent.invoke({"messages": [user_message]})

Five lines instead of thirty. On the surface, that looks like an obvious improvement.

But notice what vanished. The loop is gone. The check on stop_reason is gone. The manual handling of messages is gone. None of that logic disappeared for real — it still runs, it's just tucked away inside create_agent where you can no longer see it.

When everything goes smoothly, you gained time. When something breaks, you're stuck debugging a process you can't inspect.

That tension is really the whole story behind frameworks. Everything else is just detail layered on top.

What you actually do vs what the framework does

Here's the part that tends to catch people off guard. Once you're using a framework, you never look at stop_reason directly. You never check for a tool_use block. You never manually append a tool_result. You never write the loop at all.

Instead, your job shrinks down to three steps:

1. Write your tool functions, exactly as you would with the raw SDK.
2. Register those functions with the agent through something like create_agent(tools=[...]).
3. Call agent.invoke(...) a single time.

That's the whole workflow. You wire up the tools and trigger the call once.

Behind that single call, the framework is silently running the entire loop you built earlier: sending the messages, checking the stop reason, noticing the model wants a tool, invoking your function, appending the result, looping again, and repeating that cycle until the model finally returns end_turn. Only then does it hand you the finished answer.

So a framework doesn't just hide the loop itself — it hides the entire mechanism that makes tool calling work in the first place. Someone learning agents by starting with a framework wouldn't even know that a stop reason like end_turn exists, or that tool calls are resolved through repeated iterations. To them, it would simply look like "I registered a tool and it got used automatically."

That's fine right up until a tool call starts misbehaving. At that point, you're left staring at a black box, because you never saw the mechanics running underneath. You, by contrast, built that mechanism with your own hands. You know exactly what's happening inside it.

LangChain, LangGraph — what's the difference?

You'll run into both names constantly, so here's the short version.

LangChain is the framework itself. It supplies tool definitions, model connections, and the create_agent call — the same loop-hiding shortcut discussed above.

LangGraph is a lower-level runtime that LangChain sits on top of. You reach for it when you need finer control — pausing an agent so a human can approve a step, coordinating branching logic across multiple agents, or persisting state so a crashed server can pick up exactly where it left off.

A simple mental model: LangChain is the fast, high-level entry point. LangGraph is what you drop down into when that entry point isn't enough. Since late 2025, LangChain has been rebuilt on top of LangGraph, so the two aren't rival tools anymore — they're two layers of a single system, one simple and one powerful.

If you're just getting started, you probably don't need either yet. The raw SDK you already understand can carry you surprisingly far.

When a framework helps

Frameworks aren't inherently a trap. In some situations, reaching for one is genuinely the right move.

You need ready-made integrations. Suppose your agent has to pull records from a Pinecone vector store and pull documents from Google Drive. Writing both connectors yourself in the raw SDK is doable but tedious. LangChain ships with them already built — you just import and wire them up. That's real time saved.

You're prototyping under a deadline. Your manager wants a working demo tomorrow morning. At that point the internals don't matter yet — you just need something functional fast. A five-line setup can get you there tonight.

You need orchestration that's genuinely complex to build. Picture an agent that pauses mid-task, waits for someone to click "approve" before releasing a payment, and then resumes exactly where it stopped — even after a server restart. Certain frameworks provide this behavior out of the box. Recreating it from scratch is a substantial engineering effort.

When a framework hurts

Debugging becomes painful. Imagine your agent occasionally returns an empty response and you can't tell why. In code you wrote yourself, you'd drop in a print statement, trace the loop, and find the issue within minutes. Inside a framework, that same bug lives somewhere inside create_agent — code that isn't yours. You end up digging through the framework's source on GitHub just to understand what your own agent is doing.

The abstraction starts to leak. Frameworks are optimized for the common case. Say you need tool output formatted in a nonstandard way, or a retry policy tailored to your specific setup. The framework never anticipated that. Now you're bolting on awkward workarounds just to coerce it into doing something thirty lines of your own code would have handled directly.

You end up learning the tool instead of the concept. Starting with a framework teaches you "how LangChain works," not how agents actually function. Then LangChain's API shifts — which it has, repeatedly — and your knowledge goes stale overnight. The loop covered earlier in this series hasn't changed since agents were first built, and it isn't going to.

The rule worth following

Start with the raw SDK. Build the loop by hand. That way you know precisely what your agent is doing and can trace every line when something breaks. For the majority of agents, that's genuinely all you'll ever need.

Bring in a framework only when it solves something specific better than you could — a ready-made integration, state that survives a crash, human-in-the-loop approval steps. Use it deliberately, for that exact reason, not as a default.

Don't reach for a framework just to skip learning the loop. That's the real trap. Skip that step and you end up with a black box built on ideas you never actually absorbed.

Understand the loop first. After that, a framework becomes a tool you choose on purpose — not a crutch you lean on because you never learned the fundamentals.

Why this series built everything from scratch

This is exactly the reasoning behind holding off on frameworks until now.

Had this series opened with "install LangChain, call create_agent," you'd have a working agent and no real understanding of it. You wouldn't know what a tool_use block is, why results from parallel tool calls get bundled into a single message, or why authorization logic belongs in a hook.

Now that groundwork is already yours, so any framework's vocabulary translates instantly. Whatever it calls its "agent" is really just the same loop underneath. Whatever it calls "memory" is nothing more than the running list of messages you already know. What it labels "tools" map straight onto the tool_use blocks you've been handling by hand. And what it markets as "middleware" is just another name for the hooks you built yourself.

That's the position worth being in. Not "I know LangChain" — but "I understand how agents work, and LangChain is just one way of expressing that."

Frameworks will keep evolving. New ones show up every few months. The loop underneath stays constant. Build your understanding on the part that doesn't change.