TechResearch/LighteningTalkOct2026/lightning-talk-oct2026-requirements

Lightning Talk Oct 2026 — Requirements & Lineup

[!note] Purpose Capture the RBC internal lightning-talk event constraints in one place, map them to a concrete 3-talk lineup, and record which talk is chosen as the flagship. Deep detail on the chosen talk lives in talking-to-the-network-source-of-truth.

1. Event Overview

Field	Detail
Event	RBC internal technology conference — lightning talks
Format	15 min presentation + 15 min Q&A per talk
When	October 2026
Multiple talks	Allowed — can submit/deliver more than one
Deliverable bar	Proof-of-Concept / MVP, or at minimum a live demo + Q&A
Presenter context	Technology & Operations — Network domain
Goal	Ideas useful to other teams, not just Network — experiment with the latest AI-engineering concepts

2. The Three Themes

The talk must align to one (or more) of RBC's intelligence themes:

Intelligence-powered client journeys — how technology reimagines client experience to deliver personalized experiences across user journeys.
Intelligent automation for scale & speed — accelerating operational efficiency by combining intelligent processing and AI-driven decision-making.
Intelligence-enabled workplace — how RBCers make intelligence an integral part of how they collaborate, decide, and deliver.

3. Tracks (pick 3)

Architecting at scale
Developer experience
Early talent
Hybrid infrastructure
Hyper-personalized client journey
Orchestrated security
Risk and embedded compliance
SRE and intelligent operations
Women in technology
World-class data and AI

4. Depth Levels

Level	Meaning
101	No prior knowledge of the subject required
201	Some working knowledge of the subject required
301	Strong understanding of the subject required

5. Strategic Insight — One Backbone, Three Angles

Don't build three unrelated demos. Build one demo backbone — Mihir's existing Hermes self-maintaining-knowledge harness (dispatcher → fix-agent → validator → synthesis → wiki-graduation, cron-driven, with memory tiers and permission gates) — re-skinned to point at sanitized network runbooks / postmortems / a source-of-truth export instead of the PKM vault. Film it once, narrate it three ways. That's how "multiple lightning talks" happens without tripling the work.

Why now (the 2026 hooks)

Harness engineering crowned the "fourth paradigm of AI engineering" (replacing prompt engineering) — RUCAIBox 500-paper survey + the awesome-harness-engineering canon.
MCP 2026-07-28 spec landed right before the October slot — stateless core, Tasks, MCP Apps, hardened auth. Fresh material.
NetBox Labs open-sourced an MCP server + llms.txt for exposing network source-of-truth to an LLM — the exact bridge the Network domain needs.

6. Chosen Lineup — 3 Talks, 3 Tracks, Depth Spread

#	Talk	Track	Theme	Depth	Demo effort
A	The Compounding Wiki (was "Runbooks That Repair Themselves")	SRE & intelligent operations	Intelligent automation for scale & speed	201	Low — already built
B ⭐	The Network That Answers Back	Hybrid infrastructure	Intelligent automation for scale & speed	301	Medium — new wiring
C	The Harness Is the Product	Developer experience	Intelligence-enabled workplace	101/201	Low — reuse A's stack

⭐ Talk B is the chosen flagship — deep detail in talking-to-the-network-source-of-truth. It's home-turf (Network domain), deepest (301), and rides the freshest tech (MCP spec + NetBox MCP server).

Talk A — "The Compounding Wiki: Turning Tribal Ops Knowledge Into Shared Organizational Memory" (upgraded 2026-07-10, was "Runbooks That Repair Themselves")

Track: SRE and intelligent operations · Theme: Intelligent automation for scale & speed · Depth: 201
Opening line: "I built this before it had a name — here's what it looks like applied to a real ops problem instead of my personal notes."
Hook: Every team — SRE, NetOps, Infra, Build, Provisioning, Data Engineering, Cloud — generates knowledge daily in tickets, incident postmortems, and runbooks. Almost none of it compounds; each team re-derives the same answers from scratch, in its own tool, invisible to everyone else. Karpathy's April 2026 "LLM Wiki" pattern formalizes the fix industry-wide: instead of RAG re-searching raw documents every query, an agent incrementally builds a persistent, structured, cross-linked wiki that gets richer with every question asked of it. Hermes — raw drops → frontmatter → wikilinks → _index.md hubs → nightly lint/synthesis — is structurally the same pattern, built and running for months, before Karpathy's write-up existed.
Abstract: This talk introduces a Hermes-style agent that applies the LLM-Wiki pattern org-wide: it ingests raw artifacts from any team, compiles them into a structured, cross-linked knowledge base with entity pages (devices, apps, incidents, owners), flags contradictions, and synthesizes cross-team connections — running inside a shared harness that any team's own agent can plug into for the same reliability guarantees: deterministic verification before anything is trusted, full observability, zero silent hallucination. This isn't a network tool. It's shared infrastructure any team here could build on.
Demo / PoC: Feed the agent a mix of synthetic artifacts from 2–3 different teams (a ticket excerpt, a report excerpt, an incident note) → show it compile into linked wiki pages with an entity page, a contradiction flag, and a cross-team synthesis note — the same nightly-lint-and-synthesize loop Hermes already runs, just pointed at multi-team input instead of personal notes. Show the live git diff, tagged log, and a graduated wiki entry.
Why it wins: (1) Explicitly cross-team — SRE, Build, Provisioning, Data Eng, and Cloud all share the exact "knowledge doesn't compound" problem, directly answering the "useful to other teams" brief. (2) Rides vocabulary the industry is forming right now (harness engineering, LLM wiki) — reads as current, not behind. (3) Lowest-risk build of anything in this lineup — it's a direct re-skin of a system already built and run for months, not vaporware. (4) Clean, honest Q&A answer to "does this replace ServiceNow/Confluence/whatever": no — it's the compounding memory layer that sits underneath existing tools, harvesting what they already produce.
Backs the whole lineup's spine: 65% of enterprise AI agent failures trace to harness defects — context drift, schema misalignment, state degradation — not model weakness. Same citation anchors Talk B's safety framing; see talking-to-the-network-source-of-truth §8 for sourced links.

Talk B — "The Network That Answers Back" ⭐ (flagship)

Track: Hybrid infrastructure · Theme: Intelligent automation for scale & speed · Depth: 301
Hook: "What actually breaks if this link goes down?" lives in three tabs and one person who's on vacation. Wire an agent to a network source-of-truth (NetBox/Nautobot) over MCP, ask it out loud, get the blast radius in seconds — then it drafts remediation and stops at an approval gate.
Full detail, abstract, architecture, run-of-show, and Q&A → talking-to-the-network-source-of-truth.

Talk C — "The Harness Is the Product"

Track: Developer experience · Theme: Intelligence-enabled workplace · Depth: 101/201
Hook: Everyone's debating which model to use. The teams shipping reliable AI are engineering the harness around it — tools, memory, permissions, loops, evals. This is the vocabulary shift of 2026.
Demo: The same task run two ways — naive one-shot prompt vs. the full Hermes harness (dispatcher, validator, memory tiers, permission gates, cron loop). Same model, wildly different reliability. Teaches the 4-layer mental model: context → prompt → loop → harness.
Why it wins: Maximum reach — every team leaves able to name the four layers and audit their own setup. The talk people quote afterward.

7. Backup / Bonus Track

If a slot opens or a track is oversubscribed, the bank-safe 4th talk:

"Orchestrated Security for MCP" — Track: Orchestrated security or Risk and embedded compliance · Theme: intelligence-enabled workplace.
The 2026 MCP overhaul introduced real new attack surface — tool-result prompt injection, over-scoped permissions, audit gaps. For a bank, "here's the security harness you wrap around all of the above before you ship" is an easy yes. It also pre-answers the scariest Q&A for talks A and B.

8. Submission Strategy

Lock Talk A's backbone first — it's ~80% built. Everything else reuses it.
Sanitize ruthlessly — no real RBC device names / IPs / topology in any recorded demo. Synthetic dataset only.
Pre-write 3 Q&A landmines per talk. For a bank the recurring one is always "how do you stop it doing damage?" The propose-don't-push + validator design is the answer — rehearse it.
Submit Talk B (or A) first if only one slot is guaranteed — B is home-turf and deepest; A is lowest-risk and broadest.