Database-Connected AI Chatbot

The goal wasn't to build a chatbot — it was to understand which AI capabilities genuinely change what a product can do for a user, and which ones are complexity for its own sake. I structured the build in five stages so each capability had to justify itself before the next one was added.

Memory changed the product more than any other single decision. Without it, every message is a cold start. With it, the assistant can hold a thread, refer back to earlier context, and feel like a persistent tool rather than a search bar. The implementation was simple; the product difference was not.

Tool calling shifted who is in control. Instead of writing decision logic myself, I defined what the assistant could access — a live weather API and a PostgreSQL database of student profiles — and let the model decide when and in what order to use them. The most revealing test was a chained query: asked about the weather where a user lives, it retrieved the city from the database first, then called the weather API. That sequencing came from the model, not a script.

The system prompt is the product layer. Changing how the assistant communicates — its voice, its constraints, its defaults — required no changes to tools or memory. The same underlying system produced a completely different user experience. For a PM, that's the most important thing to internalise: the model is infrastructure. The decisions that shape what users actually feel sit above it.

The assistant runs on Streamlit with a Python backend and deploys automatically to Fly on every commit.