What is a LangChain agent, and how is it used in NLP?

What you need to know

Chain versus agent

A chain is a fixed pipeline: prompt, then model, then parser, always in that order. An agent is a loop where the model picks the next step. That one difference drives everything else.

How the loop works

1. Bind tools — each tool's name, description and argument schema is sent to the model as JSON.
2. Call the model — it returns either plain text (the answer) or one or more tool calls.
3. Run the tools — the runtime executes each call and adds the result as a ToolMessage.
4. Repeat — the model sees the results and decides again, until it answers or a limit stops it.

This uses the model's native tool calling (also called function calling): the model returns structured JSON arguments, not free text that has to be parsed.

The current API

1from langchain.agents import create_agent2from langchain.tools import tool34@tool5def get_order_status(order_id: str) -> str:6    """Return the delivery status of an order, e.g. 'ORD-1042'."""7    return orders_db.status(order_id)89agent = create_agent(10    model=settings.chat_model,     # e.g. "provider:model-name", kept in config11    tools=[get_order_status],12    system_prompt="You are a support agent. Use tools for facts; never guess.",13)14result = agent.invoke(15    {"messages": [{"role": "user", "content": "Where is ORD-1042?"}]}16)17print(result["messages"][-1].content)

create_agent (LangChain 1.0 and later) returns a compiled LangGraph graph. The result is the full message list: the question, the tool call, the tool result and the final answer. The older initialize_agent and AgentExecutor APIs now live in the langchain-classic package and are legacy.

Where agents are used in NLP

• Question answering over live systems — "Is my refund processed?" needs a database lookup, not just text.
• Research assistants — search, read, search again, then summarise.
• Support flows — the lookup needed depends on what the customer asked.
• Text-to-SQL analytics — the model writes a query, reads the result, and fixes the query if it failed.

When not to use one

If every request follows the same steps — retrieve five chunks, answer — use a chain. It is one model call, easy to test, and cheaper. Use an agent only when the branching really cannot be listed in advance.

A real-life example

An electronics store in Bengaluru runs a product Q&A assistant. Most questions ("What is the warranty on the X200 laptop?") are answered from the product pages with a simple retrieval chain: one model call, about 1.5 seconds.

Some questions are different: "Is the X200 in stock at the Koramangala store, and can it reach 560034 by Friday?" This needs two lookups — stock, then delivery estimate — and the second depends on the first. The team routes only these to an agent with three tools: check_stock, estimate_delivery and search_catalogue. The agent makes 3 model calls and takes about 4 seconds, but it answers questions the chain simply could not. About 15% of traffic goes to the agent; the rest stays on the cheap chain.

Follow-up questions to expect

• "What is the difference between an agent and a chain?" — A chain's steps are fixed in code; an agent's model chooses the steps at run time in a loop.
• "What stops an agent from looping forever?" — Limits: ModelCallLimitMiddleware or ToolCallLimitMiddleware in create_agent, or a recursion_limit in the run config. Always set one.
• "Is AgentExecutor still used?" — It is legacy, kept in langchain-classic. New code uses create_agent, which adds persistence, streaming and human-in-the-loop.