Hermes Wiki
opportunities/2026-08-14-incremental-RBC_Work

Opportunities: Wiki Knowledge Applicable to RBC Work Projects — Incremental Pass, 2026-08-14

Scope: this pass checks this window's Architecture/CaseStudies and Tools additions against item #28 ("Config drift, authorization agent... autonomously detect, analyze, and correlate configuration, drift, events against approved CR") and item #3 (Aegis — the ExtraHop/Corvil/Elastiflow telemetry stack).

Item #28's config-drift agent is the fourth instance of a pattern the vault now has three worked examples of

This window's synthesis note names a four-part reconciliation loop (declared state → continuous observation of actual state → automated fix for the narrow safe case → explicit escalation, never silent guessing, for anything outside that case) that recurs across three unrelated domains already in the vault: AWS Config/Cloud Custodian (cloud resource compliance), Pinterest's automated schema evolution (CDC pipeline schema drift), and the NetBox/Slurp'it/NetPicker network source-of-truth loop (synthesized in a prior window). RBC's item #28 — an agent correlating live config drift against approved Change Requests — is structurally a fourth instance of the exact same loop, with the CR serving as the "declared state."

Pinterest's case study is the most directly transferable of the three: it states its own design principle explicitly — auto-apply only within a narrow, defined-safe zone (additive/backward-compatible changes), and route everything else to a manual-review path rather than attempting a best-effort fix on ambiguous drift. This is a concrete answer to the question a config-drift authorization agent will eventually face: when live config diverges from the approved CR, does the agent only flag the divergence, or does it attempt to auto-remediate — and if the latter, what's the explicit, narrow boundary of what it's allowed to touch unattended versus what gets escalated to a human?

Concrete next step: if #28 reaches a design-review stage, use Pinterest's "reject rather than guess" boundary as the model answer to that question, and use AWS Config's detection-vs-remediation split (does the agent report, or does it auto-fix) as the concrete design fork to resolve early, before the agent's scope is defined only in terms of detection.

Item #3 (Aegis) and item #14 (agentic harness fed by ExtraHop/Corvil) now have a directly relevant concurrency-audit tool already in the vault

Developer/Checklists/concurrency_and_scalability_checklist.md (added this window, for the Async Python blog series) explicitly names Tools/ExtraHop and Tools/Corvil — RBC's own Aegis telemetry stack — as example external API dependencies to audit under its "External API & Resource Contention" section (shared API clients as singletons, contention under concurrent load). This wasn't written with RBC in mind, but the checklist's core question — for any service consuming ExtraHop/Corvil data under concurrent load, is the client a shared singleton, is it thread-safe, does connection pooling exist and is it sized correctly — is a direct, reusable audit for any FastAPI/async service sitting in front of the Aegis/flowiq pipeline (or a future agentic harness per item #14 consuming the same telemetry sources).

Concrete next step: if any Aegis-adjacent service (or the item #14 harness prototype) is built on an async Python stack, run the checklist's six sections against it before assuming a single-instance dev setup's concurrency behavior will hold once the service scales to multiple workers — the checklist's Section 3 ("In-Process State — the multi-worker killer") is specifically about catching exactly this class of bug before it ships.

Hermes Wiki