Full-Time
Updated on 9/3/2026
Open-source framework for LLM-powered apps
$190k - $270k/yr
No H1B Sponsorship
Washington, DC, USA
Remote
US Top Secret Clearance Required
See people who can refer or advise you
LangChain provides an open-source framework for building applications powered by large language models (LLMs). It offers a modular toolkit with components like Model I/O, Data Connection, Chains, Agents, Memory, and Callbacks, allowing developers to create apps that can reason about and act on external data sources and APIs. The product works by letting users assemble chains of LLM calls, connect LLMs to data sources, enable agents to make decisions and use tools, persist state across interactions, and monitor activity through callbacks. This modular design differentiates LangChain from competitors by its emphasis on flexibility, extensibility, and open-source collaboration, enabling a wide range of users—from individuals to large enterprises—to tailor LLM-powered applications. The company's goal is to simplify the development and deployment of AI-powered applications, providing an adaptable framework that handles data integration, reasoning, and action for diverse use cases.
Company Size
201-500
Company Stage
Series B
Total Funding
$160M
Headquarters
San Francisco, California
Founded
2023
See people who can refer or advise you
Help us improve and share your feedback! Did you find this helpful?
Company Equity
LangChain and LangGraph CVEs: what your deployment needs to know. LangChain and LangGraph carried three disclosed CVEs as of March 2026 - a path-traversal flaw, a critical deserialization bug, and a SQL injection in LangGraph's checkpoint store - that together let an attacker read arbitrary files, exfiltrate environment secrets, and manipulate conversation-history queries. If your deployment predates the March 2026 patch cycle, this is the first thing to check before anything else in this post. What happened. Security researcher Vladimir Tokarev at Cyera disclosed three separate vulnerabilities across the LangChain ecosystem on 27 March 2026, characterizing them as "three independent paths" to drain sensitive data - filesystem contents, environment secrets, and conversation histories - from any enterprise LangChain deployment (The Hacker News, 27 Mar 2026). One of the three, "LangGrinch," had actually first been flagged by Cyata in December 2025 before being formally CVE-assigned and re-covered in the March wave. The scale matters as much as the severity. LangChain, LangChain-Core, and LangGraph together see 52M+, 23M+, and 9M+ weekly downloads respectively (The Hacker News, 27 Mar 2026). A vulnerability class that ships to that many installs by default is a supply-chain event for the agent ecosystem, not an isolated bug report - the same reasoning that applies to any widely-vendored open-source dependency now applies squarely to agent orchestration frameworks. As of late August 2026, this remains the reference framework-security incident for LangChain and LangGraph, five months on from disclosure. The three CVEs. Each of the three targets a different layer of a typical LangChain/LangGraph deployment: prompt loading, object deserialization, and checkpoint persistence. | CVE | Component | CVSS | What it allows | | CVE-2026-34070 | LangChain prompt-loading API | 7.5 | Path traversal - access to arbitrary files without validation via a crafted prompt template | | CVE-2025-68664 ("LangGrinch") | LangChain deserialization | 9.3 | Leaks API keys and environment secrets through unsafe deserialization | | CVE-2025-67644 | LangGraph SQLite checkpoint implementation | 7.3 | SQL injection via metadata filter keys, manipulating checkpoint queries | CVE-2026-34070 sits in LangChain's prompt-loading API. A crafted prompt template can traverse outside the intended directory and pull arbitrary files off the host - no input validation stands between the template path and the filesystem read (The Hacker News, 27 Mar 2026). CVE-2025-68664, the highest-severity of the three at CVSS 9.3, is a deserialization vulnerability that leaks API keys and environment secrets. It was the first of the three publicly flagged, by Cyata in December 2025, months before it carried a formal CVE identifier - a reminder that community disclosure and formal CVE assignment can run on very different timelines (The Hacker News, 27 Mar 2026). CVE-2025-67644 is the LangGraph-specific entry: a SQL injection in LangGraph's SQLite checkpoint implementation. LangGraph persists agent state - the running conversation and execution graph - as checkpoints, and this flaw lets an attacker manipulate the underlying SQL queries through metadata filter keys, rather than through the checkpoint content itself (The Hacker News, 27 Mar 2026). What can go wrong when these stack. Read individually, each CVE looks bounded - a file read here, a secret leak there. Read together, Tokarev's framing is the useful one: three independent paths converging on the same category of outcome, sensitive data leaving a production agent deployment (The Hacker News, 27 Mar 2026). A realistic chain: an attacker who can influence a prompt template (directly, or indirectly through content the agent ingests) uses the path-traversal flaw to read configuration files off the host. Those files often contain, or point to, the same environment secrets the deserialization bug can leak directly - API keys for the LLM provider, database credentials, third-party service tokens. Separately, if the deployment uses LangGraph's SQLite checkpointing to persist multi-turn agent state, the SQL injection gives an attacker a second, independent route into stored conversation history - including whatever the agent discussed with legitimate users, potentially spanning sessions. None of the three requires the attacker to have valid credentials to the application first. That is what elevates this from "a bug in a library" to a framework-level trust problem: the vulnerable surface is the orchestration layer itself, sitting underneath whatever authentication the application built on top of it. Why framework-level CVEs are a distinct risk class from runtime prompt injection. It's worth being precise about what kind of vulnerability this is, because the fix and the mitigation differ from the runtime threats most agent-security content focuses on. Indirect prompt injection is a runtime problem: an agent processes untrusted content and gets manipulated into taking an unintended action, and the defense is layered detection and least-privilege scoping applied continuously, session by session. A framework CVE like the three above is a supply-chain problem: the vulnerability exists in the orchestration code itself, independent of what any individual agent does at runtime, and the fix is a version bump, not a behavioral control. That distinction matters for how a team should triage exposure. A runtime prompt-injection control (content scanning, output validation) does nothing to close CVE-2026-34070's path-traversal hole - the flaw is in how the prompt-loading API resolves file paths, not in what a malicious prompt asks the agent to do. Conversely, patching the framework does nothing to stop a legitimate, unpatched agent from being manipulated by injected content at runtime. Both categories of control are necessary, and treating a framework patch as if it covers runtime risk (or vice versa) leaves a gap either way. Controls a platform team should apply. The single highest-leverage action is also the simplest: confirm your pinned versions. The patched releases are langchain-core >=1.2.22 (also backported to 0.3.81 and 1.2.5) and langgraph-checkpoint-sqlite 3.0.1 (The Hacker News, 27 Mar 2026). If your lockfile predates these, treat it as an active exposure, not a hygiene item for the next sprint. Beyond the patch itself, three structural controls reduce exposure to this entire class of framework-level vulnerability, independent of which specific CVE is in play: * Track framework dependencies like any other supply-chain risk. Agent orchestration frameworks now sit in the same trust position as web frameworks or serialization libraries did a decade ago - pin versions, subscribe to security advisories for the specific packages in your dependency tree, and treat a framework CVE as a production incident, not a documentation update. * Scope what the checkpoint store - or any persistence layer - can expose. A checkpoint database that holds full conversation history is a high-value target by design. Isolating it from broader network access and encrypting it at rest limits what a successful injection can retrieve even before the underlying bug is patched. The same logic that governs MCP server security - classify data by sensitivity, don't trust the default configuration - applies directly to checkpoint stores. * Validate untrusted content before it reaches a prompt template. CVE-2026-34070 is exploitable through a crafted prompt template; the deeper pattern is the same one behind indirect prompt injection - content an agent processes can carry structure the framework did not anticipate. Input-side scanning and template validation are complementary to patching, not a substitute for it. For teams building or operating agents with LangChain or LangGraph as the orchestration layer, these three controls sit alongside the broader identity, authorization, and audit-logging controls covered in the AI agent security guide - framework patching handles one class of risk; the surrounding controls handle what happens if a future, unpatched flaw is exploited before a fix ships. Frameworks with community-contributed extensions carry an adjacent risk worth flagging here too: an agent's dependency tree can include third-party packages with far less scrutiny than the core framework itself, a supply-chain pattern also documented for Agent Skills - vet what you pull in, not just what ships from the framework maintainer. Faq. Is LangChain still safe to use in production after these CVEs? Yes, if patched. The vulnerable versions predate the March 2026 fixes; deployments running langchain-core >=1.2.22 (or the 0.3.81 / 1.2.5 backports) and langgraph-checkpoint-sqlite 3.0.1 are not exposed to these three specific issues. Which CVE is most urgent to patch? CVE-2025-68664 ("LangGrinch," CVSS 9.3) is the highest severity - it directly leaks API keys and environment secrets - but all three should be treated as one patch cycle, since fixes ship together. Does this affect LangGraph's checkpointing feature specifically, or all of LangGraph? Only CVE-2025-67644 is LangGraph-specific, and it's scoped to the SQLite checkpoint implementation's handling of metadata filter keys - not every LangGraph deployment or persistence backend is implicated.
Accelerating Trellix's transformation with AI-native security engineering. By Joe Chen · August 10, 2026 Cybersecurity is at an inflection point. Recent Trellix research shows a 67% increase in AI-driven APT campaigns and a 300% increase in the monthly attack cadence, underscoring a fundamental shift in the speed and scale of today's threats. These increases have made one thing clear: incremental improvement isn't enough. Recent examples of OpenAI and Anthropic models breaking out of sandboxes further reinforce the new "machine speed" the cybersecurity industry is facing. Trellix is meeting this challenge head-on by enhancing how Trellix build, secure, and optimize its technology through AI-native security engineering. When I joined Trellix as CTO in May, the stakes couldn't have been clearer. Frontier AI models were changing traditional time-to-exploit, compressing it across the industry and forcing vulnerability management to evolve alongside it. Simultaneously, Trellix was navigating its own security matter that required a thorough, expedited review of its codebase, architecture, and supply chain. So Trellix leaned in all the way, moving from experimental AI-enabled pilots available to a few teams to a standardized AI-enabled framework for all teams. Trellix embraced frontier AI models to review its entire codebase on an accelerated timeline, and Trellix embedded AI-powered auditing directly into its development pipelines, so potential vulnerabilities surface earlier in the development process. What began as a response to an immediate challenge has become a catalyst for fundamentally elevating its engineering standards. The result is a hardened foundation and an evolved engineering philosophy embracing the modern landscape. Driving innovation with a secure AI adoption framework. With high-performance AI-native security engineering as its foundation, Trellix is guided by the principles of accelerated, intentional, and responsible adoption of leading-edge technology, where security isn't a constraint on innovation but the condition that makes it sustainable. Here are a few examples of how Trellix is putting shift-left AI security into practice: * Trellix has retooled its engineering system around AI, not as a layer on top of existing processes, but woven into how Trellix build. Features will ship in smaller, highly validated increments. * AI capabilities and frontier models now identify and remediate vulnerabilities earlier in the software development lifecycle. Trellix is embracing a simplified architectural philosophy: AI maintains visibility throughout the development cycle, and secure-by-design principles remain at the forefront. * Trellix has also established strategic partnerships with two leading AI companies: Anthropic and LangChain. These aren't just vendor agreements; they're foundational alignments for its engineering and research teams. These partnerships grant Trellix privileged access to cutting-edge models, frameworks, observability, and roadmaps as they evolve, and its spend commitment with Anthropic, signed in May, signals the depth of its investment in this space. * Trellix is embracing both closed and open-source AI models for various tasks, depending on which is best suited, adapting to the new pace of AI innovation. AI amplifies what its engineering teams have always prioritized, bringing continuous intelligence and real-time visibility to its rigorous security practices, so its engineers can direct more of their expertise toward innovation, architecture, and customer outcomes. Leading the next era of cyber defense. Trellix has a lot of work to do, but Trellix is at the beginning of what I believe will be a defining chapter, not just for Trellix, but for the broader industry. The organizations leading the next era of cyber defense aren't the ones who add AI to their slide decks. They're the ones willing to rebuild their engineering foundations to make AI native to how they think, build, and protect. Its mission is clear: set the standard for high-performance engineering, responsible AI adoption, and the kind of customer trust that can be earned only through consistent execution. The threat landscape will keep evolving. So will Trellix.
MSSP Market News: Attackers bypassed MFA in 100% of BEC cases. July 24, 2026 Attackers are moving faster, while security teams are still struggling to see what is happening across the environment. LevelBlue found that phishing started 65% of intrusions in the second quarter, and business email compromise accounted for 45% of incidents. The main story is that attackers bypassed MFA in every BEC case where it was in place. They are also stealing OAuth tokens, API keys, and machine identities, giving them trusted access to cloud systems without setting off the usual alarms. Proofpoint's ransomware research shows how AI is adding to that pressure. Among organizations hit by ransomware, 65% said AI made the attack more effective. Employees were also more likely to engage because the messages looked convincing. Forty percent said users trusted an attack because it appeared authentic, while 38% said employees interacted with malicious content. More than half of the affected organizations paid a ransom, and 37% of those were hit with another demand. Ransomware is increasingly tied to identity theft and social engineering, rather than malware alone. At the same time, companies are adding more AI tools and agents to environments they already struggle to monitor. Radware found that generative AI and LLMs are widely used by 83% of organizations, and 96% expect to deploy AI agents or autonomous workflows within the next year. Yet only 17% say they have full visibility into those agents and processes. Nearly half of organizations update production APIs at least once a day, but only 19% have a fully automated, continuously updated API inventory. For MSSPs, this opens up a broader security conversation. Customers need help understanding who and what has access, where APIs are exposed, how AI agents are behaving, and whether stolen credentials or tokens are being used. The opportunity is moving beyond alert monitoring toward helping customers manage a more complicated identity, cloud, API, and AI environment. Market pulse: cybersecurity deals, funding, and platform shifts. ExtraHop launches Agentic SOC alliance: ExtraHop has launched the Agentic SOC Alliance, bringing together vendors including CrowdStrike, Command Zero, Dropzone AI, Intezer, LangChain, TENEX.AI and Torq to develop a common operating model for autonomous security operations. The group is proposing a three-layer architecture built around Context, Harness and Model: structured security data that agents can reason over, an orchestration layer that controls workflows and permissions, and interchangeable AI models that handle triage, investigation and response. The goal is to give enterprises a clearer blueprint for deploying agentic SOC tools without tying the entire architecture to a single model or vendor. ThreatDown adds Shadow AI and Machine Identity Visibility for MSPs: ThreatDown has expanded its platform with AI visibility and broader identity threat detection and response capabilities aimed at helping security teams and MSPs track shadow AI use and non-human identities from the same console. The new AI dashboard inventories applications across customer environments, showing which tools are in use, where they are running and which devices are accessing them, while the expanded ITDR coverage tracks service accounts, API tokens, OAuth credentials and machine identities by ownership, age and privilege level. ThreatDown is also adding an AI assistant that turns security data into plain-language guidance and recommends actions for administrators to review before execution. 7AI launches partner program for agentic SOC services: 7AI launched its first formal global partner program, creating Select and Premier tiers for MSSPs, resellers, and other security partners that want to build services around its agentic SOC platform. The program offers training, certification, and dedicated sales and technical resources, giving MSSPs a structured way to use 7AI's autonomous investigation agents within their own security operations. Keyfactor expands partner program around post-quantum services: Keyfactor expanded its global partner program to help MSPs, MSSPs, and systems integrators build services around crypto-agility, machine identity, and post-quantum cryptography. The program supports partners developing quantum-readiness assessments, cryptographic modernization projects, and post-quantum centers of excellence. For MSSPs, this creates a potential recurring service category around discovering certificates and cryptographic assets, monitoring risk, and helping customers manage a migration that will take place across several years rather than through a single technology upgrade. Veraify targets shadow AI and agent security: Veraify has launched a new AI-native security platform designed to help enterprises monitor and control how employees, applications, and AI agents access data and use AI tools. The platform combines endpoint intelligence, AI-aware policy enforcement, data loss prevention, identity controls, and secure connectivity, with a focus on detecting shadow AI and stopping sensitive information from leaving through prompts, uploaded files or autonomous workflows. Veraify can identify sanctioned and unsanctioned AI services, inspect text, documents and images for personal or proprietary data, and apply policies to both human users and AI agents from one control plane. Palo Alto Networks to acquire application monitoring provider Embrace: Palo Alto Networks is acquiring application monitoring provider Embrace to strengthen real user monitoring and application observability across its Cortex platform. The company plans to combine Embrace with its new Synthetics service and Cortex AgentiX, giving customers a clearer view of application performance from the user interaction through the backend, with the longer-term goal of automatically identifying and fixing issues. The deal also extends Palo Alto Networks' broader push into observability following its $3.35 billion Chronosphere acquisition. Abstract raises $25 million for composable security operations: Abstract raised $25 million to expand its streaming-first security operations platform, which is designed to let customers connect security data, analytics, and AI workflows without moving everything into a single SIEM ecosystem. The company is betting that more enterprises will move away from sending every log into a single SIEM and instead use a composable model that detects threats while data is still moving, routes that data to different destinations, and gives teams more control over storage costs. The funding will support broader in-stream detection, further development of its Astro AI capabilities, and expansion of its go-to-market team. Glow raised $180 million in Series A funding at a reported $1.2 billion valuation: Glow raised $180 million in Series A funding at a reported $1.2 billion valuation, making it the biggest cybersecurity funding story of the week. The new company is building an AI-powered endpoint security platform that maps customer environments, assesses risk, and automatically enforces prevention policies. Neo Launches with $100 million to secure AI-enabled software: Neo has emerged from stealth with $100 million in seed and Series A funding to build security for AI-enabled enterprise software. The startup was founded by former SentinelOne executives Nick Warner and Shlomi Salem, along with Eran Shirazi, and is backed by Andreessen Horowitz, Bessemer Venture Partners, Craft Ventures, and Merlin Ventures. Have news to share or just want to connect? Reach anytime at [email protected]. Suparna is the Senior Managing Editor for CyberRisk Alliance's Channel Brands, including MSSP Alert and ChannelE2E. She manages content development, sharpens editorial workflows, and ensures storytelling is tightly aligned with audience needs. With a background in technology, media, and education, she combines strategic insight with creative execution.
MCP vs langchain: which should you choose? A detailed comparison of the protocol vs the framework for AI agent development. MCP and LangChain are often discussed as competing approaches to AI agent development. But they're fundamentally different things serving different purposes. This guide clarifies the distinction and helps you choose - or combine - them. The core misconception. MCP is a protocol. It defines how agents interact with tools. LangChain is a framework. It provides code for building agents. They're not mutually exclusive. LangChain actually includes MCP integration. Understanding this distinction is key to using both effectively. What each does. MCP handles. Agent | MCP Protocol | Tool Server * Tool discovery * Tool invocation * Schema validation * Transport (stdio, HTTP, WebSocket) * Standardized pricing and payments LangChain handles. User | LangChain Agent | [LLM, Memory, Tools, Prompts, Parsers] * Agent logic and orchestration * Prompt management * Memory systems * Output parsing * Tool chains * Document loaders * Vector store integration Feature comparison. | Feature | MCP | LangChain | | Type | Protocol (specification) | Framework (code library) | | Scope | Tool interaction | Full agent lifecycle | | Language | Any (SDKs for Python/JS) | Python, JavaScript | | Standardization | Universal | LangChain-specific | | Learning curve | Low | Medium-High | | Vendor lock-in | None | Medium | | Ecosystem | Growing rapidly | Mature | | Community | Open, multi-vendor | LangChain-centric | | Marketplace | SkillExchange, others | LangChain Hub | Using LangChain with MCP. LangChain has built-in MCP support: from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_openai import ChatOpenAI from langchain_mcp import MCPToolkit # Connect to MCP servers toolkit = MCPToolkit( servers=[ {"command": "node", "args": ["./db-server.js"]}, {"url": "https://api-mcp.example.com/sse"},]) # Get MCP tools as LangChain tools mcp_tools = await toolkit.get_tools # Mix MCP tools with native LangChain tools from langchain.tools import Tool all_tools = [*mcp_tools, # Tools from MCP servers Tool(name="calculator",...), # Native LangChain tool Tool(name="python_repl",...), # Another native tool] # Create agent with all tools llm = ChatOpenAI(model="gpt-4o") agent = create_tool_calling_agent(llm, all_tools, prompt) executor = AgentExecutor(agent=agent, tools=all_tools) When to Use MCP Only. Choose MCP-only (without LangChain) when: * Simple tool integration - Just need to connect a few tools to Claude or another MCP-compatible agent * Protocol-first architecture - You want maximum portability across agent platforms * Publishing tools - Building tools for SkillExchange or other marketplaces * Minimal dependencies - Don't want the LangChain dependency tree * Custom agent - You've built your own agent framework Example: MCP-Only Agent. from mcp import Client # Connect to MCP servers db_client = Client("https://db-mcp.example.com/sse") api_client = Client("https://api-mcp.example.com/sse") # Discover tools db_tools = await db_client.list_tools api_tools = await api_client.list_tools # Simple agent loop async def process(message): # Use LLM to decide which tool to use tool_choice = await llm.select_tool(message, [*db_tools, *api_tools]) # Execute via MCP if tool_choice: result = await tool_choice.client.call_tool( tool_choice.name, tool_choice.arguments) return result # Direct LLM response return await llm.complete(message) When to Use LangChain. Choose LangChain (with or without MCP) when: * Complex agent logic - Multi-step reasoning, conditional branching * Rich memory - Conversation summary, entity memory, knowledge graph * Document processing - Load, chunk, embed, and retrieve documents * Multiple LLM providers - Switch between OpenAI, Anthropic, Google * Production infrastructure - Tracing (LangSmith), evaluation, deployment Example: LangChain with MCP. from langchain.agents import AgentExecutor from langchain_openai import ChatOpenAI from langchain_mcp import MCPToolkit from langchain.memory import ConversationSummaryMemory from langchain.prompts import ChatPromptTemplate # MCP tools toolkit = MCPToolkit(servers=[{"url": "https://tools.example.com/sse"}]) tools = await toolkit.get_tools # Memory memory = ConversationSummaryMemory( llm=ChatOpenAI(model="gpt-4o-mini"), max_summary_length=200,) # Prompt prompt = ChatPromptTemplate.from_messages([ ("system", "You are a helpful assistant with access to tools."), ("placeholder", "{chat_history}"), ("user", "{input}"), ("placeholder", "{agent_scratchpad}"),]) # Agent llm = ChatOpenAI(model="gpt-4o") agent = create_tool_calling_agent(llm, tools, prompt) executor = AgentExecutor( agent=agent, tools=tools, memory=memory, verbose=True, max_iterations=10,) result = await executor.ainvoke({"input": "What's in our database?"}) Architecture patterns. Pattern 1: LangChain Agent + MCP tools. User | LangChain Agent | MCP Protocol | External Tools Best for: Complex agents that need external tools via standard protocol. Pattern 2: MCP-Only Agent. User | Custom Agent | MCP Protocol | External Tools Best for: Simple agents, maximum portability, minimal dependencies. Pattern 3: LangChain Only (No MCP). User | LangChain Agent | Direct Tool Calls Best for: Prototyping, internal tools, when portability doesn't matter. Pattern 4: MCP Server published for LangChain Users. Your MCP Server | SkillExchange | LangChain Users Import via MCPToolkit Best for: Tool developers who want to reach LangChain users. Migration path. From LangChain to MCP. If you want to make LangChain tools MCP-compatible: # Before: LangChain-only tool from langchain.tools import Tool def search_tool(query: str) -> str: return search_api.search(query) langchain_tool = Tool( name="search", description="Search the web", func=search_tool,) # After: MCP-compatible tool from mcp import Server server = Server("search-tools") @server.tool("search") async def search(query: str) -> dict: results = search_api.search(query) return {"content": [{"type": "text", "text": str(results)}]} # Works with LangChain AND every other MCP-compatible agent From MCP to LangChain. If you have MCP tools and want to use them in LangChain: from langchain_mcp import MCPToolkit toolkit = MCPToolkit(servers=[{"url": "https://your-mcp-server.com/sse"}]) tools = await toolkit.get_tools # Now use them as native LangChain tools agent = create_tool_calling_agent(llm, tools, prompt) Performance comparison. | Aspect | MCP-Only Agent | LangChain + MCP | LangChain Only | | Cold start | Fast (~0ms) | Slow (~500ms) | Slow (~500ms) | | Per-query overhead | Minimal | Framework overhead | Framework overhead | | Memory usage | Low | Higher | Higher | | Dependency size | ~5MB | ~50MB+ | ~50MB+ | | Flexibility | Protocol-level | Full framework | Full framework | Community and Ecosystem. | Aspect | MCP | LangChain | | Governed by | Open standard (Anthropic-initiated) | LangChain Inc. | | GitHub stars | 15K+ | 90K+ | | Contributors | 200+ | 2,000+ | | Documentation | Growing | Extensive | | Courses | Limited | Many available | | Job market | Growing rapidly | Established | Conclusion. MCP and LangChain aren't competitors - they're complementary. Use MCP to make your tools universally accessible. Use LangChain when you need a full-featured framework for building complex agents. For most production agents, the best approach is: LangChain for orchestration + MCP for tool access. Explore both MCP tools and LangChain integrations on SkillExchange. Enjoying this article? Get weekly insights on building and selling AI skills, MCP tools, and creator economics. Join 2,000+ AI builders and creators. No spam. Unsubscribe anytime. Get the free MCP Server handbook. 50+ pages of practical guides, code examples, and production-ready templates. * Complete MCP protocol reference * 15+ production-ready templates * Security best practices guide No spam. Unsubscribe anytime. SkillExchange respect your privacy.
Build durable chat memory for RAG using ScyllaDB and langchain. By Attila Tóth July 14, 2026 How to replace LangChain's in-memory chat history with ScyllaDB - so your RAG chatbot retains context across restarts and scales across replicas This post demonstrates how to integrate ScyllaDB Vector Search into your LangChain project for RAG use cases, as well as how to use ScyllaDB as a durable conversation memory within LangChain. Background. Large language models are trained on a fixed snapshot of the world. RAG patches that gap by retrieving relevant documents at query time and injecting them into the prompt. The pipeline has two phases: * Index: load documents, split them into chunks, embed each chunk, store embeddings in a vector store. * Retrieve & Generate: enrich and embed the user's question, find the nearest vectors (ANN search), pass the matching chunks as context to the LLM. But RAG alone is not enough. You still need to keep track of all inputs provided by the user. Persistent chat memory. LLMs are stateless. Every call starts with a blank slate unless you replay the conversation history. LangChain's BaseChatMessageHistory abstraction lets you plug in any backend as the storage layer for that history. The default in-memory implementation vanishes on process exit. A database-backed implementation survives restarts, scales across replicas, and lets you inspect or audit conversations later. That's where ScyllaDB comes in. ScyllaDB + LangChain. ScyllaDB is a NoSQL database optimized for high-throughput, low-latency workloads. Combined with LangChain, you can build reliable and always-on AI applications: * High availability: data is automatically replicated across nodes, so there is no single point of failure. The cluster continues serving reads and writes even if a node goes down. * Predictable P99 latency: ANN queries return results fast enough that retrieval doesn't dominate your chain's total latency. * Horizontal scalability: add nodes to the cluster to increase throughput without schema changes or downtime. * Built-in vector search: a native vector<float, N> type and HNSW index are created automatically in ScyllaDB. In this example, embeddings are generated locally with sentence-transformers (all-MiniLM-L6-v2, 384 dimensions). For production use, you can swap in OpenAI embeddings, Cohere, or any other provider supported by LangChain. In each conversation turn, the chatbot is reading data from ScyllaDB and then writing back into it using LangChain. Setup example. With the release of ScyllaDB 2026.2, you can now integrate LangChain with ScyllaDB seamlessly by reusing the existing Cassandra connector. Install dependencies. pip install langchain langchain-community \ sentence-transformers langchain-groq \ langchain-text-splitters cassio \ scylla-driver python-dotenv Environment variables. Copy demo/.env.example to demo/.env and fill in your credentials: # ScyllaDB Cloud SCYLLADB_CONTACT_POINTS=node-0.your-cluster.cloud.scylladb.com SCYLLADB_DATACENTER=AWS_US_EAST_1 SCYLLADB_USERNAME=scylla SCYLLADB_PASSWORD=your-password-here SCYLLADB_KEYSPACE=demo # Groq (LLM) GROQ_API_KEY=gsk_... Retrieve the contact points, datacenter name, username, and password from the Connect tab of your cluster in ScyllaDB Cloud. Connect to ScyllaDB Cloud. from cassandra.cluster import Cluster from cassandra.auth import PlainTextAuthProvider from cassandra.policies import DCAwareRoundRobinPolicy import cassio cluster = Cluster( contact_points=["node-0.your-cluster.cloud.scylladb.com"], auth_provider=PlainTextAuthProvider( "scylla", "your-password"), load_balancing_policy=DCAwareRoundRobinPolicy( local_dc="AWS_US_EAST_1"),) session = cluster.connect cassio.init(session=session, keyspace="demo") The cassio.init call registers the session and keyspace globally so all downstream integrations (the vector store and the chat history) pick it up without further configuration. Although cassio was originally built as a Cassandra integration, it is session-agnostic. It works with whatever driver session you hand it, so passing a session created by scylla-driver works just as well. Integrating ScyllaDB with LangChain vector store. As an example, consider a chatbot that ingests articles, answers questions using retrieved context, and preserves conversation history in the database. from langchain_community.document_loaders import WebBaseLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Cassandra loader = WebBaseLoader([ "https://docs.scylladb.com/stable/get-started/scylladb-basics.html", "https://docs.scylladb.com/stable/get-started/data-modeling/query-design.html",]) docs = loader.load chunks = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, ).split_documents(docs) embeddings = HuggingFaceEmbeddings( model_name="all-MiniLM-L6-v2") vectorstore = Cassandra( embedding=embeddings, table_name="rag_docs") vectorstore.add_documents(chunks) retriever = vectorstore.as_retriever( search_kwargs={"k": 4}) WebBaseLoader fetches and parses each URL into a Document. RecursiveCharacterTextSplitter then breaks each document into 500-token chunks with a 50-token overlap so sentences are not severed at boundaries. Cassandra(table_name="rag_docs") creates the table on first use, including a vector<float, 384> column (matching all-MiniLM-L6-v2's output dimensions) and an HNSW index. Subsequent runs reuse the existing table; you only pay the embedding cost once unless you call add_documents again. Persistent chat memory implementation. from langchain_community.chat_message_histories import CassandraChatMessageHistory def get_chat_history(session_id: str) -> CassandraChatMessageHistory: return CassandraChatMessageHistory( session_id=session_id, table_name="chat_history",) CassandraChatMessageHistory stores each message as a row keyed on session_id. Because rows are written to ScyllaDB, the history survives process crashes, server restarts, and horizontal scaling. Any replica that opens the same session_id sees the same history. Change session_id to start a fresh conversation. Keep it the same to resume where you left off - that is the entire persistence mechanism. Putting it together. from langchain_groq import ChatGroq from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough from langchain_core.runnables.history import RunnableWithMessageHistory llm = ChatGroq(model="llama-3.3-70b-versatile") ablePassthrough from langchain_core.runnables.history import RunnableWithMessageHistory llm = ChatGroq(model="llama-3.3-70b-versatile") prompt = ChatPromptTemplate.from_messages([ ("system", "You are a helpful assistant. Answer the user's question using the " "retrieved context below.\n\nContext:\n{context}"), MessagesPlaceholder(variable_name="chat_history"), ("human", "{question}"),]) chain = (RunnablePassthrough.assign(context=lambda x: "\n\n".join( d.page_content for d in retriever.invoke(x["question"]))) | prompt | llm | StrOutputParser chain_with_history = RunnableWithMessageHistory( chain, get_chat_history, input_messages_key="question", history_messages_key="chat_history",) config = {"configurable": {"session_id": "user-abc-session-1"}} answer1 = chain_with_history.invoke( {"question": "What is the difference between a partition key and a clustering key in ScyllaDB?"}, config=config,) print(answer1) answer2 = chain_with_history.invoke( {"question": "How does using both keys affect the sort order of the data within a partition?"}, config=config,) print(answer2) # References the prior turn via memory RunnableWithMessageHistory wraps the chain and automatically loads prior turns from get_chat_history before each call, then appends the new turn after. Both storage operations hit ScyllaDB. The second question drills deeper into clustering columns introduced in the first answer. Without persistent memory, the LLM would have no context for what was already explained; with it, the conversation flows naturally across turns. ScyllaDB schema. rag_docs, the vector store: CREATE TABLE demo.rag_docs ( row_id text PRIMARY KEY, attributes_blob text, body_blob text, metadata_s map<text, text>, vector vector<float, 384>,); CREATE CUSTOM INDEX idx_vector_rag_docs ON demo.rag_docs (vector) USING 'vector_index'; CREATE INDEX eidx_metadata_s_rag_docs ON demo.rag_docs (ENTRIES(metadata_s)); chat_history, the message store: CREATE TABLE demo.chat_history (partition_id text, message_id timeuuid, body_blob text, PRIMARY KEY (partition_id, message_id)) WITH CLUSTERING ORDER BY (message_id DESC); Next steps. The full demo code is available on GitHub. You can run it once to ingest and embed the articles, then run it again with the same SESSION_ID to verify that prior conversation turns are loaded from the database. Resources: Post on the ScyllaDB Forum if you have questions!