Persistent multi-bot "gateway" mode — long-running agent roster with per-bot memory

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code currently supports Scheduled Tasks (cron-triggered, stateless per run) and subagents (ephemeral, single-session). What's missing is a middle layer: a long-running gateway process that can host multiple named bot personas simultaneously, each with:

1. A persistent identity/scope — not just a SKILL.md read fresh each run, but a profile that stays "alive" between invocations
2. Event-driven wake-up — listening for messages/webhooks (Telegram, email, Slack) and responding in near-real-time, not just on a cron clock
3. Isolated persistent memory per bot — durable state that's automatically scoped per-persona, not something the user has to hand-roll as flat files with manual prefix conventions
4. A router that picks which bot persona handles an incoming event

Today, achieving anything like this requires building the entire gateway/router/state layer outside Claude Code (e.g. a custom process that polls and re-invokes Claude Code per event) — Claude Code itself only offers the "worker" half (Scheduled Tasks, subagents), not the "always-on dispatcher" half.

Use case: running a small fleet of specialized agents (e.g. per-vessel, per-department) that need to receive messages continuously and maintain separate long-term memory, similar to custom multi-bot setups people have built on other agent runtimes.

Proposed Solution

Add a "gateway"/daemon mode: claude gateway start --profiles ./bots/ that keeps a background process alive, loads one persona config per bot (prompt, scope, persistent-memory path), and listens for inbound events (webhook, Telegram, email poll) to dispatch to the right persona and invoke it — instead of the user having to build this dispatcher outside Claude Code. Each persona would get an automatically-scoped memory directory (like the existing auto-memory system, but keyed per-persona instead of per-project) so state naturally persists between invocations without hand-rolled file-prefix conventions. Scheduled Tasks would remain for pure cron-only routines; this would fill the event-driven / always-on gap.

Alternative Solutions

Workaround today: run a custom external process (e.g. a Node/Python script) that polls for events and shells out to re-invoke Claude Code per event, plus hand-rolled state files with manual naming conventions to fake per-bot persistent memory. Works but is entirely self-built outside Claude Code.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Example scenario:

1. I run several specialized agents that each own a narrow domain (e.g. one per project/team/data-source), each needing its own prompt, tool scope, and long-term memory.
2. Right now each one only runs on a cron schedule (Scheduled Tasks) — nothing listens for an inbound message and responds right away, and nothing keeps state alive between runs except files I manually read/write with my own naming convention.
3. With claude gateway start, I could register each agent as a persona, point the gateway at a webhook/inbox, and have it route each incoming event to the right persona automatically — with that persona's memory already scoped and persisted for me.
4. This would save the significant work of hand-building a dispatcher process and a file-based state convention outside Claude Code just to get persistent, always-on multi-agent behavior.

Additional Context

_No response_