---
title: "Executor Spawning Research"
aliases:
  - "Executor Spawning"
  - "executor-spawning-research"
  - "Spawned Worker"
created: '2026-05-14'
updated: '2026-05-31'
tags:
  - personal-os
  - executor
  - research
  - architecture
related:
  - "[[personal/projects/personal-os/executor-orchestrator-redesign]]"
  - "[[personal/projects/personal-os/executor-v2-redesign]]"
---
# 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.

```bash
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

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

---

## Связанные заметки
- [[personal/projects/personal-os/executor-orchestrator-redesign|Executor Orchestrator Pattern]]
- [[personal/projects/personal-os/executor-v2-redesign|Executor v2 Redesign]]