hermes - 💡(How to fix) Fix RFC: Agent-native task relay with auto-forking subagents + async human approval gates

Summary

I'd like to gauge interest in upstreaming an agent-native task relay system with auto-forking subagents + async human approval gates. I think it complements (not replaces) the existing "Delegates and parallelizes: Spawn isolated subagents for parallel workstreams" feature.

The core idea: instead of a human dragging cards across a Kanban board to coordinate work across agents/profiles, agents themselves emit next-step pointers in their results, which auto-spawn follow-up tasks — gated optionally by async human approval. A small watcher polls for approved tasks and routes them.

I've been running this in production for ~10 days. Existing subagent-spawn paths are unchanged; this is additive.

Why this exists (vs a Kanban board / manual orchestration)

In a multi-profile Hermes deployment, real work usually looks like:

Profile A finishes a turn → result mentions "should be reviewed by Profile B" → Profile B should pick it up → Profile B's result mentions "needs follow-up by Profile A or C" → ...

Coordinating this manually means the user is the message bus. Coordinating it via a traditional Kanban (Trello / Linear / Jira) means the user is also the card-mover. Neither scales when agent-to-agent handoffs become the dominant flow.

A task relay with two channels:

Channel 1 — autofork (no human in loop): worker writes @<next-profile> in a structured next_steps field of its result. A watcher parses and auto-spawns the follow-up task. Used for continuation, review, follow-up, downstream work that the worker itself has authority to initiate.

Channel 2 — submit (human approval required): explicit dispatch submit --to <profile> --title ... --content ... posts a PENDING task that needs the human's approve <id> / reject <id> reply before the target picks it up. Used for net-new work or anything cross-team.

A 3-second poller watches the PENDING / APPROVED queues and routes accepted tasks into the target profile's inbox, where the existing subagent-spawn API takes over.

Why I think this beats Kanban for agent workflows

Kanban is human-centric workflow tooling retrofitted onto agent work. This is agent-native from the ground up — humans participate only when authority crossing requires it.

Design sketch

[Channel 1 — autofork]

worker finishes turn
       │
       ▼
   result.next_steps = "@profile_b review the diff"
       │
       ▼
   sweep_autofork() parses → spawns child task → status = APPROVED
       │
       ▼
   watcher (3s poll) sees APPROVED → injects into profile_b inbox
       │
       ▼
   profile_b's gateway picks up on next turn → processes


[Channel 2 — submit]

human or agent calls: dispatch submit --to <profile> --content "..." --parent <id>
       │
       ▼
   status = PENDING → notification posted to approver's chat
       │
       ▼
   approver replies "approve <id>" (or clicks button in optional UI)
       │
       ▼
   status = APPROVED → watcher routes → target picks up

Optional pieces (configurable)

• dispatch-memory recall — before submit, agent runs recall --scope today|week|month|full to find related open tasks and auto-fills --parent <id> so relay chains don't fragment when titles drift
• result_summary schema — standardized sections (## Summary / ## Artifacts / ## Next steps) so downstream agents can parse predictably without LLM extraction
• Auto-expire — PENDING tasks past TTL silently drop
• Conflict detection — submit checks against in-flight tasks writing to the same file to prevent two workers stomping each other

What this is NOT

• Not a Kanban replacement for human teams — this is agent-native; humans participate via chat approvals
• Not a new transport — uses Hermes's existing platform layer (Feishu / Telegram / Discord / CLI / Slack / WhatsApp / Signal)
• Not opinionated about the UI — works headless via chat; an optional 1-click web UI is bonus, not required
• Not a workflow engine (no DAG, no conditional logic) — pure relay + approval gate

Use case it solves for me

I run a 3-profile Hermes deployment where the workflow is constantly:

1. profile_executor does X
2. result mentions "needs profile_advisor to review"
3. autofork spawns the review task
4. profile_advisor reviews, result mentions "needs profile_intelligence for context"
5. autofork spawns intelligence-gathering task

Before the relay, I was the message bus copy-pasting between three chat threads. After: I'm only the approver of net-new work — continuation chains run themselves.

Questions before I open a PR

1. In scope? Does this fit alongside the existing subagent-spawn API, or do you see it as out of scope (better as a third-party orchestrator on top of Hermes primitives)?
2. Boundary with Spawn isolated subagents — is autofork's "worker emits next-step → system spawns" something the existing API can already express? I might just be re-inventing on top of a primitive I missed.
3. Approval gate UX — chat-only (simple but couples to platform) vs a generic web UI (more work, transport-agnostic) — preferences?
4. Persistence — I currently use a flat JSON state file; should this go through whatever DB Hermes prefers (SQLite? something else)?
5. Scope split — if you like the idea but the surface is too large, would you prefer minimal-first: just the autofork channel + chat approval, defer recall / schema / conflict-detection to follow-ups?

Not opening a PR yet — checking interest first. Related: I've also opened #31385 (subprocess executor bridge), #31387 (SSoT drift hook), #31388 (multi-profile shared memory). Happy to sequence all four however you prefer.

Thanks!