[Feature]: Enable specialized sub-channel agents with independent configurations

[louisdevzz]

Summary

Enable each sub-channel (Telegram forum topic, Discord channel, Slack channel) to be assigned a specialized agent with its own system prompt, tool allowlist, and model configuration. A Telegram supergroup, Discord server, or Slack workspace can host multiple sub-channel agents running in parallel, each operating independently.

Problem Statement

Currently, ZeroBuild operates as a single agent per platform instance. In multi-channel environments like Telegram supergroups with forum topics, Discord servers with multiple channels, or Slack workspaces, all channels share the same agent configuration. This creates several limitations:

1. Context pollution: Different channels have different purposes (e.g., #general vs #dev-support vs #announcements), but the agent treats all messages as part of the same context
2. Permission sprawl: All channels get the same tool access, which may be inappropriate (e.g., giving deployment tools to a public channel)
3. Personality mismatch: One system prompt cannot serve diverse channel purposes effectively
4. No channel specialization: Cannot have a coding assistant in #dev and a marketing assistant in #growth

Proposed Solution

Configuration Schema

sub_channel_agents:
  enabled: true
  
  agents:
    - id: "dev-support"
      name: "DevBot"
      # Platform-specific channel matching
      match:
        telegram:
          forum_topic_id: 12345
        discord:
          channel_id: "987654321"
        slack:
          channel_id: "C12345678"
      
      # Agent-specific configuration
      system_prompt: "You are a senior Rust developer..."
      model: "gpt-4"
      temperature: 0.2
      
      # Tool allowlist (subset of available tools)
      allowed_tools:
        - shell
        - file_read
        - github_*
      
      # Channel-specific memory namespace
      memory_namespace: "dev-support"
      
      # Optional: inherit base config + overrides
      extends: "base"
      overrides:
        temperature: 0.1

Key Components

1. Channel Resolver: Platform-specific module to identify which sub-channel a message originates from
2. Agent Registry: In-memory or persistent store mapping channel IDs to agent configurations
3. Isolated Context: Each sub-agent maintains its own conversation history and memory
4. Tool Proxy: Middleware that filters tool calls based on agent's allowlist
5. Model Router: Routes to different models/providers per agent configuration

Parallel Execution Model

┌─────────────────────────────────────┐
│         Platform Connector          │
│  (Telegram / Discord / Slack)       │
└─────────────┬───────────────────────┘
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
┌───────┐ ┌───────┐ ┌───────┐
│Agent A│ │Agent B│ │Agent C│  ← Different sub-channels
│#dev   │ │#design│ │#admin │
└───────┘ └───────┘ └───────┘

Each agent runs independently with:

• Dedicated memory namespace
• Isolated tool permissions
• Custom system prompt
• Independent model selection

Non-goals / Out of Scope

• Cross-channel agent communication (future feature)
• Dynamic agent creation via chat commands (admin-only config for now)
• Shared memory between sub-agents (explicitly isolated by design)
• Channel migration/hot-swapping agents without restart
• Multi-agent orchestration in a single channel

Acceptance Criteria

• Configuration schema supports sub-channel agent definitions
• Telegram forum topics can be matched by topic ID
• Discord channels can be matched by channel ID
• Slack channels can be matched by channel ID
• Each sub-agent loads its own system prompt from config or file
• Tool allowlist restricts available tools per agent
• Model configuration (provider, model name, temperature) per agent
• Memory isolation: each agent has its own conversation history
• Fallback to default agent when no sub-channel match found
• Admin commands to list active sub-agents and their configs
• Documentation with example configurations for each platform

Architecture Impact

Current Flow

Message → Platform Handler → Single Agent → Response

New Flow

Message → Platform Handler → Channel Resolver → Agent Registry → 
Matched Agent → Response

New Modules

• channel_resolver.rs - Extract channel identifiers from platform-specific message metadata
• agent_registry.rs - Load and manage sub-agent configurations
• agent_context.rs - Per-agent context isolation
• tool_filter.rs - Middleware for tool allowlist enforcement

Data Changes

• New table/collection: sub_channel_agents with fields for channel matching, config overrides
• Memory keys gain namespace prefix: memory:{namespace}:{key}

Risk and Rollback

Risk	Likelihood	Impact	Mitigation
Config complexity increases	Medium	Low	Provide templates and validation
Memory usage increases with many agents	Medium	Medium	Implement agent TTL/lazy loading
Breaking change to existing single-agent setups	High	High	Sub-agents are opt-in via config flag
Channel ID format changes across platform versions	Low	Medium	Abstract channel identifiers
Permission misconfiguration	Medium	High	Config validation + dry-run mode

Rollback Plan

• Feature is opt-in via sub_channel_agents.enabled = true
• Default behavior unchanged (single global agent)
• Can disable per-agent or globally without data loss

Breaking Change

No breaking changes. This feature is opt-in and defaults to existing single-agent behavior.

Data Hygiene Checks

• Validate all channel IDs exist at startup (optional strict mode)
• Ensure memory namespaces don't collide with reserved keys
• Check tool allowlists only contain valid tool names
• Verify model configurations are valid before agent spawn
• Audit log for sub-agent creation/config changes