DEV Community: Vedant chidrawar

Building an Agentic AI Assistant with LangGraph and MCP

Vedant chidrawar — Thu, 29 Oct 2026 14:43:31 +0000

A basic chatbot receives a question and generates a response. An AI agent can go further: it can select tools, execute actions, observe the results, and decide what to do next.

I explored this approach in my Agentic AI Assistant with MCP Tools project, built with Python, LangGraph, the Model Context Protocol (MCP), Groq, and Streamlit.

The assistant supports multi-turn conversations and can use a sandboxed filesystem tool and a web-search tool. This article explains how the components fit together and what I learned about building tool-using AI systems.

1. From chatbots to agents

Consider a user asking:

"Search for the latest LangGraph release notes and save a short summary in a text file."

A simple chatbot might explain how to perform these steps. An agent can instead work through the task:

Interpret the user's request.
Decide to use a web-search tool.
Examine the search results.
Summarize the relevant information.
Use a filesystem tool to write the summary.
Report the result to the user.

The important difference is that the application can coordinate multiple tool calls rather than generating only a text response.

Tool use does not mean an agent is always correct. The model can choose an unsuitable tool, misunderstand results, or produce an inaccurate summary. The surrounding application must therefore control which actions are available and how they are executed.

2. What does LangGraph do?

LangGraph provides orchestration for agent workflows.

In my project, the assistant uses a ReAct-style agent pattern. The model can alternate between reasoning about the request, selecting a tool, receiving its output, and deciding whether another action is needed.

The simplified flow is:

User request → Agent → Tool call → Tool result → Agent → Final response

Some requests require only a final response. Others require multiple tool calls.

The agent orchestration is handled through LangGraph's prebuilt agent functionality, while the Streamlit application provides the conversational interface.

This separation is useful because the interface does not need to implement the agent's decision-making logic itself.

3. Why use the Model Context Protocol?

Integrating every external tool directly into an agent can make the application tightly coupled to individual implementations.

The Model Context Protocol (MCP) defines a standard way for applications to communicate with tool-providing servers and discover available capabilities.

In this project, I use MCP to connect the agent to two separate servers:

Filesystem server: Lists, reads, and writes files inside a designated sandbox directory.
Search server: Uses Tavily to perform web searches.

The agent uses MultiServerMCPClient from langchain-mcp-adapters to connect to the servers and retrieve their available tools.

In the current implementation, the servers are launched as subprocesses and communicate over standard input/output (stdio).

This architecture separates the agent's orchestration from the individual tool implementations. Adding another compatible server can extend the assistant's capabilities without placing every tool implementation directly inside the agent.

MCP standardizes communication; it does not automatically make a tool safe. The application still needs to validate inputs, limit permissions, and control access to sensitive resources.

4. Understanding tool discovery

Tool discovery allows the agent application to learn which operations a connected MCP server exposes.

For example, the filesystem server provides operations for listing, reading, and writing files within its allowed directory. The search server exposes a web-search capability.

The application retrieves these tools and makes them available to the agent.

When a request arrives, the model can select an appropriate tool based on the request and the tool descriptions. The orchestration layer then routes the call to the correct server and returns its result to the agent.

This approach is more flexible than writing a separate hard-coded branch for every possible user request.

However, the model's choice should never be treated as authorization by itself. Tool execution must remain constrained by the application's actual permissions.

5. Adding memory to multi-turn conversations

Without conversation history, a chatbot may struggle with follow-up questions such as "Now save that result to a file."

My project uses LangGraph's MemorySaver with a conversation-specific thread_id to maintain state across turns.

The application assigns a thread identifier to the session, allowing follow-up requests to access the relevant conversation history.

This helps the agent understand references to earlier questions and results.

There is an important distinction between in-memory conversation state and durable storage. An in-memory checkpointer is useful for a prototype, but its state should not be assumed to survive every process restart or to provide a permanent database-backed conversation archive.

6. Why sandboxing matters

An AI agent that can read and write files needs stronger safeguards than a chatbot that only generates text.

My filesystem tool restricts access to a designated sandbox directory and resolves requested paths against that directory. Paths that attempt to escape the sandbox, such as those containing traversal sequences, are rejected.

This is an important defense because an agent may construct a path incorrectly or respond to an unsafe instruction.

Other safeguards worth considering include:

Validating tool arguments before execution.
Keeping API keys in environment variables rather than source code.
Limiting network and filesystem permissions.
Recording tool calls and errors for debugging.
Requiring user confirmation for consequential actions.

A sandbox is one layer of defense, not a guarantee of complete security.

7. Lessons from building the assistant

This project helped me understand several practical aspects of agent development:

Tool calling requires orchestration, not just a capable language model.
MCP can separate tool providers from the agent that consumes them.
Multi-turn memory helps the assistant interpret follow-up requests.
Tool descriptions and return values influence how effectively the agent works.
Filesystem access should be restricted and validated.
Observability becomes increasingly important as workflows involve multiple tool calls.

Conclusion

Building an agentic assistant helped me explore how language models, workflow orchestration, and external tools can work together to complete multi-step tasks.

LangGraph manages the agent workflow, MCP provides a consistent tool-integration layer, and Streamlit makes the system accessible through a chat interface.

The most important lesson is that useful agents need more than tool access. They also need clear boundaries, reliable error handling, and careful control over what actions they are permitted to perform.

Project: Explore Agentic AI Assistant with MCP Tools on GitHub

Live demo: MCP-Assistant

Technologies: Python, LangGraph, MCP, Groq, Tavily, Streamlit, and Docker.

Further reading: LangChain and LangGraph learning resources · MCP documentation

Building a PDF Question-Answering Chatbot Using RAG and FastAPI

Vedant chidrawar — Thu, 29 Oct 2026 14:39:38 +0000

Large language models can explain concepts and generate useful responses, but they do not automatically know the contents of a private PDF uploaded by a user.

A document question-answering application needs a way to retrieve relevant information from that document and provide it to the language model before generating an answer.

That is the idea behind Retrieval-Augmented Generation (RAG).

In my PDF Chatbot project, I worked with a stack involving FastAPI, LangChain, FAISS, PostgreSQL, SQLAlchemy, Streamlit, and Docker. The application combines document retrieval with conversational question answering and persistent chat history.

This article explains the architecture and some of the engineering decisions involved.

1. What is RAG?

RAG combines two main operations:

Retrieval: Find information relevant to a user's question.
Generation: Give that information to a language model so it can formulate an answer.

Instead of relying entirely on information learned during model training, the application retrieves relevant passages from the uploaded documents.

A typical workflow is:

PDF upload → Text extraction → Chunking → Embeddings → Vector search → Answer generation

The quality of the final answer depends on more than the language model. If retrieval misses the relevant passage, the model may not have enough information to answer correctly.

2. Preparing documents for retrieval

A PDF is not automatically suitable for semantic search. Its text needs to be extracted and organized into manageable sections.

Text extraction and chunking

The application processes uploaded PDFs and divides their content into smaller text chunks.

Chunking is useful because embedding and retrieval systems generally work better with manageable pieces of text than with an entire long document treated as one unit.

However, chunk size involves a trade-off:

Very small chunks may lose important context.
Very large chunks may contain irrelevant information and make retrieval less precise.

The right strategy depends on the document structure and the questions users are likely to ask.

Generating embeddings

An embedding model converts text into numerical vectors that represent semantic information.

In my project, local ONNX-based embeddings are used as part of the retrieval pipeline. Using a local embedding model can reduce dependence on an external embedding API, although model quality and deployment resource requirements still matter.

Searching with FAISS

FAISS provides vector similarity search. The application can use it to retrieve document chunks that are semantically related to a question.

This is different from ordinary keyword matching: a semantic search system can find related passages even when the wording of the question differs from the original text.

FAISS handles vector search; it is not itself the language model that generates the final answer.

3. Generating answers from retrieved context

After retrieving relevant chunks, the application passes the available context and the user's question to the language model.

A useful instruction is to answer using the supplied context and acknowledge when the retrieved material does not contain enough information.

This reduces the risk of unsupported answers, but it cannot guarantee that hallucinations will never occur. Retrieval quality, prompt design, and answer validation all affect reliability.

My project also uses history-aware retrieval so that follow-up questions can be rewritten using previous conversation turns.

For example:

First question: "What does the document say about authentication?"
Follow-up: "What are its main limitations?"

The second question is ambiguous by itself. Conversation history can help the retrieval system understand that "its" refers to the authentication approach discussed previously.

4. Designing persistent conversation storage

A chatbot becomes more useful when users can return to earlier conversations instead of losing their history whenever the interface reloads.

I used SQLAlchemy ORM models to organize the application's relational data into three main entities.

Model	Responsibility
`Document`	Stores document metadata, including the filename, page count, chunk count, and creation time
`Conversation`	Associates a conversation with a document and stores its title and creation time
`Message`	Stores each message's role, content, source information, and creation time

The relationships follow a straightforward structure:

Document → Conversations → Messages

A document can have multiple conversations, and each conversation can contain multiple messages. Foreign keys maintain the associations between these records, while SQLAlchemy's ORM relationships make it easier to work with related objects in Python.

The Message model also includes a JSON field for source information, allowing retrieved source details to be stored alongside the response.

5. Why separate vector search from relational storage?

The application has two different data responsibilities.

FAISS supports similarity search over embedded document chunks.

PostgreSQL stores structured application information such as document metadata, conversation records, and messages.

Keeping these responsibilities separate makes the design easier to understand. Relational data can be queried and managed through SQLAlchemy, while vector search is handled by the retrieval component.

The two systems still need consistent lifecycle management. For example, if a document is deleted or reprocessed, the application must handle its associated retrieval data and metadata appropriately.

6. Managing the application layers

The project uses FastAPI for backend API functionality and Streamlit for the interactive interface.

FastAPI provides a boundary for operations such as uploading documents and asking questions. Streamlit gives users a convenient way to interact with the application without building a separate JavaScript frontend.

SQLAlchemy sessions also require careful handling. A session should have a clear lifecycle, and database changes that need to persist must be committed. Closing a session alone does not guarantee that pending changes are committed.

Docker provides a consistent packaging approach for running the application and its dependencies, while deployment configuration must still account for environment variables, database connectivity, and persistent storage.

7. Lessons from building a RAG application

This project reinforced several important ideas:

Retrieval quality is just as important as answer generation.
Chunking affects both relevance and context.
Conversation history can help interpret follow-up questions.
Source references improve traceability, but do not independently prove an answer is correct.
Persistent chat history needs a clear relational data model.
Database sessions and application resources need explicit lifecycle management.

Conclusion

Building a PDF chatbot involves more than connecting a language model to a file. It requires document processing, semantic retrieval, context-aware generation, persistent storage, and a user interface that brings the components together.

RAG provides a practical foundation for document-grounded question answering, but reliable results still require careful testing of retrieval relevance, answer correctness, and failure cases.

Technologies: FastAPI, LangChain, FAISS, PostgreSQL, SQLAlchemy, Streamlit, ONNX embeddings, and Docker.

Live Demo:PDF Chatbot with RAG

Project: Github

Further reading: LangChain learning resources · SQLAlchemy ORM documentation

ShopSphere

Vedant chidrawar — Thu, 29 Oct 2026 14:35:24 +0000

Building a Full-Stack E-commerce Platform with Next.js, Express, PostgreSQL, and Redis

A full-stack e-commerce application is more than a product listing page and a shopping cart. It needs to manage users, protect private operations, process orders, handle payments, and keep inventory consistent.

While building ShopSphere, I worked on bringing these pieces together in a single application. The project uses Next.js and TypeScript for the frontend, Node.js and Express for backend APIs, PostgreSQL with Prisma for data persistence, Redis for caching, and Razorpay for payment processing.

In this article, I'll explain the architecture, important engineering decisions, and lessons from building the application.

1. Understanding the architecture

ShopSphere separates the user interface from the backend services.

Next.js and TypeScript: Provide the application interface, product pages, cart, checkout, order history, and admin dashboard.
Node.js and Express: Handle API requests, authentication, validation, and business logic.
PostgreSQL and Prisma: Store structured application data and provide an ORM for database operations.
Redis: Cache frequently requested product information and selected dashboard results.
Razorpay: Handles the payment checkout flow.

Separating these responsibilities makes the application easier to maintain. For example, the frontend can display products without needing to know how the backend queries PostgreSQL.

2. Authentication and authorization are different

One important lesson from ShopSphere was that authentication and authorization solve different problems.

Authentication answers: Who is the user?

Authorization answers: What is this user allowed to do?

The application uses JWT-based authentication with short-lived access tokens and refresh tokens stored in HTTP-only cookies. The access token is sent through the Authorization header when calling protected APIs.

Role-based authorization adds another layer. A customer should be able to manage their cart and view their orders, while administrative operations—such as managing the product catalog—must be restricted to authorized administrators.

The backend must enforce these permissions. Hiding an admin button in the frontend is not sufficient because a user can still attempt to call the API directly.

3. Improving response times with Redis

Product listings and product details are requested frequently, so repeatedly querying the database for unchanged information can introduce unnecessary work.

ShopSphere uses Redis to cache selected product data.

A simplified cache-aside flow looks like this:

Check whether the requested data exists in Redis.
If it exists, return the cached result.
If it does not, query PostgreSQL.
Store the result in Redis and return it.
When the underlying product data changes, invalidate the affected cache entries.

The last step is important. Caching without invalidation can cause users to see outdated prices, product information, or stock details.

Caching is useful for frequently read data, but it should not replace database validation for operations such as checkout.

4. Handling payments safely

Payment processing requires particular care because an incorrect implementation can leave an order and its payment status inconsistent.

The ShopSphere checkout flow creates an order in a pending state and initiates a Razorpay order. After the checkout process, the backend verifies the payment signature before marking the order as paid.

The backend also uses a Prisma database transaction to update the payment-related order state and decrement inventory atomically.

Why does this matter?

Imagine an order contains the last available unit of a product. Payment verification and inventory updates must be handled carefully so that concurrent checkouts do not accidentally oversell stock.

A database transaction helps ensure that related database changes succeed together or roll back together. It does not, by itself, make an external payment operation atomic with the database; payment verification and failure handling still need to be designed correctly.

For a production system, I would also pay close attention to duplicate callbacks, idempotency, transaction failures, and reconciliation between the payment provider and the application.

5. Making the application useful for administrators

ShopSphere also includes an administrative dashboard that displays information such as revenue, order status, top products, low-stock alerts, and customer counts.

This transforms the application from a basic shopping interface into a tool for managing the business.

The dashboard combines backend aggregation with frontend visualizations. Frequently requested summary data can be cached briefly, provided that the application handles invalidation and freshness appropriately.

6. What I learned

Building ShopSphere reinforced several practical lessons:

Authentication must be complemented by server-side authorization.
Cache invalidation is part of the feature, not an afterthought.
Payment status should be verified by the backend rather than trusted from the browser.
Related inventory and order updates require careful transaction handling.
A clear separation between frontend, API, and persistence responsibilities makes debugging easier.

Conclusion

ShopSphere helped me understand how frontend development, backend APIs, databases, caching, authentication, and payment integrations work together in a full-stack product.

The biggest takeaway is that a working interface is only one part of a reliable application. Correct data handling, security, and failure management are equally important.

Project: ShopShpere

Live Demo:Github
Technologies: Next.js, TypeScript, Express, PostgreSQL, Prisma, Redis, and Razorpay.