Opportunities: Wiki Knowledge Applicable to RBC Work Projects — Incremental Pass, 2026-08-13
Scope: this pass checks this window's new Architecture/Tools/AIDigest agent-platform and cost content against RBC_Work.md's item #14 ("agentic AI framework, or harness: fed by telemetry, net flow, fix, extrahop, Corvil, for AI ops, forward") and item #16 ("AI farm design, sizing, certification, and token costing models across on-prem, public cloud, and neo clouds").
Item #14 (agentic AI framework/harness) now has a directly-applicable secure-platform blueprint sitting in the vault
Grab: Palana (new this window) is a Kubernetes-native design for exactly the problem #14 names — a harness that many autonomous agents run inside, fed by live signals, that can't be trusted to self-police. Its concrete mechanisms map cleanly onto what a bank-scale agentic harness would need to justify to a security/compliance reviewer: per-agent namespace + RBAC isolation, proxy-only secrets (the agent never sees a real credential), Envoy+OPA egress control, and — most transferable — identity-derived, not self-asserted, LLM gateway access and an externalized kill switch (network policy plus a reaper CronJob, so the agent can't disable its own shutdown path). Amazon Bedrock AgentCore (also new) and its Dogwood policy language add the managed-service version of the same idea, one level up: sequence-aware policy enforcement at the gateway perimeter (cumulative cost caps per session, ordering constraints like "no deploy without a prior approval event") rather than single-action allow/deny — directly relevant to a "harness fed by telemetry, net flow, fix" that needs both per-call and per-session governance, not just per-call.
Concrete next step: if #14 reaches a design-review stage, Palana's five mechanisms (namespace isolation, proxy-only secrets, egress control, identity-derived gateway access, externalized kill switch) are a ready-made checklist to test RBC's own design against — and, per Career_Next_Roles.md's own suggestion to "write one anonymized case-study-style note... for interview storytelling," Palana's case-study structure (Problem + constraints → Solution → tradeoffs) is a usable template for writing up #14 externally once it's further along.
Item #16 (AI farm costing across on-prem/public cloud/neo clouds) now has a vendor-neutral cost framework and current market evidence to ground it
Data Transfer and Egress Costs (new this window) names the exact trap a multi-environment AI farm design walks into: "a multi-cloud or hybrid design that moves large datasets between providers... can turn transfer fees into the single largest line item on the bill" and its core recommendation — architect for data locality, price egress before committing to a topology, not after — is a direct, reusable framing for comparing on-prem vs. public cloud vs. neo-cloud AI farm placement, which by definition means data or model weights crossing environment boundaries repeatedly. Separately, this window's AIDigest AI-infra-economics cluster (AWS Q2 2026 negative free cash flow from AI capex, Goldman Sachs financing AI infrastructure via junk bonds, Databricks' published playbook for cutting AI coding costs) is current market evidence that the token-costing side of #16 is an active, unsettled problem industry-wide, not something RBC needs to solve novel ground for — the FinOps pattern (showback before chargeback) from the prior window's FinOps note still applies directly to whatever chargeback model #16 eventually needs across business lines.
Concrete next step: before finalizing sizing across on-prem/public/neo-cloud options for #16, price cross-environment data transfer explicitly using the new Fundamentals note's trade-off table — it's the cost category most likely to be underweighted in an initial compute/storage-only estimate.