Meet Maria: How We Built a Support Agent That Actually Knows TAIKAI

If you've worked in a growing company, you know how it goes. The product keeps evolving, more users show up, and at some point the support inbox becomes this endless thing. The same questions keep coming in, and the team is stretched thin trying to answer everyone while also building the product. That was us at TAIKAI.

So we decided to do something about it.

It started with a simple question

The idea didn't come from a brainstorming session or a product roadmap. It came from the day-to-day. Our support team was spending way too much time answering the same questions over and over. "How do I submit my project?", "How do teams work?", "What are KAIs?", "Where can I find the results?". You get the picture.

We looked at what was out there. There are plenty of customer support tools with AI baked in. But most of them start at over $100 per month, and that's just the base plan. For a startup like TAIKAI, that adds up quickly when you're being careful about where every euro goes.

So we asked ourselves: what if we just build our own? We had the engineering team, we knew our product better than any third-party tool ever would, and with the AI models available today, running our own thing would cost a fraction of what we'd pay for something off the shelf. Maria runs for less than $5 per month. Five. Dollars.

Cost wasn't the only driver, though. We didn't want one of those chatbots that spits out canned responses and makes people feel like they're talking to a wall. We wanted something that understood context, that knew TAIKAI inside out, and that still felt like talking to a real person. Building it ourselves gave us full control over that.

From hackathon idea to product

Like many things at TAIKAI, the project started small. And in a very fitting way. The first version was born during one of our internal hackathons. Someone pitched the idea of a support bot, the team got excited, and in a few hours we had a working prototype answering basic questions on Telegram. A minimum viable experiment to see if the idea had legs. It did.

We saw the potential pretty quickly and decided to turn it into an actual product. But we also realized Telegram alone wasn't going to cut it. Our community lives on Discord, users interact with us through the platform itself, and we needed something that could work across multiple channels. So instead of building a bot for one platform, we'd build an API-first support system that could plug into anything.

That's how we went from a hackathon prototype to a proper support engine. We called her Maria, a name that felt right for who we are and where we come from.

How does Maria actually work?

I'll keep this light.

Maria has a knowledge base at her core. A curated collection of questions and answers about TAIKAI: the platform features, hackathons, submissions, teams, all of it. When someone sends a message, she doesn't scan for keyword matches. She understands the meaning behind the question and finds the most relevant answers from what she knows.

If you ask "How do I join a team?" or "I want to be part of a group", Maria gets that both questions are about the same thing, even though the words are completely different. That's semantic search. Intent over exact wording.

She also remembers the conversation. If you asked something two messages ago, she keeps that context. It makes the whole thing feel like an actual conversation, not a form you're filling out.

A peek under the hood

For those curious about the tech side, here's how the pieces fit together.

Maria runs as her own service, built with TypeScript and Node.js. She sits behind an API, which is how both our main platform and the CMS communicate with her. When a user sends a message, it goes through this API, gets processed, and the response streams back in real time. No waiting around for a full answer before anything shows up on screen.

For data, we use PostgreSQL to store conversations, sessions, and the knowledge base. Redis takes care of the fast operations like rate limiting and tracking active sessions. The AI part connects to large language models through OpenRouter, which lets us swap between different models depending on what performs best.

The knowledge base is where it gets interesting. Each Q&A pair lives in the database alongside its vector embedding, a numerical fingerprint of its meaning. When someone asks a question, Maria turns it into the same kind of fingerprint and looks for the closest matches. That's how she finds the right answers even when the phrasing is totally different from what's stored.

Everything connects through a session system. Each conversation gets its own session with full message history, so Maria always knows where things left off. When Discord is involved, threads link directly to sessions, so our human agents can pick up the same conversation without missing anything.

The architecture is simple. It does what we need, and that was the goal.

Knowing when to step aside

This was important for us from the start: Maria had to know her limits. Not every question has a clean answer, and not every situation can be solved by an automated system. We've all been stuck talking to a bot that keeps looping with irrelevant responses when you clearly need a human. We didn't want that.

So we built a confidence system. Every time Maria generates a response, she scores how confident she is in it. If that score drops below a certain point, she stops trying. She escalates to a human agent and sends an alert to our team on Discord with the full conversation, so whoever picks it up already has all the context.

We'd rather Maria say "Let me get someone from the team to help you" than give a wrong answer. Trust takes a long time to build and very little to break.

Building it piece by piece

The project grew through iteration. We didn't design the whole system upfront. We started with the basics, tested, learned, and kept going.

It began with the hackathon prototype on Telegram. From there we built a proper API with session management and conversation memory. Semantic search came next to make answers more accurate, followed by Discord integration so the team could step in when needed. We added rate limiting to keep things stable and made the knowledge base easy to update so it could grow alongside the platform.

Every step came from a real need. We never added something because it sounded cool or because someone else was doing it. Each feature had to earn its place.

What we learned along the way

Building Maria taught us a few things beyond the technical stuff.

The hackathon prototype was a simple experiment, but the vision was always bigger. Starting small let us validate the idea without overcommitting. Having that bigger picture in mind helped us make better decisions when it came time to grow.

The knowledge base turned out to be the most important piece. The best AI model in the world can't help if it doesn't have the right information. We spent real time curating and organizing Q&A pairs, and that effort showed directly in the quality of Maria's responses.

We used to see escalation to humans as a limitation. Over time it became clear that it's a feature. It builds trust with users and shows us exactly which questions the knowledge base doesn't cover yet, so we can keep improving.

And giving the project a name mattered more than we expected. Once we started calling her Maria, people on the team talked about her like a colleague. That sense of identity helped everyone take ownership.

What's next for Maria

Maria already helps our users every day, but there's a lot more we want to do. Right now she knows TAIKAI as a whole: the platform, the features, the common questions. But what if she knew you? What if she knew which hackathon you're in, what projects you've submitted, what stage you're at?

We want to connect Maria to the TAIKAI API so she has real context about who she's talking to. Imagine asking "How do I submit my project?" and instead of a general answer, Maria knows your specific hackathon, checks if submissions are still open, and walks you through the exact steps for that challenge. Or a customer on the CMS asking about event settings, and Maria already knows which challenge they manage and what's configured.

Going from a support assistant that knows the platform to one that knows your situation. We also want her to learn from every interaction, growing the knowledge base automatically from conversations our human agents have with users.

We never set out to replace human support. The goal was to free up the team for the conversations that actually need a person, while Maria handles the repetitive stuff. So far, that's what's been happening.

Today Maria lives in two places: on our main platform, where hackers and users interact with TAIKAI, and on our CMS, where the companies and organizations running challenges manage their events. Each side has its own context. Maria knows where she is and adjusts accordingly. A hacker asking how to submit a project gets different answers than a customer asking how to set up their challenge. Same Maria, different knowledge.

If you're part of the TAIKAI community, there's a good chance you've already talked to her. If not, say hi next time you have a question.