The idea behind NEXUS started with the curiosity. As a team, we wanted to explore the Model Context Protocol (MCP), a concept we had recently come across. Rather than limiting ourselves to reading about it or experimenting with random examples, we wanted to understand how it worked by building something around it. We needed a project that would give us a practical reason that everyone could use in their regular life.

That led us towards personal productivity.

We wanted to build somethinng that could do more than simply responding to questions. Most conversational AI experiences revolve around asking questions and getting answers. With NEXUS, our intention was to explore a different kind of interaction: a system that could understand what a user wants and carry out the appropriate task using connected tools. We also wanted it to retain useful information about the user, making interaction more useful over time.

The idea was to bring everyday productivity activities into one place. From managing to-do lists and reminders to using Whatsapp for timely notifications, we wanted NEXUS to be useful in situations student could actually relate to. For example, a student could recieve a reminder about their upcoming project deadline, along with relevant notes before scheduled time.

Building this experience also brought us to another engineering consideration that is, relibality. As, the system depends upon LLM to understand and process instructions, we explored a Dual-LLM architecture with primary model and a fallback model. It was intended to make NEXUS less dependent on single provider when a request fails.

Basically, NEXUS became a way for us to explore how AI models, tools connection and their workflow could work together to make everyday tasks easier.

What NEXUS Actually Does

So, at the end of the day, we wanted to build something genuinely useful. Something that could handle everyday tasks rather than just respond to questions.

We started by focusing on few things that people deal with regularly Managing tasks, keeping track of upcoming deadlines, remembering important things and staying updated without requiring to check multiple applications throughout the day.

Managing Everyday Tasks

One of the basic thing we wanted NEXUS to handle was tasks management. User could easily tell the assistant what they need to do, NEXUS couple help them manage those tasks through a connected To-Do system.

For example, instead of opening a separate application to add a task, a user could simply ask NEXUS to add an upcoming assignment or mark an existing task as completed or delete a task completely from list.

Reminders and Notifications

We also wanted NEXUS to help users keep track of things that they might forget.

Think of a student working on multiple assignments, preparing for exams and managing projects at the same time (side note: why does this feel so relatable?). It's easy to forget something important when everything is happening together.

We wanted NEXUS to make this a little easier by reminding users through timely WhatsApp notification.

Interacting with External tools

Another thing we wanted to explore was how an AI assistant could interact with tools outside its own environment.

For us, this was important part of our project because we didnt wanted NEXUS to be limited to generating just responses. We wanted it to be capable of interacting with external services and performing operations based on what the user requested.

This included working with files and directories, managing tasks and retrieving information through web search.

Making Interactions More Contextual

We also explored the idea of making interactions more meaningful overtime.

A useful assistant shouldnt necessarily treat every conversation as something completely new. Retaining useful information about users could help make future interactions more contextual and reduce the need to repeat the same details.

This was another part of what we wanted to explore while building NEXUS.

Bringing Everything Together

If we look at all features individually they seem simple, but bringing them together into one assistant was what made our project more interesting.

We werent trying to build another chatbot with long list of features. We wanted to understand how an AI model could work with different tools, coordinate their execution and turn users' requests into actions.

Understanding the Architecture

Now that we have covered what we wanted NEXUS to do, lets look at how we approached building it.

One of the things we realised early was that connecting an LLM to a few tools wouldnt be enough. We needed a way for different components to communicate with each other, handle requests and coordinate their operations.

To make that easier to understand, here's a high-level overview of different parts of NEXUS:

This is a conceptual overview of the architecture, not a representation of the exact execution sequence for every request. The LLM provider act as a primary and fallback options, while the three MCP servers provide separate capabilities that NEXUS can use when required.

NEXUS Architecture Overview

Lets go through the main components one by one:

1. Application Layer:

This is where interaction begins.

We used Streamlit to build the interface, providing a simple way for users to communicate with the assistant and submit their requests. Rather than requiring users to interact with individual tools or services directly, the interface brings these interactions into one place.

When a user submits a request, it moves into the NEXUS application, where the agent takes responsibility for coordinating the next steps.

2. Agent and Orchestration Layer:

At the centre of NEXUS is the agent responsible for coordinating the different components.

A user might ask NEXUS to create a task, search for something online or perform a file-related operation. This requests require different capabilities, so the application needs way to determine what should happen next.

So, agent and orchestration layer connects the language model's understanding of the request with the tools available through the MCP client.

Instead of implementing every operation directly inside the main application, we kept the responsibility separated. This makes overall system easier to organize and give individual component space to develop accordingly.

3. Dual-LLM Architecture: Gemini and Groq:

Another important part of the architecture is the use of two LLM providers.

We configured Google gemini as the primary model and Llama 3.3 70B hosted through Groq as the fallback model (side note: This is the part that I worked on).

The reason behind this was to add reliability. Depending entirely on a single provider can become a limitation when that provider fails in fetching.

The two models didnt process every request simultaneously. Gemini handles requests as the primary model, while Groq-hosted model serves as a fallback when required.

4. MCP Client:

The MCP client acts as the communication bridge between the NEXUS application and its MCP servers,

We chose to use the Model Context Protocol so that the application could communicate with different tools through a common interface.

In NEXUS, the MCP client connects with three specialized MCP servers, each responsible for different set of operations.

5. MCP Servers:

We separated the tool integrations into three MCP servers instead of combining everything into one. Each server focuses on a specific responsibility.

• File System MCP Server: The File system MCP server handles operation through files and directories. It allows NEXUS to interact with files inside its designated workspace. This includes operations such as reading files, deleting files, writing files and managing related tasks.
• To-Do MCP Server: The To-Do MCP server is responsible for task management. We didnt wanted NEXUS to simply generate to-do lists. We wanted it to interact with actual task data. This server provides task-related capabilities such as creating tasks and marking them as completed and also deleting if required. We used SQLite to store and access task related information.
• Web Search MCP server: The Web Search MCP server provides NEXUS with access to web search capabilities. For this integration, we used DuckDuckGo to fetch relevant information from when a request is made for it.

6. Human-in-the-Loop:

Giving full control to an assistant to perform operations? No! So, we added a extra layer through which users could review the actions made by the agent that includes modification of data.

We basically included a confirmation step before execution. This allows users to review the intended actions and decide whether to proceed. It may be a small part of architecture but it is important because automation should not take all the control away from the users.

Brining the Architecture Together

As we know that every component in NEXUS have their own responsibility.The Streamlit interface handles user interaction, the agent coordinates requests, the LLM layer provides reasoning and the MCP clients connects the application to its three specified servers.

Together, these components form NEXUS.

But, this bring us to another question: why did we use MCP to connect this tools? why not build custom integrations for all services?

To understand this, lets take a closer look at MCP and its role in NEXUS.

Why Model Context Protocol (MCP)?

While building NEXUS we wanted to explore how AI application could interact with external tools in a more structured way.

One way is by writting individual integration for every service and connect them directly to the main application. This works, but in future if we integrate more tools, managing them becomes a complicated task.

So, the other way is by using Model Context Protocol (MCP).

What is MCP?

The Model Context Protocol is a open protocol, which standardizes how application communicates with external tools and data sources (side note: Ask our team lead what MCP is and there's a good chance you will hear, "They are basically like lego blocks that you can attach to your application").

MCP follows a client-server architecture with three main concepts:

• MCP Host: The application that provides the environment for interaction with AI models and MCP integrations.
• MCP Client: The component responsible for maintaining communication with an MCP Server.
• MCP Server: A service that provides capabilities such as tools or resources to the application.

This components work together to make external capabilities accessible without requiring to build an integration directly into the main application.

Why Did We Choose MCP for NEXUS?

For us, the main reason was modularity.

NEXUS was intended to handle the different productivity related operations including file management, task management and web search. Building this integration directly into main application would be very difficult to manage.

MCP gave us a common way to connect these capabilities.

It also offered some practical advantages:

• New capabilities can be introduced through MCP servers without requiring to redesign the entire application.
• The application can communicate with different servers using a common protocol.
• Each MCP server handles a specific responsibility instead of placing all the loic inside the main application

How We Applied MCP in NEXUS?

We didnt wanted to experiment with MCP through random examples, we wanted to understand how it would work in a real application.

We integrated three MCP servers into NEXUS:

• File System MCP Server for file and directory operations.
• To-Do MCP Server for task management.
• Web-Search MCP Server for fetching information through DuckDuckGo.

Now each server provides different capabilities to the application which allowed us to keep integration modular while bringing their functions together through single application.

But connecting tools was one part we also needed to consider the intelligence behind the system, how it would interpret requests and what would happen if primary model becomes unavailable.

Dual-LLM Architecture

Since NEXUS relies on an LLM to interpret instructions and support its operations, we also had to consider what would happen if the model we depended on become unavailable.

We didnt wanted our application to to become unusable just because one model provider experienced an issue. This led us to explore a Dual-LLM architecture, where we could use a second model as a fallback when the primary model could not handle a request.

Why Did We Need Two Models?

When building an application around an external LLM API, the application becomes dependent on that provider's availability.

One failed API request and service might become unavailable or application might be unable to get a response.

We wanted to reduce this dependency on a single provider.

Instead of relying entirely on one model, we decided to integrate two different models which will increase the reliability and if one model fails, another model can take its place. Thats what we call fallback mechanism.

Gemini as Our Primary Model

For the primary LLM, we chose Google Gemini.

Gemini handled the main language model responsibilities with NEXUS. It was responsible for understanding user requests and supporting interaction of application with tools.

We used it as a default model because it formed the primary intelligence of our application.

Groq-hosted Llama 3.3 70B as Our Fallback Model

For the fallback, we integrated Llama 3.3 70B through Groq.

This gave us an alternative model that could be used, when our primary model failed.

One important thing is that we didnt wanted both models to work simultaneously. We wanted it to work in a primary-and-fallback arrangement. Keeping this arrangement in backend meant that we could continue the overall application workflow without making user manually choose between different models.

How Does the Fallback Mechanism Work?

The idea behind the implementation was to keep the model selection and fallback handling within the LLM layer itself.

Under normal conditions, NEXUS sends the request to Gemini. If the primary model fails, the fallback mechanism can use the Groq-hosted Llama 3.3 70B model instead.

The important part is that the fallback model is not another step that runs after every Gemini responses. It is an alternative used when the primary route cannot provide a successful response.

Challenges & Engineering Decisions

Building NEXUS was not just about connecting an LLM to a few tools and making everything work together. As we started bringing different components into one application, we had to think about how would they interact and how to keep the system manageable.

Some decisions were straightforward but some required us to think a little differently about how we wanted to approach the project.

Managing Multiple Components

One of the thing we had to consider was how to organize the different components without making NEXUS unnecessarily complicated.

NEXUS involved an interface, agent, multiple LLM providers and MCP servers. Each component had its own responsibility and putting all the logic in one place would have made NEXUS harder to maintain.

Keeping Tool Operations Under User Control

Giving an AI assistant access to external tools also introduced another consideration, how much control should it have?

An AI assisatnt that can modify files or change tasks needs to be handled carefully.

We addressed this through Human-in-the-loop confirmation for sensitive changes. This allowed users to review an action before its execution.

What We Learned

Looking back at NEXUS, the most interesting part of building it was not simply getting an LLM to respond to user queries. It was understanding how different components could work together and turn this request into executable actions.

When we started exploring MCP, we werent entirely sure how we would fit this in a practical application. Building NEXUS gave us an opportunity to move beyond theory and work on real application with external tools.

Onw thing that stood out to us was keeping the system modular. Separating different responsibilities made it easier to understand how each component contributed to the application.

And ofcourse, working with two LLMs provider gave us a better understanding of why reliability needs to be considered with functionality.

What's Next

NEXUS is still an opportunity for us to learn and explore.

There are several directions in which we would like to take the project further. This includes expanding tool integration, refining overall user experience and making its execution more reliable.

We would also like to explore various way of making NEXUS useful in everyday productivity scenarios.

Final Thought

For us, NEXUS was more than an AI assistant. It was a practical way through which we explored MCP, experimented with Dual-LLM architecture and understand how LLM can work with external tools.

We started with curiosity about MCPs and that curiosity eventually turned into something we could build, test and learn from as a team.

And honestly, thats how one of the best projects are made. You start with idea, run into problems, make a few questionable decisions and gradually understand things that once seemed unfamiliar.

Thats what building NEXUS was for us.

So, thats it. See you in the next one.

Peace out :)

- darshan