Loom — Background Workers Scheduler

Name: Loom | Leader: V (COO) | Group: Platform | Status: Active Org Chart: Interactive Org Chart

---

Identity

Loom is the unified scheduler that orchestrates 12 autonomous background workers via GitHub Actions. Every worker runs on its own schedule — some daily, some weekly — and Loom manages the execution engine, worker registry, enforcement context loading, and output validation. It's the loom that weaves all the background threads into a coherent operational fabric.

Philosophy: Autonomy requires orchestration. Individual workers are powerful; a unified scheduler makes them reliable.

Origin: Background workers started as individual scripts with separate cron jobs. Scheduling conflicts, missing enforcement context, inconsistent output validation — all problems of fragmentation. Loom unified them: one runner, one registry, one enforcement loader, one validation layer. The hourly GitHub Actions cron triggers the runner, which checks the registry and executes workers whose schedule matches.

---

Role Type

Autonomous infrastructure. Loom runs hourly via GitHub Actions cron.

Loom doesn't produce reports itself — it ensures all 12 workers execute correctly, with enforcement context loaded and output validated.

Activated by: GitHub Actions hourly cron, "Run background workers" (manual), npx tsx agents/background-workers/runner.ts (CLI)

---

For Humans

When to engage	Automatic — runs hourly. Manual: "Run background workers" or "Check worker status." When a specific worker needs debugging, check the registry and execution logs.
What you'll get	Execution status for all 12 workers. Enforcement context confirmation. Output validation results. Any failures escalated.
How it works	Hourly cron triggers the runner. Runner reads worker-registry.json for schedule definitions. Enforcement loader provides standalone CI context (no CLAUDE.md dependency). Output validator checks worker results. Each worker runs in its scheduled time window.
Autonomy	Fully autonomous. GitHub Actions triggers hourly. No human intervention unless failures escalate.

Key Value Indicators

KVI	VP Dimension	What It Measures	Anti-Pattern
Execution Reliability	vp_cap_operational_independence	All scheduled workers execute on time, every time	Not: worker runs logged
Enforcement Integrity	vp_cap_ute_maturity	Every worker runs with full enforcement context loaded	Not: enforcement files present
Zero Silent Failures	vp_val_platform_leverage	Every failure is detected, logged, and escalated	Not: errors caught

---

For AI

Activation	GitHub Actions hourly cron, manual trigger, CLI npx tsx agents/background-workers/runner.ts
Skills	None — Loom IS the execution framework
Receives from	GitHub Actions (cron trigger), worker-registry.json (schedule definitions)
Reports to	V (leader). Output consumed by: all 12 managed workers, /daily-ops (worker health)
Dependencies	GitHub Actions, Node.js runtime, worker-registry.json, enforcement-loader.ts, output-validator.ts

12 Managed Workers

Worker	Agent Name	Schedule	Status
pattern-memory-analyzer	Echo	Daily 3AM CT	Active
instruction-optimizer	Refiner	Weekly Sun 3AM CT	Active
staleness-detector	Archivist	Weekly Sun 4AM CT	Active
relationship-sentinel	Sentinel	Daily 6AM CT	Active
content-queue-scanner	Forge	Weekly Mon 3AM CT	Active
data-integrity	Audit	Weekly Sat 3AM CT	Active
website-health-scanner	Lookout	Weekly Fri 2PM CT	Active
media-pre-production	Prelude	Daily 6AM CT	Active
media-post-production	Encore	Daily 4PM CT	Active
media-distribution	Broadcast	Daily 10AM CT	Active
media-youtube-comments	Broadcast	Daily 8AM CT	Active
media-linkedin-events	—	Weekly Sun 6PM CT	Disabled

Architecture

GitHub Actions (hourly cron)
    ↓
runner.ts (execution engine)
    ↓
worker-registry.json (schedule definitions)
    ↓
enforcement-loader.ts (standalone CI context)
    ↓
[Worker execution]
    ↓
output-validator.ts (result validation)

Design Principles

• Workers read but NEVER write HubSpot
• Enforcement is portable (standalone loader, no CLAUDE.md dependency)
• Each worker is independently testable
• Registry is the single source of truth for schedules

---

Current State (Honest Assessment)

Active and operational. All 12 workers registered. 11 active, 1 disabled.

What works well:

• Unified runner with single registry
• Standalone enforcement loader (CI-portable)
• Output validation for every worker
• GitHub Actions hourly cron reliable
• Each worker independently testable

What doesn't work:

• No retry logic. Failed workers don't automatically retry — they wait for the next scheduled window.
• No worker health dashboard. Execution status requires checking GitHub Actions logs manually.
• esbuild compatibility. Workers must use line comments (//) not block comments due to esbuild limitation with em dashes and */.

---

Connections

Connected To	Direction	What Flows
All 12 workers	Loom → Workers	Execution scheduling, enforcement context, output validation
GitHub Actions	GH Actions → Loom	Hourly cron trigger
V's /daily-ops	Loom → daily-ops	Worker execution health in morning briefing
Klaxon (V)	Loom → Klaxon	Worker failures escalated to alert manager

---

Leadership Commentary

V (COO): Loom is the backbone of autonomous operations. 12 workers running on schedule without human intervention — that's what operational independence looks like. The standalone enforcement loader was the key design decision: workers run in CI without access to CLAUDE.md, so enforcement had to be portable. My focus: adding retry logic and a worker health dashboard so failures are visible without checking GitHub Actions logs.

Sage (CCO): The background workers that serve relationship intelligence — Sentinel, content queue scanner — depend on Loom's reliability. If Sentinel doesn't run at 6AM, relationship signals go undetected for a day. Loom's execution reliability is a relationship intelligence dependency.

Pax (CFO): The background-workers framework is the most efficient infrastructure investment in the system. 12 workers, one runner, one cron job. The operational cost is near-zero (GitHub Actions minutes). The operational value is 12 autonomous processes that would otherwise require manual execution. That's leverage.

---

Filed: 2026-03-08 | Companion: Org Chart Implementation: agents/background-workers/ (runner.ts, worker-registry.json, enforcement-loader.ts, output-validator.ts) Schedule: GitHub Actions hourly cron Workers managed: 12 (11 active, 1 disabled)