Agent frameworks are a prototyping tool, not an architecture
LangChain, LangGraph, AutoGen and the rest get you to a working demo fast. What they do not give you is an operable system — and the gap between those two things is where most agent projects stall.
There is a moment in most agent projects where the framework stops helping.
It usually arrives about six weeks in. The demo works. Someone asks what happens when the third tool call times out, whether the run can be resumed, how much a single request costs, and who gets paged when it goes wrong. The answers are not in the framework.
What frameworks give you
They give you the fast parts: a tool-calling loop, a memory abstraction, prebuilt integrations, and a graph or chain structure you can reason about. That is genuinely useful and it is why every team starts there.
What they do not give you
- Durable state. An agent run that dies at step 7 of 12 should be resumable. Most in-memory abstractions cannot do this.
- Cost and latency budgets per run, enforced rather than observed after the fact.
- A replay story. When a run produces a wrong answer, can you reconstruct exactly what the model saw?
- Idempotency on tool calls. Retrying a search is free. Retrying a write is not.
- A permission boundary between what the agent can propose and what it can actually do.
The architecture that usually emerges
Once teams hit that wall, the shape they converge on looks less like a framework and more like a workflow engine: a durable queue, a state store, typed tool contracts, and the LLM call as one step among many rather than the centre of the system.
Keep the framework where it is strong — rapid iteration on the reasoning loop. Put the operational concerns in infrastructure that was designed for them. The teams that ship are the ones that make that split early, rather than trying to make the framework do a job it was never built for.