Skip to content

cclawton/supervisor

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

supervisor

Autonomous supervisor agent — triage prompt, Hermes cron configuration, and operator scripts for a two-layer agentic monitoring system.

Architecture

Three Hermes cron jobs run daily in sequence:

Job Time Role Delivery
tasks-watcher 07:10 Bash script — scans Tasks.md for aging tasks, writes run file Silent
capabilities-check 07:20 Hermes agent — researches model/tool updates, appends to known-capabilities.md Silent
supervisor triage 07:30 Hermes agent — triages all worker output, writes daily log, Signals if actionable Signal

Notifications arrive via Signal. The bin/ scripts and launchd/ plists are retired — retained for reference only.

Three pillars

  1. Agentic systems — headless supervisor/worker loop with producer/verifier separation
  2. Observability — daily audit trail in agents/daily-log/, append-only capabilities baseline
  3. Signal delivery — triage results delivered as a single Signal message (max 3 bullets), only when something is actionable

Repository layout

agents/
├── supervisor.md          # supervisor prompt (Hermes cron)
├── known-capabilities.md  # append-only capabilities baseline + deltas
├── README.md              # agent conventions
└── workers/
    └── capabilities-check.md  # capabilities-check worker prompt

bin/                       # RETIRED shell scripts (reference only)
launchd/                   # RETIRED launchd plists (reference only)
install.sh                 # RETIRED install script (reference only)

Operator commands

# List all cron jobs
hermes cronjob list

# Run supervisor manually
hermes cronjob run <supervisor_job_id>

# Pause / resume
hermes cronjob pause <job_id>
hermes cronjob resume <job_id>

# View today's audit log
open ~/ccl-home/agents/daily-log/$(date +%Y-%m-%d).md

Filesystem integration

The supervisor integrates with external tools and pipelines via the filesystem — no direct coupling required. Any tool that writes files to a watched directory becomes part of the loop.

Example: Obsidian + Writers' Room

An interactive content pipeline (Writers' Room) runs separately, writing article drafts and todo.md state files into an Obsidian vault. The supervisor scans those same vault paths every morning — checking checkbox states, file ages, and safety flags — and signals the user if anything needs attention.

Writers' Room orchestrator
  → writes draft.md / todo.md → Obsidian vault
                                      ↓
                              Supervisor reads vault paths
                                      ↓
                              Classifies: needs-review / blocked / stale
                                      ↓
                              Signals user (if actionable)

The two systems share no code and don't call each other. The vault is the integration point. This pattern generalises to any tool that writes structured files — CI outputs, scraper results, RSS caches, task managers — as long as the supervisor knows where to look and what to classify.

Design principles

  • Producer ≠ verifier: the agent that generates output is never the one that triages it
  • Deterministic work in bash, reasoning in LLM: date math and thresholds in scripts; classification and prioritisation in the supervisor agent
  • Silent workers, selective supervisor: workers never deliver output directly; only the supervisor signals, and only when something actually matters
  • Append-only audit trail: known-capabilities.md and daily logs are never rewritten, only appended

About

Autonomous supervisor agent — two-layer producer/verifier architecture with Hermes cron and Signal delivery

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages