Markdown edition

# Give two Telegram topics separate OpenClaw agents and check their memory

> Route two Telegram forum topics to separate OpenClaw agents, verify each approved note through an explicit read, then check a corrected fact in a fresh session.

By BIGCHANGE.AI Editorial

Published: 2026-10-26T03:38:39.079Z
Updated: 2026-10-26T03:38:39.079Z
Canonical: https://bigchange.ai/blog/openclaw-telegram-topics-separate-agents-memory-check

![Conceptual charcoal illustration of a phone in a charging stand showing two unlabelled conversation entries, with the upper entry accented orange.](https://bigchange.ai/api/media/file/openclaw-telegram-two-topics-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

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](https://core.telegram.org/bots/api) and [OpenClaw's Telegram setup](https://docs.openclaw.ai/channels/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:

```sh
openclaw --version
openclaw agents add --help
openclaw sessions --help
openclaw channels status --probe
```

Run 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](https://docs.openclaw.ai/channels/telegram/setup) 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.

```text
{
  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](https://docs.openclaw.ai/channels/telegram/access-control) 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:

```text
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](https://docs.openclaw.ai/channels/telegram) 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.

```sh
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 --json
```

Confirm 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](https://docs.openclaw.ai/cli/agents) 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.

```text
# project-a/MEMORY.md
Project A decision (approved <REAL_DATE>, revision <REAL_REVISION>): <EXACT_APPROVED_A_FACT>.
Source: <OWNER_CONTROLLED_A_RECORD_REFERENCE>.
```

```text
# 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](https://docs.openclaw.ai/concepts/memory) and the [workspace guide](https://docs.openclaw.ai/concepts/agent-workspace) 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.

```text
"<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](https://docs.openclaw.ai/channels/telegram/threads-and-sessions) 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.

```text
@<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:

```sh
openclaw sessions --agent project-a --json
openclaw sessions --agent project-b --json
```

Record 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:

```text
@<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](https://docs.openclaw.ai/cli/sessions) provides the readback; [Telegram message behavior](https://docs.openclaw.ai/channels/telegram/messaging) 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](https://docs.openclaw.ai/channels/telegram/messaging) 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](https://docs.openclaw.ai/help/faq/sessions-and-chats)

## 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](https://docs.openclaw.ai/concepts/session-pruning) and [sessions FAQ](https://docs.openclaw.ai/help/faq/sessions-and-chats) describe those separate operations.

For a maintenance preview, run this **read-only dry run** in POSIX or PowerShell:

```sh
openclaw sessions cleanup --all-agents --dry-run --json
```

It 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](https://docs.openclaw.ai/concepts/memory-provenance) 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](https://bigchange.ai/blog/hermes-vps-docker-private-telegram-first-reply), [Redis-backed agent recall across sessions](https://bigchange.ai/blog/redis-agent-memory-cross-session-recall-guide) and [a Claude Code project-memory correction](https://bigchange.ai/blog/claude-code-local-project-memory-correction-guide). This procedure is specifically about OpenClaw's two forum-topic routes and the files and sessions behind their answers.

## Sources

- [OpenClaw, Telegram threads and sessions](https://docs.openclaw.ai/channels/telegram/threads-and-sessions) — Documents topic IDs, agent routing and session keys; actual routes need reader readback.
- [OpenClaw, Telegram setup](https://docs.openclaw.ai/channels/telegram/setup) — Separates bot creation, group membership, token configuration and channel probe. The operator must verify the exact bot, IDs and installed setup.
- [OpenClaw, Telegram access control](https://docs.openclaw.ai/channels/telegram/access-control) — Documents group and sender allowlists, mention gates and account-level map behavior; the example requires effective-config readback.
- [OpenClaw, Telegram channel reference](https://docs.openclaw.ai/channels/telegram) — Requires each Telegram account to have a resolvable agent owner; a missing binding blocks that account.
- [OpenClaw, channel routing](https://docs.openclaw.ai/channels/channel-routing) — Shows the Telegram forum topic suffix in group session keys and distinguishes routing from the delivery surface.
- [OpenClaw, agents CLI](https://docs.openclaw.ai/cli/agents) — Documents non-interactive agent creation, workspace paths and listing after an uncertain result; commands depend on the reader's installed version.
- [OpenClaw, memory overview](https://docs.openclaw.ai/concepts/memory) — Distinguishes curated MEMORY.md, daily notes, tool-based recall and provenance limits; it does not prove this group turn read a note.
- [OpenClaw, agent workspace](https://docs.openclaw.ai/concepts/agent-workspace) — Explains that group sessions do not auto-load root MEMORY.md; a permitted explicit read is needed for this guide's note check.
- [OpenClaw, sessions CLI](https://docs.openclaw.ai/cli/sessions) — Provides per-agent JSON session listing and a dry-run maintenance preview, separate from memory deletion.
- [OpenClaw, sessions and multiple chats](https://docs.openclaw.ai/help/faq/sessions-and-chats) — Explains standalone /new, fresh live session IDs and compaction; neither establishes erasure.
- [OpenClaw, Telegram message behavior](https://docs.openclaw.ai/channels/telegram/messaging) — Describes retained group/topic history and authorized reads after reset, subject to visibility and version limits.
- [OpenClaw, session pruning](https://docs.openclaw.ai/concepts/session-pruning) — Explains that pruning trims eligible tool-result context rather than workspace notes or ordinary conversation.
- [OpenClaw, memory provenance and deletion](https://docs.openclaw.ai/concepts/memory-provenance) — Explains provenance and the incomplete reach of memory forget across transcripts and external copies; deletion needs separate authorization.
- [Telegram, Bot API](https://core.telegram.org/bots/api) — Defines message_thread_id and Telegram chat/user identifiers; actual values must come from the owner's authorized account.