The Catalyst 2026 (Toronto) — "The Network That Answers Back"

Submission package and talk-shaping doc for The Catalyst 2026, Toronto. Reuses the flagship architecture already researched for the RBC internal Oct 2026 lightning talk — see talking-to-the-network-source-of-truth and lightning-talk-oct2026-requirements — reshaped for a 30-minute external slot (vs. the internal 15+15) and framed as a Principal Engineer narrative: problem → architecture decision → trade-offs → what I'd do differently, plus an explicit incident-severity (P1/P2) lens and a harness engineering throughline.

1. Submission Snapshot

2. One-Pager

3. Architecture (the decision, in one picture)

Why the gate sits where it does, not further right: the temptation is to put the approval gate after the digital twin ("let the twin auto-validate, then just ask a human to rubber-stamp a green checkmark"). That's backwards for a 301 audience — a human approves the intent of the draft before any compute is spent validating it, so the twin is validating something a person already agreed should exist, not something an agent invented and a human is now pressured to wave through under a green light.

4. The 15-Minute Narrative (Principal Engineer framing)

The internal run-of-show (talking-to-the-network-source-of-truth §6) is demo-beat-by-beat. For a 301 external audience, restructure the same 15 minutes around four Principal-level moves — the goal is to leave people able to repeat the decision process, not just the demo.

4.1 Problem (0:00–3:30)

Open on the page, not the architecture. "What breaks if this link drops?" is a blast-radius question, and today it's answered by manually cross-referencing topology, IPAM, and app-dependency data across tools that don't talk to each other. That manual cross-reference isn't just slow — it's the dominant cost in the first phase of any network incident: time-to-triage, which gates everything downstream, including time-to-resolve. Name the severity split explicitly here (detail in §5) — a P1 (full-impact outage) and a P2 (degraded, high-priority) both start with the exact same bottleneck: a human manually deriving blast radius before any remediation decision can even be proposed.

4.2 Architecture Decision (3:30–7:30)

Walk the diagram in §3 as a decision, not a feature list. State the three decisions that mattered, and the alternative each one rejected:

4.3 Trade-offs (7:30–11:30)

1. Page fires: "link X down, blast radius unknown"
2. Open topology tool tab -> find link X, note connected devices
3. Open IPAM tab -> cross-reference affected prefixes
4. Open app-dependency tool (or ping a colleague who "just knows")
5. Manually reconcile 3 sources by hand under time pressure
6. Draft a remediation plan from memory / a runbook doc that may be stale
7. Get a second human to sanity-check before touching anything

1. Page fires: "link X down, blast radius unknown"
2. Ask the agent: "what breaks if link X drops?"
3. Agent queries source of truth via MCP (topology + IPAM + deps)
4. Agent returns blast radius: affected devices, prefixes, tenants
5. Agent drafts a remediation change -- and stops
6. Human reviews the draft against the same data, approves or rejects
7. Approved draft is validated in the digital twin before it reaches field

What the trade-off table doesn't show: the agent-assisted flow removes step 4's tribal knowledge dependency ("ping a colleague who just knows"), which is the actual single point of failure in the manual flow — not the tooling, the bus factor. Say that out loud; it's the line that lands with an infra-leadership audience.

The honest trade-off to name on stage: this design trades raw speed-of-execution (an autonomous agent could theoretically push a fix faster than a human clicks approve) for bounded blast radius of the agent itself — the agent's worst-case failure mode is a bad draft, never a bad change. For a 301 audience that's the correct trade in year one of adoption; say explicitly that it's a starting posture, not a permanent ceiling — autonomy is earned incrementally as trust in the harness (not the model) is established.

4.4 What I'd Do Differently (11:30–14:00)

This is the section that separates a 301 Principal-level talk from a product demo — a real retrospective, not a highlight reel:

• I'd scope the digital twin before writing a line of the agent loop. Twin fidelity is the single highest-risk unknown in this whole build (talking-to-the-network-source-of-truth §11) — starting with the flashy agent-loop demo and treating the twin as a later stub risks a "twin" that's honest in a slide but not in practice. Decide the twin's minimum honest scope in week one, not week six.
• I'd instrument the harness for observability from day one, not bolt it on after the demo works. The 65% harness-failure stat (§6) is exactly the argument for building the audit trail alongside the agent loop, not after.
• I'd pick the source-of-truth tool (NetBox vs. Nautobot) on a one-day spike, not a multi-week comparison — the MCP wiring pattern generalizes across both; the decision only mattered for demo speed, and I initially treated it as more architecturally significant than it was.
• I'd write the P1/P2 framing (§5) into the pitch from the start. Leading with "cool agent demo" undersells it; leading with "this collapses the first 15–20 minutes of every P1" is the sentence an infra VP repeats to their boss.

4.5 Close (14:00–15:00)

Land on the one line that should survive in the audience's memory after everything else fades: the harness — not the model — is the engineering. Then explicitly invite the hardest "what if it goes rogue?" question into Q&A.

5. The P1/P2 Lens — Why This Is a Resolution-Speed Story, Not a Chatbot Demo

Framing the talk around incident severity turns it from "neat agent trick" into "this moves a number leadership already tracks."

Both severities share the same first bottleneck: someone has to manually derive blast radius before anyone can act. That's the phase this talk's architecture directly attacks — not the fix itself, the triage step that gates the fix.

The resolution-speed argument, stated precisely: this doesn't claim to shrink fix time (the remediation itself still requires the same execution steps it always did) — it claims to collapse the triage phase that sits in front of every P1/P2 before a fix can even be proposed. For a severity-1 outage where every minute of triage is a minute the org is down, compressing triage from "tens of minutes of manual cross-referencing" to "a single query with a machine-verifiable answer" is the actual resolution-speed lever, independent of the remediation-execution time it doesn't touch.

6. Harness Engineering — The Real Argument Underneath the Demo

"Agent = Model + Harness." The demo is the model doing something impressive; the talk's actual thesis is that every component in §3's diagram is a harness layer, and the harness — not the model — is what makes this safe enough to run against production network state.

The number to say out loud, because it's the whole argument in one sentence: 65% of enterprise AI agent failures trace to harness defects — context drift, schema misalignment, state degradation — not model weakness (talking-to-the-network-source-of-truth §8, sourced). That's why this talk swaps models freely in Q&A without flinching — the reliability doesn't live in the model.

7. Run-of-Show (30 min total)

8. Open Items Before Submitting

• Confirm final track selection (2 vs. 3) — recommend locking Architecting at Scale + Hybrid Infrastructure, and deciding on Developer Experience only if the MCP-surface framing is written into the talk explicitly (see §1 callout).
• Confirm Catalyst 2026's actual submission deadline and event date — not yet known, needed to set the rehearsal calendar (mirrors the Sept 1 build checkpoint already planned for the RBC internal version in talking-to-the-network-source-of-truth §12).
• Decide whether this is a new build for Catalyst or a reuse of the same recorded demo planned for the RBC internal Oct 2026 talk — if the same footage/PoC serves both, say so explicitly in prep notes so rehearsal time isn't duplicated.
• Sanitize check: confirm no real RBC device names/IPs/topology in whatever gets recorded or shown live, same rule as the internal version.

Related

• talking-to-the-network-source-of-truth — the flagship architecture, full Q&A prep, and build checklist this talk reuses
• lightning-talk-oct2026-requirements — original theme/track taxonomy this submission's options mirror
• hermes-harness-spec
• agent_harness_hands_on
• Networking_Concepts
• RBC_Work