OpenClaw Feishu dynamic agents

A public Feishu bot with hundreds of users cannot share one memory file, so OpenClaw can create a separate agent for each person who sends a DM, with its own workspace and history. Here is what dynamic agent creation builds, how a first message triggers it, the session scope decision that comes with it, and the boundaries the docs are careful to state.

What it creates

• Enabling dynamic agent creation automatically creates isolated agent instances for each DM user, each with an independent workspace directory, separate user, soul and memory files, private conversation history, and isolated skills and state, which is essential for public bots where each user should have a private assistant.
• Dynamic bindings include the normalised Feishu account ID, so default and named accounts route each sender to the correct dynamic agent; a named account that created an unscoped dynamic agent on an older release still counts that legacy agent toward the maximum, and you confirm the default account does not use it before removing it, or raise the maximum temporarily, because OpenClaw cannot safely infer which account owns ambiguous legacy state.
• The quick setup opens the DM policy with a wildcard allowlist, enables dynamic creation with a workspace template and an agent directory template containing the agent ID placeholder, and sets the global DM session scope to main so each user's DM becomes their main session and loads the bootstrap files automatically, with per-channel-peer as the stronger-isolation alternative.
• When a new user sends a first DM the channel generates a unique agent ID, the feishu prefix plus the user's open ID for the default account or a bounded account-prefixed identity digest for a named account, creates the workspace at the template path, registers the agent and creates a binding for the user, the workspace helper ensures the bootstrap files on first access, and all future messages from that user route to the dedicated agent.

This is a messaging-context isolation mechanism, not a hostile co-tenant security boundary.

Options and session scope

The options are the enabled flag, off by default, the workspace template defaulting to a workspace directory suffixed with the agent ID, the agent directory template defaulting to an agents directory with the agent ID, and a maximum number of dynamic agents, unlimited by default; the template variables are the generated agent ID and the sender's open ID. The DM session scope is a global setting that affects all channels: main maps each user's DM to their agent's main session, best for single-user bots that want the bootstrap files to auto-load; per-peer gives each peer a separate session regardless of channel; per-channel-peer gives each channel and user combination its own session, best for public multi-user bots needing stronger isolation; and per-account-channel-peer separates by account too, for multi-account bots. The trade-off is that main enables automatic bootstrap loading but means all DMs across all channels share the same session key pattern, so public bots that value isolation over auto-loading consider per-channel-peer and manage bootstrap files manually, and named Feishu accounts that should keep separate sessions for the same sender use the per-account scope, which dynamic bindings preserve.

Deployment, verification, notes

• The typical multi-user deployment sets the app ID and secret, an open DM policy with the wildcard, an open group policy with the mention requirement on, dynamic creation with both templates, the DM scope chosen for the isolation needs, and an empty bindings list because dynamic agents auto-bind.
• Verification is a gateway log line announcing the creation of a dynamic agent for a user with its workspace and agent directory paths, and a listing of the workspace directories shows every created workspace.
• The notes matter: each user gets their own workspace and agent instance and cannot see others' history or files in the normal messaging flow, but this is messaging-context isolation rather than a hostile co-tenant security boundary because the agent process and host are shared; config writes must stay enabled since creation writes agents and bindings into the config and is skipped when they are off; bindings should be empty because dynamic agents register their own; existing manual bindings keep working alongside; and the session scope is global to every channel.

OpenClaw on Feishu is the channel post this feature belongs to, and OpenClaw Feishu access control the open DM policy it relies on.

Isolation, honestly labelled

The docs draw the line carefully: a per-user workspace keeps conversations apart, but the process and the host are shared, so this is privacy between users rather than a security boundary against a hostile one. OpenClaw channel routing covers the binding model these agents register into, and Diali security the boundary Diali describes for its hosted agents.

On Diali

Feishu and Lark are not among the channels Diali connects today: WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS and voice. Hosted OpenClaw on Diali is the assistant, and Connect your first channel in five minutes shows the channels you can connect in five minutes.

• One DM, one agent, one workspace, created on the first message.
• Main auto-loads bootstrap files; per-channel-peer isolates harder.
• Config writes on, bindings empty, and the scope is global.