Autonomous Claude System

Claude works 24/7. User sets goals, not tasks. Quality over speed.

The Vision

Replace 30 terminal windows with one web conversation.

TODAY
W1
W2
W3
O1
W4
W5
W6
O2
W7
...
User overwhelmed
Watching 30 terminals, losing context
NOW

ORCHESTRATOR + POOL

(3-tier architecture)

User talks to Orchestrator
Orchestrator builds prompts
Raw Claudes + Specialists execute
User focused & calm
Talks only to Orchestrator

Three-Tier Architecture

Evolved from 6 actors to 3 tiers. Orchestrator subsumes Creator, Dispatcher, and Optimizer.

USER

Sets goals directly with Orchestrator

TIER 1: ORCHESTRATOR

1 persistent instance

Builds prompts via /build_prompt
Validates results
Dispatches queued prompts
Reviews quality patterns
Sends /clear to recycle
Talks to user directly
3-part prompt

TIER 2: RAW CLAUDE POOL

Up to 10 ephemeral

Generic instances
Specialized per-task via prompt
/verify → report → /clear → reuse
The prompt IS their specialization
can delegate to
TIER 3: SPECIALISTS

5-6 persistent — launched on boot, recycled with /clear

researcher

Investigation

web_designer

HTML, CSS, UI

cloudflare

Deploy, SSH

database

Schema, SQL

email

Email domain

Superseded Roles
Creator → User talks directly to Orchestrator
Dispatcher → Orchestrator dispatches prompts
Optimizer → Orchestrator reviews quality
Inbox system → Messaging API (/send-prompt)

3-Part Prompt Architecture

How the Orchestrator builds ~40-line prompts that turn generic Raw Claudes into specialists.

Part 1: IDENTITY (5-15 lines)

Source: bespokes table in Master_Claude.db

Task-specific framing, not generic roles. Tells the Claude what kind of worker it is for this task.

Part 2: TASK (front and center)

The actual work — prominent and clear

  • Domain knowledge from specialist_contexts table
  • Relevant learnings from FTS search
  • Completion criteria

Part 3: TOOLS (trigger-based, minimal)

Only 2-3 relevant skills, not everything

  • Trigger format: "After X → run /verify"
  • MCPs from focused_claude_mcps table
  • Reply-back messaging instructions
Key Insight

27 bespokes with multiple scopes in the DB. The prompt builder selects the right identity + context + tools per task. A Raw Claude receiving this prompt becomes the specialist it needs to be.

Prompt Builder Pipeline

Visual flow from task to ready-to-send prompt.

Orchestrator receives task

From user or queued work

/build_prompt skill fires

Invokes prompt_builder.py

prompt_builder.py queries Master_Claude.db

bespokes → identity
specialist_contexts → domain knowledge (with scope)
focused_claude_mcps → available tools
learnings_fts → relevant existing knowledge

Orchestrator assembles 3-part prompt

~40 lines, focused and minimal

Raw Claude

Ephemeral task worker

or

Specialist

Persistent domain expert

Context Hierarchy

Three layers of context injection, in priority order. Key insight: on-demand context > hints at action > pre-loaded docs.

Layer Mechanism When It Fires Token Cost
1 MCP on-demand docs (Context7) Claude pulls what it needs Zero until used
2 Contextual hints (tool_hints.json via hooks) At moment of action ~5 lines
3 Lightweight skills (SKILL.md with context: fork) When keyword triggers Fork context

This replaces pre-loading massive CLAUDE.md files. Each layer fires only when needed, keeping base context lean. The prompt builder uses layer 1 (MCP lookups) + layer 3 (skill triggers) when assembling prompts for Raw Claudes.

Boot Sequence

6 persistent Claudes launched on startup. Raw Claudes spawned on-demand.

Order Claude Why Persistent
1 Orchestrator Core — receives goals, builds prompts, validates
2 Researcher Always-on investigation
3 Web Designer Frequent UI work
4 Cloudflare/Infra SSH, deployment
5 Database Schema coordination
6 Email Separate domain
Raw Claudes: Spawned on-demand, up to 10, recycled with /clear. Each receives a 3-part prompt that makes it a task specialist for the duration of that task.

Communication Hub

Messaging API enables any-to-any communication. Replaced file-based inbox system.

Messaging API

SENDERS
User Orchestrator Raw Claude Specialist
VIA
POST /send-prompt/{id} POST /complete/{id} GET /messages/recent
Feature Description Status
Send Prompt POST to /send-prompt/{session_id} Working
Complete Signal POST to /complete/{session_id} Working
Sessions API /sessions/active lists all running Claudes Working
Message History /messages/recent for audit trail Working
Command Center Web UI for /chat, /messages, /sessions Working

Task Lifecycle

GOAL
(user)
PROMPT
(orchestrator builds)
RUNNING
(raw claude working)
VERIFY
(/verify → report)
COMPLETE
(/clear → recycle)
State Where Who Acts
queued Orchestrator queue Orchestrator dispatches when Raw Claude available
prompt_built /build_prompt output 3-part prompt assembled from DB
in_progress Raw Claude / Specialist Worker actively executing
verifying Orchestrator Orchestrator validates results
complete Logged /clear sent, Raw Claude recycled

Worker Completion Protocol

Worker thinks "done"
Runs /verify
(self-check before reporting)
Reports to Orchestrator
(via /send-prompt or /complete)
FAIL → Fix it
(Orchestrator sends fix instructions)
PASS → /clear
(learnings captured, recycled)

Key Principles

Complexity-Based Review Paths

Different validation levels based on task complexity. Orchestrator handles all review paths.

SIMPLE
Research, docs
Worker
Orchestrator
AUTO ✓
COMPLEX
Code, deploy
Worker
Orchestrator
Spot-check
CRITICAL
Infra, security
Worker
Orchestrator
User
ComplexityValidationHuman Review
SimpleQuick keyword matchNone — auto-proceed
ComplexGit evidence, file changesOrchestrator spot-check
CriticalDeep verification criteriaUser approval required

What Exists vs What To Build

Component Status Notes
Launcher API (localhost:5111) Working /launch, /send-prompt, /complete with validation
Sessions tracking Working Token fields, worker_type, learnings
Workers registry (workers.db) Working Named workers → active sessions, short_name for tabs
Idle detection Working worker_idle_detector.py reads status line
Validator Working validator/validator.py — catches fake completions
autonomous_supervisor.py Working Launches workers, monitors health
Worker completion protocol Working Orchestrator feedback loop validates before recycle
/build_prompt skill Working Orchestrator prompt building from DB context
prompt_builder.py Working DB context lookup for 3-part prompt assembly
specialist_contexts table Working Scoped domain knowledge (27 bespokes, multiple scopes)
orchestrator_notifier_service Superseded Replaced by messaging API
task_dispatcher.py Superseded Orchestrator handles dispatch directly
optimizer_analysis.py Superseded Quality review folded into Orchestrator

Proactive Orchestrator Triggers

Orchestrator monitors for conditions that need intervention.

Trigger Detection Action
Idle pool + no queued work Raw Claudes available, nothing to send Create proactive tasks or notify user
High error rates > 3 failures in 1 hour for same task type Pause, investigate, adjust prompt
Stale tasks Queued > 24 hours without progress Review blockers, reassign or escalate
Token thresholds Session approaching 80% context limit Preemptive /clear with handoff.md
Loop detection Same task sent > 3 times Analyze patterns, fix root cause
Quality drift Rising verification failure rate Adjust prompt templates, update bespokes

Open Questions

1. Pool sizing — What's the optimal Raw Claude pool size for typical workloads?
2. Prompt caching — Should identical task types reuse cached prompts?
3. Specialist vs Raw — When should Orchestrator route to a specialist vs build a prompt for a Raw Claude?
4. Context budget — How to balance prompt richness (more context) vs token efficiency (shorter prompts)?

Next Steps

Build 3-tier architecture (Orchestrator + Raw Pool + Specialists)
Done
Create /build_prompt skill + prompt_builder.py
Done
Populate specialist_contexts with 27 bespokes
Done
Messaging API + Command Center
Done
1
Prompt quality feedback loop
Track which prompts produce good results, tune templates
Medium
2
Raw Claude pool auto-scaling
Spawn/recycle based on queue depth
Medium
3
Context hierarchy optimization
Measure token savings from on-demand vs pre-loaded
Small
4
Iterate based on learnings
Ongoing
Document created: 2026-01-29 | Updated: 2026-02-10 | Status: Active
Updated: 3-tier architecture (Orchestrator/Raw Pool/Specialists), 3-part prompt system, prompt builder pipeline, context hierarchy, boot sequence. Superseded: Creator, Dispatcher, Optimizer, inbox system.