Designing an AI Chatbot for IT Technicians at Harvard

HKS IT technicians resolved support tickets across campus without a reliable way to quickly surface institutional knowledge. The answers existed, in documents, wikis, and the heads of senior colleagues, but none of it was accessible at the moment you needed it. The workaround was to call someone who'd seen the issue before. That created bottlenecks, interrupted senior staff, and made it harder for newer technicians to build confidence independently. I experienced this firsthand as a technician during my co-op. Every time I had to stop and search through a folder of PDFs to answer a basic question, I thought: there has to be a faster way to do this. A previous version of AgentAI existed but lacked visual cohesion and a clear identity. The goal was to redesign it into something technicians would actually trust and use.

• 01

  Because I was a technician myself, I already had a clear picture of the problem before the project started. The questions we were asking each other weren't complex, they were recurring situations with known answers that were just hard to find fast. That told me this was a retrieval problem, not a knowledge problem. The knowledge existed. We just needed it to be accessible.

• 02

  I talked to other technicians about what they actually wanted. The consistent answer wasn't 'better search', it was something they could ask in plain language, the way you'd ask a colleague. That defined the interaction model: a conversational interface, not a search bar.

• 03

  The key constraint I scoped around: the chatbot would only answer questions grounded in HKS's own existing documentation. No general web search. The reason was trust, if technicians got a wrong answer once, they'd stop using it. Reliability over breadth was the right call for an internal tool.

• ·

  I owned the design and led the project across a 3-month co-op term. The interface was a chatbot that pulled from HKS IT's existing document library, the goal was to make the knowledge already in the organization instantly accessible, not to create new knowledge.

• ·

  I kept the scope deliberately tight for the first version: answer IT-specific questions accurately, in plain language, grounded in real HKS documentation. I pushed back on expanding the scope to general HR or admin questions, that would have diluted the core use case and added complexity without adding value for the technicians we were building for.

AgentAI was completed and handed off to the HKS IT team in July 2024 at the end of my co-op term. The chatbot interface, documentation, and deployment instructions were all complete. It launched after I left so I don't have adoption data to point to. What I can say is that the problem it was built to solve was real. During my time as a technician I personally resolved 300+ support tickets, which gave me a clear read on the kinds of questions technicians were asking repeatedly. Those were the exact cases AgentAI was designed to handle.

• ·

  The biggest thing I'd change: getting the chatbot in front of actual technicians earlier. I built the interface based on what I thought technicians wanted from my own experience using the tools, but I didn't do a structured test until the product was mostly done. Even one early prototype session would have surfaced edge cases I caught late.

• ·

  I'd also push harder to define a measurable success metric before starting. We never agreed on what 'good' looked like post-launch, adoption rate, time-to-answer, something. That made it hard to make confident decisions about scope during the build.