Initial commit: Discord-Claude Gateway with event-driven agent runtime
This commit is contained in:
150
docs/FUTURE-FEATURES.md
Normal file
150
docs/FUTURE-FEATURES.md
Normal file
@@ -0,0 +1,150 @@
|
||||
# Aetheel — Future Features Roadmap
|
||||
|
||||
Features inspired by nanoclaw that can be implemented in the CLI-based gateway. Excludes Docker containers, WhatsApp channel, and Agent SDK (already ruled out).
|
||||
|
||||
## Quick Wins (hours)
|
||||
|
||||
### 1. Message History Storage
|
||||
|
||||
Store inbound/outbound messages in a JSON file per channel. Nanoclaw uses SQLite, but a simple `config/messages/{channelId}.json` would work. This lets the agent see conversation history even after session expiry.
|
||||
|
||||
How nanoclaw does it: SQLite table with id, chat_jid, sender, sender_name, content, timestamp, is_from_me, is_bot_message columns. Indexed by timestamp.
|
||||
|
||||
Our approach: JSON file per channel at `config/messages/{channelId}.json`. Append-only. Include sender name, content, timestamp, and direction (inbound/outbound). Load recent messages into the system prompt or pass as context.
|
||||
|
||||
### 2. Structured Logging
|
||||
|
||||
Replace `console.log` with a proper logger (pino). Nanoclaw logs everything with structured context (group, duration, event type). Makes debugging way easier on a headless server.
|
||||
|
||||
How nanoclaw does it: Pino logger with pretty-printing, configurable log levels via LOG_LEVEL env var, uncaught exception routing, container logs saved to disk.
|
||||
|
||||
Our approach: Install pino, replace all console.log/error/warn calls, add log levels, save logs to `config/logs/`. Structured JSON logs make it easy to grep and filter.
|
||||
|
||||
### 3. Conversation Archiving
|
||||
|
||||
Before sessions get too long, archive transcripts to `config/conversations/`. Nanoclaw does this via a PreCompact hook that saves the full transcript as markdown before Claude compacts its context.
|
||||
|
||||
Our approach: After each CLI response, optionally append the exchange (prompt + response) to `config/conversations/{channelId}/{date}.md`. This creates a human-readable conversation log separate from Claude's internal session storage.
|
||||
|
||||
### 4. Retry with Backoff
|
||||
|
||||
When the Claude CLI fails, retry with exponential backoff (5s, 10s, 20s, 40s, 80s) up to 5 times. Nanoclaw does this for container failures.
|
||||
|
||||
How nanoclaw does it: GroupQueue tracks retryCount per group, uses `BASE_RETRY_MS * 2^retryCount` delay, max 5 retries, resets on success.
|
||||
|
||||
Our approach: Wrap the `executeClaude` call in a retry loop. On transient errors (timeout, CLI crash), wait and retry. On permanent errors (auth failure, invalid session), fail immediately.
|
||||
|
||||
## Medium Effort (day or two)
|
||||
|
||||
### 5. Agent-Managed Tasks via File-Based IPC
|
||||
|
||||
The big one from nanoclaw. The agent can create, pause, resume, and cancel scheduled tasks dynamically during a conversation.
|
||||
|
||||
How nanoclaw does it: Custom MCP server with tools like `schedule_task`, `list_tasks`, `pause_task`, `resume_task`, `cancel_task`. Tasks stored in SQLite with schedule_type (cron/interval/once), context_mode (group/isolated), and full lifecycle tracking.
|
||||
|
||||
Our approach (simpler): The agent writes task definitions to `config/tasks.json` using the Write tool. The gateway polls this file periodically and schedules/unschedules tasks accordingly. Task format:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"id": "morning-briefing",
|
||||
"prompt": "Good morning! Check email and summarize.",
|
||||
"schedule_type": "cron",
|
||||
"schedule_value": "0 9 * * *",
|
||||
"status": "active",
|
||||
"target_channel": "1475008084022788312"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
The agent can add/remove/modify entries. The gateway watches the file and updates schedulers.
|
||||
|
||||
### 6. Multi-Turn Message Batching
|
||||
|
||||
Instead of sending one message at a time to Claude, batch multiple messages that arrive while the agent is processing.
|
||||
|
||||
How nanoclaw does it: Collects all messages since the last agent run timestamp, formats them as XML (`<messages><message sender="..." time="...">content</message></messages>`), sends the batch as a single prompt.
|
||||
|
||||
Our approach: When a message arrives while the agent is already processing for that channel, queue it. When the current processing finishes, batch all queued messages into a single prompt with sender/timestamp metadata. This prevents the agent from missing rapid-fire messages.
|
||||
|
||||
### 7. Idle Timeout for Sessions
|
||||
|
||||
Auto-clear sessions after a configurable period of inactivity per channel.
|
||||
|
||||
How nanoclaw does it: 30-minute idle timeout per container. After last output, a timer starts. If no new messages arrive, the container is closed and the session ends.
|
||||
|
||||
Our approach: Track `lastActivityTimestamp` per channel in the session manager. Run a periodic check (every 5 minutes) that removes sessions older than the timeout (default 30 min). This prevents stale sessions from accumulating and keeps memory.md relevant.
|
||||
|
||||
### 8. Per-Channel Isolation
|
||||
|
||||
Different channels could have different persona configs. A "work" channel gets a professional persona, a "fun" channel gets a casual one.
|
||||
|
||||
How nanoclaw does it: Per-group folders with separate CLAUDE.md, sessions, memory, and container mounts. Each group is fully isolated.
|
||||
|
||||
Our approach: Support a `config/channels/{channelId}/` override directory. If it exists, load persona files from there instead of the root config. Falls back to root config for missing files. This lets you customize identity.md or soul.md per channel.
|
||||
|
||||
## Bigger Features (multi-day)
|
||||
|
||||
### 9. IPC-Based Proactive Messaging
|
||||
|
||||
Let the agent send messages to Discord channels proactively — not just as a response to a user message.
|
||||
|
||||
How nanoclaw does it: Filesystem-based IPC. The agent writes a JSON file to `/workspace/ipc/messages/` with `{type: "message", chatJid: "...", text: "..."}`. The host polls the directory every second and sends the message.
|
||||
|
||||
Our approach: Create a `config/ipc/outbound/` directory. The agent writes JSON files there using the Write tool. The gateway polls every 2 seconds, reads new files, sends messages to the specified Discord channel, and deletes the processed files. This enables:
|
||||
- Agent sending follow-up messages after thinking
|
||||
- Agent notifying you about something it found during a heartbeat
|
||||
- Agent sending messages to channels it's not currently chatting in
|
||||
|
||||
File format:
|
||||
```json
|
||||
{
|
||||
"type": "message",
|
||||
"channelId": "1475008084022788312",
|
||||
"text": "Hey, I found something interesting in your email!"
|
||||
}
|
||||
```
|
||||
|
||||
### 10. Skills Engine (Simplified)
|
||||
|
||||
A system for adding capabilities via markdown skill files that get loaded into the system prompt.
|
||||
|
||||
How nanoclaw does it: Full manifest-based system with YAML manifests, dependency resolution, conflict detection, file operations (rename, delete, move), backup/restore, rebase capability, and resolution caching.
|
||||
|
||||
Our approach (much simpler): A `config/skills/` directory where each subdirectory contains a `SKILL.md` file. Skills are loaded into the system prompt as additional sections. The agent can reference skills by name. No dependency management — just markdown files that add context.
|
||||
|
||||
```
|
||||
config/skills/
|
||||
├── web-research/
|
||||
│ └── SKILL.md → "When asked to research, use WebSearch and WebFetch..."
|
||||
├── code-review/
|
||||
│ └── SKILL.md → "When reviewing code, focus on security, performance..."
|
||||
└── email-helper/
|
||||
└── SKILL.md → "When checking email, use the Gmail API via..."
|
||||
```
|
||||
|
||||
### 11. SQLite Storage
|
||||
|
||||
Replace JSON files with SQLite for messages, sessions, tasks, and state. Better for concurrent access, querying, and doesn't corrupt on partial writes.
|
||||
|
||||
How nanoclaw does it: Single SQLite database at `store/messages.db` with tables for chats, messages, scheduled_tasks, task_run_logs, router_state, sessions, registered_groups. Uses better-sqlite3 (synchronous API).
|
||||
|
||||
Our approach: Install better-sqlite3, create a single `config/aetheel.db` with tables for sessions, messages, tasks, and state. Migrate existing JSON files on first run.
|
||||
|
||||
### 12. Secrets Management
|
||||
|
||||
Prevent API keys and sensitive data from leaking through agent tool use.
|
||||
|
||||
How nanoclaw does it: Secrets passed via stdin (never written to disk), stripped from Bash subprocess environments via a PreToolUse hook, never mounted as files in containers.
|
||||
|
||||
Our approach: Since we use `--dangerously-skip-permissions`, the agent can run Bash commands that might echo environment variables. Add a sanitization step: before passing the prompt to Claude, strip any env var values that look like secrets from the system prompt. Also consider using `--disallowedTools Bash` if the agent doesn't need shell access.
|
||||
|
||||
## Priority Recommendation
|
||||
|
||||
1. Structured logging (immediate debugging value)
|
||||
2. Message history storage (conversation context)
|
||||
3. Retry with backoff (reliability)
|
||||
4. IPC-based proactive messaging (agent autonomy)
|
||||
5. Agent-managed tasks (dynamic scheduling)
|
||||
6. Conversation archiving (audit trail)
|
||||
7. Everything else as needed
|
||||
Reference in New Issue
Block a user