I Thought We Were Building a Chatbot. We Were Building Something Else.

The last few days, I have been thinking a lot about a project I built for SIH last year.

I remember feeling that there was still something in it. The project was done, the competition was over, but I never really felt that Meena had reached where she could go.

Maybe it was curiosity. Maybe it was the fact that AI had changed so much since we first built it.

Either way, I came back to it.

And once I did, I realised I didn't just want to improve the old project.

I wanted to rethink it.

The first thing we went back to was the design.

There is something slightly strange happening with AI products today. Everything is becoming beautifully polished, but at the same time, everything is starting to look familiar.

Similar gradients. Similar cards. Similar illustrations. Similar futuristic language.

Somewhere between making products clean and making them usable, we sometimes forget to make them feel like they belong somewhere.

So we started asking a different question.

What should Meena feel like?

We went back to our roots.

Not because we wanted to make an "Indian-themed AI", but because we wanted the product to have a story of its own. And our roots naturally took us towards Indian visual culture.

We started looking at colours that we have grown up seeing without really thinking about them.

Kesari.

The colour of saffron, associated with courage, sacrifice and spirituality. A colour that has existed in our visual language for centuries.

Sindoori.

That deep vermilion associated with auspiciousness, celebration and rituals.

And then neela, moving towards indigo and the deep blues that have their own history in Indian art, textiles and craft.

None of these colours were chosen because they looked "Indian" on a moodboard.

We spent time looking at where these colours came from, what they represented and how they could coexist in a modern interface.

Eventually, they came together as a gradient.

Not just a gradient for the sake of looking good, but a visual transition between things that already exist in our culture. Something warm, familiar and energetic, without making Meena feel old-fashioned.

Then came the question of who we were actually making this for.

Students.

And that made us look at our own college experience again.

The places we spend time in. The hostel. The chai. The little references that only make sense when you have actually lived there. The conversations that have nothing to do with an official college website but are a very real part of college life.

That is why the interface has things like Mata Mandir ki chai, hostel references and little pieces of campus life.

They are not there just to fill empty space.

They are there because we wanted Meena to feel like she knows the environment she is entering.

Friendly. Familiar. A little playful.

Something closer to a campus companion than a government portal with an AI box attached to it.

And somewhere in all of this, the circular mark became important too.

The logo is deliberately simple. A circle that feels complete, soft and approachable. We started thinking of it almost like a signature of trust. Something you recognise before you even read the name.

Because if Meena is supposed to become someone you come back to, the identity cannot just be decoration.

It has to become familiar.

But then we reached the uncomfortable part.

A beautiful product isn't enough.

The interface could look exactly how we wanted it to look and still fail the first time someone asked it a question it couldn't answer.

So we went back to the architecture.

The earlier Meena had a fairly straightforward embedding and retrieval pipeline. A document goes in, it gets embedded, we retrieve relevant chunks and give them to the model.

And it worked.

Actually, it worked pretty well.

But the more we tested it, the more we noticed a problem.

Relevant isn't always relevant enough.

A vector search can find something that is semantically close to the query, but the closest chunk isn't necessarily the best piece of evidence for the answer.

So we added another layer.

Reranking.

Jina became part of that pipeline because we wanted another stage between retrieval and the model. Instead of blindly passing the first few results forward, we could retrieve a wider set and then rank what actually deserved to reach the LLM.

That helped with something else too.

Context is expensive.

Every irrelevant chunk we send to a model is not just noise. It is tokens, latency and cost.

Then we looked back at the embeddings themselves.

We had experimented with lighter embedding approaches, including MiniLM, but as the requirements grew, they weren't giving us the representation quality we wanted.

So we moved towards Gemini embeddings.

One of the reasons that interested us was the multimodal direction and the research behind the embedding models. Meena isn't only going to live inside plain text. A campus is full of PDFs, images, notices and different forms of information.

The architecture needed to leave room for that.

Then we made another jump.

We gave Meena tools.

A knowledge base is useful, but the real world does not stop changing because your vector database hasn't been updated.

So we added web search.

Tavily became part of the tool layer, allowing Meena to go beyond what was already inside her knowledge base when necessary. The idea was simple: if the information is not available locally, she should have a way to look for it and ground the answer in something current.

But this is where building an AI agent became very different from building a RAG chatbot.

Once you give a model tools, you also give it the ability to make decisions about those tools.

Search.

Read.

Search again.

Try another source.

And sometimes...

Search again.

We ran into tool-calling chains and loops that looked completely reasonable from the model's perspective and completely ridiculous from ours.

This became one of the more interesting engineering problems in Meena.

We couldn't just tell the model, "please stop calling tools."

We needed the system around it to understand what was happening.

So we started putting boundaries around tool use. Maximum tool turns, fallbacks, different handling for different kinds of tools and a proper final synthesis step when the exploration had reached its limit.

The goal wasn't to make Meena magically perfect.

It was to make her fail gracefully.

If she found part of the answer, we wanted her to be able to use it.

If she couldn't find something, we didn't want her inventing it.

And if the model got stuck in a tool-calling loop, the application should be able to recover rather than simply falling over.

That last part exposed another problem.

We couldn't properly fix what we couldn't see.

With an LLM application, a normal application log saying "request failed" isn't particularly helpful.

We wanted to know what actually happened.

Which model call happened first?

What did it retrieve?

Which tool did the model choose?

What did the tool return?

Why did it call another tool?

How many turns had happened before the failure?

So we built our own lightweight observability layer rather than immediately reaching for a heavy framework.

It tracks the flow of the agent, the tool calls, retrieval behaviour and failures so that when something goes wrong, we can actually follow the path that led there.

That turned out to be one of those things that sounds boring until you need it.

And then, after all of this, we came back to the original question.

Why would someone use Meena every day?

Because if the answer is simply "she can find information about college," then honestly, that isn't enough anymore.

Google can find information.

AI search can find information.

Modern models can summarise information remarkably well.

But there is something those systems don't automatically have.

Your context.

Ask Meena:

"Kal college jaun ki nahi?"

That isn't really a search query.

The answer depends on who is asking.

Your timetable.

Your hostel.

What you are working towards.

What you have already told her.

The documents you have shared.

The things that matter to you.

That is why we are now working on user context and personalisation.

The idea is that your Meena should eventually be different from my Meena.

The underlying campus knowledge can be shared. The tools can be shared. The architecture can be shared.

But the context around the person using it should not have to be.

And that is probably where this project has changed the most for me.

We started with a campus assistant.

Then we built a better retrieval system.

Then we gave it tools.

Then we had to build an agent around those tools.

Then we had to build observability just to understand the agent we had built.

And now we are trying to make it understand the person sitting on the other side of the screen.

I don't think Meena is finished.

Actually, I think that is the interesting part.

We are still building her.