How AIClaw Keeps Messaging-Channel Chats Stateful with `/new` and `/continue`

External chat channels are convenient for AI agents, but they create a session problem fast.

In a web UI, users can see a sidebar of conversations and click back into old work. In WeCom, Feishu, Telegram, or WhatsApp, that structure usually does not exist. You get a thread, a sender, and a stream of incoming messages. If the agent cannot map that external thread back to an internal conversation reliably, the result is either context loss or messy session sprawl.

AIClaw solves that with a channel bridge that does more than relay messages. It binds external thread keys to internal conversation UUIDs, keeps archive-backed history available, and exposes a few small slash commands that let users control session continuity from inside the channel itself.

The practical problem

A channel integration usually has three jobs:

• accept inbound messages from an external system
• route them to the right agent
• send the reply back to the same place

That is enough for basic request/response behavior, but not enough for long-running agent work.

Real usage needs session control:

• start a fresh conversation without deleting the old one
• continue an earlier conversation from inside the channel
• keep one external thread attached to one internal conversation
• avoid duplicate conversations when the first inbound messages arrive concurrently

AIClaw handles those cases in its channel runtime instead of pushing the problem into prompts.

The core design: thread binding

When a channel message arrives, AIClaw derives one or more lookup keys from the inbound event. That can include the native thread key, alias keys, or the sender ID as a fallback.

Those keys are stored in a channel_threads mapping table that links:

• channel_id
• thread_key
• conversation_uuid

If a mapping already exists, AIClaw reuses the conversation. If not, it creates a new conversation and binds every relevant lookup key to it.

That sounds simple, but it matters a lot operationally:

• the same external thread stays attached to the same internal conversation
• aliases can converge onto the same conversation
• channel messages become inspectable in the normal AIClaw conversation model

There is also a concurrency guard. AIClaw uses a singleflight gate for the same (channel, thread) key set so that concurrent first messages do not create duplicate conversations or duplicate bindings.

Slash commands that work inside the channel

The interesting part is that AIClaw does not make users jump back to the admin panel just to manage sessions.

It intercepts a few slash commands before the LLM call:

• /new
• /reset
• /continue
• /continue N
• /archives
• /help

That gives channel users lightweight session control with no extra UI.

/new

/new creates a fresh conversation for the current channel thread.

If the thread was already bound to an older conversation, AIClaw removes that binding, creates a new conversation record, and rebinds the current thread keys to the new conversation. The older conversation is not deleted. It can still be recovered later.

This is the right behavior for channel-based agent usage because “start over” should not destroy prior work.

/continue

/continue lists recent archived conversations for the same agent and channel user. The archive list is scoped by user identity, so one person does not accidentally browse another person’s channel history.

/continue N switches the current thread binding to the selected archived conversation. After that, the next message in the same external thread continues that older context directly.

This is the part I like most: AIClaw turns a plain messaging thread into a recoverable working session without inventing a separate UI surface.

Why archives matter here

The /continue workflow depends on session archives instead of raw database rows alone.

AIClaw periodically regenerates a Markdown archive for a conversation after enough messages accumulate. The archive is generated without another model call and summarizes things such as:

• user goals
• tool usage counts
• recent assistant decisions

Those archive files live under the agent workspace and are sorted by update time when AIClaw builds the /continue list.

That design gives channel users a workable “recent sessions” experience while keeping the implementation cheap and inspectable.

A realistic channel workflow

Here is a simple example:

1. A WeCom user starts a deployment investigation in one channel thread.
2. AIClaw binds that thread to a conversation and keeps all later messages in the same context.
3. After the task is done, the user sends /new to start a clean debugging session without mixing contexts.
4. A day later, the user wants the original deployment investigation back.
5. They send /continue, pick the archived session number, and the same thread is rebound to that old conversation.
6. The next message continues from the earlier session rather than starting cold.

That is a small feature on paper, but it removes a lot of friction from channel-native agent usage.

Why I think this design is good

There are a few design choices worth calling out:

• session control is implemented in the runtime, not hidden in prompts
• channel threads map onto first-class conversation records
• archives are cheap to generate and easy to inspect
• user-facing commands are small, memorable, and channel-friendly

Most importantly, the system acknowledges that messaging channels are not just notification sinks. For many teams, they are the primary operating surface.

If an agent platform wants to work there, it needs explicit session semantics, not only transport adapters.

AIClaw’s channel bridge takes that seriously.

---

AIClaw is an open-source, self-hosted AI agent platform written in Go with a Vue admin console. It supports built-in tools, custom tools, MCP servers, multi-provider models, runtime planning, sub-agents, persistent memory, execution logs, and messaging-channel integrations in one deployable binary.