[EPIC] Sovereign Orchestrator — remove Alexander from dispatch loop #354

New Issue

Timmy · 2026-04-07T16:02:07Z

Timmy commented

2026-04-07 16:02:07 +00:00

Goal

Timmy becomes the orchestrator. Alexander reviews results, not manages processes. No more Telegram thread-hopping. No more manual Gitea issue assignment.

Research (committed to timmy-config)

Full 444-line evaluation of 14 frameworks: orchestration-research.md

Recommendation: Phased Approach

Phase 1: Custom Python Orchestrator (~800 lines)

Build it ourselves with what we have:

Reads Gitea backlog across all repos
Scores and prioritizes issues (urgency, complexity, agent fit)
Dispatches to agents via their APIs (Groq loop, Ezra gateway, Bezalel gateway)
Monitors results via our poka-yoke guards
Posts ONE consolidated report to Alexander (not N agent threads)
Uses existing infrastructure: Gitea API + Hermes gateways + guard scripts

Phase 2: CrewAI Layer

Adopt CrewAI (48K stars, MIT, production-grade) for sophisticated agent reasoning:

Define crew roles: Coder, Reviewer, Researcher, DevOps
Each role maps to an agent with its own LLM backend
Timmy runs as Crew Manager
Human-in-the-loop for Alexander to approve major decisions

Phase 3: Distributed Execution

Add Temporal or durable task queues for cross-VPS reliability:

Jobs survive VPS reboots
Retry logic, timeouts, dead-letter queues
Full observability

Why NOT just adopt a framework now?

No framework solves our actual problem: dispatching to DISTRIBUTED agents across Mac + 3 VPSes. They all assume agents run in one process. We need the custom orchestrator layer regardless.

Sub-issues below.

## Goal Timmy becomes the orchestrator. Alexander reviews results, not manages processes. No more Telegram thread-hopping. No more manual Gitea issue assignment. ## Research (committed to timmy-config) Full 444-line evaluation of 14 frameworks: orchestration-research.md ## Recommendation: Phased Approach ### Phase 1: Custom Python Orchestrator (~800 lines) Build it ourselves with what we have: - Reads Gitea backlog across all repos - Scores and prioritizes issues (urgency, complexity, agent fit) - Dispatches to agents via their APIs (Groq loop, Ezra gateway, Bezalel gateway) - Monitors results via our poka-yoke guards - Posts ONE consolidated report to Alexander (not N agent threads) - Uses existing infrastructure: Gitea API + Hermes gateways + guard scripts ### Phase 2: CrewAI Layer Adopt CrewAI (48K stars, MIT, production-grade) for sophisticated agent reasoning: - Define crew roles: Coder, Reviewer, Researcher, DevOps - Each role maps to an agent with its own LLM backend - Timmy runs as Crew Manager - Human-in-the-loop for Alexander to approve major decisions ### Phase 3: Distributed Execution Add Temporal or durable task queues for cross-VPS reliability: - Jobs survive VPS reboots - Retry logic, timeouts, dead-letter queues - Full observability ## Why NOT just adopt a framework now? No framework solves our actual problem: dispatching to DISTRIBUTED agents across Mac + 3 VPSes. They all assume agents run in one process. We need the custom orchestrator layer regardless. ## Sub-issues below.

Timmy self-assigned this 2026-04-07 16:02:07 +00:00

Timmy referenced this issue

2026-04-07 16:02:08 +00:00

[ORCHESTRATOR-1] Build Gitea backlog reader + priority scorer #355

Timmy referenced this issue

2026-04-07 16:02:09 +00:00

[ORCHESTRATOR-2] Build agent dispatcher — route issues to the right agent #356

Timmy referenced this issue

2026-04-07 16:02:09 +00:00

[ORCHESTRATOR-3] Build consolidated reporter — one report for Alexander #357

Timmy referenced this issue

2026-04-07 16:02:10 +00:00