DEV Community: Syed Mehrab

Stop Building Static Chatbots: A Beginner’s Guide to LangGraph with Persistence 🚀

Syed Mehrab — Thu, 09 Apr 2026 08:07:46 +0000

Building a chatbot that just responds to prompts is easy. Building an Agent that can think, use tools, and remember conversations across restarts? That’s where it gets tricky.

Enter LangGraph. It’s the evolution of LangChain, designed to give you total control over the flow of your AI.

In this post, I’ll break down the core concepts and show you how to implement a persistent agent using MongoDB as your "brain."

1. The Core Concepts (The "Mental Model")

Before we code, you need to understand the four pillars of LangGraph:

State: The "Source of Truth." It's a shared dictionary or object that every part of your graph can see and update.

Nodes: These are just regular Python functions. They take the State, do some work (like calling Claude or GPT), and return an update.

Edges: These are the "traffic lights" They tell the graph where to go next. Conditional Edges are the most powerful. they decide if the agent should call a tool or talk to the human.

Checkpointer: The "Save Game" button. It stores your state in a database (like MongoDB) so your agent doesn't suffer from amnesia if the server restarts.

2. Setting Up Your State

In LangGraph, you define what your agent needs to remember. Usually, this is a list of messages.

from typing import Annotated, TypedDict
from langgraph.graph.message import add_messages

class AgentState(TypedDict):
    # 'add_messages' is a Reducer. 
    # It tells LangGraph: "Don't overwrite the list, just append new messages!"
    messages: Annotated[list, add_messages]
    user_id: str

3. Creating Your First Node

A node is where the logic happens. Here is a simple node that calls an LLM:

from langchain_anthropic import ChatAnthropic

model = ChatAnthropic(model="claude-3-5-sonnet-20240620")

def chatbot_node(state: AgentState):
    # The node receives the state, calls the LLM
    response = model.invoke(state["messages"])
    # It returns a dictionary updating the 'messages' list
    return {"messages": [response]}

4. Adding "Memory" with MongoDB Checkpointers

If you want your agent to remember "Ali" from yesterday's conversation, you need a Checkpointer. Since many of us use MongoDB, the MongoDBSaver is a perfect choice.

Why use a Checkpointer?
Fault Tolerance: If a node fails, it resumes from the last save.

Multi-User: Use a thread_id to keep 1,000 different user conversations separate.

Audit Trails: You can literally see the "thinking" process saved in your collections.

5. Putting it all together: The Implementation

Here is how you compile your graph with persistence:

from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.mongodb import MongoDBSaver
from pymongo import MongoClient

# 1. Setup Database
client = MongoClient("mongodb://localhost:27017")
checkpointer = MongoDBSaver(client, db_name="agent_memory")

# 2. Build the Graph
workflow = StateGraph(AgentState)
workflow.add_node("chatbot", chatbot_node)

# 3. Define the Flow
workflow.add_edge(START, "chatbot")
workflow.add_edge("chatbot", END)

# 4. Compile with Checkpointer!
app = workflow.compile(checkpointer=checkpointer)

# 5. Run it with a Thread ID
config = {"configurable": {"thread_id": "user_42"}}
inputs = {"messages": [("user", "Hi, my name is Ali!")], "user_id": "ali_01"}

for event in app.stream(inputs, config):
    print(event)

6. Pro-Tip: Debugging in MongoDB Compass

When you run this code, open MongoDB Compass. You will see a collection named checkpoints.

Each document is a "Snapshot" of your agent's brain at a specific moment. If your agent starts hallucinating, you can look at the channel_values in the database to see exactly what "State" the agent was in when it made the mistake.

Summary
LangGraph turns AI development from "prompt engineering" into "system engineering."

Nodes do the work.
Edges manage the flow.
Checkpointers give it a soul (memory).

Building the "Boss" of AI: The Agentic Supervisor Architecture

Syed Mehrab — Thu, 26 Mar 2026 08:53:39 +0000

In the world of AI Agents, we are moving past single-task bots toward multi-agent systems. But how do you prevent a team of specialized agents from descending into chaos? The answer is the Supervisor Architecture.

Think of it as the "Project Manager" for your LLMs. Instead of every agent trying to talk to everyone else (which is computationally expensive and confusing), you introduce a central orchestrator.

How the Architecture Works
The Supervisor pattern follows a Hub-and-Spoke model. Here is the typical lifecycle of a request:

The Intake: The user provides a complex goal (e.g., "Research this company and write a 5-page investment report").

The Planner (Supervisor): An LLM with a specialized prompt acts as the Supervisor. It breaks the goal into sub-tasks.

The Delegation: The Supervisor looks at its "team" (e.g., a Researcher Agent, a Coder Agent, and a Writer Agent) and hands off the first task.

The Review: When an agent finishes, it sends the result back to the Supervisor—not to the next agent. The Supervisor decides if the work is good enough or needs a revision.

The Hand-off: Once Task A is perfect, the Supervisor passes that context to the agent responsible for Task B.

How the Architecture Works

The Supervisor pattern follows a Hub-and-Spoke model. Here is the typical lifecycle of a request:

The Intake: The user provides a complex goal (e.g., "Research this company and write a 5-page investment report").

The Planner (Supervisor): An LLM with a specialized prompt acts as the Supervisor. It breaks the goal into sub-tasks.

The Delegation: The Supervisor looks at its "team" (e.g., a Researcher Agent, a Coder Agent, and a Writer Agent) and hands off the first task.

The Review: When an agent finishes, it sends the result back to the Supervisor—not to the next agent. The Supervisor decides if the work is good enough or needs a revision.

The Hand-off: Once Task A is perfect, the Supervisor passes that context to the agent responsible for Task B.

Why Use a Supervisor?

State Management: The Supervisor keeps the "Source of Truth." Individual agents don't need to remember the entire conversation; they only need to know their current task.
Error Correction: If a specialized agent hallucinates, the Supervisor (using a different model or prompt) can catch the error before the final output.

Scalability: You can easily add a "Legal Agent" or an "SEO Agent" to the spoke without rewriting the logic for the other agents.

Top Tools for Building Supervisor Architectures

If you are looking to build this today, these frameworks have built-in support for supervisor patterns:

LangGraph (by LangChain): This is the current gold standard. It allows you to create "cycles" and state machines where a supervisor node manages the flow between other nodes.

2.
CrewAI: Uses a "Manager" role that can be assigned to an LLM to automatically coordinate "Tasks" among a "Crew."

3.
Autogen (by Microsoft): Uses a GroupChatManager that acts as the moderator for a conversation between multiple agents.

The Future: Hierarchical Supervision

In very complex systems, we are now seeing Hierarchical Supervision. A "Lead Supervisor" manages several "Sub-Supervisors," who each manage their own team of functional agents. This mimics a real-world corporate structure and allows AI to handle massive, multi-week projects.

Key Takeaway: Don't just build agents; build teams. And every team needs a leader.

Stop Leaking Your Database Logic: The Repository Pattern 🏗️

Syed Mehrab — Sat, 14 Mar 2026 12:58:12 +0000

Ever found yourself writing the same SQL query or ORM call in three different controllers? Or worse—trying to unit test business logic but getting stuck because it’s hard-coded to a live database?

That’s where the Repository Pattern saves the day. It acts as a mediator between your domain/business logic and the data mapping layer.

The Architecture at a Glance
Instead of your service talking directly to the database, it talks to an Interface.

Client/Service: "I need user #42."
Repository: "I'll go get that for you (I don't care if it's from SQL, NoSQL, or a Cache)."
Data Source: Returns the raw data.

💻 The "Before vs. After"
The "Spaghetti" Way (Logic + DB Mixed):

# Controller
def get_user_dashboard(user_id):
    user = db.query("SELECT * FROM users WHERE id = ?", user_id) # Leaking DB logic
    stats = redis.get(f"stats_{user_id}")
    return render_template(user=user, stats=stats)

The Repository Way (Clean & Decoupled):

# Service
def get_user_dashboard(user_id):
    user = user_repo.get_by_id(user_id) # Abstracted
    stats = user_repo.get_activity_stats(user_id)
    return render_template(user=user, stats=stats)

Why bother?

Testability: You can easily "mock" the repository during unit tests without needing a real database.

Don't Repeat Yourself (DRY): Centralize your data access logic. If a query needs to change, you change it in one place.

Flexibility: Want to switch from Postgres to MongoDB? You only update the Repository implementation; your business logic stays exactly the same.

Separation of Concerns: Your API/Controller stays "thin" and focused only on handling requests.

The "Golden Rule"
The Repository Pattern is powerful, but don't over-engineer! If you are building a very simple CRUD app with only 2-3 tables, adding a repository layer might just be unnecessary boilerplate.

Use it when your business logic starts getting complex or when you plan to support multiple data sources.

Stop Staring at JSON: A Developer's Guide to MongoDB Compass 🧭

Syed Mehrab — Tue, 10 Mar 2026 07:26:48 +0000

If you are building an Auth Service or a CRUD app, looking at raw BSON in a terminal is a recipe for a headache. MongoDB Compass is the official GUI that lets you visualize your data, analyze your schemas, and manage your indexes without writing a single line of MQL (MongoDB Query Language).

Here is how to get it running on your machine and the essential "day one" commands you need.

🚀

Installation Guide

🐧 Ubuntu (24.04+)
For Linux users, the .deb package is the most stable way to ensure all dependencies are met.

The Terminal Way:

# 1. Download the latest package
wget https://downloads.mongodb.com/compass/mongodb-compass_1.45.0_amd64.deb

# 2. Install it
sudo apt install ./mongodb-compass_1.45.0_amd64.deb -y

# 3. Launch
mongodb-compass

🪟 Windows
Download the .exe or .msi installer from the Official Download Page.

Run the installer and follow the wizard.

Once installed, it will be available in your Start Menu.

🍎 macOS
Download the .dmg file.

Open the .dmg and drag the MongoDB Compass icon into your Applications folder.

If you get a "Developer cannot be verified" warning, go to System Settings > Privacy & Security and click "Open Anyway."

🔌 Connecting for the First Time
Most local development setups use the default port. Paste this into the connection string box:

Standard Local URI:
mongodb://localhost:27017

If you are using Docker:
mongodb://admin:password@localhost:27017

🛠 Top 3 Features for Every Developer

1. The "Filter" Bar (Finding your Data)
Instead of writing db.users.find({"email": "test@example.com"}), just type this into the Filter field:

{ "email": "test@example.com" }

Hit Find, and Compass will instantly isolate that document.

2. Schema Analysis
Ever wonder why your Python UserInDB model is crashing? Use the Schema tab. Compass will scan your collection and show you if some documents are missing fields (like phone) or have the wrong data type (like a string where an int should be).

3. Visual Explain Plan
Is your login query slow? Click the Explain Plan tab. It shows you exactly how MongoDB is searching. If you see "COLLSCAN" (Collection Scan), it’s time to add an index!

Pro Tip for Auth Devs
When testing JWT Refresh Tokens, keep Compass open on your users collection. Watch the token_creation_at and last_login fields update in real-time as you hit your FastAPI endpoints. It’s the fastest way to debug your Repository logic!

16-bit AI Quality at 11-bit Size? How DFloat11 achieves Lossless LLM Compression

Syed Mehrab — Fri, 06 Mar 2026 21:03:33 +0000

The AI world has a massive "obesity" problem. Models like Llama 3.1 405B are brilliant, but they are also digital giants. To run them, you usually have two choices:

Buy more GPUs: (Extremely expensive)
Quantize the model: (Shrink it to 4-bit or 8-bit, but lose accuracy/logic)

But what if I told you there is a third way? A way to shrink a model by 30% without losing a single bit of information?

Enter *DFloat11 *(Dynamic-Length Float), a new lossless compression framework that is changing the game for LLM inference.

🧠 The Core Insight: BFloat16 is Inefficient
Most modern LLMs are stored in BFloat16 format. Each number uses 16 bits: 1 for sign, 8 for exponent, and 7 for mantissa.

Researchers found something shocking: while the sign and mantissa are fully utilized, the exponent bits are mostly "empty air." Out of 256 possible exponent values, only about 40 actually show up in real models. This is a massive waste of memory.

🛠️ How DFloat11 Works
Instead of cutting off bits (like quantization), DFloat11 uses Entropy Coding (Huffman Coding):

Common Exponents get very short codes (2-3 bits).
Rare Exponents get longer codes.
Sign & Mantissa stay exactly the same.

The result? The model's "weight" drops from 16 bits to roughly 10.8 - 11.1 bits. It’s like a ZIP file for your LLM, but one that stays "zipped" even while the model is running!

🚀 The "Magic" of Lossless
The biggest headache with 4-bit or 8-bit quantization is the "Accuracy Drop." In reasoning-heavy models like DeepSeek-R1, quantizing can lead to a 9% drop in accuracy.

DFloat11 is Bit-for-Bit identical. * MMLU Scores? Identical.

WikiText Perplexity? Identical.

Logic & Reasoning? Zero change.

💻 GPU Magic: Making Huffman Coding Fast
Huffman decoding is usually slow on GPUs because it's sequential. DFloat11 solves this with three brilliant engineering tricks:

Hierarchical LUTs: Compact lookup tables that fit in the GPU’s lightning-fast SRAM.
Two-Phase Kernels: A smart way for GPU threads to coordinate where to read and write variable-length data.
Transformer-Block Batching: Decompressing entire blocks at once to keep the GPU cores busy.

📊 The Real-World Impact
Llama 3.1 405B on One Node: You can now run the 810GB Llama 405B on a single 8x80GB GPU server instead of two.

5.7x - 14.9x Longer Context: Because weights take up less room, there is more "VRAM" left for the KV Cache (the model's memory of your conversation).

Faster than Offloading: It is 2.3x to 46x faster than trying to offload parts of the model to your system RAM (CPU).

Read the full paper: https://arxiv.org/abs/2504.11651
Github : https://github.com/LeanModels/DFloat11
connect on LinkedIn: https://www.linkedin.com/in/syed-mehrab-18934220a/

Giving LLMs a Long-Term Memory: An Introduction to Mem0 🧠

Syed Mehrab — Wed, 04 Mar 2026 16:31:44 +0000

We’ve all been there: You build a sophisticated AI agent, have a great conversation, and then, the moment you start a new session, it treats you like a complete stranger.

Most LLMs are essentially goldfish. While RAG (Retrieval-Augmented Generation) helps them "read" documents, it doesn't really help them "remember" you. That’s where Mem0 comes in.

What is Mem0?

Mem0 (pronounced "Memory Zero") is a self-improving memory layer for AI assistants and agents. It allows your LLM applications to retain information across different sessions, learning from user interactions to provide a truly personalized experience.

Think of it as the "Personalized Intelligence" layer. Instead of just searching through a static PDF, the AI learns that you prefer Python over JavaScript, or that you’re currently working on a specific microservices architecture.

Key Features:
Adaptive Learning: It doesn't just store data; it improves based on user interactions.

User-Centric: It organizes memory by user, session, and even AI agent.

Platform Agnostic: It works with OpenAI, Anthropic, Llama, and more.

Developer Friendly: The API is designed to be integrated into existing stacks in minutes.

How It Works

Standard RAG pulls snippets of text based on a query. Mem0, however, acts more like a continuously updated diary. When a user says something important, Mem0 extracts the "fact," stores it, and makes it available for the next prompt.

Quick Start
Getting started is surprisingly simple:

from mem0 import Memory

# Initialize Mem0
m = Memory()

# Store a memory
m.add("I'm allergic to peanuts and prefer coding in Rust.", user_id="dev_user_123")

# Retrieve relevant memories later
all_memories = m.get_all(user_id="dev_user_123")
print(all_memories)

Why use Mem0 over standard Vector DBs?
While you could build this yourself using Pinecone or Milvus, Mem0 handles the heavy lifting of memory management:

Conflict Resolution: If you tell the AI "I live in New York" today and "I moved to Tokyo" tomorrow, Mem0 understands the update.
Contextual Ranking: It prioritizes the most relevant memories for the current conversation.
No Manual Cleanup: You don't have to write complex logic to delete or update old embeddings.

Alternatives to Mem0
If you're exploring different ways to handle AI memory, here are the top contenders and how they differ:

Zep: A high-performance, production-grade long-term memory store. Unlike Mem0, Zep excels at automatically enriching and summarizing chat history, making it great for high-scale applications that need to stay fast.

*Letta *(formerly MemGPT): If you want your agents to manage their own memory like an OS manages RAM, this is it. It allows LLMs to "page" information in and out of their context window dynamically.

LangChain Memory Modules: The "classic" choice. It’s perfect for quick prototyping (using ConversationBufferMemory), though it can be harder to scale for long-term, multi-session persistence compared to a dedicated memory layer.

*Redis *(with Vector Search): The speed king. If you already use Redis for caching, you can use its vector capabilities to store user sessions. However, you’ll have to build the "memory extraction" logic yourself.

Pinecone / Weaviate: These are pure Vector Databases. They are industry standards for storing massive amounts of data, but they don't "manage" the human-like memory logic (like updating old facts) out of the box like Mem0 does.

Beyond Chatbots: Can We Give AI Agents an "Undo" Button? Exploring Gorilla GoEx 🦍

Syed Mehrab — Sat, 28 Feb 2026 18:01:33 +0000

The world of Large Language Models (LLMs) is shifting. We are moving from simple chatbots that just "talk" to Autonomous Agents that can actually "do" things: like sending Slack messages, managing files, or calling APIs.

But there’s a massive problem: Trust. How do we stop an LLM from sending a wrong email or deleting a critical database entry?

I’ve been diving into the research from the UC Berkeley Gorilla LLM team, specifically their latest tool: GoEx (Gorilla Execution Engine). Here’s what I’ve learned and where I think the next big research challenge lies.

What is GoEx? (The Post-Facto Paradigm)
Traditionally, we try to verify LLM code before it runs (Pre-facto). But code is hard to read! GoEx introduces Post-Facto Validation.

Instead of over-analyzing the code, GoEx lets the LLM execute the action and gives the human two powerful safety nets:

The Undo Feature: If the LLM sends a Slack message or creates a file you don't like, you can simply "revert" the state.

Damage Confinement: It restricts the "blast radius" by limiting permissions (e.g., the LLM can read emails but can’t send them without extra clearance).

The Missing Piece: The "Social Damage" Gap
While GoEx is a huge step forward, my deep dive into the paper [arXiv:2404.06921] led me to an interesting research gap.

The Problem: Technical reversibility $\neq$ Social reversibility.If an LLM sends a sensitive Slack message and the recipient reads it within 2 seconds, deleting it doesn't solve the problem. The "Information Leak" has already happened.
My Take: We need a "Semantic Damage Confinement" layer. This would involve:

Risk-based Buffering: Delaying high-risk messages based on sentiment analysis.
Context-Aware Throttling: Switching back to "Pre-facto" validation automatically if the action is deemed socially irreversible.

Check out the project:

📄 Paper: https://arxiv.org/abs/2404.06921

💻 GitHub: gorilla/goex