Introduction
This artifact is the capstone of the AIML‑500 AI Lab, an assignment that moved through hands‑on practice with large language models, a custom GPT, and Stanford's STORM research assistant before culminating in a build: design and deploy an AI chatbot using design thinking. I chose to build an assistant grounded in my own open‑source project, pgtriage, so the result would be honest to my actual expertise and useful beyond the classroom.
Description
The pgtriage Assistant is a publicly deployed AI chatbot that helps engineers triage PostgreSQL performance problems. It classifies an incoming problem as a single slow query, a system‑wide slowdown, or a connection‑level issue, asks for the minimum evidence needed, reads pasted EXPLAIN ANALYZE output, and maps each problem to a diagnostic path, naming the pgtriage tool that automates the relevant check. It explains its reasoning at the level of PostgreSQL internals rather than issuing instructions without justification.
A representative exchange from testing:
EngineerMy database is slow
pgtriage AssistantIs this a single slow query, a system‑wide slowdown, or a connection‑level issue? If you want the fastest path, paste one of these: the SQL plus EXPLAIN (ANALYZE, BUFFERS) output, symptoms like high CPU or lock waits, or current connection counts. Once I know the class, I can point you to the right check.
Objective
The assignment objective was to apply design thinking to develop an AI‑based solution to a real problem and demonstrate proficiency with generative AI tools. My personal objective was sharper: reduce an engineer's time from "this query is slow" to "I know exactly what to check next," and prove that an AI assistant can carry safety guardrails appropriate to production database work, such as never emitting destructive SQL as copy‑paste advice.
Process
I followed the design thinking cycle end to end:
- Empathize. The target user is a peer: an engineer facing a slow database who does not know where to start and pastes query plans into chat tools with no structure. I drew on pain points I have observed repeatedly in production incident work.
- Define. I answered ten planning questions before touching any tool: the bot's objective, its knowledge sources, its hard prohibitions, its interaction style, its step‑by‑step process, and what a successful engagement looks like, plus a test scenario for every rule.
- Ideate. I evaluated build platforms against the plan, read the selected platform's privacy policy and terms of use before signing up, and scoped the knowledge base to my own public open‑source documentation as a deliberate data‑governance choice.
- Prototype. I built the agent on Chatbase, replaced the platform's default system prompt entirely after finding it conflicted with my design, and loaded the pgtriage README as the knowledge source.
- Test. I ran six scenarios, one per design rule: a destructive SQL request, a query plan with a hidden type cast, a question about a feature that does not exist, an off‑topic request, an ambiguous problem statement, and a demand to justify its reasoning. All six passed, and I verified the public deployment separately in a logged‑out browser session.
Tools and Technologies Used
- Chatbase (agent platform, GPT‑5.4 Mini model) for the build and hosted deployment
- pgtriage documentation as the curated knowledge source
- Design thinking framework for planning, prototyping, and test design
- ChatGPT, Gemini, Claude, a custom GPT, and Stanford STORM in the lab's earlier comparative exercises, which informed the guardrail and evaluation approach
Challenge and Key Lesson
The hardest design problem was preventing a technically fluent assistant from sounding authoritative outside its evidence. I learned that guardrails are strongest when they are testable product requirements, not broad warnings: every boundary in the design became a specific adversarial prompt and an expected behavior. That lesson now shapes how I evaluate any AI assistant before asking users to trust it.
Value Proposition
Unique Value
This artifact shows the full arc from user empathy to a live, guardrailed, tested AI product, grounded in a real open‑source tool rather than a toy example. The safety constraints and the test suite mapped one‑to‑one to design rules are what distinguish it from a default chatbot.
Relevance
Engineering teams everywhere are deciding how to adopt AI assistants safely. This artifact is a working reference for how to scope an assistant's knowledge, set hard behavioral boundaries, and verify each one before shipping, exactly the judgment those teams need.
References
- Live assistant: chatbase.co/re2tXFwC-G8Z8DfDyKkY0/help
- pgtriage project: github.com/pgtriage/pgtriage
- Shao, Y., Jiang, Y., Kanell, T. A., Xu, P., Khattab, O., & Lam, M. S. (2024). Assisting in writing Wikipedia‑like articles from scratch with large language models. NAACL 2024. (STORM, used in the lab's research‑assistant exercise.)