AI Chatbot
A full-stack conversational AI chatbot combining a Python backend, a Streamlit chat frontend, and Google's Gemini API. It started as Project 1 for the Coincent AI Domain Internship Program (a small, working request loop end to end), and has stayed in active development since, as the base for features the original submission never needed: persistence, better conversation handling, and a less bare-bones interface. It's not finished, and this write-up reflects where it actually stands rather than where it will eventually land.
Why I Built This
This started as Project 1 for the Coincent AI Domain Internship Program; the goal was a working, submission-ready chatbot that actually calls a real LLM API rather than a mocked response.
Once the submission was done, the project didn't feel finished so much as minimally functional, a chat loop with no memory of the conversation and nowhere to store anything is a fine internship deliverable, but not something I wanted to leave alone. It's become the project I keep returning to for practicing the parts a one-week brief doesn't ask for: persistence, conversation state, and a frontend that isn't just the fastest thing to stand up.
Current Architecture
The request path today is intentionally simple: Streamlit UI → Python backend → Gemini API → response back to the UI. There's no conversation memory beyond what's visible on screen, no database, and no user accounts; it's the same shape the internship submission shipped with, just with more thought going into where the seams for real features will go.
Planned Capabilities
The near-term goal is persistent conversation history (actually storing and retrieving past sessions rather than losing everything on refresh) followed by moving the frontend off Streamlit toward something that can support a more considered chat UI as the feature set grows.
Next Milestones
The immediate milestone is a persistence layer for conversation history. After that, the plan is to reassess whether Streamlit is still the right frontend once the app needs to do more than render a single chat loop.
Key Decisions
Streamlit was chosen for the frontend specifically because it let the whole submission (UI and backend wiring) stay in Python, with no separate frontend build step to manage under a deadline. That decision is now up for revisiting as the project grows past what Streamlit is comfortable doing.
API keys are loaded from a local .env file via dotenv and explicitly excluded from the repo, rather than hardcoded, so the credential-handling pattern is correct even in a small internship project; a habit that's stayed as the project has grown.
The current architecture is still a straightforward Streamlit-frontend-to-Python-backend-to-Gemini path with no persistence layer yet, which is the honest state of the build rather than a gap I'm papering over.
What I Learned
Wiring a real LLM API into an app (rate limits, response latency, occasional malformed output) surfaces failure modes that don't show up until you're calling something outside your own control, unlike a mocked chatbot demo.
Keeping a project's structure minimal on purpose, without premature abstraction, made it much faster to actually finish and submit than reaching for a heavier framework would have; though it also means some of that minimalism now has to be deliberately unwound as real features get added.