DEV Community: Divya Munnuru

Building AgriMind: My Journey into Agentic AI – Part 4

Divya Munnuru — Sat, 18 Jul 2026 16:03:09 +0000

Making AI Smarter with RAG: Bringing Trusted Agricultural Knowledge into the Conversation

In the previous parts of this series, I explored how Agentic AI can solve real-world agricultural problems, how I designed MCP servers to expose farming capabilities, and how adding Memory helped the AI remember previous interactions with farmers.

While Memory made conversations more personal, I soon discovered another limitation.

The AI could remember who the farmer was.

But it didn't always know where to find the most relevant and trustworthy information.

That led me to another fascinating concept that's becoming an essential part of modern AI systems—Retrieval-Augmented Generation (RAG).

Why Memory Wasn't Enough

Imagine a farmer asking:

"What government schemes am I eligible for?"

A Large Language Model can certainly explain what PM-KISAN or crop insurance is.

But eligibility depends on several factors:

State
District
Land size
Previous crop
Type of subsidy requested

These details change over time, and government schemes are updated regularly.

Relying solely on an LLM's training data isn't always the best approach.

The AI needs access to current, structured, and trusted information before generating a response.

That's exactly where RAG becomes useful.

Understanding RAG

Before implementing it, I assumed RAG was simply another AI buzzword.

Once I started building it, I realized the idea is surprisingly simple.

Instead of expecting the LLM to remember everything, we first retrieve the most relevant information from a knowledge source.

Only then do we ask the model to generate a response using that retrieved context.

The workflow becomes:

Farmer Question
        │
        ▼
Retrieve Relevant Knowledge
        │
        ▼
Provide Context to LLM
        │
        ▼
Generate Personalized Response

Instead of guessing, the AI answers using information that it has just retrieved.

My Design Decision

One thing I deliberately chose not to implement was a traditional vector database.

Most RAG tutorials immediately introduce embeddings, semantic search, and vector stores.

While those are excellent approaches for unstructured documents, my use case was different.

Government agricultural schemes already contain structured attributes such as:

Eligible states
Supported crops
Maximum land size
Benefits
Scheme description

Rather than adding unnecessary complexity, I built a lightweight local retrieval engine using a structured JSON knowledge base.

Sometimes the simplest solution is the most appropriate.

Building a Government Scheme Knowledge Base

I created a local database containing agricultural schemes such as:

PM-KISAN
PMFBY (Crop Insurance)
PMKSY (Irrigation)
State-specific agricultural subsidies

Each scheme stores important eligibility information including:

State
Supported crop
Maximum farm size
Benefits
Description

Instead of searching documents manually, the application filters this structured data based on the farmer's profile.

Bringing Memory and RAG Together

One feature I really enjoyed implementing was combining the work from Part 3 with RAG.

The frontend already knows the farmer's profile from previous interactions.

Whenever the farmer asks:

"What subsidies am I qualify for?"

the application automatically shares contextual information such as:

State
District
Farm size
Previous crop

The farmer doesn't have to repeat these details.

The retrieval engine uses this context to identify matching schemes before the LLM generates its answer.

This made the entire experience feel much more natural.

How the Retrieval Works

The flow is intentionally simple.

Farmer asks about subsidies
          │
          ▼
Retrieve Farmer Profile
          │
          ▼
Filter Local Scheme Database
(State + Crop + Land Size)
          │
          ▼
Retrieve Matching Schemes
          │
          ▼
Inject Retrieved Schemes into Prompt
          │
          ▼
LLM Generates Personalized Response

The AI no longer responds with generic information.

Instead, it explains the schemes that are actually relevant to that particular farmer.

Adding ReAct Reasoning

Since AgriMind follows an Agentic AI approach, I wanted the reasoning process to be transparent.

Whenever a scheme-related question is detected, the agent internally follows a simple ReAct workflow.

For example:

Thought:
The user is asking about government schemes.

Tool:
Retrieve matching schemes from the local knowledge base.

Observation:
Found PM-KISAN and state-specific irrigation subsidy.

Response:
Explain eligibility and benefits in simple language.

Although the retrieval happens behind the scenes, this approach helped me understand how reasoning and retrieval work together in an AI Agent.

Designing for Reliability

Another important goal of this project was ensuring that the application remains useful even if the LLM becomes unavailable.

For that reason, I implemented a fallback mode.

If the LLM API is offline, the retrieval engine still filters the scheme database and returns a friendly summary of matching schemes.

This reinforced another lesson for me:

Good AI systems should continue providing value even when external AI services are unavailable.

What I Learned

Implementing RAG completely changed my perspective.

Initially, I thought RAG was mainly about embeddings and vector databases.

After building this feature, I realized that RAG is fundamentally about retrieving the right knowledge before generating an answer.

The retrieval mechanism should fit the problem you're solving.

For structured agricultural data, a lightweight retrieval engine was more than enough.

The goal isn't to use the most advanced technology.

The goal is to deliver the right information to the user.

Looking Ahead

At this point, AgriMind can:

Reason using MCP tools
Remember previous interactions
Retrieve trusted agricultural knowledge

The next feature I wanted to explore was even more exciting.

What if a farmer could simply upload a picture of an infected crop leaf and receive an instant diagnosis?

That became the inspiration for the next phase of the project.

In Part 5, I'll share how I integrated Vision AI into AgriMind to detect crop diseases from uploaded images and combine computer vision with Agentic AI to provide treatment recommendations.

As always, this project continues to be my way of learning modern AI by building real-world applications rather than just reading documentation.

Building AgriMind: My Journey into Agentic AI – Part 3

Divya Munnuru — Sat, 04 Jul 2026 16:33:17 +0000

Giving AI a Memory: Building Context-Aware Conversations for Farmers

In the first two parts of this series, I shared why I chose Agriculture as the domain to explore Agentic AI and how I designed MCP Servers to expose agricultural capabilities like crop recommendations, disease detection, mandi prices, and conversational assistance.

As I continued using the application, I noticed something interesting.

The AI was intelligent enough to answer questions.

It could detect diseases from crop images.

It could recommend crops.

It could even generate reports.

But every time I started a new conversation, it behaved as if we had never spoken before.

The farmer had to explain everything again.

That made me realize something important.

An AI Agent that forgets every conversation doesn't feel like an assistant—it feels like a search engine.

That became my motivation for implementing Memory and Context in Kisan Mitra AI.

Why Memory Matters

Imagine visiting your family doctor.

Every appointment begins with the doctor asking:

What's your name?
What illness did you have last month?
Which medicines were prescribed?
Have you recovered?

That would be frustrating.

Doctors become effective because they remember your medical history.

The same principle applies to AI.

A farmer shouldn't have to repeatedly explain:

Which crop they're growing
Which disease was detected previously
What treatment was recommended

An intelligent farming assistant should already know.

The Problem I Wanted to Solve

Let's imagine a farmer uploads an image of a tomato leaf.

The AI detects:

Crop:
Tomato

Disease:
Early Blight

The farmer receives treatment recommendations.

Everything works perfectly.

Now imagine the same farmer comes back three days later and asks:

"How do I prevent this from happening again?"

Without memory, the chatbot has no idea what "this" refers to.

It asks the farmer to upload the image again or explain the disease from scratch.

That isn't a natural conversation.

My Approach

For this learning project, I wanted to keep the implementation simple while demonstrating the concept of persistent memory.

Instead of introducing databases or vector stores immediately, I implemented a lightweight JSON-based memory store.

Each farmer is identified using their email address.

Whenever a disease is successfully detected from an uploaded image, the application stores:

Farmer Email
Last Crop
Last Detected Disease

For example:

{
  "farmer@email.com": {
    "last_crop": "Tomato",
    "last_disease": "Early Blight"
  }
}

Although simple, this creates persistent memory across chatbot sessions.

Bringing Context into the Conversation

Storing memory alone isn't enough.

The AI also needs to use that information.

Whenever the farmer opens the chatbot, the application checks whether previous memory exists.

If it does, the chatbot welcomes the farmer with something like:

Welcome back! I remember that your Tomato crop suffered from Early Blight during your last visit. How is your crop doing today?

Immediately, the conversation feels more personal.

More importantly, the previous crop and disease are injected into the AI's system prompt before sending the request to the LLM.

Instead of starting from zero, the model now has context.

How the Flow Works

The memory workflow is straightforward.

Farmer uploads crop image
          │
          ▼
Disease Detection
          │
          ▼
Store Crop + Disease
(using farmer email)
          │
          ▼
Persistent JSON Memory
          │
          ▼
Next Chat Session
          │
          ▼
Retrieve Previous Memory
          │
          ▼
Inject Context into LLM Prompt
          │
          ▼
Context-Aware Response

This small enhancement dramatically changes the user experience.

A Practical Example

First Conversation

Farmer:

My tomato leaves have brown spots.

AI:

Your tomato crop is affected by Early Blight.

The diagnosis is saved.

A Few Days Later

Farmer:

How can I prevent this?

Instead of asking,

Which crop are you talking about?

the AI already knows.

It responds:

Since your tomato crop previously suffered from Early Blight, regular monitoring, proper spacing between plants, and avoiding overhead irrigation can significantly reduce future infections.

That's the difference context makes.

What I Learned

Before implementing this feature, I assumed "memory" simply meant saving conversations.

After building it, I realized it's much more than that.

Memory allows an AI Agent to:

Continue conversations naturally
Reduce repetitive questions
Personalize recommendations
Build trust with users

Even a small amount of remembered information makes the assistant feel far more intelligent.

Looking Ahead

This implementation is intentionally lightweight because my goal was to understand the fundamentals.

In the future, I plan to extend memory much further.

Instead of remembering only the last diagnosis, the AI could maintain a complete farming profile, including:

Soil type
State and district
Current crops
Disease history
Previous recommendations
Seasonal farming activities
Irrigation methods

Combined with Agentic AI, this opens the door to highly personalized agricultural assistance.

Imagine an AI that says:

"Last Kharif season, your groundnut crop experienced Leaf Spot disease. Based on the current weather forecast and your farm history, I recommend preventive measures this week."

That's no longer just a chatbot.

It's beginning to behave like a digital farming advisor.

What's Next?

Now that the AI can remember previous interactions, the next challenge is making it knowledgeable.

Memory helps the AI remember the farmer.

But what if the AI needs to answer questions using trusted agricultural documents, government advisories, or research papers instead of relying only on its training?

That's where Retrieval-Augmented Generation (RAG) comes in.

In Part 4, I'll share how I integrated RAG into Kisan Mitra AI so that the assistant can retrieve information from agricultural knowledge sources and provide more accurate, grounded, and reliable recommendations.

As always, I'm learning by building, and I hope this series helps others who are exploring the exciting world of Agentic AI.

Building AgriMind: My Journey into Agentic AI – Part 2

Divya Munnuru — Fri, 03 Jul 2026 14:39:38 +0000

Designing MCP Servers for an Agriculture AI Assistant

In my previous blog, I shared why I chose Agriculture as the domain for learning Agentic AI and how I started building Kisan Mitra AI (AgriMind) as a practical project instead of just experimenting with isolated AI examples.

As I continued building the application, I came across another topic that is gaining a lot of attention in the AI ecosystem—Model Context Protocol (MCP).

Everywhere I looked, developers were discussing MCP as the standard way for AI Agents to interact with external tools.

Naturally, I wanted to understand it beyond the theory.

So instead of reading documentation alone, I decided to integrate MCP directly into my Agriculture AI Assistant.

Why MCP?

When we think about an AI-powered farming assistant, it quickly becomes clear that a single Large Language Model isn't enough.

A farmer may ask questions like:

Which crop should I grow this season?
Can you identify the disease from this leaf image?
What are today's mandi prices?
Which government schemes am I eligible for?

Some of these require reasoning.

Others require external data.

Some need image analysis.

Others need business logic.

Instead of embedding everything inside one application, MCP allows us to expose each capability as a reusable tool that an AI Agent can discover and invoke whenever needed.

That modular approach immediately made sense to me.

My MCP Architecture

For Kisan Mitra AI, I built a dedicated MCP Server using FastMCP.

Instead of exposing REST endpoints directly to the AI Agent, I exposed agricultural capabilities as MCP tools.

The architecture looks like this:

This separation made the application much cleaner and easier to extend.

Instead of teaching the AI how to perform every task, the AI simply decides which tool should solve the problem.

The Four MCP Tools I Implemented

To begin with, I kept the design intentionally simple.

🌾 Crop Recommendation Tool

The first tool helps farmers decide which crop is best suited for their land.

The AI collects:

State
District
Soil type
Cropping season
Irrigation level
Water source

The MCP server then generates crop recommendations, expected yield, fertilizer guidance, and even creates a professional PDF report.

If the farmer provides an email address, the report is automatically sent through Gmail.

This was one of my favourite features because it demonstrates that an AI Agent can not only answer questions but also complete useful business tasks.

🔬 Disease Detection Tool

One of the most exciting parts of the project was integrating Vision AI.

The farmer uploads an image of a crop leaf.

The AI Agent invokes the Disease Detection MCP tool.

The tool analyses the image and returns:

Crop name
Disease
Confidence score
Symptoms
Organic treatment
Prevention tips

Instead of receiving a generic response, the farmer gets structured and actionable recommendations.

📈 Mandi Price Tool

Farmers often want to know whether it is the right time to sell their crops.

For this, I created a Mandi Price MCP tool.

The tool provides:

Current market prices
Minimum price
Maximum price
Modal price
Daily price trend

Although I currently use simulated market data for learning purposes, the same architecture can easily integrate with real government market APIs in the future.

💬 Agricultural Chat Tool

This became the central intelligence of the application.

Rather than simply forwarding every question to an LLM, I implemented a routing workflow.

Depending on the farmer's question, the AI decides whether it should:

Detect crop disease
Retrieve mandi prices
Search government schemes
Answer general farming questions

This was my first experience building an AI Agent that reasons before taking action, and it helped me understand why everyone is excited about Agentic AI.

One Feature I Really Enjoyed Building

One feature that made the project feel much more complete was automatic report generation.

After generating crop recommendations, the system creates a professional PDF report and sends it directly to the farmer's Gmail account.

From the farmer's perspective, the experience is seamless:

Ask a question
Receive recommendations
Get a detailed report in your inbox

This small addition made the AI feel less like a chatbot and more like a digital farming assistant.

Designing for Reliability

While working on this project, I also wanted to ensure the application remained useful even if an AI service became unavailable.

So I implemented graceful fallbacks.

If the LLM isn't available:

Crop recommendations fall back to rule-based logic.
Disease detection falls back to a local disease database.
Chat responses use predefined agricultural knowledge.

This taught me an important architectural lesson:

Good AI systems should degrade gracefully instead of simply failing.

What I Learned

Implementing MCP completely changed the way I think about AI applications.

Initially, I thought AI Agents were just LLMs with better prompts.

After building this project, I realised that the real strength lies in orchestration.

The AI isn't expected to know everything.

Instead, it reasons about the user's request, decides which tools are needed, gathers information, and then generates a meaningful response.

That shift from "answer generation" to "problem solving" is what makes Agentic AI so powerful.

What's Next?

One thing still bothered me while testing the application.

Every time the farmer started a new conversation, the AI forgot everything.

It asked the same questions again.

That led me to explore another fascinating topic—Memory.

In the next part of this series, I'll share how I implemented Memory and Context so that the Agriculture AI Assistant can remember previous conversations, disease history, crop details, and provide much more personalized recommendations.

Stay tuned for Part 3 – Implementing Memory in AI Agents, where I'll explore how memory transforms an AI chatbot into a true digital farming companion.

If you've been experimenting with MCP or Agentic AI, I'd love to hear about your experiences. Let's continue learning together.

Building AgriMind: My Journey into Agentic AI - Part1

Divya Munnuru — Mon, 29 Jun 2026 15:20:25 +0000

Why Agriculture Needs Agentic AI

Over the past few months, one topic has been impossible to ignore in the AI world—Agentic AI.

Whether it's conferences, LinkedIn discussions, tech blogs, or AI communities, everyone seems to be talking about AI Agents. Like many architects, I found myself asking the same question:

"What makes an AI Agent different from a chatbot, and where can it truly create value?"

Instead of just reading articles or watching demos, I decided to learn by building something from scratch.

Choosing the right use case was probably the most important decision. I wanted to work on a problem that was meaningful, technically challenging, and capable of showcasing modern AI concepts like Agentic AI, Memory, RAG, Vision AI, and Model Context Protocol (MCP).

That's when I started exploring the agriculture domain.

Why Agriculture?

Agriculture is one of the most important sectors in India and supports the livelihood of millions of people. Farmers make countless decisions throughout a crop's lifecycle—from selecting the right crop and monitoring weather conditions to identifying diseases and deciding when to harvest or sell their produce.

While information is available from many different sources, it is often scattered across websites, government portals, research papers, weather services, and local experts. Accessing the right information at the right time isn't always easy.

This made me think:

What if an AI Agent could act as a digital farming assistant—bringing together all this information and helping farmers make better decisions through simple conversations?

That idea became the foundation of my learning project.

Why Not Just Use an LLM?

Large Language Models are incredibly powerful at answering questions, but agriculture often requires more than general knowledge.

For example:

A crop recommendation depends on the farmer's state, soil type, irrigation level, and cropping season.
Disease diagnosis requires analyzing an uploaded image.
Weather advisories need current forecasts.
Government schemes and market prices change over time.

An AI Agent can reason about the farmer's request, decide which tools to use, retrieve the latest information, and then generate a personalized response.

Instead of simply answering questions, the agent performs actions and combines information from multiple sources before responding.

That's what makes Agentic AI so exciting.

The Learning Journey

Rather than building everything at once, I'm approaching this project feature by feature.

The Agriculture AI Assistant I'm developing will gradually evolve to include:

Crop recommendations based on soil, season, and irrigation
Disease detection using uploaded crop images
Personalized farmer memory
Retrieval-Augmented Generation (RAG) using agricultural knowledge
MCP-based tool integration
Email reports and notifications
Multilingual conversational support

My goal isn't just to build another chatbot. I want to understand how different AI building blocks work together to solve a real-world problem.

Why This Project Excites Me

As a Solution Architect, I've spent years designing enterprise solutions. Agentic AI feels like the next evolution in application architecture.

We're moving from applications that simply respond to user requests to systems that can reason, plan, retrieve information, invoke tools, and collaborate to complete tasks.

Learning these concepts through a practical project has been far more rewarding than simply reading documentation.

If this journey also helps me contribute—even in a small way—to building technology that could benefit farmers across our country, that makes the learning even more meaningful.

What's Next?

This is just the beginning.

In the next part of this series, I'll share how I implemented Model Context Protocol (MCP) for this Agriculture AI Assistant, how I designed dedicated MCP servers for different agricultural capabilities, and why MCP is becoming an important building block for modern AI Agent architectures.

Vercel Deployed URL - https://agri-assistant-drab.vercel.app/

Stay tuned for Part 2 – Designing MCP Servers for Agriculture.

I'd love to hear your thoughts, suggestions, or ideas. If you're also exploring Agentic AI, let's learn and build together.