Plan: Executor Orchestrator — Spawned Worker Pattern

Date: 2026-05-14 Status: Research needed Parent: executor-v2-redesign Linked: executor-orchestrator-redesign

Background (from session 2026-05-14)

Alex's request (verbatim intent):

Ты (орёл) должен спавнить воркер процессы, от лица другого бота (не Eagle а Executor), и как оркестратор реагировать на его "я сделал" / запросы пермишенс, читать недавний контекст (не весь тред) — и аппрувить/денаить автоматом, либо эскалировать и меншенить меня если ambiguity.

Also from Kraken dictation (2026-05-14, not saved due to vault bug):

Собирать планы в executor чтобы по крону запускались конкретные работы — не как сейчас что каждый агент по поставленной задаче работает, а чтобы автоматически спавнились если в папке Obsidian есть работа.

Core Design

Eagle (orchestrator, Zulip topic)
  ↓ spawn
Executor (worker, separate process/session)
  ↓ messages to #executor topic
Eagle monitors #executor (sliding window, last ~20 msgs)
  ↓ auto-approve obvious / escalate ambiguous
  ↓ @mention Alex only for ambiguity or high risk

Research Findings (2026-05-14)

Q1: How to spawn Executor as separate bot persona?

Answer: Hermes Profiles — the correct mechanism.

Hermes supports named profiles: each profile = separate ~/.hermes/profiles/<name>/ with its own SOUL.md, .env, config.yaml, gateway, bot token, memory, cron jobs.

hermes profile create executor --clone    # clone Eagle config
# then configure:
echo "You are Исполнитель..." > ~/.hermes/profiles/executor/SOUL.md
# set different Zulip bot token for "Executor" bot in Zulip
nano ~/.hermes/profiles/executor/.env     # ZULIP_BOT_EMAIL=executor-bot@zulip.local
executor gateway install                  # separate systemd/launchd service

Key properties:

Each profile can have its own Zulip bot token → appears as different bot in UI
executor gateway start runs independently from Eagle
Cron jobs in executor profile run under executor's identity
Safety: if two profiles share same Zulip token → second gateway is blocked with error

Spawn pattern: Eagle triggers Executor by sending a message to the Executor's Zulip topic (or writing to a shared queue). Executor's gateway picks it up as a new session.

OR: Eagle uses cronjob(action='create', schedule='once', ...) with executor profile — but this stays within Eagle's identity. For true persona separation → need separate profile with separate gateway.

Recommended: Option B (separate profile + gateway)

executor profile with its own SOUL, its own Zulip bot ("Исполнитель")
Eagle sends trigger message to #executor as Eagle → Executor bot responds as Executor
Natural separation of concerns, no code changes needed

Q2: How does Eagle monitor #executor without blocking?

Answer: Hermes cron every 2 min (simplest, already proven infrastructure)

Eagle cron job: */2 * * * * → query Zulip REST for recent #executor messages → parse [REQUEST]/[ESCALATE] tags → auto-approve or @mention Alex
Alternative: Zulip webhook → Hermes webhook trigger (needs setup, lower latency)
Cron is sufficient given that executor tasks run for minutes-hours, not seconds

Q3: Message protocol format

Need a structured format Executor uses so Eagle can parse O(1) without LLM:

[REQUEST:create_worktree] branch=fix/tab-preview-stuck run_id=42
[REQUEST:run_tests] scheme="macOS UI Tests CI"
[STATUS:investigation] Analysing bug...
[STATUS:pr_open] PR #1234 https://github.com/...
[DONE:pr_ready] CI green, no comments
[ESCALATE:scope_expansion] Found unrelated issue in TabBar.swift

Q4: Plans-to-executor trigger (from Kraken dictation)

If there are "work items" in an Obsidian folder (e.g. work/plans/executor-queue/), cron should auto-spawn workers.

Research: what's the folder-watching mechanism? Options:

Eagle morning-brief cron checks folder, spawns workers
Dedicated executor-plans-watcher cron (every 30 min)
Executor-analyzer.sh already does this via DB — maybe just add Obsidian→DB bridge

Auto-Approval Rules (draft)

Action	Auto	Rule
create worktree	✅ approve	safe, reversible
run build	✅ approve	safe
run tests	✅ approve	safe
open draft PR	✅ approve	draft = no merge
push to branch	✅ approve	executor branch only
post Asana comment	⚠️ escalate	external side effect
merge PR	❌ always escalate	irreversible
modify files outside worktree	❌ deny	scope violation
scope expansion	❌ deny + notify	default policy

Implementation Phases

Research (this phase) — answer Q1-Q4 via web search + Hermes source inspection
Protocol — define message format, write Executor posting code
Eagle monitor — cron job that reads #executor, applies auto-approval rules
Worker spawn — Eagle can trigger Executor on demand
Plans watcher — Obsidian folder → auto-spawn (Q4)
Test — dry run with a real executor task

5.4 KiB Raw Blame History