DEV Community: Godspower Anthony-Ikpe

Another way to use tool calling: intent classification

Godspower Anthony-Ikpe — Thu, 21 May 2026 02:03:58 +0000

Tool calling is one of those LangChain features that looks simple on the surface — give the LLM a function, it decides when to call it, it returns the result. Most tutorials stop there.

But there's a more powerful way to use it. One that doesn't involve the LLM calling any function at all.

In IhuSale — my AI SaaS for Instagram vendors — I use tool calling not to fetch data, but to classify intent. The LLM reads the schemas, picks a tool, and returns structured data. My code does the routing and execution. The result is a classification system reliable enough to run in production.

Here's how it works.

The problem with plain text classification

The naive approach to intent classification is to ask the LLM a question and read the answer:

response = llm.invoke("What is the intent of this message: 'I want to buy rice'")
# Returns: "order", "ORDER", "place_order", "purchase intent", ...

The LLM is smart enough to understand the message. The problem is the output. You get unpredictable strings — different capitalizations, different phrasings, edge cases you didn't anticipate. Now you're writing brittle string matching logic to interpret the interpreter.

Tool calling solves this cleanly.

The insight: define intents as tools

Instead of asking the LLM "what is the intent?", you define each intent as a tool with a schema. The LLM is forced to pick one and fill in its fields. It cannot return something malformed — the structure is the output.

from langchain_core.tools import tool

@tool
def handle_order(product_name: str, quantity: int) -> dict:
    """Customer wants to place an order for a product."""
    pass

@tool
def handle_inquiry(question: str) -> dict:
    """Customer is asking a general question about a product."""
    pass

@tool
def handle_complaint(issue: str) -> dict:
    """Customer is reporting a problem with an order."""
    pass

@tool
def handle_greeting(message: str) -> dict:
    """Customer is sending a greeting or starting a conversation."""
    pass

The function bodies are empty. The LLM never executes them. It only reads the signatures and docstrings — which LangChain serializes into JSON schema and sends with the API request. The tool is serving two purposes: a schema guide for the LLM, and a source of tool_name and tool_args you extract from the response.

The pipeline: model → tools → classifier → handler

Think of it like this. You're a manager. You hire a smart assistant — the LLM — and hand them a sheet of paper listing four intents with descriptions. When a customer message comes in, the assistant reads it, picks the right bucket, and fills in the relevant details. They hand the sheet back to you. You run the code.

In practice, that's four components:

Models — define the shape of data per intent. Two kinds: intent models that describe what fields belong to which intent, and request/response models for the API layer.

Tools — teach the LLM what intents exist. When you call llm.bind_tools(ALL_TOOLS), LangChain serializes those function signatures and docstrings into JSON schema that gets sent to the model in every API request.

Classifier — chains the prompt and LLM together, calls it with the customer message, and reads the response. The response comes back with a tool_calls field — the LLM saying: "I picked handle_order and here are the args: {product_name: 'rice', quantity: 2}." The classifier pulls out tool_name and tool_args. It doesn't execute anything.

ALL_TOOLS = [handle_order, handle_inquiry, handle_complaint, handle_greeting]

llm = ChatAnthropic(model="claude-3-5-sonnet-20241022")
classifier_llm = llm.bind_tools(ALL_TOOLS, tool_choice="any")

prompt = ChatPromptTemplate.from_messages([
    ("system", "Classify the customer message and extract relevant data."),
    ("human", "{message}")
])

chain = prompt | classifier_llm
response = chain.invoke({"message": "I want to buy 2 bags of rice"})

tool_name = response.tool_calls[0]["name"]
tool_args = response.tool_calls[0]["args"]
# tool_name = "handle_order"
# tool_args = {"product_name": "rice", "quantity": 2}

tool_choice="any" is the constraint that makes this work. It forces the LLM to always pick a tool — it cannot return a plain text response. Without this, the model might occasionally just answer the question instead of classifying it.

Handler — one function per intent. The classifier passes tool_args into the matching handler, and the handler constructs the final response — a suggested reply, an escalation flag, whatever the intent requires.

handlers = {
    "handle_order": handle_order_handler,
    "handle_inquiry": handle_inquiry_handler,
    "handle_complaint": handle_complaint_handler,
    "handle_greeting": handle_greeting_handler,
}

handler = handlers[tool_name]
result = handler(tool_args)

The full flow in five steps

Receive customer message
Ask LLM: which bucket does this fall into?
LLM says: "Bucket 3 — handle_order — here's the extracted data"
Run the handler for bucket 3
Return response

The LLM never runs any Python function. It reads schemas, makes a decision, and returns a structured JSON object. Your code does the routing and execution.

This pattern is used in production not because tool calling is fancy, but because it makes the LLM predictable. And predictable is what you need when you're routing to handlers, building graphs in LangGraph, or processing Instagram DMs at scale.

Next: LangGraph — what happens when your AI needs to remember where it left off across multiple messages.

LangChain fundamentals part 2: structured outputs and tool calling

Godspower Anthony-Ikpe — Fri, 01 May 2026 00:39:48 +0000

This is where LangChain stops being a convenience layer and starts becoming genuinely powerful.

If you missed part 1, start there — it covers the Runnable protocol and LCEL, the mental model everything else builds on.

Concept 4 — structured outputs

Raw LLM responses are strings. Real applications need JSON — predictable, parseable, typed data your code can actually work with.

LangChain gives you two approaches. The more reliable one is .with_structured_output(), which uses your Pydantic model to constrain what the LLM returns.

from langchain_anthropic import ChatAnthropic
from langchain_core.pydantic_v1 import BaseModel, Field
from typing import List

class CodeReview(BaseModel):
    issues: List[str] = Field(description="List of code issues found")
    severity: str = Field(description="low, medium, or high")
    refactored_snippet: str = Field(description="Improved version of the code")

llm = ChatAnthropic(model="claude-3-5-sonnet-20241022")
structured_llm = llm.with_structured_output(CodeReview)

result = structured_llm.invoke("Review this code: for i in range(len(items)): print(items[i])")
print(result.issues)
print(result.severity)

The Pydantic field descriptions are not just documentation — the LLM reads them to understand what each field should contain. Write them like instructions, not labels.

The alternative is PydanticOutputParser, which asks the LLM to format its response as JSON then parses it. It works, but .with_structured_output() is more consistent in production — use that by default.

Concept 5 — tool calling

Tool calling is the bridge to agents. It lets the LLM decide at runtime which Python functions to call based on the user's intent — and when to call them.

A tool is just a Python function decorated with @tool:

from langchain_core.tools import tool

@tool
def get_contact(email: str) -> dict:
    """Fetch a CRM contact by email address.

    Use this when the user wants to look up, retrieve, or find
    information about a specific contact using their email.
    """
    return db.query("SELECT * FROM contacts WHERE email = ?", email)

llm = ChatAnthropic(model="claude-3-5-sonnet-20241022")
llm_with_tools = llm.bind_tools([get_contact])

response = llm_with_tools.invoke(
    "Look up admin@example.com and tell me if they've shown interest in the product"
)
print(response)

The @tool decorator reads your docstring and type hints to generate the tool schema automatically. The LLM uses that schema to decide when and how to call the tool. Write good docstrings — they are not optional documentation, they are instructions the model actually reads.

That example is pulled from something I actually built — a CRM integration where the agent looks up contacts and updates their interest flags based on conversation context. The docstring is what makes the LLM call the right tool at the right moment.

Why this all fits together

Structured outputs give you reliable data extraction from unstructured language. Tool calling gives the LLM agency to act on your systems. Put them together and you have the foundation for any serious AI feature — automated pipelines, conversational agents, multi-step workflows.

And because everything is still a Runnable, it all chains together with | the same way you learned in part 1.

Next: LangGraph — when your LLM needs to make decisions across multiple steps, loop back, and maintain state. That's where single chains stop being enough.

LangChain fundamentals: the mental model that makes everything click

Godspower Anthony-Ikpe — Fri, 01 May 2026 00:31:09 +0000

Before you touch agents or RAG pipelines, you need to understand one pattern. Everything else builds on it.

The problem LangChain solves

Most LLM applications share the same structural patterns — connect a prompt to a model, parse the output, pass it somewhere else. Without a framework, you end up reinventing that plumbing on every project.

LangChain standardizes those patterns. It gives you modular components that work across different model providers — OpenAI, Anthropic, Gemini — and slot together predictably. The key is understanding how they slot together.

One pattern to rule them all

Everything in LangChain follows a single pattern:

Input → Runnable → Output

Every component — prompt templates, models, retrievers, output parsers, chains — is a Runnable. And because they all share the same interface, they can be chained together using the pipe operator |.

This is called LCEL — LangChain Expression Language. Once this clicks, the rest of LangChain becomes intuitive.

Concept 1 — the Runnable protocol

Every object in LangChain implements three methods:

runnable.invoke(input)     # single input, single output
runnable.stream(input)     # yields chunks as they arrive
runnable.batch([inputs])   # multiple inputs in parallel

Because every component shares this interface, you can swap components in and out without rewriting your chain.

Concept 2 — prompt templates

Forget f-strings. Prompt templates are composable, testable, and serializable — and because they're Runnables, you can .invoke() them directly.

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a senior {role}. Be concise and precise."),
    ("human", "{question}")
])

formatted = prompt.invoke({
    "role": "backend engineer",
    "question": "What is a connection pool?"
})
print(formatted)

The template is already a Runnable — which means it can plug directly into a chain using | without any wrapping or conversion.

Concept 3 — LCEL and the pipe operator

The | operator chains Runnables left to right. The output of each step becomes the input of the next.

from langchain_anthropic import ChatAnthropic
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate

llm = ChatAnthropic(model="claude-3-5-sonnet-20241022")

chain = (
    ChatPromptTemplate.from_messages([
        ("system", "You are a senior software engineer."),
        ("human", "{question}")
    ])
    | llm
    | StrOutputParser()
)

response = chain.invoke({"question": "Explain connection pooling in one paragraph."})
print(response)

Three Runnables. One pipe. The prompt formats the input, the model generates a response, the parser extracts the text string. That's the full pattern.

Next in this series: structured outputs with Pydantic and tool calling — where LangChain stops being a convenience layer and starts becoming genuinely powerful. Read part 2 →