A language model on its own is well-read and completely powerless. Ask it to refund an order, check stock levels, or file a ticket and you get a beautifully worded paragraph explaining how such a thing might be done. LangChain AI agents exist to close the gap between describing an action and taking one. The framework’s real value sits in the plumbing wrapped around the loop, not in the loop itself.
What actually turns a model into an agent
The difference is a loop. The model receives a task, chooses an action, the framework executes that action against a real system, the result comes back, and the model decides again. Repeat until it returns a final answer or hits a step limit. That is the whole idea. The reasoning-and-acting loop that turns models into doers breaks down the mechanics, but the practical consequence matters more: the model never touches your database. It asks. Your code decides whether to allow the request, and your code does the work.
LangChain’s contribution is standardising the dull parts. Tool schemas get generated from Python or TypeScript function signatures. Message history is formatted for whichever provider you’re using. Retries, callbacks, and streaming are handled once rather than in every project. Before LangChain, wiring a model to three APIs meant writing the same glue code for the fourth time.
The four parts you actually configure
Strip away the abstractions and an agent is four things bolted together.
- The model. Usually a chat model with tool-calling support, though you can run a text-completion model with a ReAct-style prompt if you enjoy extra failure modes.
- The tools. Ordinary functions with names, descriptions, and typed arguments. A search tool, a SQL query tool, a ticket-creation endpoint, a calculator that isn’t the model’s own arithmetic.
- The prompt. System instructions, tool descriptions, and whatever scratchpad format the agent expects. This is where most quality lives.
- The loop controller. The piece that decides when to stop, how many steps to allow, and what to do when a tool throws.
Tools are consistently the weakest link. A tool that returns a 2,000-row JSON dump will flood the context window, push out the original instructions, and produce confused behaviour on the next turn. Tools should return summaries, not exports. A weather tool returning 18C, light rain, wind 12km/h beats one returning a full meteorological payload nine times out of ten.
Chains, executors, and where LangGraph fits
The classic setup pairs a prompt, a model, and a tool list inside an AgentExecutor. You set a step ceiling, typically somewhere between 5 and 15 for customer-facing work, and pick an early-stopping behaviour. That structure covers a surprising number of use cases: research assistants, internal lookup bots, simple triage.
LangGraph is the answer when your agent needs to remember where it was. It models the workflow as a state machine with explicit nodes and edges, persists checkpoints, and lets a run pause mid-flight for human approval and resume hours later with full context. If your support agent refunds anything over £200 only after a human clicks approve, and that approval might arrive tomorrow morning, you want the graph version rather than an executor holding state in memory.
Some of the ambition here is about interfaces, not internals. The pitch that has agents gradually replacing chunks of the mobile app stack only works if tool calls are reliable, which is why the next few sections are about failure rather than features.
A build path that survives contact with reality
Resist the urge to build a general assistant. Pick one job, give the agent two or three tools, and get the success rate above 90% on real inputs before adding anything. A document question-and-answer bot is a good first project because the tool surface is tiny and the failure modes are obvious — this seven-step LangChain document Q&A walkthrough covers the retrieval wiring without drowning you in framework trivia.
Language choice matters less than people expect. The Python ecosystem has more examples and research code; the JavaScript version has caught up enough for production work, and putting the agent in the same process as your web app removes a network hop and a deployment. There’s a solid argument for building agents in JavaScript if the rest of your stack already lives there.
The failures you’ll actually hit
Loop thrash
The agent calls the same tool with the same arguments three times and gets the same answer three times. Add argument-based deduplication and a hard step cap. Log every step with its arguments so you can spot the pattern in a trace instead of guessing.
Swallowed tool errors
A Python exception inside a tool often surfaces to the model as a string that reads like a successful result. Return structured errors instead — {status: error, reason: rate_limited, retry_after: 30} — so the model can choose a different path rather than confidently reporting that it booked the meeting.
Context bloat
Every tool result joins the message history. Ten steps in, you’re paying for a conversation where 80% of the tokens are stale tool output. Trim old results, keep the last few in full, and summarise the rest.
Cost drift
A single runaway loop against a large model can burn more budget than a normal day of traffic. Set per-run token and spend ceilings, and alert on p95 steps per task rather than average.
Guardrails that pay for themselves
Split tools into read and write categories and require explicit authorisation for the second group. Idempotency keys prevent double refunds when a retry fires. Allowlists on database queries stop the model from inventing a DROP statement. Approval queues handle the genuinely irreversible stuff, and they’re worth designing early — this support triage agent walkthrough shows the routing-plus-escalation pattern in a different framework, and the shape of it transfers directly.
Then measure what matters. Freeze 50 real requests and score task success by hand each time you change a prompt or a tool description. Track median steps per task, tool error rate, p95 latency, and cost per completed task. An agent succeeding 85% of the time is fine for suggesting a help article and unacceptable for issuing refunds; knowing which one you’ve built is half the engineering work.
When an agent is the wrong answer
If you can draw the flowchart on a napkin, write the flowchart. Deterministic pipelines are cheaper, faster, testable, and won’t invent a step. Extract the fields, validate them, call the API, format the response. An agent earns its place only when the sequence genuinely depends on what the previous step returned — when the number of steps and the choice of tool can’t be known in advance.
That line moves as models improve, but it hasn’t moved past the point where most teams should ask the question first. The projects that go well tend to start with a chain, hit its limits on a specific task, and add agency exactly where the branching lives. The ones that go badly start with a general-purpose agent and spend six months discovering that the hard part was never the framework.