The Assistant That Would Rather Say "I Don't Know"

The Problem

Most website chatbots have the same quiet flaw: they will answer anything, whether or not they actually know. Ask one a question the site never addressed and it will often invent a confident, plausible, wrong reply — because the underlying model is built to always produce an answer. For a business, that’s a liability wearing a friendly face. The one place a visitor most needs to trust what they read — your own site, in your own voice — is the place a made-up answer does the most damage.

The interesting question isn’t “can we add a chatbot.” It’s “can we add one that we’d actually trust to speak for us.” That means an assistant that does three things a default chatbot doesn’t: answers only from content we’ve actually published, shows its work so a visitor can check it, and — the hard part — says so plainly when it doesn’t know, instead of guessing.

The Approach

We built that assistant for our own site first, as a reference implementation — the honest way to stand behind a claim is to run it on yourself first. The design rests on a single discipline: the assistant is grounded by construction. It doesn’t answer from the model’s general knowledge; it answers from a curated set of our own published pages, and every reply is tied back to the specific pages it drew on. When a visitor asks something those pages don’t cover, the assistant doesn’t reach — it says it doesn’t have that in the published material and points the visitor to a way to get in touch.

Ground every answer in published content. The assistant draws only on a curated set of our own pages, and ties each reply back to the ones it used — no answering from the model’s general knowledge.
Do the slow work up front, not while the visitor waits. The effort of deciding what’s trustworthy happens once, when we curate the knowledge — so the live assistant can stay fast and simple.
Keep the trusted content separate from everything else. What the assistant is allowed to say comes from one curated, verified place. Visitor conversations and contact details live in a separate store and never quietly feed back into what the assistant tells the next visitor.

None of that is exotic technology. It’s a set of choices about what the assistant is allowed to do — and the restraint is the point.

What It Does

The assistant is live on this site. In plain terms:

It answers from our published pages, and cites them. Every answer ends by naming the pages it drew on, so a visitor can go read the source themselves.
It refuses rather than guesses. Ask it something outside what we’ve published, and it says it doesn’t have that — no invented answer, no bluffing.
It treats page content as reference, not instructions. Retrieved text is data to answer from, never commands to follow — which makes it much harder for a stray instruction buried in a page to hijack it.
It captures a lead the honest way. A visitor who wants to be contacted can leave their details through a consent-based form — separate from the chat, tied to a published privacy policy written to match exactly what the system actually collects.

Built on standard, well-established components (Cloudflare for hosting and retrieval, Anthropic’s Claude for the language), with the privacy policy and the data handling designed alongside the build rather than bolted on after.

The Outcome — and Where It Stops

Because a case study that only lists strengths is its own kind of dishonesty, here is what this assistant doesn’t do, first:

It’s deliberately small and single-purpose. It answers questions over a curated set of pages and captures a lead. It isn’t a voice agent, it doesn’t take actions or make bookings, and it isn’t built for high-traffic enterprise scale. Those are real, worthwhile problems — just not this one.
Grounding reduces made-up answers; it doesn’t abolish them. Anchoring every answer to retrieved sources sharply narrows the room for invention, but no current system removes it entirely. That’s exactly why the refusal path matters — it’s the honest backstop for the cases grounding doesn’t catch.
It doesn’t remember you between visits. Each conversation stands alone by design. Whether an assistant should carry memory across visits is a genuine design question with real privacy trade-offs — not a box we quietly ticked.

What it does deliver is the thing most website chatbots can’t: an assistant you can trust not to make things up on your behalf, because it would rather admit a gap than fill it with a guess. It’s live, it’s demonstrable, and you can test the refusal behavior yourself — ask it something we’ve never published and watch it decline.

The distinctive thing here isn’t scale or novelty. It’s the combination of grounded design, honest-by-design behavior, and privacy considered from the start — a small assistant that tells the truth about what it knows, and tells you plainly when it doesn’t. Building it well took many working sessions, kept coherent by a documented practice — a discipline in how it was built, not anything the assistant does at runtime.

Try It Yourself

Use the “Ask about Echo Angel” button on our homepage — ask it something we’ve published, then ask it something we haven’t, and watch it decline rather than guess.

Open the Assistant →

For the practitioners — the posture in brief

Retrieval-grounded, refusal-first. Answers come only from retrieved passages of curated content; when that material doesn’t cover a question, the assistant refuses instead of guessing.
Two speeds. The expensive correctness work — deciding what enters the knowledge base — is done offline at curation time, so the visitor-facing path stays a fast retrieve-and-cite. The slow, thorough work never sits on the visitor’s request.
Two stores, one direction. A trusted answer store (the only thing visitors are grounded on) is kept strictly separate from the interaction log (conversations, leads). Nothing flows from the log back into the answer store without a human deciding it should — the discipline that keeps an assistant from slowly poisoning itself on its own unverified output.
Retrieved content is data, not instruction. A standing defense against instructions smuggled inside retrieved text; not a solved problem industry-wide, but a defense worth holding — kept paired with a read-only knowledge base and no ability to take actions.
Honest subprocessor disclosure. The privacy policy names the services involved and reflects that neither the language provider nor the infrastructure provider trains on the content sent through — verifiable against each provider’s own published terms, not asserted on our say-so.
Stated limits. Grounding reduces but does not eliminate hallucination; the refusal path is the acknowledged backstop. Scale, per-visitor access control, systematic evaluation, and cross-visit memory are deliberately out of scope for a reference build — named here rather than hidden.

Work You Can Check

Whether it’s a grounded assistant for your own site or a research deliverable you need to be able to verify — we build work products with the checking built in, so you never have to take our word for it.