Hub and Spoke

Type: Automation architecture pattern

Definition

Hub and Spoke is a routing architecture where a central dispatcher (the hub) receives incoming requests and routes them to appropriate handlers (the spokes). The hub's job is classification and routing — it inspects the request and decides which handler processes it. Handlers are independent and specialized, each doing one type of work. This pattern is ideal for systems that receive varied input types and need to route each to the right processing path — like a WhatsApp command router that directs "status" to log checks, "report" to project reports, and "check [url]" to URL fetching.

How It Works

The hub listens for incoming requests — from a messaging channel, an API endpoint, or any input source. It classifies the request by inspecting content: keywords, command structure, intent signals. Based on classification, it routes to the appropriate spoke handler.

The spoke handlers are independent: each handles one type of request, doesn't know about other handlers, and returns its output to the hub. The hub then formats and delivers the response to the user. Spokes can be simple (single script execution) or complex (spawning sub-agents, running multi-step pipelines).

In OpenClaw, the hub lives in SOUL.md keyword routing rules. When a WhatsApp message arrives, the Gateway creates a session and the agent reads SOUL.md to determine routing: "status" → log check workflow, "report" → project report generation, "check [url]" → URL fetch and summarize. The hub is the Router's classification logic.

The power of Hub and Spoke is extensibility: add new handlers by updating routing rules, without touching existing handlers or the hub core. Each spoke is isolated — one failing doesn't crash others.

Key Properties

  • Central hub — classifies and routes; doesn't do the work itself
  • Specialized spokes — independent handlers, each doing one type of work
  • Keyword or intent routing — hub uses message content to determine handler selection
  • Extensible — add new handlers by updating routing rules; existing handlers unaffected
  • Fault isolation — one failing spoke doesn't crash others or the hub
  • OpenClaw implementation — SOUL.md keyword routing + Router logic for WhatsApp command routing
  • kelly-router — the Router acts as the hub; spokes are named leads (research-lead, project-lead, etc.)
  • simple-pipeline — individual spokes often implement Simple Pipeline internally
  • event-driven — Hub and Spoke can use event detection to trigger spoke handlers

Source Chapters