Waterside Chatbot EngineDirected

Our sites answered questions the way brochures do, which is to say they did not. A visitor to Longfellow Design Build wanting to know how long a kitchen takes, or whether the firm works in their town, had a contact form and a phone number. Most people with a question at 9pm do not fill in a contact form, and the ones who do are answered the next day by someone reading the same question for the hundredth time.

I directed this one and a Northeastern co-op engineer built it, in agentic AI coding environments, across 214 commits. The brief was one engine that every Waterside site could install rather than a bot per site: shared retrieval and tools, separate content, voice, and keys, and no path by which one site could read another's data.

Answers are grounded in the site's own CMS content. Keyword and semantic search run in parallel, merge, and rerank, and every answer carries citations back to the page it came from. The harder design decision was what it refuses to do: prices and timelines swing too much per project, so it names the factors that drive them and routes to a person instead, with a guardrail that scans replies for any number that slips past. While it helps, six conversational signals feed an intent score that decides whether to keep answering, start asking, or offer the hand-off.

When someone agrees to talk to a human, the lead is written to the database and synced to HubSpot with a transcript link. If HubSpot is down the write queues, retries with backoff, and finally emails the team, because a lead that vanishes quietly is worse than one that never came. The visitor accepts a privacy notice before the composer unlocks, and Global Privacy Control is honored automatically.

Live for Longfellow Design Build, with 58 test files behind the retrieval and tool layers. It is the clearest example of what I want the adoption work to produce: not a bot that talks confidently about everything, but one that knows what it can source, says so, and hands the rest to a person.