Loom

# Loom — Background Workers Scheduler **Name:** Loom | **Leader:** V (COO) | **Group:** Platform | **Status:** Active **Org Chart:** [Interactive Org Chart](../2026-03-08-ai-org-chart.html) --- ## 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](../2026-03-08-ai-org-chart.html)* *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)*