Chapter 1: Introduction to AI agents and applications

Introduction

The introduction describes what LLM applications and agents can do and why frameworks help developers build them.

• LLM applications and agents: Distinguish the described uses of LLMs from the role of AI agents: LLM applications can answer questions, generate content, and summarize documents, while agents take natural-language input, choose tools or services, coordinate multi-step work, and return readable results.
  Why it matters: This distinction frames the kinds of applications and agents the book goes on to build.
• Application complexity and framework benefits: Explain the integration challenges named for AI applications and agents, and why modular frameworks help developers address them.
  Why it matters: It explains why the book uses frameworks rather than treating an LLM call as the whole application.

Key terms: large language models (LLMs), AI agents, tools or services, multi-step workflows, ingest and manage data, structure prompts, chain model calls, external APIs and services, modular building blocks, boilerplate

1.1 Building LLM-based applications and agents

The section explains the common shape of LLM applications and distinguishes bounded engines, conversational chatbots, and action-taking agents.

• Natural language capabilities: Explain how LLMs’ ability to understand, generate, and extract information from text supports uses such as summarization, translation, sentiment analysis, search, chatbots, and code generation.
  Why it matters: These capabilities explain why the same underlying technology appears in many kinds of applications.
• Common application pattern: Describe the high-level pattern shared by many LLM applications: taking natural-language input, working with unstructured data, gathering additional context, and putting it into a prompt for the model.
  Why it matters: This shared pattern helps you recognize what different LLM applications have in common.
• Engine chatbot agent distinctions: Distinguish a bounded LLM engine from a context-maintaining chatbot and an agent that uses an LLM to choose actions and carry out multi-step work. Explain that an agent can adjust its next step using intermediate results rather than stopping after one output.
  Why it matters: The distinction clarifies when a system is simply producing an answer, holding a dialogue, or pursuing a goal through actions.

Key terms: natural language, summarization, translation, sentiment analysis, semantic search, code generation, natural language input, unstructured data, extra context, prompt

1.1.1 LLM-based applications: Summarization and Q&A engines

This section explains how backend LLM applications summarize text, answer questions using retrieved knowledge, and run predefined workflows rather than managing them like agents.

• Summarization as a backend service: Describe how a summarization engine serves other systems by condensing long text and returning or storing the result.
  Why it matters: It shows what an LLM application can provide to other software without being a chatbot.
• Knowledge base ingestion and embeddings: Trace how a Q&A engine prepares text for retrieval, and explain what embeddings represent at the level introduced here.
  Why it matters: This preparation is what lets the Q&A engine find relevant source text when a question arrives.
• Question answering through RAG: Trace how a Q&A engine uses a question and retrieved chunks to generate an answer, and explain why this is called Retrieval-Augmented Generation.
  Why it matters: Retrieved context can ground an answer in relevant information, though it does not guarantee accuracy.
• Predefined engines versus adaptive agents: Distinguish an engine’s predefined workflow from an agent’s runtime decisions, including how an engine may use external tools.
  Why it matters: The distinction helps you recognize whether the workflow or the LLM is making the decisions.

Key terms: LLM-based application, summarization engine, shared services, REST API, content ingestion, chunks, embeddings, vector store, query phase, semantic search

1.1.2 LLM-based chatbots

This section explains how LLM-based chatbots use dialogue, instructions, factual context, and conversation history to provide useful responses that users can refine.

• Interactive chatbot experience: Distinguish a summarization chatbot from a basic summarization engine: the chatbot supports back-and-forth requests that refine an answer, such as making a summary shorter or more casual.
  Why it matters: It explains why a chatbot is more than an engine with a chat interface.
• Instructions and message roles: Explain how clear prompts and role-based messages help shape a chatbot’s behavior across a conversation.
  Why it matters: The way a conversation is instructed and structured affects how consistently the chatbot responds.
• Factual context for answers: Describe why a chatbot may draw on a local knowledge source rather than relying only on conversational fluency.
  Why it matters: A fluent answer is more useful when it is grounded in relevant facts.
• Conversation memory and limits: Explain how tracking earlier turns helps a chatbot and why systems may compress or summarize that history.
  Why it matters: Remembering prior turns makes follow-ups work, but that history cannot grow without limit.

Key terms: summarization chatbot, summarization engine, interactivity, prompt design, role-based messaging formats, system, user, assistant, factual context, local knowledge sources

1.1.3 AI agents

This section explains how AI agents use LLM-guided tool choices to complete multi-step tasks, illustrated by holiday planning, and introduces oversight and MCP-based tool access.

• Agent autonomy and constraints: Distinguish an AI agent from a simple pipeline: it works with an LLM on multi-step tasks and can choose what to do next while following developer-set constraints.
  Why it matters: This distinction explains why an agent is useful for tasks whose next step depends on what happens along the way.
• LLM guided tool cycle: Trace how the agent consults the LLM about tools, executes the selected queries, returns results to the LLM, and may repeat this cycle before delivering an answer. Use the holiday-package example to illustrate the flow.
  Why it matters: The holiday example shows how tool results become part of an agent’s answer rather than being the answer by themselves.
• Human review of actions: Explain why an agent might pause for human review before finalizing a critical action, including the proposed holiday itinerary as an example.
  Why it matters: Human approval adds oversight when an agent’s proposed action needs checking before it is carried out.
• MCP tool access: Describe how MCP lets services expose tools through MCP servers for agents to access via MCP clients, reducing the need for developers to maintain custom connectors.
  Why it matters: A shared way to access tools makes it easier to connect agents to services.

Key terms: AI agent, LLM, simple pipelines, constraints, adaptive decision-making, tools, developer-crafted prompt, queries, SQL, REST API calls

1.2 Introducing LangChain

This section introduces LangChain as a set of reusable building blocks for handling data, composing LLM applications, and changing components as needs evolve.

• Data ingestion and retrieval: Explain why applications using company documents need more than entire documents pasted into prompts, and describe how LangChain’s building blocks help supply relevant context.
  Why it matters: This is the basic reason LangChain helps with applications that answer questions over your own data.
• Reusable application composition: Describe how LangChain helps keep growing LLM applications maintainable and supports multi-step workflows and debugging.
  Why it matters: Reusable structure makes a growing application easier to maintain and inspect.
• Modular and extensible design: Explain how LangChain’s design principles let developers change components and adapt its patterns beyond one stack.
  Why it matters: These principles explain why an application need not be tied to one model, connector, or framework implementation.

Key terms: loaders, splitters, embeddings, vector stores, retrievers, prompt templates, chains, LCEL, Runnable interface, modularity

1.2.1 LangChain architecture

This section maps LangChain’s main components from document ingestion through response generation and contrasts sequential chains with dynamic agent workflows.

• Document ingestion and semantic indexing: Trace how source text becomes searchable content: loaders create Document objects, splitters make chunks, embedding models turn chunks into meaning-representing vectors, and vector stores retain the chunks and embeddings for similarity search.
  Why it matters: This is the preparation path that makes source material available for later questions.
• Retrieval to model response: Explain how a running application retrieves relevant Documents, combines their context with user input in a prompt, sends that request to an LLM or chat model, and can parse the response into a structured format. Describe the optional cache’s role for repeated or similar queries.
  Why it matters: It connects stored knowledge to the request the model actually receives and the output an application can use.
• Vector and graph data roles: Distinguish vector stores’ similarity-based retrieval from graph databases’ representation of entities and relationships, and explain why relationship data can be useful to agents planning later actions.
  Why it matters: The distinction clarifies why an application might need relationships as well as similar text.
• Component composition and branching: Describe how Runnable and LCEL provide a consistent way to connect LangChain components, and how graph arrangements allow branching rather than only a simple pipeline.
  Why it matters: It shows that the same building blocks can support both straightforward and branching workflows.
• Sequential chains and dynamic agents: Distinguish a chain’s use-case-specific sequence of components from an agent’s dynamic workflow, which can adapt to user input or component output and use resources called tools or plugins.
  Why it matters: This distinction separates a predefined processing path from an agent that can adapt its path.

Key terms: document loaders, Document, text splitters, embedding models, vector stores, similarity search, retrievers, prompts, LLM cache, LLM/chat model

1.2.2 LangChain’s core object model

The section introduces LangChain’s core object families and shows how documents move through loaders, splitters, vector stores, and retrievers, while a shared Runnable interface supports composition.

• Document processing object flow: Trace how loaders create Document objects, splitters divide them, and the resulting segments pass into vector stores and retrievers for downstream processing.
  Why it matters: This flow gives you a mental model for how document-handling parts of an LLM application fit together.
• Shared Runnable interface: Explain how the Runnable interface lets many LangChain components, from loaders to LLMs, be composed and chained consistently.
  Why it matters: A shared interface explains how otherwise different components can fit into one workflow.
• Core class family structure: Describe the object model as class hierarchies with abstract base classes and concrete implementations, and identify the Document-centered and LLM-related families shown here.
  Why it matters: Recognizing the class families helps you place document-processing and prompting objects within LangChain’s overall model.

Key terms: Document, DocumentLoader, TextSplitter, VectorStore, Retriever, Runnable interface, composed, chained, modular workflows, class hierarchies

1.3 Typical LLM use cases

This section surveys common LLM uses and notes that real-world tasks may require capabilities beyond an LLM’s initial training.

• Text analysis and generation: Describe how LLMs can classify text, analyze sentiment, identify topics, produce tailored summaries, and extract structured information from unstructured text.
  Why it matters: These examples show that LLM applications can do more than simply answer questions.
• Intent-based semantic search: Distinguish semantic search from simple keyword matching using the section’s description of knowledge-base queries.
  Why it matters: The distinction explains what makes this search use case different from a basic keyword lookup.
• Autonomous workflow tasks: Describe the kind of task illustrated by autonomous reasoning and workflow execution.
  Why it matters: This example extends the survey from individual text tasks to requests involving multiple steps.
• Coding and tutoring assistance: Describe how LLMs assist developers and learners in the examples given.
  Why it matters: These examples show how LLM capabilities can support work and learning directly.
• Initial training limits: Explain the limitation the section raises about applying LLMs to real-world requests.
  Why it matters: It explains why the listed use cases do not guarantee an LLM will meet every user’s needs.

Key terms: text classification, sentiment analysis, natural language understanding and generation, structured data extraction, semantic search, knowledge base, intent and context, autonomous reasoning, workflow execution, code understanding and generation

1.4 How to adapt an LLM to your needs

Introduces three techniques for adapting an LLM to user requests—prompt engineering, RAG, and fine-tuning—without explaining how they work.

1.4.1 Prompt engineering

Introduces prompt engineering as a way to guide LLM responses through instructions, examples, and context, while explaining its reuse patterns and limits.

• Prompt Design and Examples: Explain how prompt engineering guides an LLM and how examples in a prompt can help it handle similar inputs without fine-tuning.
  Why it matters: Careful prompts can adapt an LLM’s responses to a task without retraining it.
• Reusable Prompts and Conversation Context: Describe how prompt templates make prompts reusable and how including recent conversation turns can help a chatbot respond coherently.
  Why it matters: These patterns make prompts practical to reuse and help chatbots respond in context.
• Limits of Prompt Engineering: Explain when prompt engineering alone may be insufficient and what RAG adds at the level described here.
  Why it matters: It helps you recognize when better wording is not enough because the answer needs external knowledge.

Key terms: prompt engineering, in-context learning, few-shot prompting, fine-tuning, prompt templates, variable fields, recent conversation turns, RAG, user-specific or enterprise data, external sources

1.4.2 RAG

Introduces RAG as a way to ground LLM answers in retrieved data, outlines how a vector-based knowledge base is prepared, and explains its benefits and safeguards.

• RAG Grounding and Hallucinations: Explain how RAG adds relevant context from a knowledge base to an LLM prompt instead of relying only on pretrained knowledge, and how this can reduce hallucinations.
  Why it matters: This is the reason to use RAG when an application needs answers based on its own data.
• Vector Knowledge Base Preparation: Trace the preparation of documents into chunks and semantic embeddings stored in a vector database, without assuming details of retrieval not given here.
  Why it matters: This preparation makes the application's documents usable as relevant context for RAG.
• RAG Efficiency and Flexibility: Explain why retrieving key chunks saves prompt space and token costs, and how replaceable components let the RAG pattern suit different needs.
  Why it matters: These benefits explain why the same RAG pattern can be practical across applications.
• Reliable RAG Safeguards: Describe the prompt instruction recommended for reliable RAG and the additional safeguards noted for high-stakes cases.
  Why it matters: Grounding is more dependable when the application tells the model how to use its sources and accounts for cases where mistakes matter greatly.

Key terms: RAG, grounding, hallucination, knowledge base, chunks, embedding model, embeddings, vector database, semantic meaning, key chunks

1.4.3 Fine-tuning

This section explains how fine-tuning adapts a pretrained LLM and when its benefits may justify its costs instead of using RAG or prompt engineering.

• Fine-tuning a pretrained model: Explain that fine-tuning adapts a pretrained LLM to a task or domain by training it on curated examples of the desired style, terminology, and reasoning patterns.
  Why it matters: This distinguishes adapting the model itself from supplying instructions or context when you use it.
• Efficiency and training costs: Explain why fine-tuning can reduce the need for lengthy instructions or examples in each prompt, while requiring a high-quality dataset and potentially costly training. Describe, at the level given here, how parameter-efficient methods such as LoRA affect that tradeoff.
  Why it matters: The time saved in repeated prompts must be weighed against the effort and expense of adapting the model.
• Fine-tuning versus runtime context: Distinguish situations where RAG may be preferable because it supplies context at runtime from highly specialized domains where fine-tuning can capture jargon and workflows that generic models struggle with.
  Why it matters: Choosing how to adapt an LLM can avoid unnecessary training while preserving fine-tuning for cases that benefit from it.

Key terms: fine-tuning, pretrained LLM, curated dataset, domain-specific knowledge, Low-Rank Adaptation (LoRA), parameter-efficient fine-tuning, RAG, domain-specific jargon, workflows

1.5 Which LLMs to choose

This section explains how to choose LLMs by balancing accuracy, speed, and cost against an application's tasks and deployment needs.

• Accuracy speed cost tradeoff: Explain how model size generally affects accuracy, latency, and inference cost, and why the best choice depends on the application.
  Why it matters: It helps you choose a model for the job rather than assuming one model is best for everything.
• Task specific model selection: Describe why a workflow may use different models for different tasks rather than one model throughout.
  Why it matters: Choosing per task can avoid paying for a powerful model where a faster, cheaper one will do.
• Task context language fit: Describe how a model's purpose, context window, and multilingual support can affect its suitability for an application.
  Why it matters: A model must fit the content and users your application actually serves.
• Instruction reasoning model distinction: Distinguish when instruction models and reasoning models are suited to a task, including the stated performance tradeoff.
  Why it matters: This distinction helps you avoid paying for problem-solving capability when the steps are already clear.
• Open proprietary deployment tradeoff: Contrast the benefits and drawbacks of open source models and proprietary APIs presented in the section.
  Why it matters: Deployment and long-term operating constraints can matter as much as model performance.
• LangChain model switching: Explain what LangChain's standardized interface changes about integrating and switching LLMs.
  Why it matters: It makes changing model choices less disruptive to an application.

Key terms: accuracy, speed (latency), cost, inference, different models for different tasks, workflow, model purpose, context window size, multilingual support, instruction models

1.6 What you’ll learn from this book

This section previews the book’s learning path and explains why LLM interaction matters to modern software.

• LLM Interaction in Software: Explain the section’s claim that LLM interaction is rapidly becoming a core feature of modern software, using its comparison to the rise of websites.
  Why it matters: This explains why the book treats LLM-powered applications as an important area of software development.

Key terms: LLM interaction, modern software

1.7 Summary

This chapter summary recaps the main kinds of LLM systems and the choices involved in grounding, assembling, and selecting models for them.