Elrond Block owner

Elrond's support role is the orchestration heart of the whole pipeline — the always-on dispatch, diagnosis and bookkeeping that every other block leans on. The Dispatcher runs the engineering queue lifecycle: enqueue/dequeue, dispatch_next with a capacity gate plus execution creation and status transitions, failure detection, prerequisite unparking, Albus auto-retries, and pause/resume. The Initiative Diagnostician inspects an initiative's state before any dispatch and emits a recommendation (RESUME / REFIRE_REVIEWER / BUMP_CYCLES_AND_REFIRE / FILE_FOLLOWON / REFUSE_CLOSED / REFUSE_NO_OP) with plain-English rationale, risks and alternatives — applying deterministic rules for clear-cut cases and calling Claude for ambiguous ones — and is consulted by the dispatcher before enqueue. The Remediation Detector is the single source of truth for scanning a title+description for CAROL-INI-NNN references near remediation keywords and conservatively resolving the one confident reference to a target row. The Bypass Shipper ships an initiative via canonical bypass by writing one BYPASS-tagged audit-trail row with a session-event and Palantir trail, touching nothing else. The Daily Planner builds a prioritized plan from the intelligence brief and pending steps, splitting automated work from Orion work. The Tracker syncs planner executions into agent_tasks in Org, tallying each agent's passes, failures and pending. The App Steward and Elrond's Reporter round it out, keeping his apps alive and posting attribution. This matters because dispatch, diagnosis, bypass shipping and daily prioritization are the connective tissue without which no initiative would move. It runs continuously and on schedule across the pipeline, with the diagnostician's recommendation and the dispatcher's failure/unpark/retry paths covering the edge cases.

Archon

Support is the always-on backbone that serves every block, and Archon's support presence is about keeping his design knowledge and his apps continuously available rather than only firing inside a specific stage. His App Steward keeps Archon's registered apps alive by detecting down apps and relaunching them, scoped to just his apps. The Design Registry maintains a live catalog of approved design patterns — reading them from the designs database, grouping and making them searchable, providing lookup functions by type or keyword for other droids, listing available app templates, and generating a readable design-context summary for Claude sessions — so patterns actually guide work instead of sitting unused. The Template Matcher does semantic search over that catalog and the template library to find the closest match for a described task, reporting a similarity score and the specific adaptations needed, and recommending whether to adapt an existing pattern, create a new one, or reference several as inspiration. This matters because the design-review and compliance gates everywhere else depend on there being a live, queryable pattern catalog to align to, and on Archon's apps staying up. It runs continuously and on demand across the whole pipeline rather than at one trigger point, with the steward's relaunch path covering the app-down scenario.

Argus

Argus's support footprint is small but it follows the same backbone principle — keeping his own registered apps alive so the testing surfaces he owns are always reachable. His App Steward is an owned instance of the shared app-liveness mechanism: it detects when any of Argus's registered apps is down and relaunches it, scoped strictly to his apps. This matters because Argus's verification and regression work depends on his apps being up; if a tester-owned app silently dies, reviews that rely on it would fail for the wrong reason. It runs continuously in the support block rather than at a single pipeline trigger, quietly health-checking and relaunching as needed. In the normal case there is nothing to do; the relaunch path fires only when one of his apps has gone down.

Merlin

Merlin's support role is the execution-side backbone — the always-on machinery that validates, dispatches and upgrades the work his execution engine runs. The Plan Validator validates the complete chain Initiative to Tasks to Jobs to Activities, confirming the execution is linked to an initiative, that strategic tasks have their child jobs, that each job's activities exist with assigned and registered agents, and blocking execution (marking the initiative failed) if anything critical is missing. The Step Execution Orchestrator dispatches agent bundles to executors: it reads the job, matches the agent role to its executor droid, composes a prompt with task context and any retry feedback, launches the executor as a subprocess with a timeout, records the run, and reports completion status, output, errors and resource usage. The Foreman Dispatch creates executions and seeds plans, marks runs failed, cancels, and resumes/dispatches the pipeline (relocated from the planner app under CAROL-INI-0928-04/R3). The Scanner runs weekly to find tool-upgrade opportunities, and the App Steward keeps Merlin's registered apps alive. This matters because dispatch and chain-validation are what actually launch and gate execution — an invalid or unagented chain that reached execution would fail downstream in a far more expensive way. It runs continuously (dispatch, validation, app-stewarding) plus on a weekly schedule (the upgrade scan), with the validator's block-and-fail path covering the broken-chain scenario.

Radagast

Radagast is the steward-and-deployer of the support backbone — the agent who keeps critical shared infrastructure alive and is the sole accountable executor of privileged actions. The App Watchdog health-checks the critical shared apps (initiatives, planner, gateway, auth) and relaunches any that are down, now triggered by the Hermione Scheduler so its runs are audited and the supervisor is itself supervised. The Deployer promotes or rolls back prod apps via deploy.sh and smoke-tests the live URL, as the accountable executor for the deploy phase of deploy-bearing skills. The Radagast Sudo Daemon is a long-running privileged daemon that executes Radagast's allowlisted admin actions as the dedicated radagast OS user — polling the admin-request queue, re-verifying each request (authentic + active + reviewed), enforcing the allowlist, executing via the radagast user's scoped sudo grant, and writing the admin-log — so caroladmin droids enqueue verified requests and never run sudo directly. The Radagast Sudo Executor runs a narrow allowlist of parameterized sudo ops (carol-* systemctl, Carol nginx confs, render routes) only after verifying the initiative is authentic+active+reviewed, logging every action and routing anything non-allowlisted to Orion. Radagast's Reporter posts the attribution. This matters because shared apps dying or unaudited root access would compromise the entire platform; centralizing privilege here keeps a human-in-loop boundary on dangerous ops. It runs continuously (watchdog, daemon) and on demand (deploy, sudo), with the verify-and-route-to-Orion path covering non-allowlisted or unverified requests.

Sage

Sage's support role is the analyst's library-and-intelligence backbone — owning the templates everyone plans against and producing the daily read on session health. The Template Keeper owns, curates and serves Carol's checklist templates (the analyst's methods library) as the single source any executor reads via the shared templates accessor, and accepts and reviews template change-suggestions — making Sage the accountable owner of templates, not merely their custodian. The Enabler Intelligence droid reads what actually happened in the session — enabler findings, retry failures, droid failures from the session ledger — counts issues, resolutions and unresolved work, detects recurring patterns where the same error appears repeatedly, sorts unresolved issues into routine pipeline fixes versus things needing new capability or policy thinking (routed to Orion), and saves a brief for downstream use. His App Steward keeps Sage's registered apps alive. This matters because every planner and executor reads the templates Sage owns, and the daily brief is what feeds Elrond's morning prioritization — without them, planning would have no canonical method library and the pipeline would have no read on its own recurring failures. It runs continuously (template serving, app-stewarding) and daily (the intelligence brief), with the routine-vs-Orion split covering which issues escalate.