What if you could ask your analytics dashboard a simple question:
"Why did sales decrease last month?"
Instead of manually filtering charts, exploring datasets, and writing database queries, imagine a system that could understand your question, generate a query, validate it, analyze the results, and present the findings with a visualization.
That idea inspired me to build AgentVerse, an agentic analytics platform that combines AI agents, MongoDB, and the Model Context Protocol (MCP).
I built this project to explore how AI agents can make data analysis more interactive and how we can build systems that are not only intelligent but also easier to control, debug, and understand.
Here are some of the things I explored while building it.
🚀 What is AgentVerse?
AgentVerse is a natural-language analytics platform designed to let users explore data by asking questions in plain English.
For example, instead of writing a MongoDB query, a user could ask:
- Show monthly sales for the last 12 months.
- Show the top 5 products by revenue.
- Compare sales across different regions.
- Why did sales decrease last month?
The platform translates these questions into an analytics workflow.
At a high level, the workflow looks like this:
User Question
↓
Orchestrator Agent
↓
Analytics Query Agent
↓
Query Guardian
↓
MCP Server
↓
MongoDB
↓
Evidence Engine
↓
Insight Agent
↓
Visualization
The goal is not just to generate an answer. It is to make the process behind that answer more structured and observable.
Figure 1: AgentVerse architecture — showing how AI agents, Query Guardian, MCP, and MongoDB work together to transform natural-language questions into evidence-based insights.
🧠 Why use multiple agents?
A simple approach to building an AI analytics application might look like this:
User → LLM → Database → Answer
But this approach combines several responsibilities into one step. The system needs to understand the question, identify the relevant fields, generate a query, interpret the results, and decide how to present the answer.
For AgentVerse, I explored separating these responsibilities into specialized components.
- Orchestrator Agent: Understands the request and coordinates the workflow.
- Analytics Query Agent: Generates MongoDB aggregation pipelines.
- Query Guardian: Validates queries before execution.
- Evidence Engine: Performs deterministic calculations on query results.
- Insight Agent: Turns the available evidence into a natural-language explanation.
- Visualization: Selects an appropriate chart or other visual representation.
This separation makes each part easier to inspect and helps establish clearer boundaries between AI-generated decisions and normal application logic.
One important lesson: adding more agents does not automatically make a system better. Each component needs a clear purpose.
🔌 MCP: Connecting AI Agents to Data
One of the concepts I explored in this project was Model Context Protocol (MCP).
I wanted a structured way for the AI workflow to interact with database capabilities without giving the model unrestricted access to MongoDB.
Instead of connecting the agent directly to the database, the architecture uses an MCP server as an intermediary:
AI Agent
↓
MCP Server
├── get_schema
└── execute_query
↓
MongoDB
The get_schema tool helps the workflow discover the available data structure, while execute_query provides a controlled way to request query execution.
This separates two important responsibilities:
- AI reasoning: Understanding the question and proposing a query.
- Data access: Validating and executing database operations through application-controlled tools.
For me, this was one of the most interesting architectural aspects of the project. MCP is not just about connecting an AI model to tools; it also provides a structured interface between the model and external capabilities.
🛡️ The challenge: Can we trust AI-generated queries?
Generating a MongoDB aggregation pipeline is only one part of the problem.
The next question is: Should we execute whatever the LLM generates?
No. A generated query can contain invalid fields, unsupported operators, or operations that are inappropriate for an analytics application.
To address this, I implemented a component called Query Guardian.
Its responsibility is to validate generated queries before they reach the database.
The validation process checks things such as:
- Allowed aggregation stages and operators
- Collection and field names
- Pipeline structure and length
- Result limits
- Forbidden operations
The analytics workflow is designed around read-only query execution rather than allowing the AI to modify stored data.
The general flow is:
LLM Generates Query
↓
Query Guardian
↓
Validation
↓
┌───┴────┐
↓ ↓
Valid Invalid
↓ ↓
Execute Repair or
Reject
Invalid queries can go through a controlled repair and re-validation process.
This taught me an important lesson:
LLM output should be treated as untrusted input, not executable truth.
The model can propose an action, but application code should enforce the rules governing whether that action is allowed.
📊 From a question to an insight
Let's consider the question:
"Why did sales decrease last month?"
Here is how the workflow is designed to handle it.
1. Understand the question
The Orchestrator identifies the request as a root-cause analysis task.
2. Discover the schema
The workflow retrieves the relevant database structure through MCP.
3. Generate the query
The Analytics Query Agent creates a MongoDB aggregation pipeline to retrieve the required data.
4. Validate and execute
Query Guardian checks the pipeline before the MCP execution tool sends the permitted operation to MongoDB.
5. Analyze the evidence
The Evidence Engine calculates measurable changes in the returned data, such as differences between periods or across regions and product categories.
6. Generate an explanation
The Insight Agent uses the available evidence to produce a natural-language explanation.
There is an important distinction here: identifying a region with declining sales does not automatically prove that the region caused the overall decline.
The system should distinguish observed changes from possible explanations instead of presenting unsupported causal claims as facts.
That distinction matters whenever AI is used for data analysis.
📈 Turning insights into visualizations
An analytics response should be more than a paragraph of text.
AgentVerse uses a React frontend with Recharts to present analytical results visually.
Depending on the data and the analytical task, suitable visualizations might include:
| Analytical task | Possible visualization |
|---|---|
| Sales trends over time | Line chart |
| Comparing regions | Bar chart |
| Showing category proportions | Pie chart |
| Displaying a single metric | KPI card |
The overall flow is:
Question
↓
Query
↓
Data
↓
Evidence
↓
Insight
↓
Visualization
The aim is to help users understand both the result and the information supporting it.
🔍 Making the workflow observable
Another thing I wanted to explore was how to debug an application where several AI-related steps happen before the final response.
If the system returns an incorrect result, inspecting only the final answer may not tell us where the problem occurred.
Was the intent misunderstood? Was the query incorrect? Did validation reject something? Did the database return unexpected data? Was the explanation inconsistent with the evidence?
AgentVerse includes an execution-trace interface that helps expose the stages of the analytics workflow.
The backend also includes audit logging for information such as the request, generated pipeline, validation status, returned row count, and execution duration.
Together, these features help make the workflow easier to inspect and debug.
🧰 Tech stack
Here is the technology stack I used for AgentVerse.
Frontend
- React
- TypeScript
- Vite
- Tailwind CSS
- Recharts
- Axios
Backend
- Node.js
- Express
- TypeScript
- MongoDB
- Mongoose
AI and tools
- Ollama
- LLM-based agents
- Model Context Protocol (MCP)
- Structured JSON generation
- Multi-agent orchestration
I used Ollama to work with a locally hosted language model. The model and Ollama endpoint can be configured through environment variables, which is useful when experimenting with different local setups.
💡 What I learned
Building AgentVerse helped me explore several practical challenges in agentic AI development.
1. Not everything needs an LLM.
Query validation, result limits, percentage calculations, and other deterministic operations are better handled by application code.
2. Generated output needs validation.
A query that looks correct is not necessarily safe or valid. The application needs independent checks before execution.
3. More agents mean more complexity.
Each additional component introduces communication, debugging, and failure-handling requirements. Agents should have clear responsibilities.
4. Observability matters.
Execution traces and audit logs make it easier to investigate what happened between the user's question and the final answer.
5. Evidence matters more than a fluent explanation.
An answer can sound convincing without being correct. Analytical explanations should be grounded in actual query results and distinguish evidence from assumptions.
These are areas I will continue exploring as I improve the project.
🚧 What's next?
There are several areas I would like to develop further:
- Supporting additional data sources
- Expanding MCP tool capabilities
- Improving query validation and error handling
- Evaluating the accuracy of generated queries and insights
- Exploring streaming responses
- Improving anomaly detection
- Strengthening observability
- Exploring deployment options
One question I particularly want to investigate is:
How can we reliably evaluate an agentic analytics system?
A fluent response is not necessarily an accurate response. Measuring the correctness of the query, the quality of the evidence, and the reliability of the final explanation is an important part of building a useful system.
🎯 Final thoughts
Working on AgentVerse has encouraged me to think beyond simply choosing an LLM and writing a prompt.
I now pay more attention to the architecture surrounding the model: the tools it can access, the validation rules it must follow, the evidence used to generate answers, and the mechanisms that help us understand failures.
LLM
↓
Tools
↓
Validation
↓
Data
↓
Evidence
↓
Insights
↓
Observability
For me, that is an important part of building agentic applications: combining the flexibility of AI with the reliability of well-designed software.
AgentVerse is an ongoing project, and I look forward to exploring these ideas further.
If you've worked with AI agents or MCP, what has been the most challenging part for you: orchestration, tool integration, security, or evaluation?
I'd love to hear your thoughts!
Tech stack: React · TypeScript · Node.js · Express · MongoDB · Ollama · MCP · Recharts
Top comments (1)
Great work buddy, build and learn more 💛.