Lesson 2 – The Six Core Components of LangChain

Learning Objectives

• Build a Mental Model: Understand how the six components interlock to form reliable LLM application pipelines.
• Reduce Accidental Complexity: Recognize where LangChain abstracts boilerplate (prompt formatting, routing, retrieval orchestration).
• Vendor Flexibility: See how interfaces decouple your app from individual model providers.
• Pattern Recognition: Identify which component to reach for when solving a specific product or research need.
• Avoid Early Pitfalls: Learn common mistakes (prompt sprawl, unbounded memory, naïve retrieval) before they cost time.

---

Context: Why These Components Exist

When teams first experiment with LLMs, they often write ad‑hoc scripts: raw prompts, direct API calls, copy‑pasted retrieval helpers. This scales poorly. LangChain introduces stable, composable building blocks—so your prototype architecture doesn’t collapse under feature growth.

Key drivers:

• Orchestration: Move data cleanly between model calls, retrieval steps, parsing, and post‑processing.
• Abstraction: Swap providers without rewriting business logic.
• Extensibility: Insert custom logic (guards, scoring, tracing) at predictable seams.

---

The Six Components at a Glance

Models (LLMs & embeddings) • Prompts (structured instructions) • Chains (deterministic composition) • Indexes (retrieval + grounding) • Memory (state across turns) • Agents (dynamic tool‑using planners).

We now dive into each with: Purpose • When to Use • Common Pitfalls.

---

1. Models (The Core Interface)

Purpose: Provide a unified interface around different LLM & embedding providers so you don’t rewrite glue code every time you switch vendors or modalities.

When to Use: Anytime raw generation, classification, transformation, or semantic embedding is required.

Common Pitfalls: Hard‑coding provider‑specific parameters; ignoring token cost monitoring; not normalizing error handling or retry strategy.

Two broad model classes:

• Chat / Completion Models: Input = text (possibly with system + messages), Output = text or tool/function call payload.
• Embedding Models: Input = text / chunk, Output = dense vector enabling semantic similarity, clustering, reranking.

Tip: Treat the model layer as a pluggable power outlet; everything else (prompt formatting, retrieval, parsing) should compose around it.

---

2. Prompts

Purpose: Shape model behavior through structured context, instructions, and examples—turning a general model into a task‑specific asset.

When to Use: Anytime you want deterministic framing, persona control, or reproducible structure across multiple invocations.

Common Pitfalls: Prompt sprawl (duplicated text), leaking sensitive instructions, overfitting to brittle few‑shot patterns.

Core strategies:

1. Parameterized Templates: Insert runtime variables safely without ad‑hoc string concatenation.
2. Role / Instruction Blocks: Establish stable tone & guardrails early in the context window.
3. Few‑Shot Examples: Demonstrate ideal input→output mappings; prune aggressively to control token cost.

Design Heuristic: If you edit the same wording in 3 places, extract a template.

---

3. Chains

Purpose: Compose deterministic pipelines—turning atomic steps (prompt → model → parser → scorer) into a reusable unit.

When to Use: Stable flows with known structure: summarization, translation, retrieval+answering, evaluation passes.

Common Pitfalls: Over‑nesting; hiding business logic inside opaque lambdas; ignoring observability (no tracing of intermediate steps).

Patterns:

1. Sequential: Linear progression of transformations.
2. Parallel / Fan‑Out: Run model variants then merge / vote.
3. Conditional: Branch based on classification or tool detection.

Modern LangChain (LCEL) lets you write `prompt | llm | parser` style pipelines—declarative and testable.

---

4. Indexes

Purpose: Inject authoritative or up‑to‑date knowledge that the base model never saw during pretraining.

When to Use: Proprietary documents, compliance corpora, product manuals, scientific archives, internal wikis.

Common Pitfalls: Over‑splitting (fragmented semantics), under‑splitting (irrelevant padding), skipping evaluation of retrieval quality.

Retrieval pipeline:

1. Load: Gather raw assets (PDF, HTML, DB rows).
2. Split: Chunk with semantic or token‑aware strategies.
3. Embed: Produce vector representations.
4. Store: Persist vectors (Chroma, Pinecone, Weaviate, FAISS).
5. Retrieve: Fetch top‑K relevant chunks (optionally rerank).

Quality Loop: Evaluate retrieval separately from generation—improves grounded answer fidelity.

---

5. Memory

Purpose: Preserve useful context across turns or processing stages without resending everything.

When to Use: Conversational assistants, multi‑step planning, personalization, iterative document refinement.

Common Pitfalls: Unbounded growth leading to token bloat; storing sensitive data without redaction; replaying irrelevant history.

Patterns:

• Full Buffer: Simple; expensive at scale.
• Sliding Window: Last N exchanges only.
• Rolling Summary: Summarize older context + keep fresh turns.
• Vector Memory: Semantic recall on demand.

Tip: Treat memory as an index with a policy—not a dumping ground.

---

6. Agents

Purpose: Introduce controlled autonomy—letting the system pick tools or branches dynamically based on intermediate reasoning.

When to Use: Multi‑tool workflows (search + retrieval + calculator), research bots, adaptive problem solving, task decomposition.

Common Pitfalls: Unbounded loops, tool hallucination, latency explosion, lack of guardrails or cost ceilings.

Loop pattern:

1. Receive query / task.
2. Plan next action.
3. Call tool (or chain) with arguments.
4. Observe result & update internal context.
5. Stop when goal satisfied or max iterations hit.

Governance: Add iteration limits, tool whitelists, and output validation for safety & cost control.

---

Wrapping Up

These six primitives give you a vocabulary for intentional system design. In practice you will often layer: retrieval (Indexes) + prompt template (Prompts) + model call (Models) + memory strategy (Memory) + optional dynamic routing (Agents), all glued via Chains or LCEL compositions.

In the next lesson we shift from concepts to implementation: environment setup, first runnable chains, and structured output patterns.

---

Quick Reinforcement Quiz

• 1. Which component would you modify to ground a model in proprietary documents?
• 2. What’s a good early signal you should turn a script of manual model calls into a Chain?
• 3. Name one pitfall of naive memory usage.
• 4. When do Agents become overkill relative to Chains?
• 5. Which trio best describes a basic RAG flow? (a) Prompt→Model→Parser (b) Load→Split→Retrieve (c) Split→Embed→Retrieve + Inject

---