Varunabishek

Building Your First RAG (Retrieval-Augmented Generation) App

2026-08-19T00:00:00+05:30

LLMs are trained on static data. Ask one about your internal docs, last week's meeting notes, or a product spec — it has no idea. RAG solves this by fetching relevant content at query time and injecting it into the prompt. The model still does the reasoning; you just give it the right context first.

How RAG works

The pipeline has two phases:

Indexing (offline) — Load your documents, split them into chunks, convert each chunk into a vector embedding, and store those vectors in a vector database.

Retrieval + generation (online) — When a user asks a question, convert the question into an embedding, find the closest-matching chunks in the vector DB, shove those chunks into the prompt alongside the question, and let the LLM answer.

That's it. The LLM never "learns" your docs — it reads them fresh on every query.

Dependencies

pip install langchain langchain-community langchain-openai \
    chromadb tiktoken

Step 1 — Load your documents

LangChain ships with loaders for almost every format. For a plain text file:

from langchain_community.document_loaders import TextLoader

loader = TextLoader("docs/handbook.txt")
docs = loader.load()

For a folder of files:

from langchain_community.document_loaders import DirectoryLoader

loader = DirectoryLoader("docs/", glob="**/*.txt")
docs = loader.load()

Each loaded item is a Document with .page_content (the text) and .metadata (source path, page number, etc.).

Step 2 — Split into chunks

Embeddings work best on short, focused passages. Long documents get split up:

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)
chunks = splitter.split_documents(docs)

chunk_overlap keeps a window of context at chunk boundaries. Tune chunk_size based on what you're embedding — 500 characters is a reasonable starting point for dense technical text.

Step 3 — Embed and store

Convert chunks to vectors and store them in Chroma (a local vector DB):

from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma

embeddings = OpenAIEmbeddings()

vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

persist_directory saves the index to disk so you don't re-embed on every run. Drop it if you want an in-memory store that resets each session.

Step 4 — Build the retrieval chain

LangChain's RetrievalQA chain wraps the retriever and the LLM together:

from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA

llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

k=4 means retrieve the 4 most similar chunks per query. chain_type="stuff" concatenates them into the prompt. For larger doc sets, map_reduce or refine handle overflow better.

Step 5 — Query it

result = qa_chain.invoke({"query": "What is the refund policy?"})

print(result["result"])
print("\nSources:")
for doc in result["source_documents"]:
    print(doc.metadata["source"])

The source_documents field shows exactly which chunks the model drew from — useful for debugging and for building citation UIs.

Full pipeline

import os
from langchain_community.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA

os.environ["OPENAI_API_KEY"] = "your-key-here"

# Load
loader = DirectoryLoader("docs/", glob="**/*.txt")
docs = loader.load()

# Split
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)

# Embed + store
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=OpenAIEmbeddings(),
    persist_directory="./chroma_db"
)

# Chain
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# Query
result = qa_chain.invoke({"query": "Summarize the onboarding process"})
print(result["result"])

Common failure modes

Bad retrieval — The right answer exists in your docs but the LLM gives a wrong or vague response. Usually means your chunks are too large or your embeddings aren't granular enough. Shrink chunk_size and re-index.

Hallucination despite good retrieval — The LLM drifts from the retrieved context. Add a system prompt that says: "Answer only using the provided context. If the context doesn't contain the answer, say so."

Slow indexing — Embedding thousands of chunks hits API rate limits fast. Batch your calls, add retry logic, or switch to a local embedding model like sentence-transformers.

Going further

Once the basic pipeline works, two things make the biggest difference in real apps:

Metadata filtering — Tag chunks with source, date, or category at index time, then filter by those fields at retrieval time. Keeps queries scoped and cuts noise.

Hybrid search — Combine vector similarity with keyword search (BM25). Pure vector search misses exact-match queries; hybrid search handles both.

Document Loaders — Pulling in PDFs, Websites, CSVs, and More

2026-08-19T00:00:00+05:30

Before any LangChain pipeline does anything useful, it needs data. Document loaders are how that data gets in — they fetch content from a source, parse it, and return a list of Document objects with .page_content and .metadata. The rest of the pipeline (splitting, embedding, retrieval) doesn't care where the content came from. That's the point.

The Document object

Every loader returns the same structure:

from langchain.schema import Document

doc = Document(
    page_content="This is the text content",
    metadata={"source": "handbook.pdf", "page": 3}
)

.page_content is what gets embedded and fed to the LLM. .metadata is free-form — source file, URL, page number, timestamps — whatever you want to carry through for filtering or citation.

PDFs

The most common use case. Two loaders worth knowing:

# PyPDF — lightweight, good for most PDFs
from langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("report.pdf")
docs = loader.load()  # One Document per page

# PDFPlumber — better for tables and layout-heavy docs
from langchain_community.document_loaders import PDFPlumberLoader

loader = PDFPlumberLoader("report.pdf")
docs = loader.load()

PyPDFLoader is faster. PDFPlumberLoader preserves layout better and handles tables more reliably. For scanned PDFs (image-based, no text layer), neither works — you need OCR. UnstructuredPDFLoader with mode="elements" can handle these via Tesseract.

Websites

from langchain_community.document_loaders import WebBaseLoader

loader = WebBaseLoader("https://docs.python.org/3/library/os.html")
docs = loader.load()

This fetches static HTML and strips the tags. Works fine for documentation sites, Wikipedia, blogs. For JavaScript-rendered pages (React/Next.js SPAs), the content won't be there — use SeleniumURLLoader or PlaywrightURLLoader instead, which spin up a real browser.

Loading multiple URLs at once:

urls = [
    "https://example.com/page1",
    "https://example.com/page2",
]
loader = WebBaseLoader(urls)
docs = loader.load()

CSVs

from langchain_community.document_loaders import CSVLoader

loader = CSVLoader(
    file_path="employees.csv",
    source_column="employee_id"   # used as the metadata source field
)
docs = loader.load()

Each row becomes its own Document. The source_column parameter sets which column gets used as the source identifier in metadata — useful when you want to trace an answer back to a specific record.

For large CSVs with many columns, consider specifying which columns matter:

loader = CSVLoader(
    file_path="data.csv",
    csv_args={"fieldnames": ["name", "description", "date"]}
)

JSON and JSONL

from langchain_community.document_loaders import JSONLoader

loader = JSONLoader(
    file_path="data.json",
    jq_schema=".messages[].content",  # jq syntax to extract the right field
    text_content=True
)
docs = loader.load()

JSONLoader uses jq syntax to navigate nested JSON. jq_schema tells it exactly which field to pull as the page content. For JSONL (one JSON object per line), set json_lines=True.

Directories (bulk loading)

from langchain_community.document_loaders import DirectoryLoader

loader = DirectoryLoader(
    path="docs/",
    glob="**/*.pdf",          # glob pattern for file types
    loader_cls=PyPDFLoader,   # which loader to use per file
    show_progress=True
)
docs = loader.load()

DirectoryLoader walks a folder and applies the specified loader to each matching file. Mix it with different glob patterns and loader_cls values if you have a folder with mixed file types.

Notion, Google Drive, and databases

LangChain has loaders for these too, though they need extra auth setup:

# Notion
from langchain_community.document_loaders import NotionDBLoader

loader = NotionDBLoader(
    integration_token="your-token",
    database_id="your-db-id",
    request_timeout_sec=30
)

# Google Drive
from langchain_community.document_loaders import GoogleDriveLoader

loader = GoogleDriveLoader(
    folder_id="your-folder-id",
    recursive=True
)

SQL databases have their own path — SQLDatabaseLoader runs a query and turns rows into documents. Useful for pipelines that need to answer questions against live relational data.

Custom loaders

If nothing built-in fits, subclass BaseLoader:

from langchain.document_loaders.base import BaseLoader
from langchain.schema import Document

class MyAPILoader(BaseLoader):
    def __init__(self, endpoint: str):
        self.endpoint = endpoint

    def load(self) -> list[Document]:
        import requests
        response = requests.get(self.endpoint).json()
        return [
            Document(
                page_content=item["text"],
                metadata={"id": item["id"], "source": self.endpoint}
            )
            for item in response["items"]
        ]

The interface is just one method: load() returning a list of Document objects. That's all the rest of the pipeline needs.

What to watch for

Encoding issues — PDFs and older text files sometimes come with encoding problems. PyPDFLoader occasionally returns garbled text from scanned or password-protected files. Check doc.page_content before embedding — garbage in means garbage retrieved.

Large files — Loading a 500-page PDF returns 500 documents at once. If you're loading many large files, stream them in batches rather than calling .load() on everything at once.

Metadata hygiene — The metadata your loaders attach is what you'll use later for filtering. Set it deliberately. A chunk with metadata={"source": "file.pdf"} is much harder to filter than one with metadata={"source": "file.pdf", "section": "terms", "date": "2026-01"}.

Intro to Vector Stores (Chroma, FAISS, Pinecone) with LangChain

2026-08-19T00:00:00+05:30

A vector store is a database that finds things by meaning, not exact match. You convert text into a numerical vector (an embedding), store it, and later search for semantically similar vectors. That's the retrieval half of RAG. Which store you pick depends on scale, whether you want persistence, and whether you're staying local or going cloud.

How similarity search works

When you embed text, you map it into a high-dimensional space where similar meanings land close to each other. "How do I reset my password?" and "Forgot password steps" produce vectors that are geometrically near each other, even though they share no words.

At query time:

Embed the user's question into the same space.
Find the k stored vectors closest to it (cosine similarity or Euclidean distance).
Return the corresponding text chunks.

That's what every vector store does. The differences are in speed, persistence, and infrastructure.

Chroma — local, zero-config

Chroma runs in-process. No server, no Docker, just install and go. The right choice for development, prototypes, and small production apps where you control the machine.

pip install chromadb

from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma

embeddings = OpenAIEmbeddings()

# Create from documents
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"   # omit for in-memory only
)

# Load an existing store
vectorstore = Chroma(
    persist_directory="./chroma_db",
    embedding_function=embeddings
)

# Search
results = vectorstore.similarity_search("What is the refund policy?", k=4)

persist_directory writes the index to disk. Without it, everything lives in memory and resets when the process ends. Chroma handles up to a few hundred thousand documents comfortably on a standard laptop.

Metadata filtering in Chroma:

results = vectorstore.similarity_search(
    query="security protocols",
    k=3,
    filter={"source": "handbook.pdf"}
)

Filter keys must match what you set in .metadata at index time.

FAISS — fast, in-memory, CPU-native

FAISS (Facebook AI Similarity Search) is a C++ library optimized for large-scale nearest-neighbor search. It's faster than Chroma for big indexes and doesn't need a server, but it's in-memory — persistence requires manually serializing and deserializing the index.

pip install faiss-cpu   # or faiss-gpu if you have CUDA

from langchain_community.vectorstores import FAISS

# Create
vectorstore = FAISS.from_documents(chunks, embeddings)

# Save to disk
vectorstore.save_local("faiss_index")

# Load from disk
vectorstore = FAISS.load_local(
    "faiss_index",
    embeddings,
    allow_dangerous_deserialization=True
)

# Search
results = vectorstore.similarity_search("explain the leave policy", k=5)

FAISS doesn't have built-in metadata filtering the way Chroma does. You filter post-retrieval by inspecting doc.metadata yourself. For production use cases needing filter logic, Chroma or Pinecone are easier.

FAISS shines when you have millions of vectors and want fast retrieval on your own hardware — local LLM setups, air-gapped environments, research workloads.

Pinecone — managed, cloud-native

Pinecone is a hosted vector database. You push vectors to their servers; they handle indexing, scaling, and replication. No infra to manage, but it's a paid service and your data leaves your machine.

pip install pinecone-client

from langchain_pinecone import PineconeVectorStore
import pinecone

pinecone.init(
    api_key="your-api-key",
    environment="us-east-1-aws"
)

# Create index (one-time setup, not per run)
pinecone.create_index(
    name="my-index",
    dimension=1536,       # OpenAI ada-002 output dimension
    metric="cosine"
)

# Upsert documents
vectorstore = PineconeVectorStore.from_documents(
    documents=chunks,
    embedding=embeddings,
    index_name="my-index"
)

# Connect to existing index
vectorstore = PineconeVectorStore(
    index_name="my-index",
    embedding=embeddings
)

# Search with metadata filter
results = vectorstore.similarity_search(
    "quarterly revenue targets",
    k=4,
    filter={"department": "finance"}
)

Pinecone's main advantage is that it scales horizontally without any work on your side. Billions of vectors, concurrent queries, namespace isolation — all handled. The tradeoff is cost and the fact that your data lives in their infrastructure.

Comparing the three

	Chroma	FAISS	Pinecone
Hosting	Local	Local	Cloud
Persistence	Built-in	Manual (save/load)	Always on
Metadata filtering	Yes	Post-retrieval only	Yes
Scale	~100k docs	Millions	Billions
Cost	Free	Free	Paid
Best for	Dev / small prod	Large local indexes	Production at scale

Which retriever mode to use

All three expose .as_retriever(), which is what you pass into LangChain chains:

retriever = vectorstore.as_retriever(
    search_type="mmr",          # or "similarity" (default)
    search_kwargs={"k": 5, "fetch_k": 20}
)

similarity — Returns the top-k most similar chunks. Simple, fast, but can return redundant results if your docs have repeated content.

mmr (Maximal Marginal Relevance) — Balances similarity with diversity. Fetches a larger candidate set (fetch_k), then picks k results that are relevant but not too similar to each other. Better for documents with repeated sections or when you want varied context.

Swapping stores without rewriting your chain

LangChain's interfaces are consistent across stores. Switch from Chroma to Pinecone by changing one line:

# Before
retriever = chroma_store.as_retriever(search_kwargs={"k": 4})

# After
retriever = pinecone_store.as_retriever(search_kwargs={"k": 4})

The chain, prompts, and LLM stay the same. This makes it easy to start local with Chroma and migrate to Pinecone when you need to scale.

LangChain vs. LlamaIndex vs. Raw API Calls — When to Use What

2026-08-19T00:00:00+05:30

Three ways to build with LLMs. Each makes different tradeoffs, and picking the wrong one early costs you time when the project grows. This isn't a ranking — it's a map of when each tool actually fits.

Raw API calls

Direct calls to OpenAI, Anthropic, Gemini, or any provider. No framework, just HTTP.

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain transformers in one paragraph."}
    ]
)
print(response.choices[0].message.content)

When this fits: - You're doing one thing — a single prompt, a classification call, a rewrite task. - You need full control over request structure and don't want a framework deciding how to format things. - You're building a lightweight microservice where a framework would add weight for no reason. - You're learning. Frameworks abstract the parts you should understand first.

Where it breaks down: - You start needing RAG. Now you're writing a vector store wrapper, a chunking function, a retrieval loop, and token management yourself. - You want conversation memory. Now you're manually tracking message history per session. - You want to swap providers. Now you're rewriting every call.

Raw API calls don't scale to complex pipelines without you rebuilding the things frameworks already built.

LangChain

LangChain is a general-purpose framework for chaining LLM calls with tools, memory, retrievers, and data loaders. It covers almost every use case — sometimes too broadly.

from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

llm = ChatOpenAI(model="gpt-3.5-turbo")
vectorstore = Chroma(persist_directory="./db", embedding_function=OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)
result = chain.invoke({"query": "What does the contract say about late fees?"})

When this fits: - You're building a multi-step pipeline: load → split → embed → retrieve → generate. - You need agents — LLMs that pick tools, take actions, and loop based on output. - You want memory management handled for you (buffer, window, summary). - You're connecting to external tools: web search, APIs, databases, code interpreters. - You want to swap LLMs or vector stores without rewriting the whole pipeline.

Where it breaks down: - Retrieval quality is your primary concern. LangChain supports many retrieval strategies, but tuning them requires working around the abstractions rather than with them. - The abstraction layers make debugging harder. When something returns wrong results, the error is often buried three layers deep. - LangChain has gone through significant API churn (v0.1 → LCEL → v0.3). Code from tutorials written six months ago may not run without changes.

LangChain is best when you need breadth — many connected components — and are willing to trade some debuggability for speed of assembly.

LlamaIndex

LlamaIndex (formerly GPT Index) is purpose-built for indexing and retrieval. Its primitives — nodes, indexes, query engines, retrievers — are designed around document ingestion and high-quality search. LangChain can do RAG; LlamaIndex was built specifically for it.

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

# Load and index
documents = SimpleDirectoryReader("docs/").load_data()
index = VectorStoreIndex.from_documents(documents)

# Query
query_engine = index.as_query_engine()
response = query_engine.query("What are the payment terms?")
print(response)

Four lines. No manual chunking, no retriever config, no chain setup.

When this fits: - Document Q&A is the core feature, not a component inside a larger pipeline. - You need fine-grained retrieval: hierarchical indexes, sub-question decomposition, hybrid search, reranking. - You want to index structured data (SQL, JSON, dataframes) alongside unstructured docs. - You care about retrieval evaluation — LlamaIndex has built-in evals for this.

Where it breaks down: - You need agents with complex tool use. LlamaIndex has agents, but LangChain's are more mature and have more integrations. - Your pipeline has many non-retrieval components (custom memory, complex branching logic, tool chains). LangChain's LCEL is better suited for composing those. - You need a wider ecosystem of third-party integrations. LangChain has more.

LlamaIndex is better when retrieval quality is what you're optimizing for and the rest of the pipeline is simple.

Side by side

	Raw API	LangChain	LlamaIndex
Learning curve	Low	High	Medium
RAG support	DIY	Good	Excellent
Agent support	DIY	Excellent	Good
Memory management	DIY	Built-in	Basic
Retrieval tuning	DIY	Moderate	Deep
Debugging	Easy	Hard	Medium
Ecosystem / integrations	Provider-specific	Large	Growing
API stability	Stable	Churn	Moderate

The real decision flow

Start with raw API calls if: You're learning, prototyping a single prompt interaction, or building something where a framework would be overhead with no benefit.

Reach for LangChain if: Your pipeline connects multiple components — loaders, retrievers, tools, memory, agents — and you want the ecosystem to handle the wiring.

Reach for LlamaIndex if: Your core problem is document retrieval and Q&A, and you want the best retrieval quality with the least configuration overhead.

Use both if: It's more common than you'd think. LangChain for orchestration, LlamaIndex as the retrieval backend. They interoperate:

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from langchain_community.retrievers import LlamaIndexRetriever

documents = SimpleDirectoryReader("docs/").load_data()
index = VectorStoreIndex.from_documents(documents)

# Use LlamaIndex's query engine as a LangChain retriever
retriever = LlamaIndexRetriever(index=index.as_query_engine())

The frameworks aren't mutually exclusive. Pick the best tool for each layer of your stack.

Managing Conversation History Without Blowing Your Token Budget

2026-08-19T00:00:00+05:30

LLMs have no memory between calls. Every time you hit the API, the model starts fresh. To build a chatbot that remembers what was said three messages ago, you have to manually pass that history back in on every request. The problem: each message adds tokens, and token budgets are finite. A naive implementation that keeps the full conversation will eventually hit the context limit — or cost you more than it should.

The naive approach (and why it breaks)

history = []

def chat(user_message):
    history.append({"role": "user", "content": user_message})
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=history
    )
    reply = response.choices[0].message.content
    history.append({"role": "assistant", "content": reply})
    return reply

This works until it doesn't. After enough turns, history overflows the context window and the API throws an error. Even before that, you're paying for tokens from 40 messages ago that have nothing to do with the current question.

LangChain's memory modules solve this by managing what gets kept.

ConversationBufferMemory — full history, simple

The most basic option: keep every message, no trimming.

from langchain.memory import ConversationBufferMemory
from langchain_openai import ChatOpenAI
from langchain.chains import ConversationChain

llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
memory = ConversationBufferMemory()

chain = ConversationChain(llm=llm, memory=memory, verbose=False)

chain.predict(input="My name is Varun.")
chain.predict(input="What's my name?")   # → "Your name is Varun."

Fine for short conversations. Breaks on long ones for exactly the same reason the naive approach does.

ConversationBufferWindowMemory — sliding window

Keep only the last k exchanges. Everything older gets dropped:

from langchain.memory import ConversationBufferWindowMemory

memory = ConversationBufferWindowMemory(k=5)  # last 5 human+AI turns
chain = ConversationChain(llm=llm, memory=memory)

Simple and predictable. The tradeoff is that context beyond k turns ago is gone entirely. A user who mentioned their project name 10 messages back and references it now will confuse the model.

Good for: customer support bots, short-session apps, anywhere long-term context doesn't matter.

ConversationSummaryMemory — compress old turns

Summarize older messages instead of dropping them. The LLM itself writes the summary as history grows:

from langchain.memory import ConversationSummaryMemory

memory = ConversationSummaryMemory(llm=llm)
chain = ConversationChain(llm=llm, memory=memory)

Recent turns are kept verbatim; older ones get collapsed into a running summary. The model always has the gist of what happened earlier, just not the exact words.

The catch: summarization costs extra tokens and adds latency on each turn. For long conversations, this is usually worth it. For short ones, it's overhead you don't need.

ConversationSummaryBufferMemory — the practical middle ground

Keeps recent messages verbatim and summarizes anything older than max_token_limit tokens:

from langchain.memory import ConversationSummaryBufferMemory

memory = ConversationSummaryBufferMemory(
    llm=llm,
    max_token_limit=1000    # keep last ~1000 tokens verbatim; summarize the rest
)
chain = ConversationChain(llm=llm, memory=memory)

This is the most practical default for production chatbots. Recent context stays sharp; older context survives in compressed form. The token budget stays bounded without losing the thread of a long session.

ConversationTokenBufferMemory — token-precise trimming

Trims by exact token count rather than by message count:

from langchain.memory import ConversationTokenBufferMemory

memory = ConversationTokenBufferMemory(
    llm=llm,
    max_token_limit=2000   # never exceed 2000 tokens in memory
)

More precise than window-based trimming since different messages have very different lengths. A user who sends one-word replies needs a bigger window than one who writes paragraphs. Token-based trimming handles both correctly.

Persisting memory across sessions

All the memory classes above are in-memory. Close the process and the history is gone. For a real chatbot, you need to save and reload it.

Manual serialization:

import json

# Save
history = memory.chat_memory.messages
serialized = [{"role": m.type, "content": m.content} for m in history]
json.dump(serialized, open("session_123.json", "w"))

# Load
from langchain.schema import HumanMessage, AIMessage
data = json.load(open("session_123.json"))
messages = [
    HumanMessage(content=m["content"]) if m["role"] == "human"
    else AIMessage(content=m["content"])
    for m in data
]
memory.chat_memory.messages = messages

With a database (Redis, MongoDB, Postgres):

LangChain has RedisChatMessageHistory, MongoDBChatMessageHistory, and others that write directly to an external store. They slot into the same memory interface:

from langchain_community.chat_message_histories import RedisChatMessageHistory
from langchain.memory import ConversationBufferMemory

message_history = RedisChatMessageHistory(
    session_id="user_456",
    url="redis://localhost:6379"
)

memory = ConversationBufferMemory(
    chat_memory=message_history,
    return_messages=True
)

Each session ID gets its own history. Users pick up where they left off, even after server restarts.

Token counting before you send

Sometimes you want to check token usage programmatically before committing to an API call:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-3.5-turbo")

# Count tokens in a message list
from langchain_community.callbacks import get_openai_callback

with get_openai_callback() as cb:
    result = chain.predict(input="How many tokens did that use?")
    print(f"Total tokens: {cb.total_tokens}")
    print(f"Prompt tokens: {cb.prompt_tokens}")
    print(f"Completion tokens: {cb.completion_tokens}")
    print(f"Cost: ${cb.total_cost:.4f}")

get_openai_callback wraps any LangChain call and reports usage. Useful for auditing costs in development and for setting hard limits in production.

The summary

Memory type	What it keeps	Best for
`BufferMemory`	Everything	Short conversations
`BufferWindowMemory`	Last k turns	Short-session apps
`SummaryMemory`	Running summary	Long sessions, cost-sensitive
`SummaryBufferMemory`	Recent verbatim + summary	Most production chatbots
`TokenBufferMemory`	Bounded by token count	Variable-length message flows

Start with ConversationSummaryBufferMemory at around 1000–1500 tokens and tune from there.

Web Scraping + Summarization Pipeline with LangChain

2026-08-19T00:00:00+05:30

You don't always need a fancy dataset. Sometimes the data you need is already live on the web — you just have to go get it and make sense of it. That's exactly what this pipeline does: scrape a URL, chunk the content, and summarize it using an LLM, all wired together with LangChain.

What you're building

The pipeline has three stages:

Fetch raw HTML from a URL
Parse and clean it into readable text
Pass that text through an LLM with a summarization prompt

LangChain handles the glue — loaders, text splitters, chains — so you spend less time on plumbing and more time on what actually matters.

Dependencies

pip install langchain langchain-community langchain-openai \
    beautifulsoup4 requests tiktoken

You'll also need an OpenAI API key (or swap in any LLM provider LangChain supports).

Step 1 — Scrape the page

LangChain's WebBaseLoader does this with one line:

from langchain_community.document_loaders import WebBaseLoader

loader = WebBaseLoader("https://example.com/article")
docs = loader.load()

Under the hood it fetches the page with requests, strips tags using BeautifulSoup, and returns a list of Document objects. Each document has .page_content (the text) and .metadata (source URL, title, etc.).

If you're scraping a JavaScript-heavy site, WebBaseLoader won't work — it only processes static HTML. Use SeleniumURLLoader or PlaywrightURLLoader instead:

from langchain_community.document_loaders import SeleniumURLLoader

loader = SeleniumURLLoader(urls=["https://js-heavy-site.com"])
docs = loader.load()

Step 2 — Split the text

LLMs have context limits. A long article will overflow the context window if you send it all at once. RecursiveCharacterTextSplitter breaks the content into chunks that fit:

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=2000,
    chunk_overlap=200
)
chunks = splitter.split_documents(docs)

chunk_overlap keeps a little context between adjacent chunks so the LLM doesn't lose thread between them. Tune chunk_size based on your model's token limit — 2000 characters is a safe starting point for most GPT-3.5/4 setups.

Step 3 — Summarize with a chain

LangChain has built-in summarization chains. load_summarize_chain wires together the LLM and a prompt strategy:

from langchain_openai import ChatOpenAI
from langchain.chains.summarize import load_summarize_chain

llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
chain = load_summarize_chain(llm, chain_type="map_reduce")
summary = chain.run(chunks)

print(summary)

stuff — Concatenates all chunks and sends them in one prompt. Works for short documents. Breaks on anything long.

map_reduce — Summarizes each chunk separately (map), then summarizes the summaries (reduce). Handles long content well, costs more tokens.

refine — Starts with the first chunk's summary, then iteratively refines it with each next chunk. Produces more coherent output than map_reduce but is slower.

For most web articles, map_reduce is the right default.

Full pipeline

import os
from langchain_community.document_loaders import WebBaseLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import ChatOpenAI
from langchain.chains.summarize import load_summarize_chain

os.environ["OPENAI_API_KEY"] = "your-key-here"

def summarize_url(url: str) -> str:
    # Load
    loader = WebBaseLoader(url)
    docs = loader.load()

    # Split
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=2000,
        chunk_overlap=200
    )
    chunks = splitter.split_documents(docs)

    # Summarize
    llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
    chain = load_summarize_chain(llm, chain_type="map_reduce")
    return chain.run(chunks)

if __name__ == "__main__":
    url = "https://en.wikipedia.org/wiki/Large_language_model"
    print(summarize_url(url))

Custom prompt

The default prompt is generic. You can replace it with something that fits your use case:

from langchain.prompts import PromptTemplate

map_prompt = PromptTemplate(
    input_variables=["text"],
    template="""
Summarize the following content in 3-5 bullet points.
Focus on key facts, arguments, and conclusions.

Content:
{text}

Summary:
"""
)

combine_prompt = PromptTemplate(
    input_variables=["text"],
    template="""
You have summaries from sections of an article.
Write a single, coherent paragraph summarizing all of them.

Summaries:
{text}

Final Summary:
"""
)

chain = load_summarize_chain(
    llm,
    chain_type="map_reduce",
    map_prompt=map_prompt,
    combine_prompt=combine_prompt
)

This gives you control over tone, format, and what the model pays attention to.

Scaling it up

If you're summarizing many URLs, a few things to watch:

Rate limits — Add time.sleep() between requests, or use async loaders (AsyncHtmlLoader).
Token costs — map_reduce on a 10,000-word article can rack up tokens fast. Cache results if you're hitting the same URLs repeatedly.
Paywalled / bot-protected sites — WebBaseLoader will get blocked. You need session cookies, headers spoofing, or a scraping API like Browserless or ScrapingBee.
Structured extraction — If you want specific fields (author, date, key claims) rather than a freeform summary, swap the summarization chain for an extraction chain or use PydanticOutputParser to force structured JSON output.

Swapping the LLM

LangChain's abstraction makes it easy to drop in a different model. For a local setup:

from langchain_community.llms import Ollama

llm = Ollama(model="llama3")

The rest of the chain stays the same. This matters if you're building something where data can't leave your machine — which is exactly the kind of setup that makes sense for projects handling sensitive internal docs.

EffortCommerce — How Kactii Turned Effort Into Currency

2026-08-02T00:00:00+05:30

My internship at Kactii doesn't just give me tasks to complete. It pays me for doing them — in credits.

What EffortCommerce means here

Every time I take a session, push code on a project, write something useful, or pitch an idea that holds up, I earn credits. They stack up in my account. Then I can go to the Kactii Academy store and spend them on real products — JBL earphones, a power bank, books, mock interviews, ergonomic gear.

That's the whole system. Work goes in, credits come out, things come home.

How it changes how I show up

The shift is subtle but real. When effort has a direct, tangible return, the motivation to do good work stops relying on abstract career benefits or end-of-internship certificates. There's something sitting in a store with a credit price on it, and the gap between me and that thing is a specific amount of work.

Taking sessions earns credits. Writing working code earns credits. Giving an idea that actually makes it into a decision earns credits. So I'm not just logging hours — I'm accumulating something.

Why this works better than a stipend model

A fixed stipend pays the same whether you contribute a lot or a little. EffortCommerce doesn't. The store is open to everyone, but your buying power is determined entirely by what you've put in. That's a clean incentive structure.

And because the credits come from specific actions — sessions, projects, code, ideas — there's no ambiguity about what counts. Show up and contribute, and the credits follow. Skip a week and your balance doesn't move.

What's actually in the store

The range is wider than I expected. There are everyday-useful items like a Zebronics power bank (17,400 credits) and an ergonomic mouse pad (4,200 credits). There are audio products from JBL and boAt. There's The Psychology of Money for 6,700 credits. There's a Python mock interview by Kactii itself — which is an interesting one, because spending credits on interview prep means your internship effort is directly funding your job readiness.

The credit prices vary enough that short-term and long-term goals both fit. You don't have to wait months to redeem something, but the bigger items give you something to work toward.

The part that sticks

Most internships end with a certificate and a LinkedIn recommendation. This one ends with whatever you earned. The effort-to-reward loop is short, specific, and honest. That's harder to build than it sounds.

Chains 101: Understanding LLMChain and Sequential Chains

2026-07-30T00:00:00+05:30

If you've poked around LangChain for more than ten minutes, you've hit the word "chain." It's everywhere — and for good reason. Chains are how you turn a raw language model into something that actually does a job.

What a chain is

A chain is a unit of logic that takes an input, does something with it, and returns an output. That "something" usually involves an LLM, but it can also include memory lookups, document retrievals, API calls, or other chains. At its core, a chain is just a pipeline with a clear contract: input in, output out.

LangChain gives you a bunch of built-in chain types. Two of them are worth knowing cold before you touch anything else: LLMChain and SequentialChain.

LLMChain

LLMChain is the baseline. It wires together three things:

A prompt template — defines the structure of what you send to the model
An LLM — the model that processes the prompt
An output parser (optional) — parses the raw text response into something usable

from langchain.chains import LLMChain
from langchain.prompts import PromptTemplate
from langchain_openai import OpenAI

llm = OpenAI(temperature=0.7)

prompt = PromptTemplate(
    input_variables=["topic"],
    template="Explain {topic} in two sentences, like I'm 15."
)

chain = LLMChain(llm=llm, prompt=prompt)
result = chain.run(topic="gradient descent")
print(result)

When you call chain.run(topic="gradient descent"), LangChain fills in the template, sends it to the LLM, and hands you back the response. That's the whole thing. Simple, but it sets the pattern for everything more complex.

The PromptTemplate is where most of the real work happens. You define input_variables — the slots that get filled at runtime — and write the template string around them. The LLM never sees {topic}, it sees the fully-rendered prompt.

Why PromptTemplate matters

You could skip the template and just format strings yourself. But PromptTemplate enforces that the variables you claim exist actually get passed in. If you declare input_variables=["topic"] and forget to pass topic at runtime, you get an explicit error instead of a silent bad output. That matters more as chains get complicated.

SequentialChain

One LLM call is often enough. But a lot of tasks need multiple steps — and the output of step one feeds into step two.

That's what SequentialChain is for. It runs a list of chains in order and threads outputs from earlier steps into the inputs of later ones.

from langchain.chains import LLMChain, SequentialChain
from langchain.prompts import PromptTemplate
from langchain_openai import OpenAI

llm = OpenAI(temperature=0.7)

# Step 1: generate a product name
name_prompt = PromptTemplate(
    input_variables=["product_description"],
    template="Create a short, catchy product name for: {product_description}"
)
name_chain = LLMChain(llm=llm, prompt=name_prompt, output_key="product_name")

# Step 2: write a tagline for that name
tagline_prompt = PromptTemplate(
    input_variables=["product_name"],
    template="Write a one-line marketing tagline for a product called '{product_name}'."
)
tagline_chain = LLMChain(llm=llm, prompt=tagline_prompt, output_key="tagline")

# Wire them together
pipeline = SequentialChain(
    chains=[name_chain, tagline_chain],
    input_variables=["product_description"],
    output_variables=["product_name", "tagline"],
    verbose=True
)

result = pipeline({
    "product_description": "a water bottle that tracks hydration via a smartphone app"
})

print(result["product_name"])
print(result["tagline"])

The key detail: output_key. Every LLMChain in a sequential pipeline needs one, so the next chain in line knows what variable name to pull from. SequentialChain stitches them together automatically — product_description goes into chain one, product_name (the output) becomes the input to chain two.

SimpleSequentialChain vs SequentialChain

LangChain has a simpler version called SimpleSequentialChain. It's fine when each step produces exactly one output and passes it to the next step. There's no naming involved — the output of step N is just the input to step N+1.

SequentialChain is what you want when steps produce multiple outputs, or when later steps need inputs from earlier steps that aren't just the immediate predecessor. The output_key / input_variables system gives you that flexibility.

A quick mental model

Think of it this way: LLMChain is one function call. SequentialChain is a composed pipeline of function calls where outputs flow through as named variables. Once you have that picture, the rest of LangChain's chain ecosystem — RouterChain, TransformChain, retrieval chains — is just variations on the same idea.

Get comfortable with these two first. They cover a surprising number of real use cases on their own.

Giving Your Chatbot Memory: ConversationBufferMemory vs. Other Memory Types

2026-07-30T00:00:00+05:30

By default, an LLM has no idea what you said two messages ago. Every call is stateless — the model processes whatever is in the current prompt and nothing else. If you want a chatbot that remembers the conversation, you have to build that yourself. LangChain's memory modules are how you do it.

Why memory is a design decision

There's no single right way to handle memory. A short customer support chat needs something different from a long-running research assistant. The tradeoff is almost always the same: how much context do you keep vs. how much do you spend on tokens?

LangChain gives you several memory types. Here's what each one does and when to reach for it.

ConversationBufferMemory

The simplest option. It stores every message in the conversation — human and AI — and injects the full history into each new prompt.

from langchain.memory import ConversationBufferMemory
from langchain.chains import ConversationChain
from langchain_openai import OpenAI

llm = OpenAI(temperature=0.7)
memory = ConversationBufferMemory()

conversation = ConversationChain(llm=llm, memory=memory, verbose=True)

conversation.predict(input="Hi, I'm Varun.")
conversation.predict(input="What's my name?")

The second call works. The model knows your name because the first exchange is still sitting in the buffer, prepended to the new prompt.

The catch: the buffer grows with every message. Long enough conversations will push you past the model's context window and start costing real money per call. Fine for short sessions, fragile for anything open-ended.

ConversationBufferWindowMemory

Same idea as the buffer, but with a sliding window. You set k — the number of recent exchanges to keep — and anything older than that gets dropped.

from langchain.memory import ConversationBufferWindowMemory

memory = ConversationBufferWindowMemory(k=5)

With k=5, the model sees the last five human-AI pairs and nothing before that. It's predictable and token-efficient. The tradeoff is that older context disappears hard — the model won't remember what you said in turn one once you're past turn six.

Good fit for chat interfaces where recent context is what matters.

ConversationSummaryMemory

Instead of storing raw messages, this one compresses older parts of the conversation into a running summary using an LLM call.

from langchain.memory import ConversationSummaryMemory
from langchain_openai import OpenAI

llm = OpenAI(temperature=0)
memory = ConversationSummaryMemory(llm=llm)

The summary gets prepended to the prompt in place of the full history. Older exchanges don't vanish — they get distilled. A 20-turn conversation might compress down to a paragraph.

The cost: you're making extra LLM calls to generate summaries. For very short conversations, that's overhead with no benefit. But for long sessions where you genuinely need the model to know what happened early on, this is often the right choice.

ConversationSummaryBufferMemory

A hybrid. It keeps recent messages verbatim (like the buffer) and summarizes everything older than a token threshold.

from langchain.memory import ConversationSummaryBufferMemory
from langchain_openai import OpenAI

llm = OpenAI(temperature=0)
memory = ConversationSummaryBufferMemory(llm=llm, max_token_limit=500)

Once the raw message history crosses max_token_limit tokens, older messages get rolled into a summary. Recent messages stay as-is. You get precise recent context and a compressed view of history — without blowing up your token count.

This is the one worth reaching for in production chatbots that need to handle both short and long conversations gracefully.

ConversationEntityMemory

A different approach entirely. Instead of storing a transcript or a summary, it extracts entities from the conversation — names, places, products, concepts — and tracks what the model knows about each one.

from langchain.memory import ConversationEntityMemory
from langchain_openai import OpenAI

llm = OpenAI(temperature=0)
memory = ConversationEntityMemory(llm=llm)

If you mention "Priya is the team lead on the backend project," the memory stores that fact about Priya. Later, when you ask "what's Priya working on?", the model has the entity context to answer correctly — even if the original message was 50 turns ago.

Useful when your chatbot needs to track facts about specific people or things across a long session, not just the conversational flow.

Picking one

Memory type	Keeps	Best for
`ConversationBufferMemory`	Full transcript	Short sessions, prototypes
`ConversationBufferWindowMemory`	Last `k` exchanges	Chat UIs with short context needs
`ConversationSummaryMemory`	LLM-generated summary	Long sessions, token budget matters
`ConversationSummaryBufferMemory`	Recent messages + summary of older ones	Production bots, variable session lengths
`ConversationEntityMemory`	Facts about named entities	Assistants tracking people, places, things

Start with ConversationBufferMemory when you're prototyping — it's zero config and easy to debug. Move to ConversationSummaryBufferMemory when you start hitting token limits or dealing with sessions that run long. Use ConversationEntityMemory when your use case is genuinely about tracking facts across a conversation, not just maintaining thread.

Every memory type plugs into ConversationChain (or any chain that accepts a memory argument) the same way. The interface doesn't change — just what gets stored and how.

Embeddings Explained for LangChain Beginners

2026-07-30T00:00:00+05:30

Before you can build a retrieval system, you need to understand what embeddings are and why they exist. Skip this and the rest of RAG won't make sense — you'll be configuring things without knowing what they do.

What an embedding is

An embedding is a list of numbers that represents the meaning of a piece of text. A sentence, a paragraph, a document — each one gets converted into a fixed-length vector of floats, typically hundreds or thousands of dimensions long.

The useful property: texts that mean similar things end up with vectors that are close together in that high-dimensional space. "The cat sat on the mat" and "A feline rested on the rug" will have similar embeddings. "Stock market futures" will be far away from both.

This is what makes semantic search possible. You're not matching keywords — you're measuring meaning distance.

Why LangChain needs them

LangChain's retrieval pipeline works like this:

Split documents into chunks
Embed each chunk into a vector
Store those vectors in a vector database
At query time, embed the user's question
Find the chunks whose vectors are closest to the question vector
Pass those chunks to the LLM as context

Steps 2 and 4 are where embeddings come in. The same embedding model has to handle both — if you embed your documents with one model and your queries with another, the vectors live in different spaces and the similarity search breaks.

Using embeddings in LangChain

LangChain wraps embedding models behind a common interface. Here's the OpenAI embedder:

from langchain_openai import OpenAIEmbeddings

embedder = OpenAIEmbeddings(model="text-embedding-3-small")

# Embed a single query
query_vector = embedder.embed_query("What is gradient descent?")

# Embed a list of documents
doc_vectors = embedder.embed_documents([
    "Gradient descent is an optimization algorithm.",
    "Neural networks learn by adjusting weights.",
    "Python is a general-purpose programming language."
])

print(len(query_vector))       # 1536 for text-embedding-3-small
print(len(doc_vectors))        # 3 vectors
print(len(doc_vectors[0]))     # 1536 floats per vector

embed_query is for single inputs at retrieval time. embed_documents is for batching your corpus during indexing. The distinction is minor — some models apply different preprocessing to each — but it's the correct way to call the interface.

Using a local embedding model

You don't need an API for embeddings. HuggingFace models run locally and are free.

from langchain_huggingface import HuggingFaceEmbeddings

embedder = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")

vector = embedder.embed_query("How do transformers work?")
print(len(vector))  # 384

all-MiniLM-L6-v2 is a solid starting point — small, fast, and good enough for most tasks. The vectors are 384-dimensional instead of 1536, which means smaller storage and faster search at the cost of some precision.

For production use cases where accuracy matters more than latency or cost, text-embedding-3-large from OpenAI or bge-large-en-v1.5 from BAAI are worth testing.

What similarity actually means

Once you have vectors, you need a way to measure how close two of them are. The two most common measures:

Cosine similarity — measures the angle between vectors. Two vectors pointing in the same direction score 1.0, regardless of their magnitude. This is the default for most embedding models because it handles texts of different lengths gracefully.

Dot product — measures both direction and magnitude. Faster to compute, but sensitive to vector scale. Some models (like OpenAI's) are trained to use dot product — check the model docs before assuming cosine is correct.

In practice, LangChain and most vector databases handle this for you. But knowing which one your retriever uses matters when you're debugging why certain results rank unexpectedly.

Embeddings are frozen at index time

One thing that trips people up: the embedding model doesn't run at query time on your stored documents. You embed documents once, store the vectors, and those vectors stay fixed. The model only runs again when you embed a new query or add new documents.

This means if you switch embedding models after indexing, you have to re-embed your entire document store. The old vectors and new query vectors are incompatible — they live in different spaces. Build your pipeline with a specific model chosen early, or you'll be re-indexing a lot.

A complete example

Here's the full flow from documents to query — embeddings included:

from langchain_openai import OpenAIEmbeddings
from langchain.vectorstores import FAISS
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Your raw text
documents = [
    "LangChain is a framework for building LLM applications.",
    "FAISS is a library for efficient vector similarity search.",
    "Embeddings convert text into numerical vectors.",
    "RAG combines retrieval with language model generation."
]

# Split (skip for short texts, but good practice)
splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=20)
chunks = splitter.create_documents(documents)

# Embed and store
embedder = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = FAISS.from_documents(chunks, embedder)

# Query
query = "What is RAG?"
results = vectorstore.similarity_search(query, k=2)

for r in results:
    print(r.page_content)

FAISS.from_documents calls embed_documents under the hood and builds the index. similarity_search calls embed_query on your question, then finds the closest vectors. The LLM step would come after — you pass results as context into a prompt.

Choosing an embedding model

A few things to weigh:

Dimension size — higher dimensions capture more nuance but cost more storage and compute. 384 is fine for prototypes; 1536 or 3072 for production.
Max input tokens — most models cap at 512 or 8192 tokens per chunk. Chunks longer than the cap get silently truncated. Know your model's limit before indexing.
Domain fit — general models handle general text well. For legal, medical, or code-heavy corpora, look for domain-specific models or test a few before committing.
Cost — local models are free to run. API-based models charge per token. At scale, that adds up.

The embedding layer looks like configuration. It's actually one of the most load-bearing decisions in a RAG pipeline.

LangSmith Basics: Debugging and Tracing Your Chains

2026-07-30T00:00:00+05:30

LLM applications fail in ways that are hard to see. A chain returns a bad answer and you don't know whether the prompt was wrong, the retriever missed, or the model just hallucinated. LangSmith is how you look inside.

What LangSmith is

LangSmith is Anthropic's observability platform for LangChain — it records every step of your chain as a trace. Prompt inputs, LLM outputs, retrieval results, tool calls, token counts, latency — all of it, in one place, for every run.

You don't change how your chain is written. You add a few environment variables and tracing happens automatically.

Setting it up

Create an account at smith.langchain.com and grab an API key from the settings page. Then set these before your chain runs:

import os

os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_ENDPOINT"] = "https://api.smith.langchain.com"
os.environ["LANGCHAIN_API_KEY"] = "your-api-key-here"
os.environ["LANGCHAIN_PROJECT"] = "my-first-project"

LANGCHAIN_PROJECT is just a label — traces get grouped under it in the UI. Use something descriptive: the chain name, the feature, or the experiment you're running.

After that, run any LangChain code. The traces show up in your project dashboard automatically.

What a trace looks like

Every chain run produces a tree of spans. The root span is the chain itself. Under it, you'll see child spans for each step — LLM calls, retrieval operations, tool invocations, memory reads.

Each span shows:

Input — what was passed in at that step
Output — what came back
Latency — how long it took
Token usage — prompt tokens, completion tokens, total
Errors — if the step threw, the full traceback

For a simple ConversationChain, the trace is shallow — one LLM call with the formatted prompt and the raw response. For a multi-step agent, the tree can go several levels deep with tool calls branching off the main path.

Debugging a bad output

Say your RAG chain returns a wrong answer. Without tracing, you're guessing. With LangSmith, you open the trace and work backwards:

Look at the LLM span — what prompt did the model actually receive? Was the context there?
Look at the retrieval span — what chunks came back? Were they relevant?
Look at the query — did the question get reformulated somewhere upstream?

Most of the time, the problem is obvious once you see the actual prompt. A template bug, a missing variable, a retriever that returned garbage — these all show up immediately.

from langchain.chains import RetrievalQA
from langchain_openai import OpenAI, OpenAIEmbeddings
from langchain.vectorstores import FAISS

llm = OpenAI(temperature=0)
embedder = OpenAIEmbeddings()
vectorstore = FAISS.from_texts(
    ["LangSmith traces every step of your LangChain runs."],
    embedder
)
retriever = vectorstore.as_retriever()

chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)

# This run will appear in LangSmith with full retrieval + LLM trace
result = chain.run("What does LangSmith do?")
print(result)

Open the project in the UI after this runs. You'll see the retrieval span with the exact chunks that were fetched, then the LLM span with the fully-rendered prompt those chunks were injected into.

Adding metadata and tags

Traces are more useful when you can filter them. LangSmith lets you attach metadata and tags to runs:

from langchain.callbacks.manager import collect_runs

with collect_runs() as cb:
    result = chain.run(
        "What does LangSmith do?",
        tags=["production", "rag-v2"],
        metadata={"user_id": "u_123", "session_id": "s_456"}
    )
    run_id = cb.traced_runs[0].id
    print(f"Trace ID: {run_id}")

Tags and metadata let you slice your traces in the UI — filter by environment, by user, by chain version. When you're running experiments, tags are how you keep the results organized.

Comparing runs

LangSmith has a comparison view. Select two runs from the same project and it shows you inputs, outputs, and latencies side by side. This is useful when you change a prompt and want to know whether the new version actually improved things — not just on the one example you tested manually, but across a batch.

Datasets and evaluation

Once you have traces, you can promote individual runs to a dataset. Pick a run where the output was correct, save it as an example, and build up a test set over time. LangSmith can then run your chain against the dataset and score outputs automatically.

from langsmith import Client

client = Client()

# Create a dataset
dataset = client.create_dataset("rag-eval-set")

# Add an example
client.create_example(
    inputs={"query": "What does LangSmith do?"},
    outputs={"answer": "LangSmith traces every step of LangChain runs."},
    dataset_id=dataset.id
)

From here you can run evaluations programmatically or trigger them from the UI. It's a short path from "this answer looked right" to a repeatable regression test.

What to check first when things break

In rough order of how often each one is the actual problem:

Formatted prompt — look at the LLM input span. Is the prompt what you expected? Template bugs show up here.
Retrieved chunks — if the answer is in your documents but the model missed it, check what the retriever actually returned.
Token counts — if a run is slow or expensive, check whether a prompt is bloated. Memory accumulation and large context injections show up clearly here.
Latency by step — if a chain is slow, the latency breakdown shows exactly which step is the bottleneck.

LangSmith won't fix your chain for you, but it removes the guesswork. Most debugging sessions that used to take an hour of print statements take five minutes once you can see every step.

Text Splitters Explained: Why Chunking Strategy Matters

2026-07-30T00:00:00+05:30

When you build a retrieval-augmented system, most of the tuning work happens before the LLM ever sees a document. How you split text determines what gets retrieved — and bad splits mean bad answers, even with a great model.

The problem with long documents

LLMs have a context window. You can't dump a 50-page PDF into a prompt. So you split it into chunks, embed each chunk, store them in a vector database, and retrieve the most relevant ones at query time.

The question is: how do you split? Cut in the wrong place and you get chunks that are missing context, start mid-sentence, or bury the answer across a boundary where no single retrieval will find it. The model can only work with what you hand it.

CharacterTextSplitter

The most basic option. It splits on a character — usually a newline or a space — and tries to keep chunks under a specified size.

from langchain.text_splitter import CharacterTextSplitter

splitter = CharacterTextSplitter(
    separator="\n",
    chunk_size=500,
    chunk_overlap=50
)

chunks = splitter.split_text(your_text)

chunk_size controls how big each chunk gets (in characters). chunk_overlap is how much text repeats between adjacent chunks — this matters because answers sometimes straddle a boundary, and overlap gives the retriever a chance to catch them.

It works. It's also blunt. A \n split doesn't know whether it's cutting between paragraphs or in the middle of a table.

RecursiveCharacterTextSplitter

This is the one LangChain recommends by default — and for good reason. Instead of one separator, it tries a list of them in order: ["\n\n", "\n", " ", ""]. It starts with paragraph breaks, falls back to line breaks, then words, then characters.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)

chunks = splitter.split_text(your_text)

The result is chunks that respect natural text structure wherever possible. A paragraph that fits under the size limit stays together. Only when it's too big does the splitter go finer. That behavior makes retrieved chunks far more coherent than character-level splits.

Use this as your starting point for most plain-text documents.

TokenTextSplitter

CharacterTextSplitter measures chunk size in characters. But LLMs charge for tokens, and token count doesn't map cleanly to character count — especially across languages, code, or punctuation-heavy text.

TokenTextSplitter measures in tokens instead.

from langchain.text_splitter import TokenTextSplitter

splitter = TokenTextSplitter(chunk_size=200, chunk_overlap=20)
chunks = splitter.split_text(your_text)

When your context window budget is tight and you're working with text that has variable token density — technical docs, mixed-language content, code — this gives you more precise control.

MarkdownHeaderTextSplitter

Structure-aware splitting. For Markdown documents, this one splits on headers (#, ##, ###) and carries the header metadata into each chunk.

from langchain.text_splitter import MarkdownHeaderTextSplitter

headers_to_split_on = [
    ("#", "Header 1"),
    ("##", "Header 2"),
    ("###", "Header 3"),
]

splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on)
chunks = splitter.split_text(your_markdown)

Each chunk knows which section it came from. When you store these in a vector database, you can filter by section at retrieval time or include the header in the chunk text so the LLM has context about where the content lives.

Good fit for technical documentation, wikis, or any structured Markdown corpus.

PythonCodeTextSplitter / Language splitters

Code has its own structure — functions, classes, blocks. Splitting it on character count will cut through function definitions and break the semantic unit the retriever should be working with.

from langchain.text_splitter import RecursiveCharacterTextSplitter, Language

splitter = RecursiveCharacterTextSplitter.from_language(
    language=Language.PYTHON,
    chunk_size=500,
    chunk_overlap=50
)

chunks = splitter.split_text(your_python_code)

LangChain supports multiple languages here — Python, JS, Markdown, HTML, and others. The splitter knows the syntax boundaries for each and tries to keep logical units intact.

Why chunk_overlap matters

Every splitter has a chunk_overlap parameter and it's worth taking seriously. If your chunks are 500 characters with zero overlap, a sentence that starts at character 495 of one chunk and ends at character 10 of the next is effectively unfindable — no single retrieved chunk contains it whole.

Overlap duplicates some text across adjacent chunks so that boundary content shows up fully in at least one of them. A 10–20% overlap is a reasonable default. Bigger overlaps help retrieval quality but increase your vector store size and embedding cost.

The actual impact on retrieval quality

Chunking strategy doesn't change what the LLM knows — it changes what the retriever can find. A model can only answer from what gets passed to it. If the relevant passage is split across two chunks and only one is retrieved, you get a partial answer or no answer. If chunks are too large, retrieved content is noisy and the signal gets buried.

Most RAG failures that look like model failures are actually retrieval failures. And most retrieval failures trace back to chunking. Get this layer right before you start tuning embeddings or prompts.

A reasonable starting point: RecursiveCharacterTextSplitter with chunk_size=500, chunk_overlap=50, then look at what your actual retrieved chunks contain. If the model keeps missing things that are clearly in the document, the chunk boundary is usually why.

Graph RAG: Retrieval Augmented Generation Meets Knowledge Graphs

2026-07-12T00:00:00+05:30

Standard RAG retrieves chunks of text and hands them to an LLM. Graph RAG retrieves a structured slice of a knowledge graph instead — entities, relationships, and the paths between them. That shift changes what kinds of questions the system can actually answer.

Why vector search runs out of road

Chunk retrieval — A vector database finds text chunks that are semantically similar to a query and stuffs them into the prompt. It works well for lookup questions: "What was the revenue in Q3?" It breaks down for questions that need connecting several facts scattered across different documents.

The multi-hop problem — Ask "Which suppliers does our biggest customer's biggest competitor use?" and a vector search has no reliable way to chain that logic. Each chunk is retrieved independently based on similarity to the query, not based on the relationships between the entities involved.

Lost global context — A single chunk rarely captures how an entity relates to the rest of the document set. A knowledge graph does, because the relationships are stored explicitly rather than implied by proximity in text.

What Graph RAG actually does

Graph RAG builds a knowledge graph from source documents, then retrieves subgraphs relevant to a query instead of flat text chunks.

Entity extraction — An LLM (or a dedicated NER pipeline) reads the source documents and pulls out entities: people, organizations, products, events, dates.

Relationship extraction — The same pass identifies relationships between entities — "acquired," "reports to," "supplies," "located in" — and stores them as edges connecting the entity nodes.

Graph construction — Entities and relationships get written into a graph database (Neo4j, TigerGraph, or a similar store). Each node can carry metadata and a link back to the source text it came from.

Community detection — Many Graph RAG implementations, including Microsoft's original approach, cluster the graph into communities of closely related entities and generate a summary for each cluster. This gives the system a mid-level view between raw entities and the full graph.

Query-time retrieval — At query time, the system identifies relevant entities in the question, walks the graph to pull connected nodes and relationships, and passes that structured context to the LLM alongside or instead of raw text chunks.

Local search vs global search

Microsoft's Graph RAG paper splits retrieval into two modes, and the distinction matters for how you design a system around it.

Local search — Starts from specific entities mentioned in the query and expands outward through their direct relationships. Good for questions about a particular entity: "What products does this company make?"

Global search — Uses the community summaries to answer questions about the dataset as a whole: "What are the main themes across all these documents?" Vector search can't do this at all, since no single chunk contains a dataset-wide view.

Where it helps and where it doesn't

Graph RAG isn't a universal upgrade over vector RAG. It's a different tool for a different shape of problem.

Multi-hop reasoning across entities and relationships
Questions that require a summary or theme across an entire corpus, not a single document
Domains with a naturally graph-like structure: org charts, supply chains, citation networks, regulatory filings
Answers where traceability to a specific relationship chain matters, since graph paths are auditable in a way that "top-k similar chunks" isn't

It costs more to build and maintain. Extracting entities and relationships accurately requires either a strong LLM pass over every document or a hand-tuned extraction pipeline, and errors compound: a missed or mislabeled edge quietly breaks every query that depends on it. For a simple FAQ bot or single-document Q&A, plain vector RAG remains faster to build and cheaper to run.

Rule of thumb: if your questions are "find the fact," use vector RAG. If they're "connect the facts," look at Graph RAG.

A few implementation notes

Hybrid retrieval — Most production systems don't pick one or the other. They combine vector search for initial candidate retrieval with graph traversal for relationship expansion, then merge both into the final context window.

Extraction quality is the bottleneck — The graph is only as good as the entity and relationship extraction step. Garbage extraction produces a graph full of duplicate entities and missing edges, and no amount of clever retrieval logic fixes that downstream.

Cost — Building the graph is a one-time (or periodic) batch cost, separate from query-time cost. Budget for re-running extraction as source documents get added or updated, not just for the initial build.

MCP: A Common Protocol for Connecting LLMs to Tools

2026-07-12T00:00:00+05:30

Every LLM app that wants to read a file, query a database, or call an API needs some way to describe that capability to the model and route the model's requests back to the right system. Before MCP, every vendor built that wiring differently. MCP is Anthropic's attempt at a shared standard for it.

The problem it solves

N×M integrations — Without a standard, connecting M different LLM apps to N different tools means building M×N custom integrations. Each app writes its own connector for Slack, its own connector for GitHub, its own connector for a Postgres database.

No portability — A tool integration built for one LLM app usually can't be reused in another. The tool description format, the auth handling, the request/response shape — all of it is bespoke.

Context fragmentation — Tools built ad hoc for a single app tend to be shallow: enough to answer one demo query, not enough to be a real interface to the underlying system.

What MCP is

MCP defines a client-server protocol for exposing data and functionality to LLM applications, built on JSON-RPC.

MCP servers — A server exposes one or more capabilities: tools (functions the model can call), resources (data the model can read, like files or database records), and prompts (reusable prompt templates). A server might wrap a single system — GitHub, Google Drive, a local filesystem — or several related ones.

MCP clients — The LLM application (Claude Desktop, an IDE, a custom agent) runs an MCP client that connects to one or more servers, discovers what they expose, and routes model requests to the right server.

Transport — Servers can run locally over stdio, which is common for filesystem or local-tool access, or remotely over HTTP with server-sent events, which is common for hosted services like a company's internal API.

The three primitives

Tools — Functions with a name, a description, and a JSON schema for inputs. The model decides when to call one based on the conversation; the client executes it and returns the result.

Resources — Structured or unstructured data the client can fetch and inject into context — a file's contents, a database row, a page from a wiki. Unlike tools, resources are typically read, not invoked with arguments.

Prompts — Predefined prompt templates a server can offer, often parameterized, so a client doesn't have to hardcode common workflows.

Why build a server instead of a custom integration

Building against MCP instead of a proprietary plugin API means the same server works across every MCP-compatible client without rewriting it. Anthropic ships MCP support in Claude Desktop and the API; other vendors have added client support since. A team maintaining a GitHub integration built as an MCP server gets Claude Desktop, IDE plugins, and custom agents as consumers, without three separate integration codebases.

There's a real ecosystem argument here too: a growing catalog of community and vendor-built servers (Slack, Postgres, Google Drive, Sentry, and others) means many integrations don't need to be built at all.

Tradeoffs

MCP is young, and that shows up in a few places.

Server quality varies a lot — some are thin wrappers with poor error handling, others are well-built
Security models differ by transport: a local stdio server runs with the permissions of whatever launched it, which is a different trust boundary than a hosted HTTP server behind auth
Discovery and versioning across many servers is still mostly manual; there's no centralized registry with strong guarantees yet
Not every LLM vendor supports it, so it's not yet a universal standard the way HTTP is

None of that erases the core value: MCP moves tool integration from "build it per app" to "build it once, connect it everywhere that speaks the protocol." Whether it becomes the actual industry standard depends on adoption outside Anthropic's own ecosystem, which is still playing out.

If you're deciding whether to build a custom tool integration or an MCP server, the MCP server is almost always the better long-term bet — the marginal cost over a custom integration is small, and the reuse is large.

Agents vs. Chains in LangChain: Who's Actually Driving?

2026-07-10T00:00:00+05:30

A chain follows the map you drew. An agent draws its own.

LangChain gives you two ways to wire an LLM into a workflow: chains and agents. Both connect prompts, tools, and models into something useful, but the control flow works in opposite directions.

Chains: fixed routes

A chain is a sequence of steps you define up front. Step one calls the model, step two parses the output, step three feeds it into a database lookup, step four formats a response. The order is fixed at build time, and the LLM has no say in what happens next.

LLMChain — The simplest building block: a prompt template plus a model call. Input goes in, text comes out.

SequentialChain — Runs multiple chains back to back, passing outputs forward as inputs. Good for multi-stage pipelines like "summarize, then translate, then extract keywords."

RouterChain — Picks one of several chains to run based on the input, but the routing logic itself is deterministic code, not a model deciding mid-task.

Chains are predictable. You can trace exactly what will happen before you run anything, and that makes them easy to test and debug.

Agents: the model picks the path

An agent flips the control. Instead of a hardcoded sequence, the LLM gets a set of tools and a goal, and it decides at each step what to do next: which tool to call, what input to give it, and when it's done.

Tool — A function the agent can call: a search API, a calculator, a SQL query runner, a custom Python function. The agent decides when and how to use it.

AgentExecutor — The runtime loop that lets the agent think, act, observe the result, and think again, until it reaches a final answer.

ReAct pattern — A common agent style where the model alternates between reasoning ("I need to look up the current stock price") and acting (calling the tool that does it).

This loop keeps going until the agent decides it has enough information to answer, or it hits a step limit you set as a safeguard.

Where the two actually diverge

The core difference isn't the tools or the prompts. It's who decides the next step.

In a chain, you decide. The path is baked into your code.
In an agent, the model decides. The path emerges while it runs.

That single distinction cascades into everything else. Chains are deterministic and fast because there's no reasoning overhead between steps. Agents are flexible but slower and less predictable, since each decision costs a model call and a wrong turn can send the whole task off track.

When to use which

Reach for a chain when the task has a known shape: extract fields from a document, translate text, summarize an article. You already know the steps, so let code handle the sequencing and save the model calls for the parts that actually need judgment.

Reach for an agent when the task's shape depends on the input: answering open-ended questions that might need a web search, a calculation, or a database query depending on what's asked. You can't write that branching logic by hand because you don't know in advance which branch applies.

A lot of production systems end up doing both — a chain that occasionally calls out to an agent for the one step that needs open-ended tool use, then hands control back to the fixed sequence. Pick the smallest amount of agency the task actually requires. More autonomy means more places for things to go wrong.

Stop Feeding Your LLM Guesses. Feed It Facts.

2026-07-04T00:00:00+05:30

The trick that turns a language model into a research assistant.

Large language models are great at reasoning and writing, but they only know what they were trained on. Ask one about a document it's never seen, or something that happened after its training cutoff, and it will either say it doesn't know or, worse, make something up.

Retrieval-Augmented Generation fixes this. Instead of relying only on the model's memory, you hand it relevant information at the moment you ask the question. The model reads that information and answers based on it. That's the whole idea. Everything else is implementation detail.

This article walks through building a simple RAG app: one that answers questions about a PDF you give it.

What RAG actually does:

A RAG system has two jobs: find the right information, then generate an answer using it.

Say you upload a 50-page company handbook and ask "how many vacation days do new hires get?" The system doesn't feed the entire handbook to the model — that would be slow and expensive, and most of it is irrelevant to the question. Instead, it searches the handbook for the few paragraphs most likely to contain the answer, and only sends those to the model along with your question.

The model then reads that small chunk of text and answers, grounded in what it just read rather than guessing from memory.

The four steps:

Every RAG pipeline, no matter how complex it eventually gets, boils down to four steps:

1. Load the document. Pull in your source material — a PDF, a website, a spreadsheet, whatever you're working with.

2. Split it into chunks. Documents are usually too long to search effectively as one block. You break them into smaller pieces, often a few hundred words each, sometimes overlapping slightly so you don't cut a sentence in half.

3. Embed and store the chunks. Each chunk gets converted into a vector — a list of numbers that captures its meaning. These vectors go into a vector database. This is what lets you search by meaning instead of exact keyword matches.

4. Retrieve and generate. When a question comes in, you convert it into a vector too, find the stored chunks whose vectors are closest to it, and pass those chunks plus the question to the language model. The model generates an answer using that context.

Building it:

Here's what this looks like in code, using LangChain, OpenAI's embeddings, and a local vector store called Chroma.

Step 1: Install what you need

bashpip install langchain langchain-openai langchain-community chromadb pypdf

Step 2: Load your document

pythonfrom langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("handbook.pdf") documents = loader.load()

documents is now a list of page objects, each holding the text from one page of the PDF.

Step 3: Split into chunks

pythonfrom langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50 ) chunks = splitter.split_documents(documents)

The overlap matters more than it looks. Without it, a sentence that spans two chunks can get cut in a way that loses meaning in both pieces.

Step 4: Embed and store

pythonfrom langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma

embeddings = OpenAIEmbeddings() vectorstore = Chroma.from_documents(chunks, embeddings)

This one block does the heavy lifting: it turns every chunk into a vector and saves it so you can search it later.

Step 5: Set up retrieval and generation

pythonfrom langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(), return_source_documents=True )**

Step 6: Ask a question

pythonresult = qa_chain.invoke({"query": "How many vacation days do new hires get?"}) print(result["result"])

That's a working RAG app. Feed it a PDF, ask it questions, and it answers based on the actual document rather than a guess.

Why it works better than just asking the model directly:

Without retrieval, the model has no way to know what's in your specific PDF. It might recognize general patterns about vacation policies, but it can't tell you your company's actual number.

With retrieval, the model sees the relevant paragraph before answering. It's the difference between asking someone to recall a policy from memory versus handing them the policy document and asking them to read the relevant page first.

This also cuts down on hallucination. A model working from a document in front of it is far less likely to invent details than one working purely from its training data.

A few things to watch for:

Chunk size matters more than you'd think. Too small, and chunks lose context — a number without the sentence explaining what it refers to. Too large, and you dilute the search: the model retrieves a big chunk where only one sentence is actually relevant, and the rest is noise.

Retrieval isn't perfect. If your question uses different words than the document, the vector search might miss the right chunk. Testing with a range of phrasings helps you catch this early.

More chunks isn't always better. Retrieving the top 10 chunks instead of the top 3 sounds safer, but it can bury the model in irrelevant text and make the answer worse, not better.

Where to go from here:

Once this basic version works, a few natural upgrades:

Swap in a hosted vector database like Pinecone or Weaviate if you need to scale past a local file.

Add a step that shows which source chunks the answer came from, so users can verify it.

Try different embedding models — some handle domain-specific language (legal, medical, technical) better than general-purpose ones.

Experiment with re-ranking retrieved chunks before sending them to the model, which can noticeably improve answer quality on tricky questions.

None of these are required to get started. The six steps above are enough to go from a static PDF to a system you can actually ask questions and get real answers from.

The Five Building Blocks of LangChain

2026-07-04T00:00:00+05:30

Most people's first LangChain project looks the same. They copy a snippet, swap in their API key, run it, and get a working chatbot in about ten minutes. Then they try to add memory, or connect a second tool, or make the thing reason through a multi-step task, and the whole mental model falls apart. The tutorial made it look like magic. It wasn't magic. It was five components working together, and nobody explained what each one actually does.

So let's fix that. Five pieces: Models, Prompts, Chains, Memory, Agents. Once you know what each one is for, LangChain stops feeling like a black box and starts feeling like a toolkit.

Models: the engine, not the car

A model in LangChain is just a wrapper around a language model API — OpenAI, Anthropic, Cohere, a local Llama instance, whatever you're using. LangChain doesn't make the model smarter. It gives you one consistent interface so you can swap GPT-4 for Claude for a local model without rewriting your application logic.

That interface matters more than it sounds like it should. Say you build a product on OpenAI and six months later want to test whether Claude handles your use case better. Without an abstraction layer, that's a rewrite. With LangChain, it's often a one-line change.

pythonfrom langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-4", temperature=0.7) response = model.invoke("Explain quantum computing in one sentence.") print(response.content)

Two things worth knowing early. First, temperature controls randomness — near 0 for consistent, deterministic output, higher for creative variation. Second, LangChain distinguishes between LLMs (plain text in, text out) and chat models (structured messages with roles like system, human, and AI). Almost everything you build today will use chat models, because that's what modern providers optimize for.

The model is the engine. On its own, it's not a product. You need somewhere to point it.

Prompts: what you say determines what you get:

A prompt template is a reusable, parameterized instruction. Instead of hardcoding "Translate 'hello' to French," you write a template with a blank for the input, and reuse the same structure for any word or sentence.

pythonfrom langchain.prompts import ChatPromptTemplate

template = ChatPromptTemplate.from_template( "Translate the following text to {language}: {text}" )

prompt = template.format_messages(language="French", text="Good morning")

This looks trivial, but it's where most of the actual engineering happens once you're past the demo stage. A prompt template can include few-shot examples, formatting rules, output constraints, persona instructions — anything that shapes how the model responds. Change the wording and the model's behavior changes with it, sometimes dramatically. Prompt engineering isn't a nice-to-have skill on top of LangChain. It's the interface layer between your intent and the model's output, and templates are what make that interface manageable instead of a pile of string concatenation.

Chains: connecting the pipes

A chain links components together so output flows automatically from one step to the next. The simplest chain takes a prompt template, feeds it to a model, and hands you the result — no manual formatting, no manual API call.

pythonchain = template | model result = chain.invoke({"language": "Spanish", "text": "See you tomorrow"})

That pipe operator is LangChain Expression Language, or LCEL. It reads left to right: take the template, pipe it into the model. You can extend that pipeline as far as you need — parse the output, pass it into a second prompt, feed that into a different model, chain a retrieval step before any of it happens.

Chains are where LangChain earns its name. A single API call to a model is rarely enough for a real application. You need to retrieve context, format it, generate a draft, check the draft against a rule, maybe regenerate. Each of those is a link. String enough of them together and you've built a pipeline that would otherwise be scattered across a dozen manual function calls — except now it's declarative, testable, and easy to swap pieces in and out of.

Memory: making the model remember it's mid-conversation:

Here's a fact that surprises a lot of beginners: language models are stateless. Every API call is a clean slate. The model has no idea what you said two messages ago unless you explicitly send it that history again.

Memory in LangChain is the mechanism for doing that — storing past exchanges and re-injecting them into future prompts so the conversation feels continuous.

pythonfrom langchain.memory import ConversationBufferMemory from langchain.chains import ConversationChain

memory = ConversationBufferMemory() conversation = ConversationChain(llm=model, memory=memory)

conversation.invoke("My name is Alex.") conversation.invoke("What's my name?")

The second call works — the model answers "Alex" correctly — because memory quietly attached the first exchange to the second prompt. Without it, the model would have no way to know.

The catch is that conversation history isn't free. Every stored message gets resent with every new call, and tokens cost money and hit context limits. That's why LangChain offers several memory strategies beyond the basic buffer: summarizing old exchanges instead of storing them verbatim, keeping only the last N messages, or storing information as structured facts rather than raw transcript. Picking the right memory strategy is a real design decision, not a default you set once and forget.

Agents: when the model decides what to do next

Chains follow a path you define in advance. Agents don't. An agent uses the language model to decide, at runtime, which action to take — which tool to call, in what order, based on what it learns from each step.

Give an agent access to a calculator, a search API, and a database query tool, and ask it a multi-part question. It might search for a fact, calculate something with the result, then query the database to verify it — choosing that sequence itself rather than following a route you hardcoded.

pythonfrom langchain.agents import create_react_agent, AgentExecutor from langchain.tools import Tool

tools = [ Tool(name="Search", func=search_function, description="Search the web for current information"), Tool(name="Calculator", func=calculate, description="Perform mathematical calculations"), ]

agent = create_react_agent(model, tools, prompt) executor = AgentExecutor(agent=agent, tools=tools)

executor.invoke({"input": "What's the population of Japan divided by the population of the UK?"})

The agent recognizes it needs two numbers before it can do the division, searches for each one, then calculates the result — all without you writing that control flow by hand.

This is also where things get harder to predict. Agents can loop, misuse a tool, or take a route you didn't anticipate, because the reasoning happens inside the model rather than in code you wrote. Debugging an agent means reading through its intermediate steps to see where its logic diverged from what you expected, which is a different skill than debugging a fixed chain.

Putting it together:

A useful way to see how these fit: models generate, prompts instruct, chains connect, memory persists, agents decide. A basic Q&A bot might need only a model and a prompt. A customer support assistant that remembers earlier tickets needs memory. A research assistant that has to search, calculate, and cross-reference on its own needs an agent.

Most real applications end up using several of these together — a chain with memory attached, or an agent that calls a chain as one of its tools. Once you can name what each piece is doing, that combination stops looking like a black box and starts looking like a set of parts you're choosing.

Time Is a Lie We All Agreed To

2026-07-01T00:00:00+05:30

Why Does New York Have Two Different Time Zones? The Truth About EST, EDT, and Daylight Saving Time

Picture this: you schedule a video call with a colleague in New York for "3 PM Eastern." In March, that call lands at a different point in the day relative to the sun than it would in January — even though nobody moved, and the call is still "3 PM Eastern" both times. Confused? You're not alone. Millions of people use EST and EDT interchangeably, but they're not the same thing — and the gap between them is the reason you lose an hour of sleep every spring and gain it back every fall.

What Do EST and EDT Actually Mean?

Both belong to the same region — the Eastern Time Zone of North America, covering cities like New York, Boston, Atlanta, and Toronto — but they represent different offsets from Coordinated Universal Time (UTC).

EST — Eastern Standard Time is the "default" time. It sits 5 hours behind UTC (UTC−5) and is used in late fall, winter, and early spring.

EDT — Eastern Daylight Time is the "summer" version. It sits only 4 hours behind UTC (UTC−4) and is used in spring, summer, and early fall.

The key detail: EDT is one hour ahead of EST. They aren't two names for the same time — they're two different offsets used at different points in the year, depending on whether daylight saving time is active. Most people lump both under "Eastern Time" (ET), which just means whichever one currently applies — but for precise scheduling, knowing which one is in effect matters.

Why Does the Time Zone Change at All?

This is where Daylight Saving Time (DST) comes in — the engine behind the EST/EDT switch.

Daylight Saving Time is the practice of moving clocks forward an hour in spring and back an hour in fall, so daylight hours line up better with when people are actually awake, shifting unused early-morning light into the evening instead.

When DST starts, you "spring forward" and EST becomes EDT. When it ends, you "fall back" and EDT becomes EST — the "D" in EDT literally stands for Daylight.

Spring forward → clocks move ahead 1 hour → EST → EDT
Fall back → clocks move back 1 hour → EDT → EST

In the U.S. and most of Canada, the schedule has been fixed since 2007: DST begins the second Sunday in March at 2:00 AM (clocks jump to 3:00 AM) and ends the first Sunday in November at 2:00 AM (clocks fall back to 1:00 AM). For 2026, that means EDT starts March 8 and EST returns November 1. Notably, EDT is actually in effect for about eight months of the year — the longer stretch, not the exception.

Where Did This System Come From?

The U.S. adopted standardized time zones in 1918, amid real public resistance to the idea of "chasing daylight" by clock. Daylight saving itself took off as a wartime energy-conservation measure during World War I.

For decades after World War II, states set their own daylight saving schedules with no coordination, creating chaos for interstate travel. The Uniform Time Act of 1966 finally standardized the practice nationally (though states could still opt out). In 1986, Congress extended the DST period to save energy, and the current schedule arrived with the Energy Policy Act of 2005, taking effect in 2007.

Not Everyone Plays Along

Daylight saving isn't universal even within the U.S. Arizona (apart from the Navajo Nation), Hawaii, Puerto Rico, and a few other territories stay on standard time all year — which is why their offset relative to neighboring states actually shifts depending on the season. Also worth knowing: the correct term is "Daylight Saving Time," not "Daylight Savings Time."

How to Keep It Straight

	Offset from UTC	When it's used	Mnemonic
EST (Standard)	UTC−5	Fall through winter	"S" = sleepier, shorter days
EDT (Daylight)	UTC−4	Spring through fall	"D" = daylight, longer evenings

Rule of thumb: between mid-March and early November, you're almost certainly in EDT. Outside that window, it's EST.

Why This Still Matters

Even with auto-updating phones, the EST/EDT switch still causes missed meetings and groggy mornings twice a year — and remains genuinely contested policy, with some pushing for permanent daylight saving time and others (including farmers' groups) preferring permanent standard time.

So next time your phone quietly jumps an hour overnight, you'll know exactly why.

CORS: The Bouncer Your Browser Hired Without Telling You

2026-06-30T00:00:00+05:30

What's really happening when your frontend can't talk to your backend

You've built a beautiful web app. Your frontend hums along on localhost:3000, your API waits on localhost:5000, and you fire off your first request between them. Instead of data, you get a wall of red text: "blocked by CORS policy." No explanation that makes sense, just a browser flatly refusing to let two parts of your own project talk to each other.

This single error has confused more developers and derailed more demos than almost any other concept in web development. The fix often feels unnecessary, because nothing about the request looks broken. The server is up, the URL is correct, the data is right there. So why won't the browser let it through?

The answer is CORS: Cross-Origin Resource Sharing. Once you understand what it actually is, it stops looking like an obscure bug and starts looking like exactly what it is, a security guard doing its job a little too literally.

A Crime That Never Happened (But Almost Did)

To understand why CORS exists, picture the web before it did.

You're logged into your bank's website in one tab. In another, you visit a sketchy site containing a hidden script. That script quietly fires a request to your bank's "transfer funds" endpoint, using your browser. Because your browser automatically attaches your bank's login cookie to requests sent to the bank's domain, the request looks legitimate to the server. It has no idea the request came from a malicious page instead of the bank's own interface. Money moves. You never clicked a thing.

This is a real, historically common attack called Cross-Site Request Forgery, and the only reason it doesn't happen to you daily is that browsers stepped in to prevent it, using a system called the Same-Origin Policy, with CORS built on top to relax it safely when needed.

The Same-Origin Policy: The Rule Behind the Rule

Long before CORS, browsers adopted a blunt rule: a webpage from one origin should not read data from a different origin, full stop.

An "origin" is defined by protocol, domain, and port together. If any one differs between two URLs, they're different origins, even if they look related. So https://myapp.com and http://myapp.com differ by protocol; https://myapp.com and https://api.myapp.com differ by domain; and localhost:3000 and localhost:5000 differ by port, which is exactly why your own frontend and backend trigger the same restriction a stranger's script would.

This Same-Origin Policy says: by default, JavaScript on one origin cannot read responses from a different origin. The request might still go out, but the browser blocks the page's script from seeing what comes back.

That's a great defense against the bank scenario. But the modern web depends on origins constantly talking to each other, frontends calling APIs, payment providers, maps, fonts, third-party logins. Taken literally, the Same-Origin Policy would forbid all of it. So the web needed an escape hatch: a way for a server to say, "I know this request is cross-origin, and that's fine, I trust it." That escape hatch is CORS.

CORS: Permission Slips for the Internet

CORS is a system of HTTP headers that lets a server explicitly tell browsers which other origins may access its resources. The Same-Origin Policy is the strict teacher who says no field trips. CORS is the signed note that says, "this specific kid can go on this specific trip."

When your frontend sends a request to your API, the browser tags it with an Origin header. The server processes it and can include a response header called Access-Control-Allow-Origin. If that header lists the requesting origin (or a wildcard *), the browser hands the response to your JavaScript. If it's missing or lists something else, the browser discards the response and throws the familiar error.

Notice the important detail: the server usually did receive and process the request, and the data was generated. The browser just refuses to let your script see it, because permission was never granted. This is why CORS errors feel disorienting, the failure isn't in the network; it's a rule enforced after the fact.

The Preflight Request: An Extra Knock Before Entering

Simple requests, like a basic GET with standard headers, follow the flow above directly. But complex requests, a POST carrying JSON, a request with custom headers like an authorization token, trigger an automatic preflight request first.

A preflight uses the OPTIONS method, essentially asking the server: "before I send the real request, will you even allow this? What methods and headers are permitted?" The server answers with headers like Access-Control-Allow-Methods and Access-Control-Allow-Headers. Only if that preflight succeeds does the browser send the actual request, automatically and invisibly, unless you check the network tab.

Why This Lives in the Browser, Not the Server:

CORS is enforced by the browser, not the server or the network. This explains a lot. Tools like Postman or curl, or one backend calling another, are unaffected, since there's no browser deciding whether to hide a response from a script. "But it works in Postman!" is a common but misleading observation; Postman was never going to be blocked, so the test doesn't prove what people think it proves.

This also clarifies what CORS actually protects. The request typically still reaches the server and gets processed; CORS isn't stopping that. What it protects is the user's browser, by preventing a malicious page from using an already-authenticated session to read sensitive responses it has no business seeing.

Fixing It: What the Server Actually Needs to Do

Because CORS is fundamentally about the server granting permission, the fix lives on the server side. A server can allow a specific origin with Access-Control-Allow-Origin: https://myapp.com, and most frameworks have CORS middleware that handles this in a few lines.

A server can allow any origin with Access-Control-Allow-Origin: *, which suits fully public APIs with no sensitive data, but is risky for anything involving authentication, since it removes the protection CORS provides.

For requests carrying cookies or credentials, the server must also set Access-Control-Allow-Credentials: true, and it cannot pair this with a wildcard origin; it must name the exact origin instead.

A frontend developer can't truly fix CORS from the client side, since the browser is simply respecting the server's stated wishes. Browser extensions that "disable CORS" only affect your own local browser, useful for debugging, but no real fix for actual users on a deployed site.

The Takeaway:

CORS often gets treated as an annoying obstacle to silence rather than understand. But it's one of the quieter, more elegant pieces of web infrastructure, a system that lets the open, interconnected web coexist with the basic expectation that one site shouldn't be able to secretly rummage through what you're doing on another.

The next time that red error shows up, it's not the browser being difficult for no reason. It's the bouncer at the door, checking the guest list, because somewhere, a server hasn't yet said "this one's with me."

Fine-Tuning Your AI: The Upgrade Everyone Wants and Almost No One Needs.

2026-06-21T00:00:00+05:30

It sounds like the obvious next step for any serious AI product. In practice, it's one of the most misunderstood — and most expensive — decisions in AI development.

It sounds like the obvious next step for any serious AI product. In practice, it’s one of the most misunderstood — and most expensive — decisions in AI development.

A founder once told me, “We need to fine-tune our model. That’s what the big companies do.”

He wasn’t wrong that big companies fine-tune models. He was wrong about why, and about what it would cost him to do the same.

Three months and a meaningful chunk of his budget later, his AI assistant was barely better than the version he started with — the one that took an afternoon to build instead of a quarter.

This happens more often than you’d think. So let’s talk about what fine-tuning actually is, why it’s so tempting, and why it quietly costs far more than the price tag suggests.

What fine-tuning actually means:

Think of a general-purpose AI model like a brilliant new employee, fresh out of a top university. They know a little about everything — law, medicine, coding, history — but nothing about your business specifically.

Fine-tuning is like sending that employee through months of specialized training, narrowly focused on your company’s exact way of doing things. Done right, you get someone deeply tuned to your specific needs.

Sounds great. And sometimes, it is. But here’s what that training program actually costs you.

Cost #1: The data you don’t have

To fine-tune well, you need hundreds or thousands of high-quality examples of exactly the behavior you want. Most companies think they have this data. Few actually do in a clean, usable form.

You usually end up paying people to create, clean, and label this data by hand — quietly one of the most expensive parts of the entire project, and the part least visible from the outside.

Cost #2: The model that forgets

Here’s the part that surprises people most: when you fine-tune a model on your data, it can get worse at things it used to do well. AI researchers call this “catastrophic forgetting” — the model overwrites old skills to make room for new ones, like a specialist who becomes so deep in their niche they lose their broader judgment.

So you don’t just need to test the new skill. You need to re-test everything the model used to do, to make sure nothing quietly broke.

Cost #3: The moving target

The AI field moves fast. A model you spend three months fine-tuning might be outperformed by a brand-new general-purpose model before your project even ships — one you could have used for free, today, with no training at all.

Fine-tuning locks you into a specific model version. Every time a better base model comes out, you face a choice: redo all that expensive work, or fall behind.

Cost #4: The maintenance nobody budgets for

A fine-tuned model isn’t a one-time purchase — it’s closer to a pet. It needs regular retraining as your business changes, ongoing monitoring to catch quiet drift in quality, and specialized people who know how to care for it. None of this shows up in the initial project plan. All of it shows up in the following year’s.

So when is it actually worth it?

Despite all this, fine-tuning isn’t a mistake — it’s a tool that’s right for a specific job. It tends to make sense when:

You need a very particular tone, format, or style, applied consistently, thousands of times a day

You have genuinely large amounts of clean, relevant data already sitting around

You’ve already tried the cheaper options — and hit a real, measurable wall

That last point matters most. Most teams hit no wall at all. They reach for fine-tuning before testing the much cheaper option: simply giving a general-purpose model clear instructions and relevant information at the moment it needs them — a technique that often gets 90% of the way to the dream outcome, for a fraction of the cost and none of the maintenance.

The real lesson

Fine-tuning isn’t a status symbol. It’s not the “advanced” version of using AI, and skipping it doesn’t mean you’re behind. It’s a specific tool for a specific, fairly narrow problem.

The best AI teams don’t ask, “How do we fine-tune our model?” They ask, “What’s the cheapest, simplest way to solve this — and is fine-tuning genuinely the only thing left that can do it?”

Nine times out of ten, it isn’t.

The AI Menu Is Huge. Here's How to Order.

2026-06-16T00:00:00+05:30

If you’ve ever Googled “best AI model” and ended up more confused than when you started — you’re not alone.

GPT this. Llama that. Claude, Mistral, Phi... it can feel like you’ve walked into a hardware store where every tool looks the same but nobody will tell you which one to grab.

Here’s the good news: once you understand a few simple ideas, the whole thing clicks. Let’s break it down.

Think of It Like a Toolbox

AI models aren’t one-size-fits-all. Just like you wouldn’t use a hammer to cut wood, different models are built for different jobs.

Microsoft’s AI Foundry catalog (a kind of “AI app store” for businesses) hosts over 1,900 models. Overwhelming? Sure. But they’re organized into helpful categories — so you don’t have to scroll through all 1,900.

Big Brain vs. Fast Brain: LLMs and SLMs

The first split you’ll encounter is between large and small language models.

Large Language Models (LLMs) — think GPT-5 or Llama 3 70B — are the deep thinkers. They’re great at complex writing, reasoning through tricky problems, and understanding long, nuanced context. The trade-off? They’re slower and more expensive to run.

Small Language Models (SLMs) — like Phi-4 or Llama 3 8B — are leaner and faster. They handle everyday tasks well and can even run on a laptop or a phone. If you need something quick and cost-effective, these are your go-to.

Everyday analogy: LLMs are like calling a specialist doctor. SLMs are like a knowledgeable friend who can handle most questions on the spot.

Some Models Have Superpowers Beyond size, models are also specialized by what they’re good at:

Reasoning models (like Claude Opus 4.6) are built to tackle hard problems — math, strategy, coding. They don’t just give you an answer; they show their work.

Embedding models (like Ada or Cohere) don’t generate text at all. They turn words into numbers so a computer can understand meaning — useful for search engines and recommendation systems.

Image generation models (like GPT-image-1) turn your words into pictures. Describe a sunset over Mumbai, and it draws it for you.

Video, speech, and audio models go even further — generating video from text, reading text aloud, or transcribing spoken words into text.

Finding the Right One:

When browsing a catalog like Azure’s Foundry, you can filter models by:

What it can do — reasoning, image analysis, translation, etc.

Who made it — OpenAI, Anthropic, Meta, Mistral, and many others

What industry it’s trained for — some models have been trained specifically on medical or legal data, which makes them sharper in those fields than a general-purpose model would be

The Takeaway:

AI models aren’t magic black boxes — they’re tools, and like any tool, the right one depends on your job.

Need deep, complex reasoning? Go large. Need something fast and affordable? Go small. Need to search by meaning, generate images, or transcribe audio? There’s a specialized model for that too.

The next time someone throws a model name at you, you’ll know exactly what questions to ask: How big is it? What’s it trained for? What task am I actually trying to do?

That’s really all it takes to start navigating the world of AI with confidence.

Agentic System Design Concepts - Patterns Every AI Engineer Should Know

2026-04-11T00:00:00+05:30

Building reliable AI agents isn't just about picking the right model — it's about the patterns you wire around it. Here's a concise reference of 15 agentic system design concepts worth knowing. Two lines each — just enough to understand what they do and why they matter.

Resilience & Failure Isolation

Agent Circuit Breaker — Prevents cascading failures by halting agent execution when downstream services or tools are repeatedly failing. Borrowed from distributed systems engineering, it stops a single broken tool from dragging the entire agent pipeline down.

Blast Radius Limiter — Restricts the impact of an agent failure to a defined scope so it can't propagate across the system. Think of it as a blast door: when something goes wrong, the damage stays local.

Dead Letter Queue for Agents — A holding area where failed or unprocessable agent tasks are parked for later inspection instead of silently dropped. It gives you a recoverable audit trail when tasks fall through the cracks at runtime.

Control Flow & Decision Quality

Orchestrator vs Choreography — Defines whether agent interactions are centrally directed (orchestrator controls all moves) or emergent (agents react to events and coordinate peer-to-peer). The choice shapes coupling, debuggability, and how gracefully the system degrades.

Confidence Threshold Gate — Ensures an agent only takes action when its internal confidence in a decision clears a defined threshold. A simple but powerful reliability lever: low-confidence branches pause for human review rather than guessing forward.

Replanning Loop — Allows agents to re-evaluate their plan mid-execution when context changes or a step fails, rather than continuing blindly on a stale plan. Essential for long-horizon tasks where the environment isn't static.

Human Escalation Protocol — Provides a structured mechanism for agents to hand off to a human when they're stuck, uncertain, or handling high-stakes decisions. It's not a failure mode — it's a designed off-ramp.

Tool Invocation Reliability

Idempotent Tool Calls — Ensures that a tool can be called multiple times with the same inputs without producing unintended side effects. Critical in agentic pipelines where retries happen frequently due to timeouts or partial failures.

Tool Invocation Timeout — Prevents agents from blocking indefinitely on a tool that is slow or unresponsive, forcing a graceful fallback or retry. Without this, a single flaky API can freeze an entire agent run.

Context Window Checkpointing — Periodically saves the agent's progress so it can resume from a known-good state rather than restarting from scratch after a context overflow or crash. Especially important for long-running, multi-step tasks.

Infrastructure & Routing

LLM Gateway Pattern — A single abstraction layer that manages all LLM API calls, handling routing, rate limiting, retries, and observability in one place. It decouples agent logic from model-specific SDKs, making provider swaps painless.

Semantic Caching — Stores LLM responses keyed on semantic meaning rather than exact input strings, so similar queries hit the cache even when phrased differently. Reduces latency and cost without sacrificing answer quality.

Multi-Agent State Sync — Maintains a consistent shared state across multiple agents working in parallel or in sequence. Without it, agents operating on stale or divergent state produce contradictory or redundant outputs.

Observability & Deployment

Agentic Observability Tracing — Tracks every decision, tool call, handoff, and LLM interaction across an agent run, producing a full execution trace for debugging and performance analysis. The difference between guessing why something failed and knowing.

Canary Agent Deployment — Rolls out a new agent version to a small slice of production traffic before full release, allowing you to compare behavior and catch regressions with limited blast radius. Applies standard software deployment discipline to the agent layer.

Every Claude Code Concept You Need to Know

2026-04-11T00:00:00+05:30

Claude Code is not a chatbot. It lives in your terminal, reads your actual files, writes code, runs commands, and executes multi-step workflows — all with your permission. Here are 30 concepts you need to understand it properly. No fluff, no hand-holding.

The 30 Concepts

1. The Terminal — Claude Code doesn't run in a browser. It runs in the terminal, the same text-based interface developers use daily. If you've never opened a terminal before, that's your first homework assignment.

2. Installation + Pricing — Install with a single command via npm. Pricing is token-based through your Anthropic account. There's no flat monthly fee tied to a UI — you pay for what you use, which means costs scale with how hard you push it.

3. File Access — Claude Code reads and edits files directly on your machine, with your permission. Not "paste your doc into a chat window." It opens the actual file, modifies it in-place, and saves it. This is the concept that makes it useful.

4. Image + PDF Reading — Claude Code can ingest images and PDFs as inputs. Point it at a PDF proposal or a screenshot and it processes the content directly — no manual copy-paste required.

5. Tool Use — Claude Code has built-in tools: file reading, file writing, shell execution, and more. These are the primitives it uses to act on your computer. You see each tool call as it happens in real time.

6. Prompting Techniques — Vague prompts produce garbage results. "Help me with my marketing" is useless. "Write a 3-email welcome sequence for my dog walking business targeting first-time pet owners, 150 words each" is not. Specificity is the skill.

7. CLAUDE.md — A markdown file you create in your project directory that tells Claude Code the rules, context, and conventions for that project. Think of it as a standing system prompt that persists across sessions. Every serious Claude Code user has one.

8. Plan Mode — Before Claude Code executes anything, you can ask it to plan first. It outputs what it intends to do, step by step, and waits for your approval. Run in plan mode for anything non-trivial. Review before you let it touch anything.

9. Context Window — The amount of text Claude can "hold in mind" at once during a session. Long conversations, large files, and extensive histories eat into it. When context fills up, older information gets dropped. This affects result quality.

10. Tokens + Costs — Everything processed by Claude Code — your prompts, the files it reads, its responses — is measured in tokens. Tokens drive cost. Reading a 50-page PDF burns tokens. Keep context lean and targeted to control spend.

11. Model Selection — You can choose which Claude model backs your session. Faster, cheaper models work for routine tasks. Heavier models are worth it for complex reasoning or production-grade code. Pick the right tool for the job.

12. /compact — A slash command that compresses your current conversation history into a shorter summary, freeing up context window space without wiping the session. Use it mid-task when context gets bloated.

13. /clear — Wipes the entire conversation and starts fresh. Every new task should start with a clean context. Don't carry leftover noise from a previous task into the next one. Use this more than you think you need to.

14. Session Management — Claude Code has no persistent memory between sessions by default. Start each session with your CLAUDE.md re-read to restore project context. Design your workflow around this statelessness rather than fighting it.

15. Permission Modes — By default, Claude Code asks for approval before running any shell command. This gets tedious fast. You can pre-approve safe, non-destructive commands (ls, cat, grep, mkdir, git status) in your settings.local.json. Destructive operations should always require explicit confirmation.

16. Effort Levels — You can signal how much effort you want Claude to apply. Quick answers for exploration, thorough analysis for production decisions. Matching effort level to task type saves time and tokens.

17. Interrupt + Redirect — While Claude Code is running a task, you can interrupt it mid-execution and redirect it. If it starts going down the wrong path, stop it early. Don't let it burn tokens on a wrong approach when you can see it happening.

18. Visual Studio Code — Claude Code integrates directly with VS Code. You can run it inside the VS Code terminal and see file changes reflected in your editor in real time. If you're not a terminal-native developer, this is the recommended setup.

19. Memory — Claude Code supports memory files that persist across sessions. Unlike CLAUDE.md (project-specific), memory files can store user-level preferences and context. Useful for encoding your personal conventions once and never repeating them.

20. Project vs Global — Configuration can be scoped at the project level (CLAUDE.md, settings.local.json) or at the global level (applies to all Claude Code sessions on your machine). Know which scope a setting lives in before you modify it.

21. Slash Commands — Built-in commands prefixed with / that control Claude Code's behavior: /clear, /compact, /help, and more. You can also define custom slash commands (skills) that map to your own workflows.

22. Skills — Custom slash commands you define once and reuse indefinitely. A skill is a markdown file that describes a reusable workflow. You build it once, invoke it with /skill-name, and Claude follows the instructions every time. Hundreds of community-built skills already exist on GitHub in repos like anthropics/skills and hesreallyhim/awesome-claude-code.

23. Hooks — Scripts that run automatically before or after Claude Code actions. Quality gate hooks, for example, can intercept Claude's output before it's committed and check it against defined standards. Hooks are how you enforce consistency without relying on Claude to self-police.

24. Web Browsing — Claude Code can browse the web when given the appropriate tool access. It can fetch pages, read documentation, and pull in live information as part of a task — not just work from static local files.

25. MCP Servers — Model Context Protocol servers extend Claude Code's tool access to external services: Airtable, Google Drive, Slack, GitHub, and more. Tools handle what Claude does on your computer. MCP extends that to the internet and third-party APIs. This is the integration layer.

26. Perplexity MCP — A specific MCP integration that gives Claude Code access to Perplexity's search capabilities. Useful when a task requires real-time research as part of a larger automated workflow.

27. Subagents — Multiple Claude Code instances running simultaneously, each handling a distinct subtask. Instead of processing platforms one at a time, you spin up parallel agents and run them concurrently. Subagents are how you turn Claude Code from a sequential tool into a parallel workflow engine.

28. Remote Control — Claude Code can be configured for remote access, meaning you can trigger and manage sessions from another machine or interface. Relevant for server automation and scheduled background tasks.

29. Scheduled Tasks — Claude Code workflows can be scheduled to run automatically at defined intervals. Combine this with skills and hooks and you have a self-operating workflow system that runs without manual invocation.

30. Git Version Control — Claude Code integrates with git. Every change it makes can be committed, branched, and rolled back through standard git workflows. This is your undo button. Always have Claude Code working inside a git-tracked project. Before: changes happen and you hope nothing breaks. After: every change is versioned, documented, and reversible.

The One Rule That Matters

Master five concepts before you touch the next five. The shiny object trap — jumping from MCP to subagents to hooks before understanding CLAUDE.md and context windows — is the single biggest waste of time. The gap between people getting real results and people falling behind is not talent. It is reps. Start with file access, prompting, CLAUDE.md, plan mode, and /clear. Everything else builds on those five.

Missing ZIP Option in Windows Right-Click Menu — Here's How to Fix It

2026-04-11T00:00:00+05:30

The classic "Send to → Compressed (zipped) folder" option sometimes disappears from the Windows right-click context menu. Here's what causes it and how to get it back in under two minutes.

What Happened

Windows ships with a built-in ZIP shell extension handled by zipfldr.dll. When third-party tools like Git, VLC, or OneDrive add their own context menu entries, they can displace or corrupt the ZIP handler registration — leaving you with a bloated menu but no ZIP option.

Fix 1 — Check the Send to Submenu

Before anything else, right-click your folder or file and hover over Send to →. The "Compressed (zipped) folder" option is sometimes hiding in the submenu even when it's not visible at the top level.

Fix 2 — Re-register the ZIP Shell Extension

Open Command Prompt as Administrator and run:

regsvr32 zipfldr.dll

This re-registers the native ZIP handler with Windows Shell. Restart Explorer or reboot after running it.

Fix 3 — Restart Windows Explorer

Sometimes a stale shell session is all that's causing the issue. Run this in CMD:

taskkill /f /im explorer.exe
start explorer.exe

Fix 4 — Verify the Registry Key

Press Win + R, type regedit, and navigate to:

HKEY_CLASSES_ROOT\CompressedFolder

If this key is missing or corrupted, the ZIP option will not appear anywhere in the context menu. You may need to restore it from another machine or via a .reg export.

Root Cause

Heavy context menu contributors — Git Bash, Git GUI, VLC, SkyDrive Pro — are visible in the screenshot. Any one of them can push a bad shell extension that breaks ZIP registration as a side effect. Fix 2 resolves this in most cases.

AI Agent Directory - Few Shots LLM Models

2026-04-10T00:00:00+05:30

The AI agent ecosystem is growing fast. Here's a quick directory of notable AI startups and a couple of few-shot LLM models worth knowing about. Two lines each — just enough to know what they do and why they matter.

AI Agent Directory

Can of Soup — An AI-powered app that lets you create fictional photos of you and your friends in imaginary scenarios. Built during Y Combinator, it uses generative AI to place people into any meme, outfit, or movie scene.

Deepgram — A foundational voice AI platform offering speech-to-text, text-to-speech, and voice agent APIs. Their Nova models deliver high accuracy and low latency, supporting 30+ languages for real-time transcription.

Diffuse Bio — Building generative AI for protein design, using diffusion models to engineer new proteins with control and accuracy. Their foundation model DSG-1 can generate 3D protein structures and design binders from user prompts.

Draftaid — An AI-powered CAD tool that converts 3D models into precise 2D manufacturing drawings automatically. It reduces manual drafting time by up to 90%, acting like a copilot for mechanical engineers.

Edgetrace — A YC-backed AI video analytics platform that lets users search camera networks using natural language. Primarily used by law enforcement and transportation for real-time threat detection and suspect identification.

EzDubz — A real-time AI dubbing tool that translates videos, livestreams, and phone calls while preserving the original speaker's voice. Their proprietary models clone voices on the fly and even replicate emotions across 20+ languages.

Exa — An AI-powered search engine and API built for developers and AI agents. Unlike traditional keyword search, Exa uses neural embeddings for semantic understanding, powering tools like Cursor and Lovable.

Guide Labs — Building interpretable AI foundation models that can explain their reasoning and are easy to audit. Their open-source Steerling-8B is an 8-billion-parameter LLM designed for transparency and debuggability.

Infinity AI — Now known as Lemon Slice, they build a video foundation model for human motion and emotion. Their tech generates expressive, talking characters across styles from photorealistic to cartoon.

K-Scale — Building open-source humanoid robots for developers, with models starting at $999. Their integrated software, hardware, and ML stack lets developers focus on building applications for embodied AI.

Sevn — A generative design startup using AI to automate and optimize the creative design process. Users define parameters and constraints, and Sevn generates a range of design options to explore.

Linux Inc — An AI startup focused on bringing intelligent tooling to the Linux ecosystem. They aim to simplify Linux administration and development workflows through AI-powered automation.

Metalware — A copilot for firmware engineers that automates low-level programming for embedded systems. Their binary analysis tool fuzzes ARM-based software to detect defects earlier in the development lifecycle.

Naiver AI — Navier AI provides a web-based platform for running CFD (computational fluid dynamics) simulations at scale. Their AI agents handle geometry cleanup, meshing, solver configuration, and cloud resource management autonomously.

Osium AI — An AI-powered platform that accelerates materials and chemicals R&D for industry leaders. Their software helps engineers design new materials faster, spanning alloys, polymers, textiles, and bio-based materials.

Phind — An AI search engine purpose-built for developers that generates direct, code-inclusive answers to technical questions. It combines real-time web search with specialized models trained on programming languages and frameworks.

Piramidal — Building a foundation model for the brain, trained on a massive corpus of EEG brainwave data. Their AI interprets neural signals for neurological diagnostics, already being deployed in ICU settings.

Playground — A browser-based AI image generation and design platform used by over 9 million users. It combines text-to-image generation with a full graphic design suite for logos, social media posts, and more.

PlayHT — An AI voice generation platform that offered ultra-realistic text-to-speech with 900+ voices in 142 languages. Known for voice cloning and custom voice creation through deep learning algorithms.

Sonauto — An AI music editor that turns prompts, lyrics, or melodies into full songs in any style. It supports thousands of styles with full-length songs up to 4.5 minutes, complete with vocals and instrumentation.

Tavus — An AI video personalization platform that creates hyper-personalized videos at scale from a single recording. It uses deep learning for voice synthesis and face cloning to generate thousands of unique video variations.

YonduAI — Building the robotic workforce of the future, starting with logistics automation in warehouses. They deploy humanoid robots with remote teleoperation that gradually transitions to full AI-driven automation.

Yoneda Labs — Building a foundation model for chemical reactions to help chemists optimize drug discovery. Their AI defines parameters like temperature, concentration, and catalyst to make synthesis faster and cheaper.

SyncLabs — An AI lip-sync video generator that creates perfectly synchronized mouth movements from any audio track. Their zero-shot model handles any face in any video context without prior training on specific individuals.

Few-Shot LLM Models

Llama 3.1 — Meta's open-source large language model available in 8B, 70B, and 405B parameter sizes. It supports 128K context length and multilingual capabilities, making it one of the most versatile open-weight models for fine-tuning and deployment.

Mixtral — Mistral AI's open-source mixture-of-experts (MoE) model that activates only a subset of parameters per token for efficient inference. It delivers performance comparable to much larger dense models while being significantly faster and more cost-effective to run.

My GenAI Blogs

2026-01-10T00:00:00+05:30

Why GenAI?

Generative AI has completely changed how I think about software, creativity, and problem-solving. Over the past year, I've gone deep into the world of large language models, prompt engineering, retrieval-augmented generation, fine-tuning, and AI agents. The pace of change is incredible, and I wanted a place to document what I'm learning as I go.

This blog is that place. I'll be writing about my hands-on experiences with GenAI, the tools I'm experimenting with, things that worked, things that didn't, and the lessons I've picked up along the way.

What I've Been Exploring

My GenAI journey started with using ChatGPT and Claude for day-to-day coding tasks. That quickly evolved into deeper exploration:

Prompt engineering — learning how to get consistent, high-quality outputs from LLMs by structuring prompts effectively.
RAG (Retrieval-Augmented Generation) — building pipelines that ground LLM responses in real data using vector databases and embeddings.
Fine-tuning — adapting pre-trained models for specific tasks and domains.
AI agents — creating autonomous workflows where LLMs can use tools, reason through multi-step problems, and take actions.
Local models — running open-source models like LLaMA and Mistral locally to understand how they work under the hood.

I'm not just reading about these topics. I'm building with them, breaking things, and learning from the results.

What to Expect

I plan to post at least one article a week covering topics like:

Practical tutorials on building GenAI applications
Comparisons of different models and frameworks
Deep dives into concepts like embeddings, tokenization, and attention mechanisms
Real-world use cases and project walkthroughs
Opinions on where GenAI is heading and what matters for developers

Some posts will be short and focused, others will be longer walkthroughs. The goal is to share useful, honest content from a developer's perspective.

Let's Go

I'm excited to start writing and sharing. GenAI is moving fast, and the best way to keep up is to build, experiment, and document. That's exactly what this blog is for.