LangChain's team explains why they rebuilt their public chat.langchain.com support chatbot after discovering their own engineers avoided using it in favor of a manual three-step workflow: checking docs, the knowledge base, and the codebase. Instead of chunking documents into embeddings and storing them in a vector database, they moved to direct API access (via Mintlify for docs, Pylon for knowledge base, and ripgrep for codebase search), giving agents full-page context instead of fragments. They built a fast Create Agent (using Claude Haiku 4.5) for simple docs Q&A delivering sub-15-second responses, and a slower Deep Agent with specialized subgraphs for complex code-related queries taking 1-3 minutes. Production middleware handles guardrails, retries, model fallback, and caching. The piece closes with key takeaways on when vector embeddings help versus hurt and how subgraphs prevent context overload.
Table of contents
BackgroundWe Decided to Automate ItThen We Had a RealizationHow We Built The New AgentWhy We Got Moved Away from Vector EmbeddingsThe Better Approach: Direct API Access and Smart PromptingTool Design: Building for Human WorkflowsHow Deep Agent and Subgraphs Solve Context OverloadMaking It Production-ReadyGetting the Agent to UsersThe ResultsKey TakeawaysWhat's NextTry It YourselfJoin the ConversationQuestions this post answers
Why might vector embeddings and chunking be a bad fit for searching structured product documentation?
Chunking breaks the structure of documentation by splitting it into small fragments (e.g. 500-token pieces), which loses headers, subsections, and context needed to explain answers properly. It also requires constant reindexing whenever docs update, and produces vague citations that users cannot trace back to a source. Vector embeddings work better for unstructured content like PDFs. Anyone weighing RAG architecture choices can find real-world tradeoffs like this one on daily.dev.
What is the difference between LangChain's Create Agent and Deep Agent architectures for a support chatbot?
Create Agent is a fast, no-planning-overhead agent that makes 3-6 tool calls and answers documentation questions in under 15 seconds, using models like Claude Haiku 4.5. Deep Agent uses specialized subgraphs (docs, knowledge base, codebase) that each filter results before passing them to an orchestrator, taking 1-3 minutes but handling complex queries requiring code-level verification. Developers comparing agent architectures for speed versus depth can track patterns like this on daily.dev.
How does a multi-agent subgraph design prevent context overload in an LLM orchestrator?
Each specialized subagent (for documentation, knowledge base, and codebase) searches its own domain independently, filters through raw results, and passes only the essential extracted facts and citations to the main orchestrator agent, which never sees the raw search results. This avoids dumping dozens of full documents and code snippets into one context window, keeping responses focused instead of bloated or unfocused. Engineers designing multi-agent systems can follow architecture lessons like these on daily.dev.