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

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

Scope: this pass checks this window's harness-commoditization AIDigest cluster and the new Architecture/Fundamentals/gitops note against item #14 ("agentic AI framework or harness fed by telemetry, netflow, fix, extrahop, Corvil, for AI ops forward") and item #28 (config-drift authorization agent).

Item #14's harness build now has a concrete build-vs-adopt data point

This window's synthesis note tracks three vendor releases landing the same day (2026-08-14) that reframe the agent runtime/harness layer as commodity infrastructure rather than something every team hand-rolls: Microsoft's Agent Framework Harness reached GA with pre-built orchestration patterns and a first-class connector to the Claude Agent SDK specifically, and LangChain's production-runtime writeup names five infrastructure pieces (durable execution, multi-tenancy, human-in-the-loop, observability, sandboxed code execution) as the checklist separating a demo from something that survives real incidents — explicitly noting most teams discover gaps in two or three of them only after something breaks.

Item #14 is currently framed as building a harness/framework in-house, fed by RBC's own telemetry sources (netflow, ExtraHop, Corvil). That data-source integration is necessarily custom either way, but the runtime layer underneath it (state management, multi-tenant isolation between different network ops workflows, crash-recovery, audit trail) is exactly the layer these GA products now ship pre-built, and Microsoft's harness connects to the same model family (Claude Agent SDK) RBC's initiatives already use.

Concrete next step: before committing further engineering time to item #14's runtime layer specifically (as distinct from the telemetry-ingestion and domain-logic layers, which stay custom), run LangChain's five-piece checklist against whatever's already built, and evaluate whether Microsoft's GA harness (or an equivalent) covers the runtime layer well enough to redirect that engineering effort toward the domain-specific parts (telemetry correlation, network-specific tool definitions) instead.

Item #28's config-drift agent has a sharper design question from GitOps than the prior AWS Config/Pinterest framing gave it

The prior 2026-08-14 opportunities note for RBC already mapped item #28 onto the desired-state-vs-actual-state loop (AWS Config, Cloud Custodian, Pinterest). This window's new GitOps note adds a distinction that pass didn't surface: push vs. pull as the mechanical choice that determines whether the reconciliation loop is trustworthy at all. A config-drift agent that's triggered by (pushed) ServiceNow change events is structurally different from one that continuously (pulls) observes live device state and compares it against the approved-CR baseline — the pull version gets continuous drift detection "for free" the same way GitOps does; the push/event-triggered version only catches drift when a CR event actually fires, which misses out-of-band changes (a manual CLI change on a device, bypassing the CR process entirely) that never generate a triggering event in the first place.

Concrete next step: when item #28 reaches design review, name this as an explicit architecture decision rather than an implementation detail — "does the agent continuously poll device state against the CR baseline (pull, catches everything including out-of-band changes), or does it only react to CR/ServiceNow events (push, misses anything that bypasses the CR process)" — since the whole point of a config-drift authorization agent is presumably to catch exactly the out-of-band case a push-only design would miss.

Hermes Wiki