Two Telegram forum topics can have separate OpenClaw conversations, yet still use the same agent and its files. The practical distinction is the topic's session key versus the agent workspace that holds durable notes. This guide routes two real topics to two agents, checks each note against an owner-approved record, then repeats the check after a fresh session and a real correction. It is based on current documentation; BIG CHANGE has not run a bot, Gateway or model for this article.
The big change
- What changed: OpenClaw documents per-topic agent routing for Telegram forums. An operator can connect each topic to a different workspace and its
MEMORY.md, beyond the separate conversation that a topic already gets. - Why it matters: A team running two projects through one bot can check each project's answer against its own reviewed record. The routing makes that check practical, but the group audience and host permissions still decide who can see or reach the material.
- What to watch: The useful result is a repeatable readback: the right topic key, agent, file and answer before and after a session reset. A reply alone cannot establish that the bot used the intended note or forgot an older one.
Before touching the bot
You need an operating OpenClaw Gateway, provider access for two agents, an administered private Telegram forum supergroup with Topics enabled, and authority to add your exact bot to it. Choose two existing project scopes whose facts you are allowed to put in bot-accessible files and Telegram replies. Use a short, non-secret fact from each project's authoritative record; note its real source and approval date. To test correction later, you also need an actual approved revision to one of those facts. Do not invent a project decision to fill the template.
Record the bot username, the owner's numeric Telegram user ID, the group's negative -100… chat ID and two distinct numeric message_thread_id values. Obtain IDs from trusted Gateway logs or an authorized Bot API update; match each ID to the visible topic before editing config. Telegram calls the topic identifier message_thread_id. Keep tokens and private facts out of shared transcripts. Every member allowed to read a topic can see the bot's reply there. If the two facts need different audiences, use separate groups or other access controls before this exercise. Telegram Bot API and OpenClaw's Telegram setup explain the identifiers and group setup.
Check your installed version and command help on the Gateway host. The examples below follow the official documentation checked on 26 October 2026; your installed build and Telegram client may differ. These are read-only checks:
openclaw --version
openclaw agents add --help
openclaw sessions --help
openclaw channels status --probeRun those same commands in PowerShell on Windows. If a flag or config key differs, use the installed version's help and matching official documentation before making a change. Model calls, Telegram hosting, Gateway hosting and backup storage have account-dependent costs; this recipe has no verified price or free-use claim.
1. Add and verify the exact bot
Create a bot with the verified @BotFather only if you need a new one. Have a group administrator add that bot account to the existing private forum group, then confirm its username and membership in the group. Keep BotFather privacy mode enabled for this mention-based check; the bot need not be a group administrator. Stop if the account or group does not match your record. The Telegram setup guide separates bot creation from adding it to the group.
Save the token through an owner-controlled editor in a private regular file, not a symlink, outside either agent workspace. On POSIX, restrict the file to the service owner (0600) and its parent directory to that operator. On Windows, use an owner-only ACL on the token file and parent directory. Do not place a token in a shell argument, this article or an example config. Record the actual absolute path to that file. Preserve existing accounts and policies when you merge the following fields into the Gateway's ~/.openclaw/openclaw.json (or the installed Windows user's corresponding .openclaw\openclaw.json). The path shown is a placeholder, not a file to create verbatim.
{
channels: {
telegram: {
enabled: true,
tokenFile: "<ABSOLUTE_PRIVATE_TOKEN_FILE>",
allowFrom: ["<OWNER_NUMERIC_USER_ID>"],
groupPolicy: "allowlist",
groups: {
"<NEGATIVE_GROUP_CHAT_ID>": {
requireMention: true,
allowFrom: ["<OWNER_NUMERIC_USER_ID>"]
}
}
}
}
}This is the complete relevant Telegram block, not a replacement for other config. Verify effective account-level settings and any wildcard or topic override; account-level group maps can replace a shared map. The group ID belongs under groups, while sender IDs belong in allowFrom or groupAllowFrom. The access-control reference details those boundaries. Check that the Telegram account already has a resolvable agent owner. If the channel probe reports a missing owner, the authorized operator must add the exact account binding at the top level of the existing config, using the real account and existing owner agent IDs, and restart the Gateway. The documented shape is:
bindings: [
{ agentId: "<EXISTING_ACCOUNT_OWNER_AGENT_ID>",
match: { channel: "telegram", accountId: "<ACTUAL_ACCOUNT_ID>" } }
]Merge this into existing bindings; never replace other entries or assume the account is named default. A topic route does not repair a missing account owner. The Telegram channel reference describes this required binding and the blocked-account status. Have the Gateway service owner reload it through the installation's normal process; the current default supports hot reload for ordinary channel config. Run openclaw channels status --probe, check config errors in service logs, then send @<BOT_USERNAME> ping from the permitted owner account in each real topic. Record each visible reply and its group/topic ID. A probe or typing indicator alone is insufficient. If either reply is missing, inspect bot membership, token resolution, account ownership, effective sender policy, mention gate and logs; do not widen the allowlist to make the test pass.
2. Create two agents and their notes
Choose two empty, owner-controlled workspace paths. The POSIX example uses home-directory paths. On Windows, replace each ~/.openclaw/... value with an actual absolute Windows workspace path and keep the rest of the CLI syntax; inspect openclaw agents add --help first. These write operations create agents and may use the running Gateway. After an uncertain response, list agents before trying again.
openclaw agents add project-a --workspace ~/.openclaw/workspace-project-a --non-interactive
openclaw agents list --json
openclaw agents add project-b --workspace ~/.openclaw/workspace-project-b --non-interactive
openclaw agents list --jsonConfirm two different agent IDs and workspace paths in the readback. Check the effective model/provider credentials and tool permissions for both agents. Do not copy credentials or grant tools just to complete this check. The agents CLI documents non-interactive creation and its failure/readback behavior.
With a private editor, put this small file in each corresponding workspace. Substitute the actual approved facts and references. These are two separate MEMORY.md files; do not paste this placeholder into a live bot message.
# project-a/MEMORY.md
Project A decision (approved <REAL_DATE>, revision <REAL_REVISION>): <EXACT_APPROVED_A_FACT>.
Source: <OWNER_CONTROLLED_A_RECORD_REFERENCE>.# project-b/MEMORY.md
Project B decision (approved <REAL_DATE>, revision <REAL_REVISION>): <EXACT_APPROVED_B_FACT>.
Source: <OWNER_CONTROLLED_B_RECORD_REFERENCE>.Read both files back locally. Check that A contains no B fact and B contains no A fact; record file hashes or revisions without publishing the facts. MEMORY.md is the curated durable note; daily memory/YYYY-MM-DD.md notes and transcripts are different stores. A Telegram group session does not automatically inject root MEMORY.md. For this check, the agent must have an owner-approved way to read its own note on demand, such as the active memory provider's memory_get. Check that the tool is available to each agent and that its result identifies the intended file. Do not grant broad filesystem access merely to make recall work. /context list or /context detail can help inspect loaded context; neither a correct answer nor a context listing alone proves a successful read. OpenClaw memory and the workspace guide describe these paths and the group bootstrap boundary.
3. Route the two observed topics
Add the topics map inside the same exact group entry above, retaining its allowlist and mention gate. Replace both placeholders with the positive topic IDs you observed; do not use the group ID or a wildcard in their place.
"<NEGATIVE_GROUP_CHAT_ID>": {
requireMention: true,
allowFrom: ["<OWNER_NUMERIC_USER_ID>"],
topics: {
"<PROJECT_A_TOPIC_ID>": { agentId: "project-a", requireMention: true },
"<PROJECT_B_TOPIC_ID>": { agentId: "project-b", requireMention: true }
}
}Read back the complete effective group configuration. Reload through the service owner and probe the channel again. OpenClaw's thread and session reference says an exact topic can select an agentId and yields a key shaped like agent:<id>:telegram:group:<groupId>:topic:<threadId>. If validation rejects a route, repair that field and re-read the config before sending more messages. Do not substitute a broad default route.
4. Test the first session in both topics
From the allowed account, ask in topic A about A's approved note without putting its answer in the question. Repeat with B in its topic. Use the template below with the actual project name. Its instruction to read the local note matters because a group turn does not get that note automatically. Check the tool result or Gateway trace as the operator; a model's claim that it read a file is insufficient. If a memory tool is unavailable or denied, stop the memory check and review that agent's permitted memory provider and tool policy.
@<BOT_USERNAME> Use your permitted memory_get tool to read your own workspace's MEMORY.md. If it fails, say that you cannot verify the note. What is the current approved <PROJECT_A_OR_B> decision? State the source and revision found in that file. Do not use another project's file.Compare each answer with both the saved file and its owner record. Record wrong, missing and uncertain answers as failures, even when the response sounds confident.
List the stored sessions with the installed CLI. These are read-only commands in both POSIX and PowerShell:
openclaw sessions --agent project-a --json
openclaw sessions --agent project-b --jsonRecord each full topic-qualified key, agent ID, live session ID, workspace path, file hash and observed Telegram reply. The two keys should contain the same group ID but different topic IDs and agents. Then ask each topic for the other project's decision without supplying that fact:
@<BOT_USERNAME> From your permitted files and memory tools only, can you verify the current approved <OTHER_PROJECT> decision and its source revision? Do not guess or use a statement in this question as the answer.Mark a confident cross-project answer as a failed behavior check and inspect files, loaded context, group history and tool access. A refusal or uncertainty is useful observed behavior, not proof that the other file is inaccessible. The sessions CLI provides the readback; Telegram message behavior explains that authorized history can enter context.
5. Correct one real stale note and start fresh
Use an actual owner-approved new revision of A's source record. Check that no other writer is editing A's MEMORY.md, read the current bytes, then replace only A's stale line and its revision/source date with the approved wording. Read it back and record its new hash. Confirm B's hash is unchanged. This correction is a file operation by the workspace owner; the bot's acknowledgement would not establish it.
In topic A, send /new as a standalone message. Check the reset acknowledgement and repeat the openclaw sessions --agent project-a --json readback: the same topic key should now identify a new live session ID. Reuse the explicit file-read prompt above without its answer. Verify the read result and compare the reply to the revised file and source record. Repeat /new and the analogous file-read check in B, which should still use B's unchanged approved note. Repeat the negative cross-project prompt in both fresh sessions and record the outcomes. If A cites an older revision, inspect its memory-tool result, A's daily notes and permitted history before making a targeted owner-approved correction. Do not erase a transcript or edit B to hide the result. OpenClaw documents /new as a fresh live session, while Telegram's retained-history behavior allows authorized earlier discussion to be read later. This test shows the observed answer at a point in time, not guaranteed forgetting or perfect recall. Sessions FAQ
6. Decide what to retain
Archiving or closing a Telegram topic under the group's policy does not by itself remove OpenClaw's workspace notes, retained messages, provider records or backups. Context pruning trims eligible old tool results in the active model context; /compact summarizes a session, and /new changes the live session. None is a general memory deletion command. Session pruning and sessions FAQ describe those separate operations.
For a maintenance preview, run this read-only dry run in POSIX or PowerShell:
openclaw sessions cleanup --all-agents --dry-run --jsonIt previews session-store maintenance under configured rules; applying cleanup is a separate owner-controlled operation and is not a substitute for a memory-removal request. If the owner asks to remove a fact, inspect the actual file, indexed daily notes and provenance report, then plan deletion across all affected stores and backups under that owner's retention policy. OpenClaw's memory deletion reference says memory forget does not delete every transcript or freeform copy. Keep the current approved notes short and dated, and review them on the owner's schedule. Separate workspaces and topic replies provide an observable routing arrangement, not a privacy, host isolation, authorization or recall guarantee.
The nearby BIG CHANGE guides cover a Hermes Agent private Telegram reply, Redis-backed agent recall across sessions and a Claude Code project-memory correction. This procedure is specifically about OpenClaw's two forum-topic routes and the files and sessions behind their answers.
