HQ as Router

An HQ is a directory holding centralized memory for a group of agents (e.g. crossmem-hq for crossmem-bridge, crossmem-chrome, …). With a [router] block in its Aidefile, the HQ also becomes the dispatch entry point for inbound GitHub Issues opened against the HQ repo. Instead of running claude on the HQ itself, the daemon picks an HQ member agent and dispatches the issue to it via the local sidecar transport.

Why

Without [router], an issue opened on yiidtw/crossmem-hq triggers a claude run inside the HQ directory — wasting tokens, and producing a context that doesn't know about the actual code repos. With [router], the daemon hands the issue off to whichever member agent is best suited (per the bandit) or to all of them (fanout).

Setup

Add a [router] block to the HQ's Aidefile:

[persona]
name = "crossmem-hq"

[trigger]
on = "issue"

[router]
mode = "bandit"            # "bandit" | "round-robin" | "fanout"
# candidates = ["crossmem-bridge", "crossmem-chrome"]   # optional override

Then register the HQ like any other agent:

aide register ~/claude_projects/crossmem-hq

Modes

Candidate resolution

• If [router].candidates is non-empty, that explicit list wins.
• If empty, the HQ's group members (from ~/.aide/config.toml) are used, matched by groups[*].hq == <HQ directory>.

Register-time validation

When you aide register an HQ with explicit candidates, every name must already be registered. Empty candidates is fine — group lookup happens at fire time.

What the routed agent sees

The dispatched task text is prefixed with HQ context so the agent knows where the work originated:

[from HQ crossmem-hq issue #42]
<issue title>

<issue body>

On the GitHub side

After successful routing the daemon comments on the issue (dispatched to <agent> or fanned out to N agents: ...) and closes it. Per agent execution still produces its own dispatch event log entries downstream through aide events.