If you're building production AI systems in 2026, choosing between RAG, AI agents, and MCP (Model Context Protocol) is probably the single most important architecture decision you'll make. The RAG vs AI agents debate alone has been raging for months, but with MCP emerging as a standardized integration layer, the whole decision landscape has shifted. This guide gives you a practical framework for when to use RAG vs agents, how MCP fits in, and — most importantly — when to combine all three.
Here's the thing most people get wrong: these three technologies aren't competitors. They operate at completely different layers of the AI application stack. RAG handles knowledge retrieval, agents handle autonomous decision-making, and MCP handles standardized tool integration. Getting clear on where each fits (and when to combine them) is what separates a fragile prototype from a system that actually holds up in production.
Understanding the Three Architectures
Before we get into the decision framework, you need a solid mental model of what each architecture does. Here's the simplest way I can put it: RAG is memory, agents are the manager, and MCP is the plumbing. Each one solves a fundamentally different problem.
RAG (Retrieval-Augmented Generation): The Knowledge Layer
RAG is an architecture pattern that grounds LLM responses in external data. Instead of relying solely on the model's training data, RAG fetches relevant documents from a vector database or search index at query time and injects them into the prompt context. The process has two phases:
- Indexing phase: Documents are chunked, converted to embeddings, and stored in a vector database (ChromaDB, Pinecone, Weaviate, pgvector)
- Query phase: The user's question is embedded, a similarity search retrieves the top-k relevant chunks, and those chunks get injected into the LLM prompt alongside the query
RAG systems follow a deterministic retrieve-then-generate flow. They're easier to audit, have predictable costs, and provide clear source attribution. The catch? They're inherently read-only — RAG can't take actions, update systems, or orchestrate multi-step workflows.
Here's a minimal RAG pipeline using LangChain 0.5 and ChromaDB:
from langchain_anthropic import ChatAnthropic
from langchain_chroma import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
# 1. Chunk documents
splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
chunks = splitter.split_documents(documents)
# 2. Create vector store
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-en-v1.5")
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db")
# 3. Build retrieval chain
llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0.0)
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})
prompt = ChatPromptTemplate.from_messages([
("system", "Answer based on the following context:\n{context}"),
("human", "{input}")
])
chain = create_retrieval_chain(
retriever,
create_stuff_documents_chain(llm, prompt)
)
# 4. Query
response = chain.invoke({"input": "What is our refund policy?"})
print(response["answer"])
AI Agents: The Decision Layer
AI agents use an LLM as a reasoning engine that can plan, execute multi-step workflows, use tools, and adapt based on intermediate results. Unlike RAG's single-pass retrieve-then-generate flow, agents operate in a plan → act → observe → iterate loop. They can decompose complex goals into subtasks, call APIs, query databases, write code, and adjust their strategy based on what they learn at each step.
The five core capabilities of an AI agent:
- Autonomous decision-making — choosing which tools to use and when
- Multi-step planning — breaking complex goals into executable tasks
- Dynamic tool use — calling APIs, querying databases, triggering systems
- Persistent memory — maintaining context across interactions
- Reasoning loops — adjusting behavior based on observed outcomes
Here's a basic agent with tool use built on LangGraph:
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
@tool
def get_order_status(order_id: str) -> str:
"""Look up the current status of a customer order."""
# In production, this queries your order database
return f"Order {order_id}: Shipped, arriving March 2"
@tool
def issue_refund(order_id: str, amount: float) -> str:
"""Process a refund for a customer order."""
return f"Refund of ${amount} issued for order {order_id}"
llm = ChatAnthropic(model="claude-sonnet-4-5-20250929")
agent = create_react_agent(
llm,
tools=[get_order_status, issue_refund],
prompt="You are a customer support agent. Help resolve issues."
)
# The agent decides which tools to call and in what order
result = agent.invoke({
"messages": [{"role": "user", "content": "Order #1234 arrived damaged. I want a refund."}]
})
The agent autonomously checks the order status, confirms it exists, and then processes the refund — multiple steps with decisions at each point. No human had to hard-code that workflow.
MCP (Model Context Protocol): The Integration Layer
MCP is an open standard created by Anthropic in late 2024 that standardizes how AI applications connect to external tools and data sources. Think of MCP as USB-C for AI — instead of building custom connectors for every tool-model combination (the dreaded N×M problem), MCP provides a single protocol that any AI application can use to talk to any tool server.
MCP follows a client-server architecture with three components:
- Host: The AI application (Claude Desktop, an IDE, your custom app)
- Client: Created by the host, maintains a JSON-RPC connection to a server
- Server: Exposes tools, resources, and prompts to the AI
MCP servers expose three types of capabilities:
- Resources: Read-only data (file contents, database views, API responses)
- Tools: Executable functions that perform actions (query databases, send emails, trigger deployments)
- Prompts: Pre-written templates for common tasks
Here's how to build a minimal MCP server in TypeScript using the official SDK (v1.12):
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "inventory-server",
version: "1.0.0"
});
// Expose a tool for checking product inventory
server.tool(
"check_inventory",
"Check current stock levels for a product",
{ product_id: z.string().describe("The product SKU") },
async ({ product_id }) => {
// Query your inventory database
const stock = await db.query(
"SELECT quantity FROM inventory WHERE sku = ?", [product_id]
);
return {
content: [{
type: "text",
text: JSON.stringify({ product_id, quantity: stock.quantity })
}]
};
}
);
// Expose a resource for reading product catalog
server.resource(
"catalog",
"products://catalog",
async (uri) => ({
contents: [{
uri: uri.href,
mimeType: "application/json",
text: JSON.stringify(await db.query("SELECT * FROM products"))
}]
})
);
const transport = new StdioServerTransport();
await server.connect(transport);
The key distinction here — and this trips people up constantly — is that MCP isn't an architecture for building AI applications. It's a protocol for connecting AI applications to the outside world. An agent or RAG system uses MCP; MCP doesn't replace either of them.
RAG vs AI Agents: A Direct Comparison
The RAG vs AI agents comparison is the most common decision point for teams building AI applications. Let's break it down across every dimension that actually matters in production.
Performance Benchmarks (2026)
Recent benchmarks from LlamaIndex (February 2026) comparing traditional RAG against agentic file-system approaches reveal some interesting tradeoffs:
| Metric | Traditional RAG | Agentic Approach |
|---|---|---|
| Average Correctness (1-10) | 6.4 | 8.4 |
| Average Relevance (1-10) | 8.0 | 9.6 |
| Average Response Time | 7.36s | 11.17s |
| Scalability at Large Datasets | Better | Degrades |
| Cost per Query | Lower | 3-5x Higher |
So the agentic approach scores 2 points higher on correctness and 1.6 points higher on relevance — but you're paying for it with an extra 3.81 seconds of latency per query. Traditional RAG's lower accuracy mostly comes down to context loss during chunking and suboptimal retrieval calls, which makes the LLM more prone to hallucinations.
At larger scale, though, the picture flips. RAG outperforms agentic approaches in both speed (by a lot) and correctness (slightly). This makes RAG the better fit for real-time applications where latency matters, while agentic approaches shine for background tasks and asynchronous processing where you can afford to wait.
Architectural Tradeoffs
| Dimension | RAG | AI Agents |
|---|---|---|
| Workflow | Retrieve → Generate (single pass) | Plan → Act → Observe → Iterate |
| Action Capability | Read-only | Full read/write/execute |
| Determinism | High (same query → similar results) | Low (emergent behavior) |
| Auditability | Easy (clear retrieval trail) | Hard (multi-step reasoning chains) |
| Error Handling | Fails predictably | Can self-correct, but may spiral |
| Deployment Complexity | Moderate (vector DB + embeddings) | High (orchestration + tools + guardrails) |
| Governance | Straightforward | Requires robust frameworks |
Where MCP Changes the Decision
Before MCP existed, connecting an AI agent to external systems meant writing custom integration code for every single tool. Five AI applications and ten data sources? That's 50 different integrations. MCP collapses this to N + M — each application implements the MCP client once, each tool implements the MCP server once, and they all just work together.
This has three practical impacts on your architecture decision.
MCP Makes Agents Way More Practical
Honestly, the biggest barrier to agent adoption was always the integration effort. Building, maintaining, and securing custom tool connectors for each API was expensive and fragile. With MCP, agents can dynamically discover available tools from MCP servers, invoke tools through a standardized JSON-RPC protocol, receive structured results in a consistent format, and work with any MCP-compatible tool without custom code.
The MCP ecosystem now includes over 500 publicly available servers covering databases (PostgreSQL, MySQL, MongoDB), file storage (S3, Google Drive), communication tools (Slack, email), developer tools (GitHub, Jira, Linear), web scraping, and more. What used to require weeks of integration work is now basically a configuration file.
MCP Complements RAG — It Doesn't Replace It
This is a misconception I see all the time: people thinking MCP replaces RAG. It doesn't. MCP is a two-way protocol for real-time tool interaction. RAG is a one-way pattern for batch-indexed knowledge retrieval. They serve completely different data access patterns:
- MCP: Real-time, deterministic, query-driven context injection — ideal for live data and system actions
- RAG: Pre-indexed, similarity-based, semantic retrieval — ideal for large document corpora and knowledge bases
The core tradeoff is freshness vs efficiency. RAG keeps per-query token usage low through pre-filtering and chunking. MCP guarantees real-time accuracy but burns more tokens per query because it fetches live data on every request.
In practice, you can actually implement a RAG server as an MCP tool. This lets agents use RAG as one of many tools they can call — querying the knowledge base when they need background information and calling live APIs through other MCP servers when they need current data.
// MCP server that wraps a RAG pipeline as a tool
server.tool(
"search_knowledge_base",
"Search the company knowledge base for relevant documents",
{
query: z.string().describe("The search query"),
top_k: z.number().default(5).describe("Number of results to return")
},
async ({ query, top_k }) => {
// Call your RAG pipeline
const results = await ragPipeline.search(query, top_k);
return {
content: [{
type: "text",
text: JSON.stringify(results.map(r => ({
content: r.pageContent,
source: r.metadata.source,
score: r.score
})))
}]
};
}
);
MCP Enables Hybrid Architectures
The most powerful pattern in 2026 — and the one I'd recommend for most non-trivial use cases — is the hybrid architecture: an agent that uses both MCP tools and RAG retrieval. The agent decides at runtime whether it needs historical knowledge (RAG) or live data and actions (MCP tools).
# Hybrid agent: RAG + MCP tools via LangGraph
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
@tool
def search_docs(query: str) -> str:
"""Search internal documentation via RAG pipeline."""
results = rag_chain.invoke({"input": query})
return results["answer"]
@tool
def check_order_status(order_id: str) -> str:
"""Check real-time order status via MCP-connected API."""
# This calls an MCP server under the hood
return mcp_client.call_tool("order_status", {"order_id": order_id})
@tool
def create_support_ticket(summary: str, priority: str) -> str:
"""Create a support ticket via MCP-connected ticketing system."""
return mcp_client.call_tool("create_ticket", {
"summary": summary, "priority": priority
})
agent = create_react_agent(
ChatAnthropic(model="claude-sonnet-4-5-20250929"),
tools=[search_docs, check_order_status, create_support_ticket],
prompt="You are a customer support agent. Use documentation search "
"for policy questions and live tools for order actions."
)
The Architecture Decision Framework
Alright, let's get practical. Use this decision framework to figure out the right architecture for your use case. The golden rule: start with the simplest approach that meets your requirements and add complexity only when you actually need it.
Step 1: Classify Your Use Case
Ask yourself three questions about what your AI system needs to do:
- Does it need to answer questions from existing documents? → You need RAG
- Does it need to take actions or make multi-step decisions? → You need an agent
- Does it need to connect to external systems in a standardized way? → You need MCP
Most production systems answer "yes" to more than one of these, which means you're looking at a hybrid architecture.
Step 2: Match Requirements to Architecture
| Requirement | Architecture | Example |
|---|---|---|
| Q&A over company docs | RAG only | Employee knowledge base chatbot |
| Semantic search + summarization | RAG only | Legal document research tool |
| Multi-step task automation | Agent + MCP | DevOps deployment assistant |
| Customer support with actions | Agent + RAG + MCP | Support agent that looks up policies and processes refunds |
| Real-time data dashboards | MCP only | AI-powered analytics copilot querying live APIs |
| Research + report generation | Agent + RAG | Market research assistant |
| Regulated industry Q&A | RAG only | Healthcare compliance chatbot (HIPAA) |
| Full enterprise automation | Agent + RAG + MCP | AI project manager across tools |
Step 3: Evaluate Operational Constraints
Even if your use case calls for an advanced architecture, real-world constraints might push you toward something simpler. Be honest with yourself here:
- Latency requirements under 3 seconds? → Favor RAG over agents. Agents add 3-5 seconds per reasoning step.
- Strict audit/compliance requirements? → Start with RAG. Agent reasoning chains are genuinely hard to audit.
- Limited engineering resources? → Start with RAG. Agents require orchestration, guardrails, and monitoring infrastructure that someone has to build and maintain.
- Need real-time data freshness? → Add MCP. RAG indexes can go stale; MCP always fetches live data.
- Budget constraints? → Start with RAG. Agent workflows cost 3-5x more per query due to multi-step reasoning.
Step 4: Plan Your Migration Path
Here's the progression I'd recommend for most organizations:
- Start with RAG — Deploy a knowledge-base chatbot. Get your vector store, embedding pipeline, and evaluation framework in place. This builds the foundation for everything else.
- Add MCP servers — Wrap your existing APIs and databases as MCP servers. This is a one-time investment that pays off regardless of whether you eventually move to agents.
- Introduce agents — When you have workflows that genuinely require multi-step reasoning and tool orchestration, layer an agent framework on top. Use RAG as a tool and MCP servers for live integrations.
- Build agentic RAG — For the most demanding use cases, let agents manage the retrieval process itself — dynamically choosing retrieval strategies, refining queries, and cross-referencing multiple sources.
Production Implementation Patterns
Here are three battle-tested patterns that cover the majority of production use cases in 2026. I've seen variations of these work across dozens of teams.
Pattern 1: RAG-First Customer Support
Best for: Teams just starting with AI, regulated industries, and Q&A-focused use cases.
# Pattern 1: Pure RAG for document-grounded Q&A
from langchain_anthropic import ChatAnthropic
from langchain_chroma import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
vectorstore = Chroma(
persist_directory="./support_kb",
embedding_function=HuggingFaceEmbeddings(
model_name="BAAI/bge-small-en-v1.5"
)
)
llm = ChatAnthropic(
model="claude-sonnet-4-5-20250929",
temperature=0.0,
max_tokens=1024
)
prompt = ChatPromptTemplate.from_messages([
("system", """You are a customer support assistant. Answer questions
using ONLY the provided context. If the answer is not in the context,
say you don't know and suggest contacting human support.
Context: {context}"""),
("human", "{input}")
])
rag_chain = create_retrieval_chain(
vectorstore.as_retriever(search_kwargs={"k": 4}),
create_stuff_documents_chain(llm, prompt)
)
# Simple, auditable, cost-effective
response = rag_chain.invoke({"input": "How do I cancel my subscription?"})
This pattern handles 70-80% of customer support queries at low cost with full auditability. Every response cites specific documents, which makes it suitable for regulated environments where you need a clear paper trail.
Pattern 2: Agent with MCP Tool Orchestration
Best for: Multi-step workflows, task automation, and systems that need to take actions (not just answer questions).
// Pattern 2: MCP server for a support ticketing system
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({
name: "support-tools",
version: "1.0.0"
});
server.tool(
"lookup_customer",
"Find customer details by email or ID",
{
identifier: z.string(),
type: z.enum(["email", "customer_id"])
},
async ({ identifier, type }) => {
const customer = await db.customers.findBy(type, identifier);
return { content: [{ type: "text", text: JSON.stringify(customer) }] };
}
);
server.tool(
"get_recent_tickets",
"Get recent support tickets for a customer",
{ customer_id: z.string(), limit: z.number().default(5) },
async ({ customer_id, limit }) => {
const tickets = await db.tickets.findRecent(customer_id, limit);
return { content: [{ type: "text", text: JSON.stringify(tickets) }] };
}
);
server.tool(
"escalate_ticket",
"Escalate a support ticket to a human agent",
{
ticket_id: z.string(),
reason: z.string(),
priority: z.enum(["low", "medium", "high", "critical"])
},
async ({ ticket_id, reason, priority }) => {
await db.tickets.escalate(ticket_id, { reason, priority });
return {
content: [{ type: "text", text: `Ticket ${ticket_id} escalated (${priority})` }]
};
}
);
Pattern 3: Hybrid Agent with RAG + MCP
Best for: Enterprise support, complex workflows that need both knowledge retrieval and real-world actions.
# Pattern 3: Full hybrid — Agent orchestrates RAG + MCP tools
from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import MemorySaver
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
@tool
def search_documentation(query: str) -> str:
"""Search product documentation and support articles.
Use this for policy questions, how-to guides, and feature info."""
result = rag_chain.invoke({"input": query})
return f"Documentation result:\n{result['answer']}"
@tool
def lookup_customer(email: str) -> str:
"""Look up customer account details by email address."""
return mcp_client.call_tool("lookup_customer", {
"identifier": email, "type": "email"
})
@tool
def check_subscription(customer_id: str) -> str:
"""Check a customer's current subscription status and billing."""
return mcp_client.call_tool("get_subscription", {
"customer_id": customer_id
})
@tool
def process_cancellation(customer_id: str, reason: str) -> str:
"""Process a subscription cancellation. Requires customer confirmation."""
return mcp_client.call_tool("cancel_subscription", {
"customer_id": customer_id,
"reason": reason,
"effective": "end_of_billing_period"
})
agent = create_react_agent(
ChatAnthropic(model="claude-sonnet-4-5-20250929"),
tools=[
search_documentation,
lookup_customer,
check_subscription,
process_cancellation
],
checkpointer=MemorySaver(), # Persist conversation state
prompt="""You are a senior customer support agent. Follow these rules:
1. Always search documentation before answering policy questions
2. Verify customer identity before accessing account data
3. Explain what you are doing at each step
4. Ask for confirmation before taking irreversible actions"""
)
This hybrid agent handles complex multi-turn conversations: searching docs for cancellation policies, looking up the customer's account, checking their subscription status, and processing the cancellation — all while maintaining conversation state and asking for confirmation before doing anything irreversible.
Security and Governance Considerations
Each architecture brings its own security headaches, and this should absolutely factor into your decision.
RAG Security
RAG systems primarily face risks around data poisoning (malicious content in the knowledge base affecting responses), prompt injection via retrieved documents (adversarial content sneaking into indexed documents), and information leakage (retrieval returning sensitive documents the user shouldn't see). Mitigations include access-control-aware retrieval, input sanitization, and output filtering.
Agent Security
Agents introduce higher-risk concerns because they can actually do things. Key risks include tool misuse (agents calling tools in unintended ways), privilege escalation (agents accessing systems beyond their authorization), and runaway loops (agents entering infinite reasoning cycles that burn through your API budget before anyone notices). Mitigations include human-in-the-loop approval for sensitive actions, tool-level permission scoping, budget caps, and step limits.
MCP Security
The MCP specification addresses security through OAuth 2.1 authentication, least-privilege permissions, and PKCE (Proof Key for Code Exchange). However, security researchers have identified some outstanding issues — prompt injection via tool responses, tool permission combinations that could enable data exfiltration, and lookalike tools that silently replace trusted ones. In production, always validate tool inputs, implement output sanitization, and use allowlists for permitted tool combinations.
Cost Analysis: RAG vs Agents vs MCP
Let's talk money, because cost is often what actually decides the architecture in practice. Here's a realistic cost breakdown for 10,000 daily queries using Claude Sonnet 4.5 (February 2026 pricing: $3/1M input tokens, $15/1M output tokens):
| Cost Factor | RAG Only | Agent + MCP | Hybrid (Agent + RAG + MCP) |
|---|---|---|---|
| Avg tokens per query | ~2,000 input / ~500 output | ~8,000 input / ~2,000 output | ~10,000 input / ~2,500 output |
| Daily LLM cost | ~$0.14 | ~$0.54 | ~$0.68 |
| Monthly LLM cost | ~$4.10 | ~$16.20 | ~$20.25 |
| Infrastructure (vector DB, MCP servers) | $50-200/mo | $100-400/mo | $150-500/mo |
| Total monthly estimate | $55-205 | $115-415 | $170-520 |
Agents cost 3-5x more per query than RAG because each agent step requires a separate LLM call. A simple query might take 2-3 steps, while complex workflows can run 5-10 steps. The tradeoff is straightforward: agents deliver higher accuracy and can actually take actions, but you'll pay a real cost premium for that capability.
Common Mistakes and How to Avoid Them
After looking at dozens of production deployments, these are the mistakes I see teams make over and over again:
- Using agents when RAG would do the job. If your users ask questions and get text answers back, you probably don't need an agent. Agents add latency, cost, and complexity. Start with RAG and only bring in agents when you genuinely need multi-step actions.
- Treating MCP as a replacement for RAG. MCP fetches live data per request. RAG pre-indexes and retrieves efficiently. For large document corpora, RAG is dramatically more efficient. Use MCP for real-time data; use RAG for knowledge bases.
- Skipping evaluation infrastructure. Whether you use RAG, agents, or both — you need automated evaluation. Track retrieval relevance, answer correctness, hallucination rate, and tool-use accuracy. Without metrics, you're flying blind.
- Over-engineering from day one. Don't build a hybrid agent-RAG-MCP system when a simple RAG pipeline covers 80% of your use cases. Ship the simple version, measure where it actually fails, and add complexity only where the data tells you to.
- Ignoring security at the MCP layer. MCP tools can take actions. Every MCP tool is an attack surface. Implement input validation, output sanitization, permission scoping, and human-in-the-loop approval for destructive operations from the very start.
FAQ: RAG vs AI Agents vs MCP
Can RAG and AI agents work together?
Absolutely. The dominant hybrid pattern in 2026 is called Agentic RAG, where an AI agent uses RAG as one of its tools. The agent decides when it needs to pull knowledge from the vector store and when it needs to call live APIs or take actions. This combines RAG's grounding accuracy with the agent's planning and action capabilities. Industry projections suggest 75% of enterprise AI apps will use hybrid architectures by the end of 2026.
Is MCP the same as function calling?
No, and this distinction matters. Function calling is a capability built into specific LLMs (like Claude or GPT-4) that lets the model generate structured tool-call requests. MCP is a protocol that standardizes how those tool calls are transmitted, executed, and returned. Think of function calling as the model knowing it should call a tool, and MCP as the standardized wire protocol that connects that call to the actual tool server. MCP works across any LLM that supports tool use.
When should I choose MCP over a custom API integration?
Choose MCP when you expect to connect multiple AI applications to the same tools, when you want your tools to be reusable across different LLM providers, or when you need dynamic tool discovery (the AI discovers available tools at runtime). If you have a single application with a single custom API, direct integration might be simpler. But once you hit 3+ integrations, MCP's standardization saves serious development and maintenance effort.
How do I know if my RAG pipeline needs an upgrade to agents?
Watch for these signals: users frequently ask follow-up questions that need context from previous answers (you need memory), users ask your system to do things rather than just answer questions (you need action capability), your retrieval pipeline needs to query multiple sources to answer one question (you need orchestration), or query accuracy keeps dropping despite tuning (you might need agentic retrieval with self-correction).
What's the recommended tech stack for a hybrid system in 2026?
Here's what's working well in production right now: LLM — Claude Sonnet 4.5 or GPT-4o for reasoning; Agent framework — LangGraph for stateful agent orchestration; RAG — LangChain 0.5 with ChromaDB or pgvector for vector storage and BGE or OpenAI embeddings; MCP — Official TypeScript/Python SDK (v1.12) with stdio transport for local servers and streamable HTTP for remote servers; Observability — Langfuse or OpenTelemetry GenAI for tracing agent and retrieval performance; Evaluation — RAGAS or DeepEval for automated retrieval and generation quality testing.