LangGraph vs CrewAI vs Raw Tool Calling

Most of the "agents" I've been paid to build this year are one model call, three tools, and a retry. That's not a criticism of the products. They work, and clients are happy. It's an observation about how much framework that requires, which is none.

So I'm going to defend raw tool calling as the correct default and make the frameworks argue their way in. They can, in specific cases. Just fewer than the marketing suggests.

What raw tool calling actually is

A while loop.

You send messages and tool definitions to the provider SDK. If the response contains tool calls, you execute them, append the results, and loop. If it contains a final answer, you return it. Add a max-iteration guard so a confused model can't spin forever, and log every turn.

That's roughly 100 lines including error handling. I can read all of it. When something goes wrong I set a breakpoint in my own code, not in a framework's callback manager. There is no version of the framework that changed its retry semantics under me.

The reason this is a good default isn't purity. Debugging agents is the hard part of the work, and when one does something stupid you need the exact messages that produced it. Frameworks that assemble those messages for you hide the one thing you need to read.

What LangGraph gives you

LangGraph is the framework I take seriously, because it's honest about what it is: a state machine. You declare nodes, edges, and conditional transitions over a typed state object, and the graph runs.

What you actually buy:

Checkpointing and durable resumption. The graph persists state after each node. If the process dies at step 7 of 12, you resume from step 7 instead of paying for the first six model calls again. If your workflow runs for minutes and costs real money per run, this is worth a lot.

Human-in-the-loop. Pause at a node, wait for a decision that might arrive tomorrow, resume with that input. Building it yourself means designing a state store and a resumption protocol, which is exactly what LangGraph already did.

Explicit control flow. For genuinely branching workflows, where this document type goes down that path and that validation failure loops back to the extraction step, a declared graph is more readable than nested conditionals. You can draw it. You can hand the drawing to a client.

The cost is real. You write in the framework's mental model, and debugging becomes reading state transitions rather than reading code. LangChain-adjacent packages churn fast enough that I pin versions hard and budget for upgrade work.

What CrewAI gives you

CrewAI's pitch is the role metaphor: a Researcher agent, a Writer agent, a Reviewer agent, given goals and backstories, collaborating on a task.

It demos beautifully, and that's the honest core of it. You get something impressive running in under an hour, and for a proof of concept or an internal tool where a wrong answer is a shrug, that's genuine value.

In production I've found the control too weak. When a crew produces a bad result, the failure is distributed across agents delegating to each other in ways you didn't specify and can't easily inspect. You end up tuning backstories, which is not engineering. It's writing character notes and hoping.

The cost problem is the one I'd flag to any client. Three agents talking to each other is not three calls. It's each agent taking multiple turns over context that grows with every exchange. I've watched a task that one well-prompted call handled for a fraction of a cent become a multi-agent run costing an order of magnitude more, for output that wasn't better. The bill scales with the conversation, not the task.

When multi-agent is real

Multi-agent is a genuine architecture when the sub-tasks have different tools, different context, or different trust levels. A retrieval agent that can read customer documents and a drafting agent that can't. A code-writing step and a separate reviewing step where reviewer independence is the point. A router that dispatches to specialists with genuinely disjoint tool sets.

That's architecture. What isn't: splitting a linear pipeline into "agents" that hand off in a fixed order. If your agents always run A then B then C, you have a script, and you should write a script.

I'd guess three quarters of the multi-agent systems I've reviewed this year were sequential pipelines wearing a costume.

The one I got wrong

Early in my freelance year I took a document-processing project: extract structured data from uploaded PDFs, validate it, flag anomalies for review. I built it as a CrewAI crew because the client had read about multi-agent systems and I wanted the project.

It worked in the demo. In production, results were inconsistent in ways I couldn't trace, and the per-document cost was several times my estimate. I'd quoted a fixed price. I rebuilt it in about three days as a plain loop with four tools and one validation step. It ran cheaper, and I could explain a wrong output when the client asked.

Those three days came out of my margin, on a project around the $6,000 mark. The lesson wasn't about CrewAI specifically. It was that I let the client's vocabulary choose my architecture, which is a mistake I'd never make about a database and somehow made about this.

What I pick now

Chatbot with tools, single conversation — raw tool calling, the way I'd build any chatbot. A framework here is pure overhead, and this is most of the work.

Long-running workflow with expensive steps, or one that needs human approval mid-flight — LangGraph. Checkpointing and interrupts are the real product and reimplementing them is a month.

Internal tool, exploratory, wrong answers are cheap — CrewAI is fine, and fast. Ship it, learn what you actually need, expect to rewrite.

Client work you'll maintain for two years — raw, plus small libraries you chose deliberately. This ecosystem's churn is brutal, and every dependency is a future upgrade you'll do unpaid.

Start with the loop. Ship it, and let a specific pain (resumption, approval gates, branching you can no longer read) tell you which framework to adopt. Adopting one before that pain exists means paying the abstraction cost for a problem you don't have yet, and in this ecosystem you'll pay it again at every minor version. Most of what makes an agent good is the same unglamorous production discipline any LLM feature needs: pinned models, validated output, logs of every turn. No framework sells you that.