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.