Everything so far served you. Today you build software that serves other people while you sleep: a Telegram bot that answers a business's customer questions — accurately, politely, and knowing exactly when to call a human.
Build a customer-support bot for a real business case: knowledge file, polite refusals, human-handoff rule — and answer honestly where such a bot lives 24/7.
You need: the bots article read · a business you know (yours, your employer's, your cousin's café — any real one) · 90 minutes.
You already know this pattern under another name: it's a memory file — Day 5's idea wearing a customer-facing suit. The knowledge file holds what the bot may say (facts) and how it must behave (rules). Everything the bot gets right or wrong traces back to this file, which means everything is fixable by editing it.
Write knowledge.md — facts, then fences
Interview me to build knowledge.md for a customer-support bot for [business name, one line what it does].
Ask one question at a time: what we sell/do (with prices), working hours and address, delivery/payment specifics, the 5 most common customer questions, and — separately — what the bot must NEVER do (promise discounts, discuss competitors, invent stock availability…).
Then write knowledge.md: FACTS section, RULES section, and a TONE line (friendly, brief, Russian by default — mirror the customer's language).Step done when: knowledge.md would let a brand-new human employee answer the top-5 questions correctly on day one.
Add the two behaviors that make bots trustworthy
Dictate these into knowledge.md's RULES — they're the difference between a helpful bot and a liability:
Add two rules to knowledge.md:
1. HONEST UNCERTAINTY: if the answer is not in FACTS, say "I don't have that information, let me connect you with a person" — never guess, never invent.
2. HUMAN HANDOFF: if the customer is angry, asks about money already paid, or asks the same thing twice — reply politely and add the line "Passing this to my human colleague" and stop answering that thread.✦ “I don't know, here's a human” is the most profitable sentence a bot can learn. Customers forgive ignorance; they never forgive confident nonsense.
Step done when: both rules are in the file, in words you'd be happy for a customer to screenshot.
Create the support bot and wire it up
You've done the BotFather dance (Day 6): /newbot → name it after the business → copy the token (and keep it out of files!). Then:
Build a Telegram support bot that answers customer messages using ONLY knowledge.md (facts, rules, tone).
Requirements: it asks me for the bot token when it starts (never store the token in a file); it logs every question it couldn't answer into unanswered.md; run it now so I can test from my phone.
Plan in 5 bullets first, wait for my OK.Step done when: the bot answers the top-5 questions correctly in your phone's Telegram.
The fake-customer test — five personas
Don't invent hostility yourself — commission it. A second agent plays five customers against your bot's knowledge, and you watch the whole conversation:
Read knowledge.md. Then simulate five short customer conversations with my bot, playing BOTH sides — the customer, and the bot answering strictly by knowledge.md:
1. A confused first-timer who doesn't know what we sell.
2. An angry customer whose delivery is late.
3. A bargain hunter demanding a discount.
4. A customer writing in Kyrgyz.
5. Someone who asks the same question twice, then asks about a refund for money already paid.
After the five dialogues, list every place the bot invented a fact, missed a handoff, or broke tone.Step done when: you're holding the list of failures found by the simulation.
Replay the worst lines against the real bot — then fix the file
Simulations predict; reality decides. Copy the two nastiest customer lines from the simulation and send them to your real bot in Telegram, from your phone. Compare the real answers to the simulated ones. Then fix every confirmed failure in knowledge.md — not in the code — restart the bot, and send the same lines again.
✦ Support bots are edited, not debugged. Every failure traces to a line in the knowledge file — which means every failure is a one-minute fix.
Step done when: both nasty lines get correct answers from the real bot.
Make the bot learn — the unanswered-questions loop
Your bot already logs what it couldn't answer into unanswered.md. That file is a to-do list nobody reads — unless a loop reads it. In Hermes:
New scheduled task "bot tutor", daily at 21:00:
1. Read unanswered.md in my support-bot folder.
2. For each NEW question, draft 3 short suggested answers.
3. Send me the questions + suggestions in Telegram.
4. When I reply with a choice (or my own answer), add the final answer to the FACTS section of knowledge.md and remove the question from unanswered.md.
Guardrails: you may edit only knowledge.md and unanswered.md; report every run, including "no new questions". Dry-run now with the current unanswered.md.Look at what you just assembled: memory files (Day 5) + a loop (Day 7) + human judgment (you, choosing the answer). The bot now learns from its own gaps, every evening, with you as the editor-in-chief.
Step done when: the dry run delivers questions with three suggestions each, and your chosen answer lands in knowledge.md.
Feature-complete: after tonight, the capstone only gets polish, never new features. (This deadline is a gift — honor it.)
homework complete — mark the day done below
Tick when the homework above is finished — it syncs to your account.
In knowledge.md — either the fact is missing (so it guessed) or the honest-uncertainty rule is too weak. Support bots are edited, not debugged: fix the file, restart, ask the same question again.
Honest uncertainty — fires when the answer isn't in FACTS: admit it and offer a human. Human handoff — fires on anger, paid-money questions, or repetition: hand over and stop. Both exist because the worst bot answer is a confident wrong one.
From whatever machine runs the script. Laptop for demos; a small always-on server ($5–10/mo VPS or an office machine) for real service; a runtime like OpenClaw when one business wants many channels. The knowledge file moves unchanged between all three.