DEV Community: Sri Deevi

Beyond RAG: Building an AI Coding Agent with Planning, Tool Execution, and ReAct Reasoning

Sri Deevi — Wed, 05 Aug 2026 02:23:22 +0000

In my previous article, I explored how I wrapped a RAG agent inside an MCP server to make enterprise knowledge accessible through standardized tools.

However, while RAG improves retrieval, software engineering tasks require something more.

A developer assistant should not only retrieve information. It should investigate.

For example:

"Where is authentication implemented?"

A useful coding assistant should be able to:

search the repository
identify relevant files
inspect source code
understand classes and functions
explain the implementation

This led me to build an AI coding agent that can reason, select tools, and analyze a codebase step-by-step. This one doesn't use RAG yet — it works directly against the repository — but that's a deliberate next step, more on that at the end.

From Chatbot to Agent

A traditional chatbot follows a simple pattern:

User Question
       |
       v
      LLM
       |
       v
    Response

This works well for general questions, but software repositories contain thousands of files and relationships.

A coding assistant needs additional capabilities:

repository awareness
search capability
code understanding
multi-step reasoning

An agent introduces a decision-making layer:

User Question
      |
      v
    Planner
      |
      v
 Choose Tool
      |
      v
 Execute Tool
      |
      v
 Observe Result
      |
      v
 Generate Answer

Architecture Overview

The agent consists of several components.

Planner

The planner decides the next action. It tries a rule-based plan first (keyword matching on the question), and falls back to an LLM (via Ollama's tinyllama) for JSON-structured tool selection when no rule matches.

Example:

User question:

Where is authentication implemented?

Planner response:

{
 "tool": "search_code",
 "input": "authentication"
}

The planner does not execute the action. It only decides what should happen next.

Tool Registry

The agent exposes capabilities through tools. Currently:

search_code
read_file
analyze_file

Each tool has a specific responsibility.

Search Tool — finds files containing a keyword.

Input: authentication
Output: auth.py, app.py

Read File Tool — retrieves source code.

Input: auth.py
Output:

class AuthenticationService:
    def login(self, username, password):
        if self.authenticate(username, password):
            return "Login successful"

Analyze Tool — understands code structure using Python's ast module.

Output:

{
 "classes": ["AuthenticationService"],
 "functions": ["login", "authenticate"]
}

The Agent Execution Loop

The core of the system is the agent loop, following a ReAct-style pattern:

Reason
  ↓
Action
  ↓
Observation
  ↓
Reason Again

Step 1 — The agent determines it needs to locate authentication code.

Action: search_code("authentication")
Observation: auth.py, app.py

Step 2 — The agent identifies that auth.py is likely the implementation.

Action: read_file("auth.py")
Observation: AuthenticationService class found

Step 3 — The agent needs more understanding.

Action: analyze_file()
Observation:

Class: AuthenticationService
Functions: login(), authenticate()

The agent now has enough information to answer.

Challenges During Implementation

Building the agent introduced several interesting engineering challenges.

Challenge 1: Reliable tool selection. Initially, the LLM sometimes selected incorrect tools or returned invalid responses. To improve reliability, I restricted tool choices, added JSON validation, and enforced structured outputs.

Challenge 2: Avoiding repeated actions. An early version of the agent could repeat search_code indefinitely, because every decision was independent. The fix was maintaining previous observations as context, so the planner can see "auth.py contains authentication" and move to reading the file instead of searching again.

Challenge 3: Separating implementation from references. A search result may return both auth.py (which defines AuthenticationService) and app.py (which just imports it). The agent needs code analysis, not simple keyword matching, to tell the two apart.

Final Result — and a Current Limitation

For this specific demo question, the agent produces:

{
 "answer": "Authentication is implemented in auth.py",
 "classes": ["AuthenticationService"],
 "functions": ["login", "authenticate"]
}

I want to be upfront about where this stands today: the search, read, and analyze steps are genuinely general-purpose — they work against any Python codebase. The final answer-generation step, however, is currently scoped to authentication-style questions specifically; it doesn't yet generalize its explanation to arbitrary questions the way the reasoning steps before it do. Making that synthesis step question-agnostic is next on my list.

Future Improvements

Some areas I want to explore next:

Generalize the answer-generation step beyond authentication-style questions
Integrate Git repositories directly
Generate dependency graphs
Understand application architecture
Connect Jira and documentation systems
Automated pull request reviews
Code migration assistants

Conclusion

Building an AI coding agent showed me that the biggest difference between a chatbot and an agent is not the language model itself.

The difference is the ability to:

plan
use tools
gather evidence
reason over observations
decide when enough information is available

RAG helps an AI find information. Agents help an AI perform tasks. The next generation of developer assistants will combine both — and connecting this agent to real enterprise knowledge retrieval is exactly where I'm headed next.

Github: https://github.com/srirdeevi/ai-coding-agent

Beyond Chatbots: Wrapping My RAG Agent in an MCP Server

Sri Deevi — Fri, 17 Jul 2026 00:35:55 +0000

In my last post, I walked through a RAG pipeline that answers questions from a company policy document. The next question I wanted to answer: what happens when I want other AI systems to use that same capability, without hardcoding a Python import?

That's what pulled me into building an MCP server. In this article, I will explain how I built a custom MCP server that exposes tools to AI agents and how this architecture enables more powerful enterprise AI applications.

What is MCP?

Model Context Protocol is an open protocol that standardizes how AI applications communicate with external tools and data sources.

Instead of creating custom integrations for every AI application, MCP provides a common interface where servers expose tools that AI clients can discover and invoke.

Technology Stack

Python, MCP SDK, Ollama / Local LLM, AI Agent Client, FastAPI (optional integration).

What's actually in the server

I built this with FastMCP, and it currently exposes four tool categories:

Calculator tools — calculator_add and calculator_multiply.
search_company_documents — the RAG agent from my last project, but now reached over HTTP instead of a direct function call. The MCP tool sends a request to the RAG agent's FastAPI /search endpoint and returns the answer. This one requires an api_key parameter.
get_employee_leave — looks up an employee's remaining PTO from an in-memory store. Simple lookup, no external calls.
get_ticket_information — same pattern, returning ticket status, assigned team, and priority.

Each tool is registered with a @mcp.tool() decorator, which is what makes FastMCP genuinely pleasant to work with.

Challenges I Encountered

The calculator, employee, and ticket tools were straightforward pure functions with no external dependencies. The RAG search tool was a different problem entirely, and it was the hardest part of this whole project.

My RAG agent runs as its own FastAPI service, on its own process, with its own vector store loaded into memory. The MCP server doesn't share any of that — it has to reach across a real network boundary with a plain requests.get() call to http://127.0.0.1:8000/search.

Handling real failure modes like connection refused if the RAG service isn't up, timeouts, a response shape that has to be parsed correctly on the other side.

Future Enhancements

Extend authentication to the employee and ticket tools, so the protection is uniform rather than partial
Replace the in-memory employee/ticket dictionaries with a real data source.
Eventually, wire this MCP server in as the tool layer for a multi-agent workflow — letting a research agent and a writer agent share the same discoverable tool set instead of each having their own direct integrations

Key Takeaways

Building an MCP server changed my perspective on AI applications. The future of enterprise AI is not only about generating better responses. It is about creating systems where AI agents can safely interact with real-world tools and business capabilities.

MCP provides an important foundation for building these next-generation AI applications.

Github: https://github.com/srirdeevi/mcp-server

From Documents to Intelligent Answers: Building a RAG Agent from Scratch & Lessons Learned

Sri Deevi — Tue, 14 Jul 2026 20:16:45 +0000

Artificial Intelligence applications are rapidly moving beyond simple question-answering systems. Modern enterprise AI assistants need to understand internal documents, retrieve accurate information, and provide reliable answers based on company knowledge.

I started building agentic AI systems from scratch — not to theorize about them, but to actually write the code, break it, and understand it from the inside out. This post walks through the second project in that journey: a Retrieval-Augmented Generation (RAG) system, what I built, what tripped me up, and where I'm taking it next.

What is RAG?

Retrieval-Augmented Generation combines two capabilities:

Retrieval: The system searches a knowledge base and finds relevant information related to the user's question.

Generation: The retrieved information is provided as context to an LLM, which generates a response based on that knowledge.

Instead of asking an LLM to remember everything, RAG allows the model to access external knowledge dynamically.

Technologies Used
Python, LangChain, Ollama (Local LLM), Embeddings, Vector Database, FastAPI.

What I Built

The core idea is to build a system that answers questions using only the content of a document, rather than whatever the underlying model already "knows."

Documents → Text Splitter → Embeddings → Vector Store → Retriever → LLM → Answer

Document loading — a company policy document, loaded with LangChain's TextLoader

Text Splitting — split into 200-character chunks with 50-character overlap, using RecursiveCharacterTextSplitter

Create Embeddings — generated with sentence-transformers/all-MiniLM-L6-v2 via HuggingFaceEmbeddings

Vector store — persisted in Chroma

Retrieval — top-2 most relevant chunks pulled per question

Generation — a strict prompt template that instructs the model to answer only from the retrieved context, run through Ollama's tinyllama.

Lessons Learned

Building a RAG system taught me that successful AI applications are not only about selecting a powerful LLM. The quality of the final answer depends heavily on:

Document quality

Chunking strategy

Retrieval accuracy

Prompt design

Evaluation methods

Conclusion

RAG provides a practical foundation for building enterprise AI assistants that can use private knowledge while reducing hallucination risks. This project became the foundation for my next experiments with multi-agent workflows, MCP servers, and autonomous AI systems.

Source Code: https://github.com/srirdeevi/agentic-ai-portfolio