OpenClaw

Use one Gateway to connect everyday messaging channels and multiple devices to the same assistant

The OpenClaw Gateway is the local control plane for sessions, tools, events, and channel connections. The Control UI, CLI, and TUI connect to the same Gateway, while Discord, Telegram, Slack, Teams, WhatsApp, and other messaging services can become additional entry points. Companion apps and nodes for macOS, iOS, Android, Windows, and Linux can add capabilities such as voice and screen access. This makes it possible to keep state and memory in infrastructure you control while mixing local models with cloud model providers.

Sources: [1]

Swap agent harnesses as well as models, and connect to ecosystems such as MCP

Model providers, channels, memory, voice, tools, and skills are extensible through plugins, and vendor agent harnesses such as Codex and Claude Code can be integrated into OpenClaw's session layer. OpenClaw can act as both an MCP client and server and supports additional protocols such as A2A and ACP. This allows operators to change execution runtimes while keeping channel connections and state in the Gateway rather than tying the entire assistant to a single model vendor.

Sources: [1][2]

For people who want an agent available through daily chat and multiple devices, not only inside a terminal

OpenClaw fits personal-assistant workflows where a task can start from a messaging app away from the desk and continue with the same sessions and memory on another device. The same foundation can also be configured for a team, making it relevant when the goal goes beyond a shared AI portal and includes persistent tasks and multiple communication channels. Its MIT license and lack of a separately licensed enterprise edition also make it attractive to operators who want to reshape the deployment themselves.

Sources: [1][2][5]

Because the assistant can act on connected machines, sandbox and user boundaries need explicit configuration

OpenClaw can use tools on connected machines, so execution boundaries matter more than they do for a conventional chat UI. The official documentation states that sandboxing is off by default; deployments can configure sandboxing, tool access, and workspace access as needed. When external messaging channels are connected, inbound-user controls should also be reviewed as part of the deployment.

A single Gateway is defined as one trusted operator domain rather than a hostile multi-tenant authorization boundary. The project recommends separate Gateway instances when users or organizations do not share the same trust boundary. Data sent to configured model providers and messaging services is still governed by those external services. OpenClaw itself is MIT-licensed.

Sources: [1][3][4][5]