# Adding an AI Chatbot to Echostats > Source: > Published: 2026-07-18 07:54:48+00:00 Echostats is a Spotify stats dashboard. You upload your extended streaming history, the app stores it, and from then on it syncs with your Spotify every time you open it, pulling in your listening history and turning it into stats: top artists, top songs, a song you've probably forgotten about, a "song of the day," and more. Numbers on a dashboard only go so far, though. A user can see that an artist sits at the top of their list, but not necessarily *why* that matters or what it says about their taste. That's the gap I wanted the AI chatbot to fill — a chat interface inside Echostats that can explain the stats in plain language and give the user deeper, more personal insight into their own music taste, instead of just handing them a chart. The chatbot runs on Google AI, specifically the `gemini-3.1-flash-lite` model, set as the default in `getGoogleConfig` . I didn't stick with my first choice the whole way through — the model got updated partway through the build as I iterated. Streaming was the original plan. A chat interface almost always benefits from a typewriter-style response, where text appears as it's generated instead of arriving all at once, and that's how I initially built it. But Vercel's hosting environment introduced limitations that made streaming unreliable in production, and rather than chase a workaround, I made the call to switch to a normal, non-streaming response. The user still gets an answer, just not the typewriter effect. The build process had a fair amount of back-and-forth, and most of it centered on two problems. **The blank message bug.** At one point, the backend was generating and sending the AI's response correctly — I could see it in storage — but the chat UI would render a blank message instead of the actual text. Tracing it back, the root cause was Vercel's Node.js serverless function limitations. Switching to the Edge runtime could have solved it, but Edge doesn't support Mongoose, which the backend depends on for MongoDB, so that fix wasn't available to me. I ended up refactoring how messages were structured and sent to the model several times (`toInteractionInput` went through a few iterations — first using a "parts" structure, then type/content, then constant type assertions) while working through this. **The two-response problem.** Some questions can't be answered by the AI alone. If a user asks something like "what was my listening history for last week," the AI first replies with an acknowledgment — essentially "processing that now" — while the backend goes and fetches the actual data (in this case, the last seven days of listening history). Once that data comes back, the AI sends a second, real response. That means a single question can produce two responses. The loading indicator originally didn't account for that: it would stop after the first "processing" message came in, making it look like the app had frozen or broken while the second response was still on its way. I fixed this by adding a "delta" command that tells the loader a second response is still coming, so it now correctly reflects both stages instead of cutting out early. If I were building this again, I'd research the limitations of whatever framework or hosting environment I'm using — and confirm it fully supports what I'm trying to do — before writing the feature. I lost a full day debugging the streaming error, only to find out it came down to a Vercel limitation I hadn't checked for upfront. A bit of research at the start would have saved that time entirely.