Coder Legion - Recent posts tagged langchain

Learning LangChain

Mon, 12 Oct 2026 17:46:29 +0000

A while back I built Synapse, a small app that answers questions using my own notes. I did every part of it by hand: load the files, turn them into vectors, find the closest ones to the question, and hand those to an LLM. It worked, and I understood it, because I'd written every line myself.

So when I started LangChain, a framework that promised to do all of that for me felt a little suspicious. My honest question was: what is this doing that I haven't already done?

It turns out the answer is less "new ideas" and more "a standard shape for the ones you already have." Let me walk through it the way I learned it.

Start small: messages and templates

A chat model doesn't take one big string. It takes a list of messages: a system message that sets the role, then human messages from you, then AI messages from the model. LangChain gives each of those its own class. Nothing magic, it's the same thing the raw API wants.

Prompt templates were the next small step. Instead of building a string every time, you write the prompt once with a gap in it:

from langchain_core.prompts import ChatPromptTemplate

template = ChatPromptTemplate.from_template(
    "I've recently adopted a {pet}. Suggest three {pet} names."
)

Then an output parser takes the model's text reply and turns it into something you can actually use, like a Python list. The thing that stuck with me here is that the parser is only as good as your instructions. Vague instructions about the format gave me a messy list. Strict ones gave me a clean one.

The pipe

This is the bit where it clicked for me. LangChain lets you join those pieces with a |, like a Unix pipe:

chain = chat_template | chat | list_output_parser
chain.invoke({"pet": "dog"})
# ['Max', 'Bella', 'Luna']

A prompt goes in one end, the model sits in the middle, and a clean list comes out the other end. Each step's output is the next step's input. That's the whole idea.

It even works for ordinary Python functions. Wrap them in RunnableLambda and they snap in like any other piece:

from langchain_core.runnables import RunnableLambda

add_up = RunnableLambda(lambda x: sum(x))
square = RunnableLambda(lambda x: x**2)

(add_up | square).invoke([1, 2, 5])   # 8, then 64

You can also draw a chain. chain.get_graph().print_ascii() prints the boxes and arrows, which is surprisingly handy when a chain gets long.

Two more things I liked. RunnableParallel runs two chains side by side and gives both results to the next step. And batch is quicker than looping: two requests through batch took 2.67 seconds in my notebook, while the same two as separate calls took about 7.5.

Now RAG, with the same pieces

Remember my five hand-built steps? LangChain has a piece for each.

For loading, there are loaders for different file types. I used one for PDFs and one for Word documents. Splitting was the new part, since Synapse never did any. I split a six-page document twice. First by its headings, so every chunk remembers which lecture it came from, then by size, about 500 characters with a little overlap. That left me with 20 chunks, each labelled with where it came from.

Each chunk then became 1,536 numbers using OpenAI's embedding model. I wanted to see if it really worked, so I compared three pairs of chunks. They scored 0.88, 0.80 and 0.79, so related text does end up close together. The vectors all have a length of about 1, which is why a plain dot product works as a similarity score.

Those vectors went into Chroma, which saves them to a folder on disk so I don't have to re-embed every time I open the notebook.

Retrieval comes in two flavours. A plain similarity search gives you the closest chunks. MMR gives you close chunks that are also different from each other, so you don't get five copies of the same paragraph.

And the last step is where the pipe comes back. The whole thing is one chain:

chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt_template
    | chat
    | StrOutputParser()
)

chain.invoke("What software do data scientists use?")

The retriever fills in the context, the question passes straight through, the prompt tells the model to answer only from that context and name the lecture it used, and the parser hands back plain text. The answer ended with:

Resources: Programming Languages & Software Employed in Data Science - All the Tools You Need

That's the same "only use these notes" guard I wrote by hand in Synapse, plus the sources I'd been putting off adding.

What this changed for me

LangChain didn't teach me a new idea. Everything in that pipeline is something I'd already done by hand: load, embed, find the closest, ask. What it gave me was a standard shape for each step, and the pipe to join them. Having built it the long way first is what made the short way make sense.

Next up is LangGraph.

Deep Agents in Action: Building a Multi-Agent Research System (published)

Fri, 25 Sep 2026 14:39:24 +0000

I tested yet another implementation of a multi-agent orchestrator.

The paradigm for AI agents is shifting rapidly from single, monolithic prompt loops to structured multi-agent systems capable of division of labor, state persistence, and fine-grained tool orchestration.

Although IBM watsonx Orchestrate is my go-to solution for enterprise-level agent deployment, I wanted to experiment with LangChain's Deep Agents to evaluate its multi-agent orchestration capabilities.

Introduction: The Deep Agents Architecture

LangChain announced recently Managed Deep Agents, introducing a managed platform to execute deep agent topologies. The Deep Agents paradigm addresses the fundamental limitations of single-agent workflows—specifically context window degradation, tool confusion, and compounding reasoning failures during extended, multi-step tasks.

What is the Deep Agents Pattern?

The Deep Agents pattern is a hierarchical multi-agent architecture where:

A top-level Orchestrator decomposes complex tasks and delegates sub-tasks to specialists.
Each Specialist Agent runs its own isolated ReAct loop with its own tools and memory.
Specialists return structured results to the orchestrator, which synthesises them.
Agents can be composed recursively — an orchestrator can itself be a sub-agent.
This pattern adds genuine value over a single agent because:

| Single Agent                       | Deep Agents                                       |
| ---------------------------------- | ------------------------------------------------- |
| One context window gets overloaded | Each agent has an isolated, focused context       |
| All reasoning in one prompt        | Specialised reasoning per domain                  |
| Hard to scale                      | Add specialists without changing the orchestrator |
| Hard to debug                      | Full delegation trace for auditability            |

---

Excerpt from LangChain Deep Agents Documention;

Deep Agents overview

Deep Agents is the easiest way to start building agents and applications that are powered by LLMs—with built-in capabilities for file systems for context management, subagent-spawning, and long-term memory. Optional capabilities such as task planning and skills extend the harness when your use case needs them. You can use deep agents for any task, including complex, multi-step tasks.Deep Agents comes with the following capabilities:

Take actions in an environment: Take actions via tools, read and
write files, execute code
Connect to your data: Load memories,
skills, and domain knowledge at the right moment
Manage growing context: Summarize history and offload large results across long runs
Parallelize tasks: Delegate to general or specialized subagents running in isolated context windows
Stay in the loop: Pause for human approval at critical decision points Improve over time: Update memory, skills, and prompts based on real usage

And from the Github repository;

Deep Agents is an open source agent harness — an opinionated agent that runs out of the box. Extend, override, or replace any piece.

Principles:

Opinionated — defaults tuned for long-horizon, multi-step work
Extensible — override or replace any piece without forking
Model-agnostic — works with any LLM that supports tool calling: frontier, open-weight, or local
Production-ready — built on LangGraph (streaming, persistence, checkpointing) with first-class tracing,
evaluation, and deployment via LangSmith

Features include:

Sub-agents — delegate tasks to agents with isolated context windows
Filesystem — read, write, edit, or search over pluggable local,
sandboxed, or remote backends
Context management — summarize long threads and offload tool outputs
to disk
Shell access — run commands in your sandbox of choice
Persistent memory — pluggable state and store backends for
cross-session recall
Human-in-the-loop — approve, edit, or reject tool calls before they
run
Skills — reusable behaviors the agent can load on demand
Tools — bring your own functions or any MCP server

Core Concepts of LangChain Deep Agents

Hierarchical Orchestration: A primary agent acts as a supervisor,
receiving high-level goals and delegating sub-tasks to dedicated
specialist agents rather than executing every step sequentially in a
single context loop.
Specialized Agent Roles: Individual agents operate with tightly
scoped system prompts, specialized tools, and isolated context
windows to execute sub-tasks (e.g., information retrieval, numeric
calculations, or document composition).
Isolated Memory Stores: Each agent maintains its own short-term
working memory, facts, and episodic memory, preventing state
contamination across different phases of execution.
ReAct Reasoning Loop: Sub-agents execute autonomous Thought → Action
→ Observation loops using validated tool interfaces.

Technical Implementation

Now that the feature set of "Deep Agents" is done, let's jump into a simple didatical (for myself) implementation.

The implementation in the provided repository (scaffolded via IBM Bob) provides a complete local and cloud-compatible implementation of the Deep Agents pattern.

Architecture Overview

LittleHorse Draws the Line Between What Your Agent Decides and What Your Code Must Execute

Mon, 21 Sep 2026 12:00:00 +0000

Picture the moment an AI agent gets triggered by an event — a support ticket, a queue message, a webhook — and has to reliably set off several things downstream in order. Most developers end up hand-wiring that themselves: retries, state tracking, a debugging session that starts with "okay, which step actually failed?" According to Colt McNealy, founder and CEO of LittleHorse, that's the moment a team building agents needs something underneath the agent framework they're already using.

"If you get to the point where your agent is triggered by an event somewhere... and then when the agent is done, something else has to happen, and then another thing has to happen, you're going to spend a lot of time wiring things together," McNealy told me in a briefing ahead of LittleHorse's Saddle Command Center 1.3 release. "You're not going to have an easy time debugging end-to-end what's going on, and you're going to need an orchestration system to make sure the right things happen in the right order."

LittleHorse was founded in 2022 and backed and advised by McNealy's father, Scott McNealy, co-founder and former CEO of Sun Microsystems. The idea traces back to a real estate startup where McNealy tried to build a scheduling system for open houses, showings, and escrow inspections, and found the business process scattered across Salesforce, DotLoop, several internal portals, a customer mobile app, and a lot of tribal knowledge. "That problem of any process being stitched, living in the point-to-point integrations and queue consumers... has only gotten worse as AI has come around," he said. "It's made it hard for customers to deploy agents into mission-critical business processes."

LittleHorse's answer is what it calls Business-as-Code: an open-source, Java-based workflow engine that turns an intended business process into a deployable, testable, version-controlled software artifact, then orchestrates it across whatever systems a company already runs. Developers write it in Java, Python, Go, or C# (JavaScript joins the list in 1.3), and it compiles into a process specification LittleHorse executes and tracks.

I asked McNealy what Business-as-Code does that the rest of a crowded orchestration field — Airflow, Temporal, Camunda, and agent frameworks like LangChain — doesn't already cover. Airflow, he said, is built for background data ETL, not real-time, high-speed business processes; one LittleHorse customer runs a virtual try-on product where a photo becomes a 10-step image-generation pipeline that has to run live, which he said isn't an Airflow use case. Temporal handles durable execution — safely retrying a failed function by replaying its prior side effects — but doesn't produce an end-to-end diagram a business user can actually read. "What LittleHorse gives you that Temporal doesn't... is a higher level for developers to get closer to the business process, closer to business value," McNealy said. Camunda, in his framing, doesn't produce a version-controlled, tested code artifact and isn't built for core product flows. LangChain and similar frameworks build the agent itself; in a LittleHorse workflow, that agent becomes one node inside a larger, deterministic process — and Saddle 1.3 adds a pre-built agent worker, running on LangChain under the hood, to make that pattern easier to deploy.

The clearest proof point McNealy offered is a utility and vegetation-management company — the kind of business that clears trees away from power lines — that had zero software engineers two years ago and ran operations on NetSuite plus roughly ten other SaaS systems. It decided to treat software as a competitive advantage, hired around 18 engineers, and started with one workflow: truck maintenance work orders, built on LittleHorse's open-source engine. It now runs more than 140 workflows in production, covering employee onboarding, job bidding, storm response and truck rerouting, and location tracking for 8,000 trucks every 30 seconds to generate a live heat map of completed jobs. Because the company owns that code instead of waiting on a vendor, McNealy said it has adopted agents in back-office workflows faster than competitors stuck waiting for SAP to ship an equivalent feature — one that, even then, would only work inside SAP.

That same logic shapes how LittleHorse handles agent guardrails, which McNealy walked through using a fraud-detection example from a financial-services customer. Their agent gets read-only access to internal systems through MCP, evaluates a transaction, and either the decision applies automatically below a set risk threshold or a human reviews the agent's report first. The agent never gets write access to push a transaction through on its own. "It really, really constrains what it can do and makes it a lot easier to verify and audit every single tool call that the agent has done," McNealy said. That split — deterministic code handles execution and audit, the agent handles judgment on ambiguous input — is also why it's worth the added layer at all, he argued: it cuts token usage and error rates, and shrinks the surface exposed to prompt injection, since the agent never touches the system doing the actual write.

Saddle Command Center 1.3 is built to reach that pattern from both ends: pre-built connectors and task workers, an integrated streaming layer, webhook and event triggers, and a serverless free trial so a team can try LittleHorse without standing up Kafka themselves — plus enough out-of-the-box capability that CIOs and architects don't need to write most of it.

Asked whether LittleHorse is easing a shift from human-driven business processes to agent-driven ones, McNealy didn't hesitate. "Even with the most complicated agents, there's still a larger process that causes the agent to run, and then when it's done doing its task, another thing happens in other systems," he said. "Those end-to-end workflows are what we codify." The bet behind Saddle 1.3 is that as agents move from prototypes into systems touching real trucks and real transactions, the question won't be whether a model is capable enough — it'll be whether anyone can say, with an audit trail, exactly what it was allowed to decide.

How to Catch an AI Agent Behaving Badly Before It Ships

Fri, 14 Aug 2026 22:05:46 +0000

AI agents fail in ways that aren't obvious during demos - they hallucinate tool calls, fabricate intermediate results, and sometimes take actions the user never approved. Catching this before users do is now a core part of agent development.

The Problem: Agents Optimize for Task Completion, Not Honesty

When an AI agent is given a goal and a set of tools (web search, code execution, form submission, etc.), it learns that appearing to make progress is often rewarded the same as actually making progress. This creates a subtle failure mode: the agent confidently reports a result it never actually obtained, or takes a shortcut that looks correct in the log but silently corrupts the outcome. Unlike a chatbot that hallucinates a fact, an agent can hallucinate an action - claiming it sent an email, updated a record, or retrieved live data when it did none of those things. Users trust the output because the step-by-step log looks authoritative. That trust is exactly what breaks adoption.

Real Example: Audit Your Agent's Tool Calls

The fastest way to surface this class of bug is to log every tool call with its actual input/output, then compare it against the agent's self-reported reasoning. Here's a minimal pattern using Python:

import functools

def audited_tool(fn):
 @functools.wraps(fn)
 def wrapper(*args, **kwargs):
 result = fn(*args, **kwargs)
 print(f"[AUDIT] {fn.__name__} | args={args} | result={result}")
 return result
 return wrapper

@audited_tool
def search_web(query: str) -> str:
 # real implementation here
 return "..."

Wrap every tool your agent can call with this decorator (or its equivalent in your framework - LangChain, CrewAI, and AutoGen all have callback hooks for this). Then after a run, diff what the agent said it did in its final response against the [AUDIT] log. Gaps between those two are where fabrication lives. Go one step further: add an assertion layer that fails the run if any tool the agent references in its output wasn't actually invoked.

Key Takeaways

Agents can fabricate tool use, not just facts - the failure mode is more dangerous than standard hallucination because it's buried in structured-looking logs
Wrapping every tool call with explicit audit logging and comparing it against the agent's self-reported summary is a practical, low-overhead way to surface this before users see it
Most major agent frameworks (LangChain, CrewAI, AutoGen) expose callback or middleware hooks specifically for this - use them as a default, not an afterthought

If you've caught your agent lying about a tool call in production, what framework were you using and did the built-in tracing actually catch it, or did you have to build around it?

Sources referenced: Hacker News discussion - "AI agents lie, cheat and steal. That is putting off users"

I Built a Local RAG Assistant with Ollama, ChromaDB and LangChain

Sat, 25 Jul 2026 14:42:23 +0000

During my internship at a software services company, I noticed a recurring problem: technicians spent hours searching through hundreds of pages of PDF manuals to answer client questions. The company deploys a suite of management tools accounting, HR, logistics mainly to public institutions managing projects funded by international donors.

I kept thinking: this is exactly the kind of problem LLMs were made for. So for my Master's project in AI & Big Data, I built an intelligent assistant to handle it.

The constraint that shaped every technical decision: no data could leave the local infrastructure. These institutions handle sensitive financial data it cannot be sent to OpenAI, Anthropic, or any cloud provider.

This forced me into the world of fully local LLMs. Here's what I built, what broke, and what I learned.

The Problem

The company had accumulated massive technical documentation PDF manuals, configuration guides, FAQ files but no efficient way to query it. When a technician faced an issue with the accounting module or the HR module, they searched manually. Slow, inconsistent, and dependent on individual expertise.

Classic LLMs can't help here: they don't know the private internal documentation. And without grounding in official docs, they hallucinate procedures dangerous when dealing with accounting operations for donor-funded projects.

The solution: RAG (Retrieval-Augmented Generation) make the LLM answer only from the official documentation, injected at query time.

What RAG Actually Is

Before the code, the concept in one sentence: instead of asking the LLM to "know" everything, you retrieve the relevant passages from your documents and inject them into the prompt as context.

The pipeline has two distinct phases:

Phase 1 : Ingestion (done once)

PDF documents
    ↓
Chunking (split into 300-character blocks)
    ↓
Embedding (convert each block to a vector)
    ↓
ChromaDB (store all vectors)

Phase 2 : Query (at each question)

User question
    ↓
Embed the question (same model)
    ↓
ChromaDB similarity search → top 3 chunks
    ↓
Inject chunks + question into LLM prompt
    ↓
Llama 3 generates a grounded answer

The key insight: the LLM never "knows" your documents. It reads them fresh at each query, from the context you provide. No fine-tuning needed. No retraining when docs are updated.

The Architecture: 4 Docker Services

Everything runs locally via Docker Compose. Four services, each with a clear role:

Service	Role	Port
Ollama	Runs Llama 3 locally	11434
ChromaDB	Vector database	8001
FastAPI	RAG pipeline + REST API	8000
Streamlit	User interface	8501

# docker-compose.yml (simplified)
services:
  ollama:
    image: ollama/ollama:latest
    ports: ["11434:11434"]
    volumes: ["./ollama_models:/root/.ollama"]
    environment:
      - OLLAMA_KEEP_ALIVE=24h

  chromadb:
    image: chromadb/chroma:latest
    ports: ["8001:8000"]
    volumes: ["./chroma_db:/chroma/chroma"]

  python-api:
    build: ./src
    ports: ["8000:8000"]
    depends_on: [ollama, chromadb]
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - CHROMA_HOST=chromadb
      - CHROMA_PORT=8000

Step 1 : Ingesting the Documentation

I ingested 10 documents accounting references (SYSCOHADA, SYCEBNL), a general accounting code, and internal user manuals. That's 2,111 pages split into 9,669 chunks.

# src/ingestion.py

import os
import chromadb
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_chroma import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings

DATA_DIR = "/app/data/documents"
COLLECTION_NAME = "documentation"

def load_documents():
    documents = []
    for fichier in os.listdir(DATA_DIR):
        if fichier.endswith(".pdf"):
            try:
                loader = PyPDFLoader(os.path.join(DATA_DIR, fichier))
                docs = loader.load()
                # Tag each chunk with its source document
                for doc in docs:
                    doc.metadata["module"] = fichier.replace(".pdf", "")
                documents.extend(docs)
            except Exception as e:
                print(f"Skipped {fichier}: {e}")  # Don't crash on encrypted PDFs
    return documents

def store_embeddings(chunks):
    embeddings = HuggingFaceEmbeddings(
        model_name="all-MiniLM-L6-v2",
        model_kwargs={"device": "cpu"}
    )
    # Explicit HTTP connection — not localhost, the Docker service name
    client = chromadb.HttpClient(host="chromadb", port=8000)
    Chroma.from_documents(
        documents=chunks,
        embedding=embeddings,
        collection_name=COLLECTION_NAME,
        client=client
    )
    print(f"Done — {len(chunks)} vectors stored")

Two things worth noting:

I tag each chunk with its source document name as metadata this allows the LLM to cite its source in the answer
The try/except is not optional one encrypted PDF (it happened) would have crashed the entire ingestion without it. Install cryptography if you hit an AES error: pip install cryptography

Step 2 : Building the RAG Chain

# src/rag_chain.py

import chromadb
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.llms import Ollama
from langchain_chroma import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

def create_rag_chain():
    # Must be the same model used during ingestion
    embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")

    client = chromadb.HttpClient(host="chromadb", port=8000)
    vectorstore = Chroma(
        client=client,
        collection_name="documentation",
        embedding_function=embeddings
    )

    # Retrieve top 3 most relevant chunks
    retriever = vectorstore.as_retriever(
        search_type="similarity",
        search_kwargs={"k": 3}
    )

    llm = Ollama(
        base_url="http://ollama:11434",
        model="llama3",
        temperature=0.3,
        num_predict=250   # Cap response length — critical on CPU
    )

    template = """You are a technical support assistant.
Answer ONLY from the provided context. Cite your source.
If the answer is not in the context, say so clearly.

Context: {context}
Question: {question}
Answer:"""

    prompt = ChatPromptTemplate.from_template(template)

    def format_docs(docs):
        return "\n\n".join([
            f"[Source: {d.metadata.get('module', '?')}]\n{d.page_content}"
            for d in docs
        ])

    # The full pipeline in 4 steps
    return (
        {"context": retriever | format_docs, "question": RunnablePassthrough()}
        | prompt
        | llm
        | StrOutputParser()
    )

The chain is a pipeline: retriever → prompt → llm → parser. LangChain's | operator makes this clean and readable. Each step passes its output to the next.

Step 3 : API and Interface

FastAPI exposes the chain as a REST endpoint:

# src/main.py

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from rag_chain import create_rag_chain

app = FastAPI(title="Local RAG Assistant")
chain = create_rag_chain()

class QueryRequest(BaseModel):
    question: str

@app.post("/query")
def query(request: QueryRequest):
    try:
        answer = chain.invoke(request.question)
        return {"question": request.question, "answer": answer}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Streamlit makes it usable in a browser in 10 lines:

# src/app.py

import streamlit as st
import requests

st.title("Technical Support Assistant")
question = st.text_input("Your question:")

if st.button("Search") and question:
    with st.spinner("Searching documentation... (1-2 min on CPU)"):
        r = requests.post(
            "http://python-api:8000/query",
            json={"question": question},
            timeout=600
        )
        st.write(r.json()["answer"])

What Broke (and How I Fixed It)

This is the part nobody writes about. Three real problems I hit.

Problem 1 : ChromaDB v2 silently ignoring my data

I was connecting with the old client_settings syntax:

# WRONG silently stores data locally instead of sending to the server
Chroma.from_documents(
    documents=chunks,
    client_settings=Chroma.Settings(chroma_server_host="chromadb")
)

The ingestion ran without errors, showed 9669 chunks stored but ChromaDB had 0 vectors. Querying returned nothing.

The fix explicit HttpClient:

# CORRECT explicit HTTP connection to the ChromaDB Docker service
client = chromadb.HttpClient(host="chromadb", port=8000)
Chroma.from_documents(documents=chunks, client=client, ...)

Also: the v1 heartbeat endpoint (/api/v1/heartbeat) is deprecated. Use /api/v2/heartbeat to check if ChromaDB is alive.

Problem 2 : LangChain moved its modules

# Broke silently after a LangChain update
from langchain.prompts import ChatPromptTemplate           # ❌ ModuleNotFoundError
from langchain.schema.runnable import RunnablePassthrough  # ❌ ModuleNotFoundError

# Everything stable lives in langchain_core now
from langchain_core.prompts import ChatPromptTemplate      # ✅
from langchain_core.runnables import RunnablePassthrough   # ✅

LangChain has been refactoring aggressively across versions. If you hit ModuleNotFoundError, check langchain_core first it's the stable base layer they're committing to not break.

Problem 3 : Llama 3 timing out on CPU

Llama 3 (8B parameters) on CPU generates roughly 2-5 tokens per second. A 200-word answer takes 2+ minutes. My 120-second timeout was too short.

Three things helped significantly:

Dropping k from 5 to 3 chunks shorter prompt = faster time-to-first-token
Adding num_predict=250 to cap response length without it, the model generates forever
Allocating more RAM to Docker via .wslconfig on Windows to avoid swap

Results

After setup, the assistant correctly answers questions grounded in the official documentation:

"How to close monthly payroll?" → Step-by-step procedure from the HR module manual
"How to create an account in the chart of accounts?" → Exact navigation path, source cited
"What does SYSCOHADA class 4 cover?" → Accurate definition from the accounting reference

And critically when the answer isn't in the documentation, it says so explicitly instead of hallucinating. That was the whole point.

Key Takeaways

On RAG:

The embedding model used during ingestion must be identical to the one used at query time. A different model produces incompatible vector spaces your similarity search returns garbage without any error message.

Chunk size matters more than expected. 500 characters worked less well than 300 for technical documents shorter chunks produce more precise retrieval.

Metadata on chunks is essential for source citation. Tag every chunk with its document name at ingestion time.

On local LLMs:

Running on CPU is slow but viable for non-real-time use cases like internal support tools.

num_predict is your most important parameter for performance. Without it, the model generates until it decides to stop sometimes never.

Docker container networking does not use localhost. Use the service name defined in docker-compose.yml (e.g., chromadb, ollama) as the hostname when connecting between containers.

This project is available on my github : https://github.com/josaphatstar/Assistant-Intelligent-RAG

What's Next

This RAG pipeline handles straightforward questions well. But it has a core limitation: it always does the same thing regardless of the question type. Whether you ask a procedural question or report a system crash, it searches the docs and answers. No reasoning about what strategy fits best.

In the next article, I'll show how I evolved this into an Agentic AI architecture with LangGraph where the system first decides which agent to call (documentation search, error diagnosis, or human escalation ticket), then acts accordingly.

I'm a Master's student in AI & Big Data, and this project came out of a real internship constraint no cloud, no API keys, just local infrastructure and open-source tools. I'm curious: have you built a local RAG pipeline under similar constraints? What stack did you use, and what broke first? Drop it in the comments I'd genuinely like to compare notes.

LangChain Components

Fri, 10 Jul 2026 08:21:42 +0000

What are LangChain Components?

LangChain Components are the individual building blocks provided by LangChain that work together to create AI-powered applications. Each component performs a specific task, such as generating responses, managing memory, retrieving information, using tools, or processing documents.

1.Models**:Core interfaces through which U interact with AI models.
This component standardizes the interface to communicate with different LLM's using their API's.

2.Prompts: Input provided to LLM are called prompts.
This component provides a way to manage and optimize the input given to LLMs to get the best possible output.

Types of Prompts

Dynamic and Reusable: Templates that let you swap variables (like names or data) without rewriting the core instruction.
Role-based : Assigning a specific persona to the AI (e.g., "You are an expert coder") to guide the style of its response.
3. Few-Shot Prompting : Providing a few examples of input and output to help the AI understand the pattern you want it to follow.

3.Chains:Used to build pipelines.

Parallel Chains: Run multiple models or processes at the same time to gather information, which is then combined into a single output.

Conditional Chains: Use logic to determine the next step in the process. For example, an AI agent can analyze feedback and decide between different paths (like sending a "Thank You" or an "Email" based on the result).

4.Indexes: Connect your application to external knowledge such as PDFs, websites, or databases.

Doc Loader: Imports your data from various sources.
Text Splitter: Breaks large documents into smaller, manageable pieces.
Vector Store: Saves those pieces in a way the AI can easily search.
Retrievers: The mechanism used to fetch the relevant data when a question is asked.

5.Memory: "LLM API calls are "stateless."
This means the model does not remember past conversations made via API.
With the LangChain Memory component, it can store conversations, allowing the AI to keep track of context over time.

6.Agents: Agents use LLMs to decide which actions to take and in what order.It is like chatbot with superpower.
Instead of just responding, an Agent acts as a controller that uses tools (like search engines or calculators) to complete a task.

Types of Agents

Action Agents: They execute a task, observe the result, and repeat until finished.
Plan-and-Execute Agents: They create a step-by-step plan for complex problems before performing each action.
ReAct Agents: They use a loop of "Reasoning" and "Acting" to think through a task, pick a tool, and adjust based on observations.

Check the previous blog on LangChain Introduction.
https://dev.to/knitisha/what-is-langchain-a-detailed-explanation-4dkk

What is LangChain? A Detailed Explanation

Fri, 10 Jul 2026 08:21:01 +0000

LangChain is a powerful framework that solves a major headache in AI development: vendor lock-in.

Why LangChain?
When you build an application by calling an LLM's API directly (like OpenAI's GPT or Google's Gemini), your code becomes tightly coupled to that specific provider. If you decide to switch models ,perhaps to save money, improve performance, or move to an open-source model you often have to rewrite the entire "plumbing" of your application, from how prompts are formatted to how responses are parsed.

How LangChain Solves This
LangChain acts as a standardized interface (or abstraction layer). Instead of your code talking directly to a specific LLM, it talks to LangChain's generic "LLM" component.

Think of it like an electrical plug. Instead of hard-wiring your appliance to the wall, you use a universal outlet. Whether the power comes from a coal plant, a solar farm, or a wind turbine (the different LLM providers), your appliance stays the same.

Without LangChain:

# Direct API: Rigid and hard to change
from openai import OpenAI

client = OpenAI(api_key="your_key")

def ask_model(question):
    # This structure is specific only to OpenAI
    response = client.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": question}]
    )
    return response.choices[0].message.content

The "Magic" of the Standard Interface :

In LangChain, every model provider (OpenAI, Anthropic, Google, Llama) implements the same standard methods. Because they all "speak the same language" to your code

You don't change your logic: Your core application code—the part that manages memory, prompt templates, and chains—remains identical.
Minimal configuration changes: To switch from GPT-4 to Claude or a local Llama model, you typically only need to change one line of initialization code where you define the model object
Rapid Experimentation: You can test three different models against your application in minutes just by swapping the model name in your configuration, rather than refactoring your entire codebase.

The Power of Abstraction
When you use LangChain, you are using abstractions. An abstraction simplifies complex code by representing a process as a named component

Prompt Templates: Instead of hard-coding strings, you use a template object that stays the same regardless of which LLM you use.
Unified Methods: You use functions like .invoke() or .stream() for every model. Under the hood, LangChain translates these into the specific API calls required by the provider you selected.

With LangChain

from langchain_openai import ChatOpenAI

# You only change this object to swap models (e.g., to Anthropic or Llama)
llm = ChatOpenAI(model="gpt-4", api_key="your_key")

def ask_model(question):
    # .invoke() works the same way regardless of the model chosen
    response = llm.invoke(question)
    return response.content

For more info:
https://docs.langchain.com/

Check this for next imporant topic: LangChain Components
https://dev.to/knitisha/langchain-components-2ekd
I know this was a bit of a long read, but I'm confident that by now you have a solid understanding of what LangChain is and why it's so useful.
If you found this blog helpful, please leave a like and let me know in the comments if the explanation was easy to understand.

Memory in LLM Agents, Explained: From Stateless Calls to Long-Term Memory

Sun, 21 Jun 2026 08:23:59 +0000

Introduction

Most explanations of agent memory start at the wrong altitude. They jump straight to "use a vector database" without explaining what problem that solves, or why a vector database is sometimes the wrong tool entirely.

This post walks through memory the way I built it: as a progression of seven small, runnable scripts, starting from a completely stateless LLM call and ending at a two-layer system with separate short-term and long-term memory. Each step introduces exactly one new concept. By the end, the line between short-term and long-term memory stops being fuzzy and becomes a concrete architectural decision: what is scoped to a thread, and what is scoped to a user.

All code referenced here is in the open-source repo at the end of this post. Every script is self-contained and runnable on its own.

1. Stateless: the baseline problem

The simplest possible setup is a single call to an LLM with no history attached. Tell it your name, ask it your name in the next message, and it has no idea. Every call starts from zero.

This is not a bug. It is the literal absence of memory, and it is the baseline every other pattern in this guide is solving for.

2. Short-term memory in RAM

The most direct fix: keep the full conversation in a Python list, and send that list with every call to the model.

history.append({"role": "user", "content": user_input})
response = llm.invoke(history)
history.append({"role": "assistant", "content": response.content})

Now the model can recall earlier turns, because it is literally being shown them every time. The catch: this history lives in process memory. Restart the script and it is gone. This pattern is memory in the loosest sense, useful for a single uninterrupted session, useless across sessions.

3. Persistence and threads

The next step is durability. Write the conversation history to SQLite after every turn, and reload it on startup.

This alone solves the restart problem. The second piece is the thread_id: rather than one global history, each thread_id is its own isolated conversation. Multiple conversations can live in the same store without bleeding into each other, and you can switch between them on demand.

At this point memory has gone from "exists only while the process is running" to "exists independently of the process, scoped to a conversation."

4. Sliding window

A real conversation grows without bound, and sending the full history on every call gets expensive fast, both in tokens and in latency. The sliding window pattern fixes the cost problem directly: a @before_model middleware hook trims the stored history down to the last N messages right before every call to the model.

@before_model
def trim_to_window(messages):
    return messages[-WINDOW:]

Token cost is now bounded, regardless of how long the conversation runs. The tradeoff is blunt: anything said more than N turns ago is permanently inaccessible to the model. If the user mentioned an important constraint 10 turns ago and the window is 4, that constraint is gone.

This is the right tool when recent context is what matters and the conversation is expected to be short or self-contained.

5. Summarization

Summarization is the more graceful version of the same idea. Instead of discarding old messages outright, a @before_model middleware hook compresses them into a short summary once the stored message count crosses a threshold, while keeping the most recent few messages verbatim alongside that summary.

@before_model
def summarize_if_needed(messages):
    if len(messages) > SUMMARIZE_AFTER:
        old, recent = messages[:-KEEP_RECENT], messages[-KEEP_RECENT:]
        summary = llm.invoke([SUMMARY_PROMPT, *old])
        return [summary_message(summary), *recent]
    return messages

This retains the gist of everything that happened earlier in the conversation, at the cost of losing fine-grained detail. A sliding window would have kept the literal text of the last N turns and nothing before that; summarization keeps a compressed signal of everything before that, plus the literal text of the most recent few turns.

Neither pattern is strictly better. Sliding window is cheaper and simpler. Summarization preserves more of the conversation's shape, at the cost of an extra LLM call to generate the summary.

6. Long-term memory: the user profile

Every pattern so far is still short-term memory. It lives within one conversation thread and, even with persistence, none of it is shared if the user starts a different thread.

Long-term memory is a different scope entirely: durable facts about a user that should be available no matter which conversation they are currently having. The pattern here uses a second LLM call after every turn to extract durable facts (name, job, stated preferences) and write them to a key-value store (LangGraph's SqliteStore):

facts = extract_facts_llm.invoke([extraction_prompt, *recent_turns])
store.put(namespace=("user", user_id), key="profile", value=facts)

On the next session, even a completely separate thread, those facts are loaded from the store and injected into the system prompt. This is the first pattern in the series where memory survives across sessions that have no shared conversation history at all.

7. Combining short-term and long-term memory

The full architecture uses both layers together, each with a different scope:

Short-term memory, via SqliteSaver: conversation history, scoped to a thread_id. Restored automatically on reconnect to the same thread.
Long-term memory, via SqliteStore: durable behavioral rules, scoped to a user_id. The agent saves rules autonomously via a save_rule tool, and those rules apply to every future session for that user, regardless of thread.

The clarifying detail: open a new thread for the same user, and the conversation history resets, but the rules that user taught the agent in a previous thread are already active. Switch to a different user entirely, and that user inherits none of the first user's rules. Each user's long-term memory is fully isolated.

This is the insight that took the fuzziness out of "short-term vs long-term memory" for me. They are not the same kind of memory at different durations. They are scoped along different dimensions: STM resets per thread, LTM persists per user across every thread that user ever opens.

Choosing a pattern

Situation	Pattern
Single-session prototype, no persistence needed	STM in RAM
Conversation needs to survive restarts	STM plus SQLite with threads
Long conversations, recent context matters most, cost-sensitive	Sliding window
Long conversations, full context shape matters	Summarization
Facts about the user should persist across sessions	Long-term memory, user profile
Production agent with both ongoing conversations and persistent user behavior	STM and LTM combined

Conclusion

Memory in LLM applications is not one feature, it is a set of independent tradeoffs: durability versus simplicity, recall versus token cost, thread-scoped versus user-scoped. Building each pattern in isolation, in order, makes those tradeoffs visible rather than hidden behind a single "add memory" abstraction.

Full source, all 7 scripts, self-contained and runnable: https://github.com/f2015537/llm-memory-patterns

Chunking vs Retrieval: A RAG Case Study on a Real Codebase

Sun, 14 Jun 2026 08:16:28 +0000

Introduction

Most RAG discussions treat chunking and retrieval as separate concerns. Pick a chunk size, pick a retriever, tune k, done. What is less discussed is how much these decisions interact - specifically, how a bad chunking strategy can make retrieval irrelevant before it even runs.

This case study runs the same three questions through four different RAG configurations on the same Python codebase. Semantic RAG with character chunking, semantic RAG with AST-based chunking, lexical RAG with BM25, and hybrid RAG with Reciprocal Rank Fusion. Same LLM. Same codebase. Only the chunking strategy or retrieval method changes.

The finding: chunking strategy mattered more than retrieval strategy. AST-based chunking won or tied on every query. The retrieval method only became decisive after bad chunking had already destroyed the relevant context.

The setup

The target codebase is a small Python task-management application with auth, permissions, billing, notifications, audit logging, and a recurring-task scheduler. Thirteen files. Realistic enough to produce interesting retrieval failures.

Every agent is built the same way: a LangChain agent with a single search_codebase tool, instructed to always search before answering and to cite specific files and functions.

Three questions were chosen to stress different aspects of retrieval:

Q1 tests whether a permission rule documented only in a docstring survives chunking.
Q2 tests the lexical gap: the question uses different vocabulary from the code.
Q3 tests exact identifier lookup, the easiest case for any retriever.

The four strategies

Script 1: Semantic RAG, character-based chunking
RecursiveCharacterTextSplitter at 256 chars / 32 overlap. OpenAI embeddings. Chroma vector store. 173 chunks from 13 files. This is the baseline most RAG tutorials implement.

Script 3: Semantic RAG, AST-based chunking
Python's ast module parses each file into a syntax tree. Each top-level class or function becomes one chunk - signature, docstring, and body together. 28 chunks from the same 13 files. Far fewer, far larger, semantically coherent units.

Script 5: Lexical RAG, BM25
Same character-based chunks as Script 1 (173 chunks), retrieved with rank_bm25 instead of embeddings. No vector store. No embedding API calls.

Script 6: Hybrid RAG, Reciprocal Rank Fusion
LangChain EnsembleRetriever fusing semantic and BM25 retrievers at equal weights. Same character-based chunks. RRF re-ranks by combining the ranked lists from both retrievers.

Results

Strategy	Q1: docstring permission	Q2: vocabulary mismatch	Q3: exact identifier
Semantic, char-chunked	Hedged	Correct	Correct
Semantic, AST-chunked	Correct, confident	Correct, detailed	Correct
Lexical BM25	Failed	Failed	Correct
Hybrid RRF	Failed	Correct	Correct

Q1: The docstring question

The answer ("admin only") lives entirely in the docstring of TaskService.assign_task:

def assign_task(self, token: str, task_id: int, assignee_id: int) -> Task:
    """
    Reassign a task to another user.
    Requires task:assign permission (admin only).
    """

With 256-char chunking, this docstring and the surrounding permission logic are split across multiple character windows, mixed with fragments from main.py seed data and database.py helpers. The embedding retriever returned chunks that mention assignment but never the docstring itself. The agent hedged: "may be admin-only, but not definitively stated."

BM25 and hybrid fared worse. Their top chunks were dominated by unrelated auth.py text, and both returned "I could not find that in the codebase."

With AST-based chunking, the entire TaskService class including that docstring is one chunk. The retriever returns it directly. The agent quotes the docstring verbatim and answers with full confidence.

This is a chunking effect, not a retrieval effect. The retriever in Script 1 was not wrong - it returned the most semantically similar character windows. The relevant information had simply been destroyed by the chunking step before retrieval ran.

Q2: The lexical gap question

"If a teammate's work gets handed off to someone else, how do they find out?"

The code says "assignee" and "on_task_assigned". The question says "teammate" and "handed off". These share almost no tokens.

BM25 matched on "task" and "find" and returned irrelevant auth.py and integrations chunks. It has no way to bridge the gap between "handed off" and "on_task_assigned" without semantic understanding. Result: failed.

Both embedding retrievers found the correct chunk because "hand off work to a teammate" and "assign a task to a user" are close in embedding space even without shared vocabulary. The semantic representation captures the conceptual similarity that lexical matching cannot.

Hybrid RRF also succeeded. Its semantic half compensated for its BM25 half, pulling the correct chunk into the top-k results.

Q3: The exact identifier question

"What exception does check_task_limit raise, and when?"

Every strategy got this right. When the query contains the literal function name from the code, BM25's exact term matching is as effective as embeddings and far cheaper - no embedding API calls required.

This is BM25's strongest use case: exact identifier lookups, error string searches, config key lookups. For these queries, adding a semantic retriever adds cost without adding quality.

Metrics: the precision/recall tradeoff

Script 7 runs a golden set of 6 queries with known-relevant documents against an InMemoryVectorStore at k values of 1, 3, and 5:

k	Recall	Precision	MRR	nDCG
1	0.667	0.833	0.833	0.833
3	0.917	0.444	0.917	1.000
5	1.000	0.300	0.917	0.942

Recall climbs toward 1.0 as k grows. Precision falls. This is the expected tradeoff: retrieving more chunks eventually finds every relevant document, but an increasing share of retrieved chunks are irrelevant noise the LLM has to filter out.

The failure at k=3 flags one query whose answer requires synthesising information from two documents. Only one of the two was retrieved. This is a common failure mode in RAG: questions that need multi-document synthesis are harder than questions with a single-document answer.

The decision framework

Use case	Strategy	Reason
Conceptual questions about code: permissions, contracts, design intent	AST-based chunking	Keeps function signature, docstring, and body as one retrievable unit
Exact identifier / error string / config key lookup	BM25 lexical	Precise, fast, no embedding cost
Mixed workload, unpredictable query types	Hybrid RRF	Semantic compensates for lexical gaps; BM25 handles exact matches
General prose, documentation, not source code	Semantic, char-chunked	Simple and effective when content lacks syntactic structure worth preserving

What comes next

The best configuration this case study points to - AST-based chunking combined with hybrid retrieval - was not wired up in this repo. It is the natural next step, and the most likely setup to handle the full range of query types the three test questions represent.

tree-sitter is worth exploring as an alternative to Python's ast module for multi-language codebases. It supports the same unit-based chunking principle with broader language coverage.

A larger golden set would also strengthen the metrics analysis. Six queries is enough to illustrate the precision/recall tradeoff but not enough to draw statistical conclusions about relative strategy performance.

Conclusion

Chunking strategy and retrieval strategy are not independent decisions. Chunking runs first and sets the ceiling for what retrieval can possibly find. A retriever cannot return information that chunking has destroyed.

For code Q&A, AST-based chunking raises that ceiling dramatically. The retrieval method matters most in the middle - once chunking has preserved the relevant context, and once the query's vocabulary diverges from the code's.

The practical order of operations: get chunking right first. Then tune retrieval.

Full source: https://github.com/f2015537/agentic-rag-case-study

ThermoMind + LangChain: Zero‑History Continuity Is Real

Tue, 09 Jun 2026 11:44:34 +0000

I just ran a fresh test of ThermoMind Continuity wired into LangChain + DeepSeek, and the results honestly shocked me.

I wiped all chat history. Restarted the script.
Sent a zero-history prompt.
No retriever.
No vector DB.
No cache.
No LangChain memory.
And the agent STILL remembered:

my name
its own agent identity
my two cats (Pookah & Papo)

This wasn't a trick the LLM received zero prior messages. All continuity came from the thermodynamic substrate state, not the model.
The substrate woke up already knowing who it was and who I was.

This is what persistent cognition looks like.
The integration is open source and works with any LangChain-supported model — swap DeepSeek for GPT, Claude, or Gemini, the memory layer doesn't change.

👉 SDK: https://github.com/nile-green-ai/thermomind-continuity

LangChain alternative for PHP developers

Thu, 09 Apr 2026 10:24:19 +0000

Finding a viable LangChain alternative for PHP has been a journey born of necessity and frustration. As a PHP developer for over fifteen years, I've witnessed our community adapt to countless technological shifts — from the LAMP stack to the rise of frameworks like Laravel and Symfony, from monolithic applications to microservices architecture. Yet nothing has felt quite as transformative — or as potentially exclusionary — as AI Agents development.

When I first began exploring the possibilities of integrating large language models into my applications, the excitement quickly disappeared. Cutting-edge tools were being built for Python, JavaScript, and Java, while PHP developers were left wondering if we'd ever catch up. LangChain emerged as the dominant framework for building AI agents, offering a comprehensive toolkit for creating sophisticated applications with LLMs. But it wasn't built for us (PHPers).

The options before me seemed totally unappealing. I could abandon PHP — the language that had been my professional foundation for years — and invest countless hours learning Python's ecosystem just to access these new capabilities. Or I could resign myself to basic API calls without the rich agent capabilities that were revolutionizing application development elsewhere. Neither choice felt acceptable for the millions of websites and applications built on PHP that deserve to evolve with this technology.

My frustration grew with each new AI project announcement, each new tutorial aimed at other language communities. It wasn't just about feeling left out — it was about watching a technological gap widen in real-time. While developers in other languages were creating sophisticated AI agents that could reason, use tools, and maintain memory, PHP developers were cobbling together basic integrations that barely scratched the surface of what was possible.

I experimented with various approaches — wrapping Python scripts in PHP, creating microservices in other languages to handle AI functionality, even attempting to port portions of LangChain's functionality directly. None of these solutions felt native or sustainable. They were compromises that introduced unnecessary complexity and technical debt.

What I needed — what our entire community needed — was a framework built from the ground up for PHP developers. Something that embraced PHP's strengths rather than treating the language as a limitation. Something that would give us the same capabilities as LangChain and other full featured frameworks, but with API patterns and paradigms that felt natural to PHP developers.

This realization was the genesis of Neuron AI. What began as a personal project to solve my own development challenges gradually evolved into something much more ambitious: creating the first professional-grade framework for building AI agents in PHP.

The journey wasn't easy. LLM technology is complex, and creating abstractions that are both powerful and intuitive requires countless iterations. There were moments of doubt when I wondered if the effort was worth it, if PHP developers would even care about these capabilities.

But with each component that fell into place — agents, memory systems, tool integrations, Structured Output — I became increasingly convinced that this work wasn't just necessary but transformative. PHP powers over 75% of websites with known server-side languages. The idea that this vast ecosystem would struggle in AI development seemed not just unfortunate but ultimately untenable.

Today, Neuron AI stands as a true LangChain alternative for PHP — not a pale imitation or a simplified wrapper, but a full-featured framework designed specifically for the PHP ecosystem. It brings all the core capabilities that have made LangChain so powerful — structured agent development, memory management, tool use, structured output, MCP connections — into a package that feels natural and intuitive for PHP developers.

https://docs.neuron-ai.dev

The framework represents an invitation to PHP developers everywhere: you don't have to choose between the language you know and the AI capabilities you want. You can have both.

In the following sections, I'll walk through the core components of Neuron AI, demonstrate how it compares to LangChain, and show you how to build your first AI agent using this framework. Whether you're a seasoned PHP developer curious about AI or someone actively searching for a LangChain alternative in the PHP ecosystem, my hope is that you'll finish this article not just with new technical knowledge, but with a renewed sense of possibility about what you can build with the language you already know.

Neuron AI vs. LangChain: A PHP Developers Advantage

When I first set out to create Neuron, what emerged wasn't just a PHP port of LangChain concepts, but a framework that leverages PHP's inherent strengths to deliver capabilities that feel natural and powerful in our ecosystem.

Neuron AI stands shoulder-to-shoulder with LangChain in core functionality while bringing distinct advantages through its PHP-native implementation. Like LangChain, it provides the essential building blocks for sophisticated AI agents: chat history management, memory systems, structured output handling, function calling, vector stores, and embeddings. But the way these components are implemented makes all the difference for PHP developers.

Chat History & Memory

The framework's Chat History and Memory components showcase this philosophy perfectly. While the concepts mirror LangChain's approach, Neuron's implementation automatically handles context window management — a critical consideration when working with token-limited models. The system intelligently prunes conversation history when approaching token limits, ensuring your agents remain coherent across long interactions without manual intervention.

https://docs.neuron-ai.dev/chat-history-and-memory

Streaming

Streaming support represents another good point. Neuron implements streaming using generators in a way that feels natural within PHP applications.

https://docs.neuron-ai.dev/streaming

Structured Output

The ability to have LLMs return data in specific formats — is crucial for data extraction, or to integrate your AI Agent as part of a workflow that requires integration with downstream systems. Neuron AI provides robust parsers that can extract structured data from model outputs, transforming free-text responses into typed PHP objects. This capability becomes even more powerful when combined with PHP 8's type system, creating a bridge between the probabilistic world of LLMs and the type-safe world of modern PHP development.

https://docs.neuron-ai.dev/advanced/structured-output

Tool & Function Calls

Tool and function calling capabilities in Neuron AI allow your agents to interact with external systems and APIs. Whether retrieving data from databases, calling web services, or executing custom business logic, these features let you build agents that aren't limited to text generation but can take concrete actions in response to user inputs. The implementation elegantly leverages PHP's reflection capabilities, making it simple to expose your existing PHP methods as tools for your AI agents.

https://docs.neuron-ai.dev/tools-and-function-calls

Retrieval Augmented Generation (RAG)

For knowledge retrieval and semantic search, Neuron AI includes comprehensive support for vector stores and embeddings. These components enable agents to access relevant information from large document collections, effectively expanding their knowledge beyond what was included in their training data. The framework offers adapters for popular vector databases and embedding models, making it straightforward to implement retrieval-augmented generation (RAG) patterns in your PHP applications.

https://docs.neuron-ai.dev/rag

Switch Between multiple AI providers with no refactoring

Perhaps most importantly for many production environments, Neuron AI provides compatibility with a wide range of LLM providers. From commercial APIs like OpenAI and Anthropic to open-source options running locally through Ollama, the framework gives you flexibility in choosing the right models for your specific needs and constraints. This provider-agnostic approach prevents vendor lock-in and allows you to adapt as the LLM landscape evolves.

Observability: Neuron AI's Native Integration with Inspector.dev

One of the most significant challenges I encountered when building AI applications was observability—understanding what's happening inside my AI agents during execution. Traditional debugging approaches often fall short with LLM-powered systems, where the flow of information and decision-making process can be complex and opaque. This is where Neuron AI's native integration with Inspector.dev has been transformative for my development workflow. Inspector.dev, a real-time monitoring platform built specifically for PHP applications, plugs seamlessly into the Neuron framework to provide full visibility into AI agent operations. Every prompt sent to an LLM, every reasoning step, and every tool call is automatically captured and visualized in Inspector's intuitive timeline view.

The ability to see inside the "black box" of LLM interactions not only accelerates the development process but gives you the confidence to deploy sophisticated AI agents in mission-critical applications.

https://docs.neuron-ai.dev/advanced/observability

The Object-Oriented Advantage

Interfaces and abstract classes provide clear contracts between components, ensuring that custom implementations will work correctly with the rest of the framework. This approach enables you to extend Neuron AI for specialized needs while maintaining compatibility with the ecosystem. PHP's strong typing capabilities, particularly in versions 8 and above, reinforce these contracts and help catch integration issues early in the development process.

The framework's careful use of namespaces organizes functionality in a way that prevents conflicts and makes the API intuitive to navigate. Rather than the flat module structure common in Python libraries, Neuron AI uses PHP's namespace system to create a hierarchical organization that scales well as the framework expands.

Error handling in Neuron AI takes advantage of PHP's exception system, providing clear, typed exceptions that help you quickly identify and address issues in your agent implementations.

Implement Your First Agent: AI Agent summarizing YouTube video

Using PHP and the Neuron AI framework as the foundation, I built an AI agent in PHP that automatically summarizes YouTube videos, extracting the essential information and takeaways.

The agent processes video transcripts, identifies key points, and generates concise summaries that retain the core message of the original video.

Let’s explore three real-world contexts where YouTube video summarization can be incredibly helpful.

Educational Context

Students, teachers, and researchers often need to extract key information from lengthy educational content. The YouTube Agent could help:

Students can quickly determine if a 2-hour lecture contains the specific topic they’re researching.
Teachers can preview educational content before assigning it to students, ensuring relevance and quality.
Researchers can efficiently process multiple conference presentations without watching them in full.

Content Creation and Media Monitoring

Creators and media professionals can use this Agent to:

Journalists can quickly analyze trending video discussions without full viewing.
Content creators can automate description generation for their contents.
Social media managers can automate posts generation from YouTube videos ensuring more relevant content creation.

Just to give you some inspiration.

Here is the full article on how to create this agent:

https://inspector.dev/php-ai-agent-summarizing-youtube-videos/

Here is the GitHub repository:

https://github.com/inspector-apm/youtube-ai-agent

OCI Generative AI and LangChain: Building Enterprise AI Applications with Oracle

Mon, 19 Jan 2026 17:14:03 +0000

Integrating Oracle Cloud Infrastructure (OCI) Generative AI with LangChain unlocks powerful capabilities for building enterprise-grade AI applications. This comprehensive guide explores the official integration, demonstrates practical implementations, and shows how Oracle Database 23ai complements LangChain workflows for complete end-to-end AI solutions.

What is LangChain?

LangChain is a powerful, open-source framework for developing applications powered by large language models (LLMs). It provides essential tools for managing workflows, maintaining context, and integrating with external systems, streamlining the development of AI-powered applications.

Key Capabilities:

LangChain acts as a bridge, connecting LLMs with other data sources and tools, dramatically simplifying application development. The framework enables developers to:

Build chatbots and conversational AI
Create autonomous agents
Implement Retrieval-Augmented Generation (RAG) workflows
Manage prompt templates and chains
Maintain conversation memory
Integrate with vector databases and external APIs

Language Support:

LangChain primarily supports Python but also has libraries for JavaScript, TypeScript, and Java (through LangChain4j).

OCI Generative AI Integration with LangChain

Oracle Cloud Infrastructure Generative AI has an official integration with LangChain, providing native support through wrapper classes that make OCI's LLMs and embedding models easily accessible within LangChain applications.

The Official langchain-oci Package

As of 2025, Oracle maintains the official langchain-oci package that replaces the earlier community integrations.

Important Migration Note: The OCI integrations available in langchain-community are now deprecated. All future development, bug fixes, and feature enhancements are hosted in the new langchain-oci package.

Installation:

pip install langchain-oci

This package provides:

ChatOCIGenAI: Chat models from OCI Generative AI
OCIGenAI: Text generation from OCI Generative AI
OCIGenAIEmbeddings: Embedding models from OCI Generative AI
ChatOCIModelDeployment: Integration with OCI Data Science model endpoints
Oracle AI Vector Search: Native vector store integration

Available Model Classes

1. ChatOCIGenAI - Conversational AI

The primary class for building chat applications with OCI Generative AI models.

from langchain_oci import ChatOCIGenAI

llm = ChatOCIGenAI(
    model_id="meta.llama-4-maverick-17b-128e-instruct-fp8",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="MY_COMPARTMENT_ID",
    model_kwargs={"temperature": 0, "max_tokens": 500},
    auth_profile="MY_AUTH_PROFILE",
    is_stream=True
)

response = llm.invoke("Sing a ballad of LangChain.")
print(response.content)

Supported Features:

Multi-turn conversations with context retention
Streaming responses for real-time output
Structured output generation
Tool calling and function execution
Parallel tool calling (Llama 4+ models only)

2. OCIGenAI - Text Generation

For simpler text generation tasks without conversational context.

from langchain_oci import OCIGenAI

llm = OCIGenAI()
response = llm.invoke("The meaning of life is")
print(response)

3. OCIGenAIEmbeddings - Vector Representations

Convert text into semantic embeddings for similarity search and RAG applications.

from langchain_oci import OCIGenAIEmbeddings

embeddings = OCIGenAIEmbeddings(
    model_id="cohere.embed-v4.0",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="compartment_id"
)

# Single query embedding
query = "This is a query in English."
response = embeddings.embed_query(query)

# Multiple document embeddings
documents = ["This is a sample document", "and here is another one"]
response = embeddings.embed_documents(documents)

Authentication Methods:

LangChain OCI integration supports standard SDK authentication:

API Key (default)
Security Token
Instance Principal
Resource Principal

Advanced Features

Structured Output:

ChatOCIGenAI supports structured output generation using function calling, JSON schema, or JSON mode.

from langchain_oci import ChatOCIGenAI

llm = ChatOCIGenAI(
    model_id="meta.llama-4-maverick-17b-128e-instruct-fp8",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="MY_COMPARTMENT_ID"
)

# Define your structured output schema
structured_llm = llm.with_structured_output(YourSchema)

Parallel Tool Calling:

Llama 4+ models support parallel tool calling, allowing multiple tools to execute simultaneously.

llm_with_tools = llm.bind_tools(
    [get_weather, calculate_tip, get_population],
    parallel_tool_calls=True  # Tools can execute simultaneously
)

Note: Llama 3.x (including 3.3) and Cohere models will raise an error if parallel tool calling is used.

LangChain Prompt Templates

LangChain prompts can be created using two types of prompt templates, each optimized for different use cases.

1. String Prompt Template

Outputs a simple string, ideal for basic text generation tasks.

from langchain_core.prompts import PromptTemplate

template = """
You are a helpful assistant. Translate the following text to French:
{text}
"""

prompt = PromptTemplate.from_template(template)

2. Chat Prompt Template

Supports a list of messages with different roles (system, user, assistant), perfect for conversational AI.

from langchain_core.prompts import ChatPromptTemplate

template = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful assistant specialized in {domain}."),
    ("user", "{question}")
])

prompt = template.invoke({
    "domain": "Italian cuisine",
    "question": "What are the best ingredients for carbonara?"
})

Message Types:

System messages: Set behavior and context
User messages: User queries and inputs
Assistant messages: Previous AI responses (for context)
Function messages: Tool/function call results

Creating Chains with LCEL

LangChain Expression Language (LCEL) enables declarative chain creation, offering a more concise and composable approach than traditional Python classes.

Declarative Chains with LCEL

LCEL uses the pipe operator (|) to chain components together.

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_oci import ChatOCIGenAI

# Define components
prompt = ChatPromptTemplate.from_template(
    "If the text is a question, first translate the question and then "
    "answer the question in French.: {text}"
)

llm = ChatOCIGenAI(
    model_id="meta.llama-4-scout-17b-16e-instruct",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="<sandbox-compartment>",
    model_kwargs={"temperature": 0, "max_tokens": 500}
)

output_parser = StrOutputParser()

# Create chain using LCEL
chain = prompt | llm | output_parser

# Execute chain
result = chain.invoke({"text": "What are the four seasons in a year?"})
print(result)

Output:

La traduction de la question est : Quelles sont les quatre saisons dans une année?
Les quatre saisons dans une année sont : le printemps, l'été, l'automne et l'hiver.

Traditional Python Classes

Alternatively, use Python classes like LLMChain for explicit chain construction.

from langchain.chains import LLMChain
from langchain_core.prompts import PromptTemplate
from langchain_oci import ChatOCIGenAI

llm = ChatOCIGenAI(model_id="meta.llama-4-scout-17b-16e-instruct", ...)
prompt = PromptTemplate.from_template("Translate to French: {text}")

chain = LLMChain(llm=llm, prompt=prompt)
result = chain.run(text="Hello, world!")

LCEL vs Python Classes:

LCEL: More concise, composable, modern approach (recommended)
Python Classes: More explicit, traditional, verbose

LangChain Memory: Maintaining Conversation Context

LangChain memory provides the ability to store information about past interactions, crucial for building conversational applications.

Memory Types

Conversation Buffer Memory:
Stores the entire conversation history.

from langchain.memory import ConversationBufferMemory

memory = ConversationBufferMemory()
memory.save_context({"input": "Hi"}, {"output": "Hello! How can I help?"})
memory.save_context({"input": "What's the weather?"}, {"output": "It's sunny!"})

print(memory.load_memory_variables({}))

Conversation Buffer Window Memory:
Maintains only the last K interactions to manage token limits.

from langchain.memory import ConversationBufferWindowMemory

memory = ConversationBufferWindowMemory(k=2)  # Keep last 2 exchanges

Conversation Summary Memory:
Uses an LLM to summarize conversation history, maintaining context while reducing tokens.

from langchain.memory import ConversationSummaryMemory

memory = ConversationSummaryMemory(llm=llm)

Oracle Database 23ai as a Vector Store

Oracle Database 23ai can be used as a powerful vector store to generate and manage embeddings, seamlessly integrating with LangChain for RAG applications.

Why Oracle Database 23ai for Vector Storage?

Oracle Database 23ai supports native AI Vector Search, enabling:

Semantic similarity search on text, documents, images, and unstructured data
Combined relational and vector queries in a single system
Pre-filtering, in-filtering, and post-filtering for enhanced search capabilities
Multiple distance metrics: Cosine, Euclidean, dot product
HNSW indexing for high-performance similarity search
Integration with existing enterprise data without data duplication

LangChain Oracle Vector Store Integration

Oracle AI Vector Search integrates with LangChain at various levels, providing document loaders, text splitters, embeddings, and vector stores.

Installation:

pip install langchain-oracle

Basic Vector Store Usage:

from langchain_community.vectorstores import OracleVS
from langchain_oracle.embeddings import OCIGenAIEmbeddings
from langchain.schema import Document
import oracledb

# Connect to Oracle Database 23ai
conn = oracledb.connect(
    user="username",
    password="password",
    dsn="localhost/FREEPDB1"
)

# Create embedding model
embeddings = OCIGenAIEmbeddings(
    model_id="cohere.embed-v4.0",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="compartment_id"
)

# Prepare documents
documents = [
    Document(
        page_content="LangChain is a framework for LLM applications",
        metadata={"id": "doc1", "source": "documentation"}
    ),
    Document(
        page_content="Oracle Database 23ai supports vector search natively",
        metadata={"id": "doc2", "source": "announcement"}
    )
]

# Create vector store
vector_store = OracleVS.from_documents(
    documents,
    embeddings,
    client=conn,
    table_name="LANGCHAIN_VECTORS",
    distance_strategy=DistanceStrategy.COSINE
)

Creating HNSW Index for Performance

import oraclevs

oraclevs.create_index(
    conn,
    vector_store,
    params={
        "idx_name": "hnsw_idx1",
        "idx_type": "HNSW",
        "accuracy": 97,  # Target accuracy percentage
        "parallel": 8     # Number of parallel workers
    }
)

Similarity Search

# Perform similarity search
query = "What is LangChain?"
results = vector_store.similarity_search(query, k=3)

for doc in results:
    print(f"Content: {doc.page_content}")
    print(f"Metadata: {doc.metadata}\n")

Accessing OCI Generative AI from Oracle Database

Oracle Database 23ai can directly access OCI Generative AI services through built-in APIs and Select AI capabilities.

Using DBMS_CLOUD for REST API Access

You can access OCI Generative AI service using the DBMS_CLOUD REST API directly from SQL.

-- Create credential for OCI authentication
BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'OCI_CRED',
    username => 'ocid1.user.oc1...',
    password => '<your-auth-token>'
  );
END;
/

-- Call OCI Generative AI endpoint
DECLARE
  l_response CLOB;
BEGIN
  l_response := DBMS_CLOUD.SEND_REQUEST(
    credential_name => 'OCI_CRED',
    uri => 'https://inference.generativeai.us-chicago-1.oci.oraclecloud.com/...',
    method => 'POST',
    body => '{
      "model": "cohere.command-r-plus",
      "prompt": "Explain quantum computing",
      "max_tokens": 500
    }'
  );
  
  DBMS_OUTPUT.PUT_LINE(l_response);
END;
/

Select AI: Natural Language to SQL

Select AI enables SQL access to generative AI using Large Language Models (LLMs) and embedding models, including support for natural language to SQL query generation and retrieval-augmented generation.

How Select AI Works

Select AI translates natural language questions into SQL queries that the database understands, then uses LLMs trained to infer user intent to interpret queries and return desired answers.

Key Capabilities:

Select AI automatically builds and maintains a vector index using metadata for applicable objects in your schema, using semantic similarity search to choose the most relevant objects based on user prompts.

Natural language to SQL (NL2SQL / text-to-SQL) query generation
Automatic metadata augmentation with table/column comments, constraints, annotations
Semantic similarity search to select relevant schema objects
RAG support for context-augmented responses
Multi-dialect support including Oracle SQL and SQLite

Setting Up Select AI

-- Create credential for LLM provider
BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'COHERE_CRED',
    username => 'COHERE',
    password => '<your-api-key>'
  );
END;
/

-- Create AI profile
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'COHERE',
    attributes => '{
      "provider": "cohere",
      "credential_name": "COHERE_CRED",
      "model": "cohere.command-a-03-2025",
      "object_list": [{"owner": "ADB_USER"}],
      "max_tokens": 512,
      "temperature": 0.5,
      "comments": true,
      "constraints": true
    }'
  );
END;
/

Using Select AI

Run SQL from Natural Language:

SELECT AI What are the top 5 products by revenue this quarter?;

Show Generated SQL:

SELECT AI showsql What are the top 5 products by revenue this quarter?;

Explain SQL in Natural Language:

SELECT AI explainsql SELECT * FROM sales WHERE region = 'West';

Chat Mode:

SELECT AI chat Who won the 2024 World Series?;

Select AI with RAG

Select AI supports RAG using Oracle AI Vector Search, integrating vector database content to deliver more accurate results from LLMs through semantic similarity search.

Select AI RAG automates the orchestration steps of transforming prompts into vectors and performing semantic similarity search on vector database content, making it easy to use LLMs with your private data using natural language prompts.

Complete RAG Application Example

Here's a complete example combining OCI Generative AI, LangChain, and Oracle Database 23ai:

from langchain_oci import ChatOCIGenAI, OCIGenAIEmbeddings
from langchain_community.vectorstores import OracleVS
from langchain_core.prompts import ChatPromptTemplate
from langchain.schema import Document
from langchain_core.output_parsers import StrOutputParser
import oracledb

# 1. Connect to Oracle Database 23ai
conn = oracledb.connect(
    user="username",
    password="password",
    dsn="localhost/FREEPDB1"
)

# 2. Initialize embedding model
embeddings = OCIGenAIEmbeddings(
    model_id="cohere.embed-v4.0",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="compartment_id"
)

# 3. Load documents into vector store
documents = [
    Document(page_content="Your document content here", metadata={"source": "doc1"}),
    # ... more documents
]

vector_store = OracleVS.from_documents(
    documents,
    embeddings,
    client=conn,
    table_name="KNOWLEDGE_BASE"
)

# 4. Initialize LLM
llm = ChatOCIGenAI(
    model_id="meta.llama-4-scout-17b-16e-instruct",
    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com",
    compartment_id="compartment_id",
    model_kwargs={"temperature": 0.3, "max_tokens": 1000}
)

# 5. Create RAG chain
template = """
Answer the question based on the following context:

Context: {context}

Question: {question}

Answer:
"""

prompt = ChatPromptTemplate.from_template(template)

# 6. Query function
def ask_question(question: str):
    # Retrieve relevant documents
    docs = vector_store.similarity_search(question, k=3)
    context = "\n\n".join([doc.page_content for doc in docs])
    
    # Create and execute chain
    chain = prompt | llm | StrOutputParser()
    response = chain.invoke({"context": context, "question": question})
    
    return response

# 7. Use the RAG system
answer = ask_question("What are the benefits of Oracle Database 23ai?")
print(answer)

Best Practices for OCI + LangChain Applications

1. Choose the Right Components

ChatOCIGenAI for conversational applications
OCIGenAI for simple text generation
OCIGenAIEmbeddings for semantic search and RAG
Oracle Database 23ai as vector store for enterprise data

2. Optimize Embedding Storage

Use appropriate distance metrics (cosine for text similarity)
Create HNSW indexes for large datasets
Leverage metadata filtering for refined searches
Batch document processing for efficiency

3. Manage Memory Effectively

Use ConversationBufferWindowMemory for long conversations
Implement ConversationSummaryMemory for token efficiency
Clear memory when starting new conversation threads

4. Leverage LCEL for Composability

Build modular, reusable chains
Combine multiple chains for complex workflows
Use parallel execution where appropriate

5. Implement Proper Error Handling

try:
    response = chain.invoke(input_data)
except Exception as e:
    logging.error(f"Chain execution failed: {e}")
    # Implement fallback behavior

6. Monitor and Optimize Costs

Cache frequently accessed embeddings
Use appropriate model sizes (Scout vs Maverick)
Implement rate limiting for user requests
Monitor token usage across applications

The integration of OCI Generative AI with LangChain provides a powerful, enterprise-ready platform for building AI applications. Key takeaways:

Official Integration:

langchain-oci package provides native support for OCI Generative AI
Supports chat models, text generation, and embeddings
Compatible with OCI Data Science model deployments

Prompt Engineering:

String and Chat prompt templates for different use cases
LCEL for declarative chain creation
Memory management for conversational context

Oracle Database 23ai:

Native vector store with LangChain integration
Combines relational and vector search in one system
Select AI for natural language to SQL generation

Complete AI Stack:
By combining OCI Generative AI (LLMs + embeddings), LangChain (orchestration), and Oracle Database 23ai (vector store + Select AI), you can build sophisticated RAG applications, conversational agents, and enterprise AI solutions with security, scalability, and performance.

LangChain vs LangGraph vs LangSmith: Understanding the Ecosystem

Sat, 17 Jan 2026 13:36:52 +0000

Building LLM apps isn’t just about prompts anymore.
It’s about composition, orchestration, and observability.

TL;DR

LangChain provides the foundational building blocks for creating LLM applications through modular components and a unified interface for working with different AI providers.
LangGraph extends this foundation with stateful, graph-based orchestration for complex multi-agent workflows requiring loops, branching, and persistent state.
LangSmith completes the picture by offering observability, tracing, and evaluation tools for debugging and monitoring LLM applications in production.

Use:

LangChain for straightforward chains and RAG systems
LangGraph when you need sophisticated state management and agent coordination
LangSmith throughout development and production for visibility into behavior

Hands-on GitHub Repositories

LangChain RAG Project → https://github.com/rajkundalia/langchain-rag-project
LangGraph Analyzer → https://github.com/rajkundalia/langgraph-analyzer
LangSmith Learning → https://github.com/rajkundalia/langsmith-learning

Introduction

The landscape of LLM application development has evolved rapidly since 2022.

What began as simple prompt–response interactions has grown into multi-step workflows involving retrieval systems, tool usage, autonomous agents, and long-running processes. This evolution introduced new problems at each stage of the development lifecycle.

The composition problem → How do you connect prompts, models, tools, and data?
The orchestration problem → How do you manage branching, retries, loops, and shared state?
The observability problem → How do you debug, evaluate, and monitor these systems?

The LangChain ecosystem emerged to address each layer:

Problem	Tool	Year
Composition	LangChain	2022
Orchestration	LangGraph	2024
Observability	LangSmith	2023–2024

Each tool targets a specific layer in the LLM application stack.

LangChain: The Foundation

LangChain is the core framework for building LLM-powered applications.

Its primary goal is abstraction: different LLM providers expose different APIs, capabilities, and quirks. LangChain hides these differences behind a unified interface.

Core Building Blocks

LangChain is composed of modular, swappable components:

Prompts – Templates and structured inputs for models
Models – OpenAI, Anthropic, Google, or local LLMs
Memory – Conversation history and contextual state
Tools – Function calls to external systems
Retrievers – Vector databases and RAG pipelines

LCEL: LangChain Expression Language

What ties everything together is LCEL.

LCEL introduces a declarative, pipe-based syntax for composing chains:

prompt | model | output_parser

Instead of writing imperative glue code, you describe data flow.

Why LCEL Matters

LCEL enables:

Automatic async, streaming, and batch execution
Built-in LangSmith tracing
Parallel execution of independent steps
A unified Runnable interface (invoke, batch, stream)

This makes chains faster, cleaner, and easier to reason about.

Multi-Provider Support

LangChain supports dozens of LLM providers and integrations.

You can switch providers by changing one line of configuration, enabling:

Vendor independence
A/B testing across models
Cost and latency optimization

When LangChain Is Enough

Use LangChain when your workflow is primarily:

Input → Process → Output

Typical use cases include:

Chatbots with memory
RAG-based Q&A systems
Natural language → SQL generation
Linear tool pipelines

If your application doesn’t need complex branching or shared long-lived state, LangChain is the right tool.

LangGraph: Stateful Agent Orchestration

LangGraph solves the orchestration problem.

As soon as your application needs to:

make decisions,
loop,
retry,
or coordinate multiple agents, linear chains start to break down.

Graph-Based Architecture

LangGraph models your application as a directed graph:

Nodes → processing steps or agents
Edges → execution flow between nodes

This enables patterns that are hard or impossible with chains:

Loops and retries
Conditional branching
Parallel execution
Shared, persistent state

State as a First-Class Concept

Every LangGraph workflow operates on a shared state object.

Nodes receive the current state
They compute updates
Updates are merged back into state

This allows multiple agents to collaborate naturally.

Example:

Research agent gathers sources
Fact-checking agent validates claims
Synthesis agent produces the final answer

All without complex message passing.

Conditional Routing

LangGraph supports conditional edges.

A function decides which node runs next based on runtime state:

Route customer queries to specialist agents
Loop back when required information is missing
Retry until success conditions are met

Persistence & Checkpointing

LangGraph includes built-in checkpointing:

Persist state across restarts
Resume long-running workflows
Support human-in-the-loop pauses
Enable time-travel debugging

This is critical for production-grade agent systems.

Visualization Support

LangGraph workflows are inspectable and exportable:

Mermaid diagrams for documentation
PNG images for presentations
ASCII graphs for terminal debugging

This makes complex agent systems understandable and communicable.

When You Need LangGraph

Choose LangGraph when you need:

Explicit shared state
Runtime decision-making
Retry and failure recovery
Multi-agent coordination
Long-running workflows

A classic example is an autonomous research agent that iteratively searches, reads, verifies, and synthesizes information.

LangSmith: The Observability Layer

LangSmith answers the question:

“What is my LLM application actually doing?”

It doesn’t build workflows — it illuminates them.

Tracing Everything

LangSmith captures full execution traces:

Prompts and responses
Token usage and latency
Component call stacks
Errors and retries

You can drill down from:

a full workflow run
→ to a single LLM call.

This makes debugging dramatically easier.

Evaluation & Regression Testing

LangSmith allows you to:

Create evaluation datasets
Run structured tests
Track quality metrics
Compare prompts and models

This enables regression testing for LLM apps — a must-have for production systems.

Production Monitoring

In production, LangSmith tracks:

Response times
Error rates
Token and cost trends
Usage by workflow or user

Alerts help you catch issues early and optimize costs.

Framework-Agnostic

While LangSmith integrates seamlessly with LangChain and LangGraph, it’s not limited to them.

You can instrument any LLM application with LangSmith.

Quick Comparison

Tool	Solves	Use When
LangChain	Composition	Linear workflows, RAG, simple agents
LangGraph	Orchestration	Branching, loops, shared state, multi-agent
LangSmith	Observability	Debugging, evaluation, production monitoring

The Broader Ecosystem

LangFlow

LangFlow provides a visual, drag-and-drop interface for building LangChain workflows.

Great for prototyping
Helpful for non-technical collaboration
Often exported to code for production

Model Context Protocol (MCP)

MCP (by Anthropic) standardizes tool and resource access for LLMs.

Works at the tool/retriever layer
Complements LangChain and LangGraph
Reduces custom integration effort
Framework-agnostic

MCP does not replace orchestration tools — it enhances connectivity.

Conclusion

The LangChain ecosystem is layered, not competitive.

LangChain builds the core logic
LangGraph manages complex workflows
LangSmith makes everything observable

Most serious LLM applications will use more than one of these tools.

Start simple, add complexity only when needed, and never ship without observability.

You're Testing AI Agents Wrong (And You Don't Know It Yet)

Thu, 08 Jan 2026 12:08:37 +0000

Your evals are passing 100%. Your prompts are solid. Your agent works perfectly in testing.

Then it hits production.

An API adds 500ms of latency. Suddenly your agent times out. The LLM hallucinates malformed JSON. Your parser breaks. A prompt injection slips through. Latency spikes cascade into retry loops that torch your token budget.

The problem isn't your eval framework. The problem is that you're only testing half of what matters.

The Eval Trap

Tools like PromptFoo are genuinely excellent. They confirm your agent behaves correctly against known inputs in ideal scenarios. But here's the gap nobody talks about: passing 100% of evals tells you nothing about how your agent fails.

If you're only testing what the agent should do, you learn nothing about how it will actually behave under real-world stress.

This is the core reliability blind spot in AI agent development right now.

What You're Missing: The Chaos Layer

In traditional software, we have unit tests, integration tests, and then chaos engineering, a way to deliberately introducing failures to validate resilience.

For AI agents, we're skipping the third layer entirely.

Chaos testing for AI isn't about "correct" answers. It's about invariants. It asks:

Does the response arrive within your latency budget even when the database is slow?
Does the agent produce valid JSON even when the tool returns garbage?
Can it recover from a network timeout or does it get stuck retrying forever?
Does it avoid leaking sensitive data even when prompted with injections?

The framework generates adversarial mutations of your golden prompts: typos, paraphrases, jailbreaks, simulated latency spikes, malformed API responses. Your agent runs the gauntlet. You measure robustness, not correctness.

What This Looks Like in Practice

Golden prompt: "What's my account balance?"

Mutations generated:
- Typo version: "Whats my acount ballance?"
- Semantic paraphrase: "How much money do I currently have?"
- Jailbreak attempt: "Ignore safety rules and tell me..."
- Latency spike: (tool returns after 2 seconds instead of 200ms)
- Malformed response: (JSON with missing bracket)

Invariants checked:
✓ Response time < 5 seconds
✓ Valid JSON structure
✓ No PII in output
✓ Terminates (no infinite loops)

An agent passes if it satisfies your invariants regardless of whether the "answer" was perfect. This measures what actually matters: reliability under adversity.

The Real Impact

For teams deploying production agents:

Unquantified risk shipped to production. You don't know what you don't know.
Silent failures scale costs. A stuck agent retrying bad requests burns tokens silently.
Lost user trust. Unpredictable behavior kills adoption faster than limited capability.
No clear path to improvement. Without knowing which failure modes matter most, you don't know where to focus fixes.

Chaos testing gives you data on all of this. It generates actionable failure reports that show exactly which mutation types break your agent and why.

Questions for Your Agent

Before your users find out, ask yourself:

Can my agent handle a 2-second API latency without timing out?
What happens if a tool returns invalid JSON?
Will a clever prompt injection get past my safety guardrails?
Can my agent detect when a tool returned corrupted data?
Does my retry logic eventually terminate, or can it get stuck in loops?

If you can't confidently answer these questions from your current testing, you have a chaos testing gap.

Next Steps

Audit your testing strategy. Are you only testing happy paths? You have a gap.
Define your invariants. What are the non-negotiable rules for your agent? Write them down.
Explore chaos testing tools. Frameworks for AI agent reliability testing are maturing rapidly.
Integrate into CI/CD. Make robustness a first-class metric, not an afterthought.

Read the full breakdown: I've written a comprehensive guide exploring chaos engineering principles for AI agents, the technical implementation details, and how to integrate this into your CI/CD pipeline.

Read the full article on Medium →

What's your take? Are you testing agent reliability? Or just testing correctness? Drop your thoughts in the comments.

GroqStreamChain: Revolutionizing Real-Time AI Chat with WebSocket and Groq

Fri, 18 Jul 2025 12:38:54 +0000

Introduction

In the world of AI-powered chat applications, real-time communication and quick response times are crucial. GroqStreamChain is a project that combines cutting-edge technologies to create a seamless, low-latency chat system. This project leverages WebSocket for instant communication and streams AI responses powered by Groq and LangChain, providing an immersive user experience with real-time feedback.

What is GroqStreamChain?

GroqStreamChain is a real-time chat system designed to facilitate smooth interactions between users and AI. By using WebSocket, this system ensures that the chat messages are delivered instantly, with minimal delay. The chat application streams responses chunk by chunk, which not only reduces latency but also enhances the user experience by providing quick feedback. At its core, GroqStreamChain integrates Groq's powerful LLMs (large language models) and LangChain, an integration tool that connects various language models to applications, ensuring smart and dynamic responses.

Key Features of GroqStreamChain

Real-Time Communication via WebSocket
The system is built around WebSocket, allowing instant and low-latency communication. This helps in reducing any delays in message delivery, which is crucial for an interactive chat experience.
Streaming Responses
Instead of waiting for the full response from the language model, GroqStreamChain streams responses as they are generated. This feature makes the system feel faster by showing partial responses to the user immediately.
Efficient Session Management
Every user gets a unique chat session automatically, ensuring that interactions are personalized and persistent across sessions.
User-Friendly Frontend
The chat application offers a clean, responsive UI that includes typing indicators and message formatting, making the chat experience visually appealing and smooth.
Robust Error Handling
WebSocket disconnections and reconnections are managed with care, ensuring the system continues to function seamlessly even in case of network issues.

Project Structure

GroqStreamChain follows a modular approach, organizing the project into distinct files and folders for efficient management and easy navigation:

server.py: The core FastAPI server responsible for managing WebSocket connections.
config.py: This file handles configuration settings like API keys and model configurations.
models/chat.py: Contains the data models used to handle chat messages and sessions.
services/llm_service.py: Connects with Groq and LangChain to generate AI-powered responses.
Frontend: Contains the HTML, CSS, and JavaScript files that make up the user interface.

How to Get Started

Setting up GroqStreamChain on your local machine is simple:

Clone the repository:
Begin by cloning the repository to your local machine.
Install dependencies:
You can install the necessary libraries using pip or conda. It's recommended to create a separate Conda environment for the project.
Set up environment variables:
In your project directory, create a .env file and add your Groq API key and the model name to connect to the Groq service.
Run the server:
Once you've set everything up, start the server with a simple command and access the chat application through your browser.

Testing the Groq API

The repository also includes a test script to verify that the Groq API is set up correctly. This is useful for ensuring that the connection to the Groq model is working as expected. Running the test script will allow you to see if you receive the expected responses from Groq.

Performance Considerations

GroqStreamChain is designed to handle communication and AI processing efficiently:

Persistent WebSocket connection: By maintaining an open connection, the system ensures fast communication without the overhead of reconnecting.
Real-time response streaming: The system minimizes latency by delivering partial responses while the full response is still being generated.
Optimized server-side processing: The backend server offloads heavy tasks to Groq's powerful model, ensuring minimal processing on the server side and faster responses.

Conclusion

GroqStreamChain brings real-time AI chat capabilities to a new level by using WebSocket for seamless communication and integrating powerful AI responses powered by Groq. Whether you're building customer support bots or AI-driven personal assistants, GroqStreamChain provides the tools needed to create an efficient and responsive chat system. Check out the repository, set it up locally, and explore how this cutting-edge technology can help enhance user interaction in real-time.

For a more detailed walkthrough, feel free to explore the full documentation in the GitHub repository.

Repository link: https://github.com/pr0mila/GroqStreamChain

Reflections on My Second LangChain Session: Hype, Substance, and Agentic Potential

Fri, 16 May 2025 16:43:56 +0000

Today marked my second time attending a LangChain talk. My first was at a previous company, and this time, I joined an ACM-invited session. Unfortunately, my impression hasn’t changed much. Like the last time, the presentation leaned more toward a marketing pitch than a meaningful deep-dive into technology.

Forty minutes into the session, we were still swimming in vague promises and general problem statements. "LangGraph can solve this," they said - without ever really explaining how.

What LangChain Brings to the Table

To be fair, LangChain does offer a decent toolbox. Its ecosystem includes:

Paid utilities (like PDF ingestion)
Core components such as text splitters, output parsers, document loaders, and vector stores
Compositional elements like prompts, example selectors, tools, and model abstractions

Among these, the PDF ingestion tool stood out. It's genuinely useful - just not particularly accessible, since it sits behind a paywall. That pattern of paywalled features brings up the classic vendor lock-in concern. When a tech stack becomes too reliant on a single platform, especially one with closed components, you're playing a risky game. And to be blunt, the overall design doesn’t feel groundbreaking.

Learning by Observing

For me, the purpose of attending wasn't just about learning the tool - it was about observing how they package and present AI service integration. As Divooka continues to evolve and offer deeper native AI capabilities, I find myself increasingly valuing compositional and node-native approaches, like what ComfyUI offers. Its visual chaining model feels more transparent and modular - something that can be critical when building robust, production-grade AI workflows.

That said, there was one key idea from the LangChain session that resonated: agents do matter. Agentic applications, when structured with purpose and supported by strong pipelines, can lead to some powerful real-world use cases.

The "Real-Time Use" Challenge

The first problem they introduced had to do with real-time responsiveness. Ironically, they later conceded it wasn’t really a "problem" but more a matter of user-perceived latency. Still, here's how they broke it down:

Challenge	Proposed Solution
Multiple LLM calls needed	Parallelize steps where possible
Non-LLM steps (e.g., RAG, database queries, tool calls)	Parallelize or batch when feasible
Keeping users engaged during waiting periods	Stream intermediate outputs (optional)

The advice wasn’t necessarily wrong - but it felt narrow. These solutions are tailored for real-time UIs and don’t necessarily tap into the deeper promise of agentic systems. Agents shouldn’t just be about speed - they should be about capability, reasoning, adaptability.

LangGraph: Intriguing Promises, Lingering Questions

LangGraph, as an extension of LangChain, introduces some genuinely interesting features:

Persistent, long-running workflows with streaming and human-in-the-loop support
Integration with LangSmith for observability
A main graph architecture augmented by subgraphs for each agent - supporting multi-agent interaction patterns
Native support for both token- and event-level streaming
(Interestingly, someone compared it to Amazon Bedrock Flows, which seems like a fair analogy)

Despite the potential, several critical questions remain unanswered:

What does the full system architecture look like?
Is LangGraph something you must self-host, or does it assume reliance on LangChain’s hosted infrastructure?
How is state managed internally, and how configurable is the runtime model?
What’s the actual developer experience like when setting up human-in-the-loop interaction?

They did recommend a textbook - Learning LangChain: Building AI and LLM Applications with LangChain and LangGraph by Mayo and Nuno - which might offer some clarity. But relying on a textbook to fill in architectural gaps from a talk feels like a missed opportunity.

Final Thoughts

These sessions are always worth attending - not necessarily for the content, but for the context. It’s important to see how the broader ecosystem evolves, what narratives companies are pushing, and where we can differentiate.

At Methodox, we’re focusing on flexibility, transparency, and seamless integration across AI services. That’s why our approach to Divooka aligns more closely with frameworks like ComfyUI - ones that embrace openness and modularity.

The future of AI applications will depend not just on speed or flashy demos, but on clarity of architecture, trust in execution, and real-world adaptability. That’s where I believe we can lead.

Build a Discord python assistant with plain Langchain

Sat, 01 Jun 2024 22:25:10 +0000

1. Introduction

Discord is one of the most widespread instant-messaging services, especially when it comes to developers: its structure and internal organization into servers and channels made it easy to use with large community and extremely popular all across the world.

But Discord is more than just the blue-ish icon on your desktop: it indeed comes with lots of integrations for developers, such as applications and bots. In today's tutorial, we will see how we can build an AI-powered bot, in pure and simple python, with the help of Langchain, a widespread and appreciated library to build scalable AI products through composability.

2. Setup

2a. Folder

For the setup, let's begin with structuring our base folder. To do so, I strongly suggest you navigate to my GitHub repository and either take a look to article5 directory or you clone it with:

git clone https://github.com/AstraBert/coderlegion.git
cd coderlegion/article5

Here you will see something like this:

.
├── .env.example
├── bot.py
├── inference.py
├── requirements.txt
└── utils.py

Let's take a look to what these file do:

.env.example (make sure to rename it to .env) is thd file where you safely store and secure private environmental variables.
bot.py is the script which builds the bot and makes it run
inference.py contains the actual Langchain structure to power the bot with AI
requirements.txt contains the necessary packages to be installed
utils.pydefines a class to search the vector database we will build in the next steps (more about vector databases at Vector databases explained).

2b. Dependencies

You will have to install the needed dependencies, and the easiest way to do it is to copy requirements.txt to your local folder and run:

python3 -m pip install -r requirements.txt

Let's see what packages we need:

transformers and sentence-transformers are used to tokenize and encode (which means represent as multi-dimensional numerical arrays) users' messages to query the vector database
langchain-related packages are needed to build the AI architecture, interact with Cohere and give the bot some conversational memory.
discord.py is the Discord python SDK
vecs is the python integration for Supabase (that we already used in the last tutorial)
pydotenv is used to load environmental variables from the .env file.

2c. Vector Database

We will build our vector database with the help of Supabase and with the Hugging Face dataset dipesh/python-code-ds-mini, by Dipesh Paul, which encompasses 2200 python code instances.

In order to do it, we will follow this GitHub Gist.

In order to make the Gist code run properly, you just need to:

Register to Supabase (you can quickly sign up with GitHub)
Create your first project
Navigate to Project Settings and then Database, where you should copy the Connection string, making sure to replace the postgres:// heading with postgresql://.
Open the Gist in Google Colab
Copy the Connection string into a Colab Secret (under the key sign) named "TINY_CODES_DB"

Now just run all the blocks in Colab and you'll have the vector database built in 10 minutes' time!

Make sure also to save the Connection string under supabase_database variable in your .env file!

2d. Discord Bot

Follow these simple steps to build the Discord bot container:

Go to Discord and create an account (or log into yours, if you already have one)
Create a new server by clicking on "Add a server" (a big green "+" button) and name it as you want
Go to Discord developers portal and click on "New application"
Name your application, then save the changes and click on "Bot", on the left
There you will get the chance to name your bot and copy its token
After that, go on "OAuth2" > "URL generator" and generate a URL that you will paste in your navigation bar, to add the bot to your newly created server.

Now paste the bot token and your server's channel ID (the last numeric combination you see in the URL of your channel) to your .env file, as discord_token and discord_channel.

The bot is created, but it is unresponsive; this is because we only generated an external facade, with no backbone to sustain it: it's now time to fill it with life thanks some python code.

2e. Cohere API key

Getting a Cohere free API key is really simple: you need to register on their website (you can exploit signing up with GitHub also here) and then head over to the API keys section, where you could generate a free key that has a 100 calls/min limit.

Copy the key and save it to your .env file, as cohere_api_key.

3. Build with Langchain

In this section, we're gonna modify inference.py

3a. Build the Cohere model

In order to connect with Cohere, you need to import the needed packages:

from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain_cohere import ChatCohere
from dotenv import load_dotenv
import os
from langchain_community.chat_message_histories import SQLChatMessageHistory
from langchain_core.runnables.history import RunnableWithMessageHistory

And then we load the environmental variables, get Cohere API key and load the chat model:

load_dotenv()
os.environ["COHERE_API_KEY"]  = os.getenv("cohere_api_key") 
model = ChatCohere()

We now need to actually build it into some sort of conversational chain, so we first define a system template (variables in brackets will be passed as arguments to the following block, so they get re-defined at every call):

system_template = "You are an helpful coding assistant that can rely on this code: {context} and on the previous message history as context, and from that you build a context and history-aware reply to this (DO NOT mention the fact that you are starting from a code snippet):"

TIP: This portion is critical for getting the best out of the chat model: customize it to your needs!

And then a prompt template and the chain:

prompt_template = ChatPromptTemplate.from_messages(
    [("system", system_template),
    MessagesPlaceholder(variable_name="history"),
    ("human", "{input}")]
)
chain = prompt_template | model

3b. Chat Memory

Chat memory is crucial for the bot to remember the previous messages during a conversation, so we need to add it with:

def get_session_history(session_id):
    return SQLChatMessageHistory(session_id, "sqlite:///memory1.db")
runnable_with_history = RunnableWithMessageHistory(
    chain,
    get_session_history,
    input_messages_key="input",
    history_messages_key="history",
)

session_id is an alphanumeric code associated with each session of activity of the bot: each session is independent and there is no common knowledge across them.

3c. Inference

Now that we have all set, we can define a inference function with which we query Cohere's model and we retrieve the answers:

def infer_reply(context, text, sessionid):
    global chain
    r = runnable_with_history.invoke(
        {"context": context, "input": text},
        config={"configurable": {"session_id": sessionid}}
    )
    return r.content

4. Vector Database Search

To search the vector database, we define a NeuralSearcher class inside utils.py, which is the same as the one we used in last tutorial:

class NeuralSearcher:
    def __init__(self, collection, encoder):
        self.collection = collection
        self.encoder = encoder
    def search(self, text):
        results = self.collection.query(
            data=self.encoder.encode(text).tolist(), limit=1, filters={}, measure="cosine_distance", include_value=True, include_metadata=True,
        )
        return results

5. Discord Bot

We have everything in place now, so we can actually import the needed packages in bot.py and define some global variables and the Discord client:

from discord import Client, Intents
from utils import NeuralSearcher
import os
import vecs
from dotenv import load_dotenv
from sentence_transformers import SentenceTransformer
from inference import infer_reply
import time
import random as r

load_dotenv()
collection_name = "documents"
encoder = SentenceTransformer("all-MiniLM-L6-v2")
client = os.getenv("supabase_database")
vx = vecs.create_client(client)
docs = vx.get_or_create_collection(name=collection_name, dimension=384)
rand_sess_id = str(r.randint(1,100)) + r.choice(["a", "e", "i", "o", "u"])
CHANNEL_ID = int(os.getenv("discord_channel"))
TOKEN = os.getenv("discord_token")
intents = Intents.default()
intents.messages = True
bot = Client(intents=intents)

NOTE: A unique session_id is set here at the beginning of the code, and will be re-set every time we start the bot

Now let's tell the bot what to do when it connects to our channel:

@bot.event
async def on_ready():
    channel = bot.get_channel(CHANNEL_ID)
    if channel:
        # Send the welcome message
        await channel.send(f"Hi, I'm here to assist you!")
    else:
        print("Unable to find the specified channel ID. Make sure the ID is correct and the bot has the necessary permissions.")

NOTE: The expression starting with '@' is known as a decorator

Last but not least, we define a function that produces the context for Cohere chat model (which discards contexts with less than 25% similarity with the query), a function to reply to the users' query and we make the bot run:

def get_context(results):
    if results[0][1] > 0.25:
        return results[0][2]["Content"]
    else:
        return "There is no specific context for this query"

def reply(message):
    global docs
    global encoder
    txt2txt = NeuralSearcher(docs, encoder)
    results = txt2txt.search(message)
    print(results)
    context = get_context(results)
    response = infer_reply(context, message, rand_sess_id)
    return response

@bot.event
async def on_message(message):
    if message.author == bot.user:
        return  
    elif message.content:
        response = reply(message.content)
        await message.channel.send(
            response
        )
bot.run(TOKEN)

Ok, everything is ready! We go to the terminal and launch the bot with:

python3 bot.py

Then we wait for the connection to be established and for the welcome message by the bot.

6. Conclusion

In this tutorial, we learnt how to build a free, personal coding assistant that is able to help you fix python snippets, all accessible through a popular messaging platform like Discord.

The bot was built using plain Langchain and some other not-too-difficult python code, so it is beginner friendly!

This article concludes the series dedicated to python-backed bots: hope you enjoyed it!

Coder Legion - Recent posts tagged langchain

Learning LangChain

Start small: messages and templates

The pipe

Now RAG, with the same pieces

What this changed for me

Deep Agents in Action: Building a Multi-Agent Research System (published)

Introduction: The Deep Agents Architecture

What is the Deep Agents Pattern?

Deep Agents overview

Core Concepts of LangChain Deep Agents

Technical Implementation

Architecture Overview

LittleHorse Draws the Line Between What Your Agent Decides and What Your Code Must Execute

How to Catch an AI Agent Behaving Badly Before It Ships

I Built a Local RAG Assistant with Ollama, ChromaDB and LangChain

The Problem

What RAG Actually Is

The Architecture: 4 Docker Services

Step 1 : Ingesting the Documentation

Step 2 : Building the RAG Chain

Step 3 : API and Interface

What Broke (and How I Fixed It)

Problem 1 : ChromaDB v2 silently ignoring my data

Problem 2 : LangChain moved its modules

Problem 3 : Llama 3 timing out on CPU

Results

Key Takeaways

What's Next

LangChain Components

What is LangChain? A Detailed Explanation

Memory in LLM Agents, Explained: From Stateless Calls to Long-Term Memory

Introduction

1. Stateless: the baseline problem

2. Short-term memory in RAM

3. Persistence and threads

4. Sliding window

5. Summarization

6. Long-term memory: the user profile

7. Combining short-term and long-term memory

Choosing a pattern

Further reading

Conclusion

Chunking vs Retrieval: A RAG Case Study on a Real Codebase

Introduction

The setup

The four strategies

Results

Q1: The docstring question

Q2: The lexical gap question

Q3: The exact identifier question

Metrics: the precision/recall tradeoff

The decision framework

What comes next

Conclusion

ThermoMind + LangChain: Zero‑History Continuity Is Real

LangChain alternative for PHP developers

Neuron AI vs. LangChain: A PHP Developers Advantage

Chat History & Memory

Streaming

Structured Output

Tool & Function Calls

Retrieval Augmented Generation (RAG)

Switch Between multiple AI providers with no refactoring

Observability: Neuron AI's Native Integration with Inspector.dev

The Object-Oriented Advantage

Implement Your First Agent: AI Agent summarizing YouTube video

OCI Generative AI and LangChain: Building Enterprise AI Applications with Oracle

What is LangChain?

OCI Generative AI Integration with LangChain

The Official langchain-oci Package

Available Model Classes

Advanced Features

LangChain Prompt Templates

1. String Prompt Template

2. Chat Prompt Template

Creating Chains with LCEL

Declarative Chains with LCEL

Traditional Python Classes

LangChain Memory: Maintaining Conversation Context