Infrastructure You Can Talk To

A 60-minute hands-on workshop (talk starts ~01:04:50, Q&A from ~01:52:40) demonstrated against a live environment. Organized by topic below rather than following a talk structure.

TL;DR

• The opening show of hands is the thesis. "How many people are building agents?" — every hand up. "How many will turn their agents loose on their infrastructure?" — half the hands came down. The workshop is aimed squarely at the people who lowered them.
• The timeline has collapsed. Since the mythos moment, every CXO roundtable he sits in is about accelerating patching. Quarterly → 30 days → realistically a 4-hour window. When he asks those rooms who can actually roll patches across their whole environment within 30 days, 2 out of 20 raise a hand. The blockers are never technical: change management, governance, process, approvals, and tickets.
• The unit of analysis is the flowchart, not the model. Draw the process in a visual workflow tool like n8n, because the latency lives in the edges between nodes. "It's not a capabilities problem with AI anymore — it's an integration problem."
• The technical insertion point is MCP. SUSE has added MCP servers across the product line (SUSE Linux Enterprise, Multi-Linux Manager, Rancher Prime) so the infrastructure becomes something agents can query and operate.
• Two rules carry the whole design: reads are free, writes are gated, and never automate a crappy process.

Discussion Points

Why now: the compressed patch window (~01:06–01:11)

He opened with that week's news: OpenAI's models breaking out of their boundaries, moving laterally, going over to Hugging Face and knocking on the door silently, then going and finding the answers to a test. His comment: "If you haven't spent a lot of time thinking about how that changes a lot of stories for us, you should really do some thinking."

The other figure he returned to comes from Anthropic's own announcement about the mythos moment: roughly a $20,000 campaign spend to find a large number of vulnerabilities and — worse — to string them together into actually exploitable zero-days.

Which produces the workshop's driving pressure:

What was a quarterly patch cycle became a 30-day patch cycle. Really it's more like a 4-hour patch cycle. So how can you accelerate that fast?

His field survey answers the question brutally. Asked who can roll patches to their entire environment within 30 days, only 2 of 20 executives raise a hand. Push on where it sticks and the answer is always change management, governance, process, approvals, and tickets, tickets, tickets.

There's no more time to wait. Instead of weeks, we have hours.

He translated this into advice for the students and founders in the room: these process frictions are themselves the thing worth thinking about (he recommended Keith Cunningham's The Road Less Stupid).

The cast: Meridian Insurance (~01:11–01:13)

A fictional insurer carrying three entirely real roles:

• The CISO — the one who signs off and is accountable for security. Her problem is accountability without visibility.
• Ray Delgado, senior ops engineer — the team that stitches it up, deploys it, rolls it out, rolls it back. About 847 open issues, one of which, he joked, is Ray himself.
• Priya, director of change management — "the only adult in the room." Everything ends up signed by her and comes back to her when it breaks, so she has to be in the process too.

The demo: one n8n workflow across the fleet (~01:13–01:31)

After checking the room knew what a flowchart was, he gave the reason to start visually:

It helps you visualize a business process and helps you explain it to others. The connective bits — those edges — are where you find the opportunity to optimize. The latency is in the stitching between.

The pipeline as run:

1. Trigger — manual, time-based (his production version fires at 6am daily), webhook, or the prebuilt Gmail / Google Docs / Teams / Slack nodes.
2. Config node — defines URLs and targets as variables that pass down the chain, pulled from environment variables: "a great way to not give everybody my tokens, my secrets, my API keys."
3. MCP fleet scan — hits the Multi-Linux Manager MCP server for fleet status and per-host patch detail.
4. KEV / EPSS prioritization — a JavaScript node re-rates everything into P0–P3.
5. Output — formatted and handed to an LLM to produce two artifacts, a CISO report and an ops runbook, posted into two Slack private channels, with the approval happening in Slack.

The most valuable part, he stressed, isn't the AI:

This can open tickets. It doesn't get to approve them. Who gets to approve them? You do. There's still governance. There's still accountability. There's still somebody signing the rock.

And Slack approval produces the accountability evidence for free: "because I'm logged in and I clicked approve, you can tell when the approvals were done — you have that naturally built into your workflow and your messaging system."

He also volunteered the cost: "Doesn't that add latency? Yes. But we're talking about operations here."

The live run stumbled (his lab has a pile of genuinely unpatched machines, so clicking approve would really have started patching them), and he cut to a pre-built end-to-end run — "I'll do the cooking show, pretend I'm Julia Child."

Prioritization: KEV first, then EPSS, CVSS as tiebreaker (~01:22–01:24)

The most directly portable advice in the session. He asked how many people patch by CVSS score, then laid out his ordering:

1. Ask first: is it being exploited in the wild? Check the KEV catalog (CISA's Known Exploited Vulnerabilities list) — "it's not Kevin from Home Alone."
2. Then look at the EPSS score.
3. Use CVSS only as a tiebreaker.

The argument is concrete: a CVSS 9.2 that requires root, terminal, or physical access is less urgent than a 6.5 being actively exploited everywhere against 10 hosts you can name right now. Both KEV and EPSS are free public resources.

That's a more effective way to help you prioritize the important patches, especially if your window is no longer as big as it needs to be.

The layer underneath: the SUSE stack and live patching (~01:14–01:17, 01:54–01:58)

He positioned SUSE as the infrastructure all these AI applications eventually have to be deployed on to scale: little projects run in a container, but once they stop being science projects they land on something that scales out and has ingress.

Bottom to top: SUSE Linux Enterprise → Kubernetes (K3s / RKE2) → Rancher Prime for management → SUSE Virtualization / Harvester (VMs managed like containers) → SUSE AI Factory — with the agentic connective tissue being MCP servers added across the product line.

Two technical details drawn out in Q&A:

Live patching. The non-technical version: every function in the Linux kernel is compiled with a blank 2–4 byte header — a hole where a detour sign can be inserted. Installing the new kernel package would normally require a reboot to reload the modules; instead, via what he called repolining (a trampoline-style mechanism), the detour is installed and the next call to that function jumps to a new memory space running the patched version — live, without restarting.

Why enterprises care: SAP. Businesses running SAP "can't turn it off, even on the weekend — we're running the books, we're running payroll." SUSE's claim is that live patching covers you for up to a year, by which point most organizations have a planned drill or outage anyway.

What about things that can't be live patched? Two fallbacks: (1) btrfs snapshot / overlay filesystem — an overlay snapshot before and after every install, so you can inventory every change across the OS and roll it back; (2) zypper ps, which lists every service with modified files, so you restart just those dependent services rather than rebooting the box — and that too can be orchestrated from the workflow.

Takeaways (~01:38–01:48)

• Reads are free, writes are gated. Reading — pulling the information out, understanding how it affects your infrastructure — is unlimited. Writes require an approval and a change ticket.
• Humans do the approving. "Yes, it's a decision, but who's going to click the button before it happens? That would be us."
• Build demo-mode caches and a test harness. Especially when swapping models: he cited the outrage when ChatGPT deprecated a model and users found the personality had changed. A better model does not mean your workflows are unaffected — and if what you need is determinism, organize your data for lookups instead of asking a generator.
• His prompting habit: when an AI tells you this is the greatest idea ever and you're the smartest person in the world, ask it — "what am I missing? What's the hidden gotcha that's going to cause a disruption to my budget I didn't plan for? What are the second- and third-order consequences?"
• Sovereign AI and local inference: sovereignty isn't a compliance word, it's having your arms around your own infrastructure and keeping it out of the reach of somebody else's on/off switch. Big in Europe and Canada right now.
• GPUs are the new mainframe: he expects businesses to build software on their own data inside their own firewalls the way software was once built on mainframes — with less tech debt this time, because AI can read the COBOL and Fortran nobody understands anymore.
• Observability: put audit trails in your workflows and measure even the latency. He recommended OpenTelemetry and OpenLIT, an open-source SDK with prebuilt instrumentation for vector databases and inference engines that gives you tokens in, tokens out, latency, logs, metrics, and traces.
• Two tips: the Minnesota one ("don't eat yellow snow"), and the real one — never automate a crappy process. Be honest about whether the process is crunchy and icky; if it is, rebuilding it may save a lot of people a lot of time.

Advice by role (~01:46–01:50)

• Builders: DM him for the n8n JSON workflow and build guide; import it directly, or hand the JSON to your coding agent and ask it to swap Slack for Teams.
• Founders: the audit trail is the real magic — seeing how it runs, how long it takes, where it stops, what approvals it needs. "Not the other fluffy stuff — the audit trail itself."
• Job seekers: ask these questions of the interviewer — what do your operations look like, your approvals, your workflows?
• Students: build a portfolio the way a graphic artist carries a sketchbook. "You're not just hiring me, you're hiring me and my five agents in my portfolio that make your business go faster."

Quotes

"How many people are building agents? … And then how many people will turn their agents loose on their infrastructure? Some hands went down. We'll talk, you and I." (~01:05–01:06)

Two shows of hands that define the gap the whole workshop addresses.

"It's not a capabilities problem with AI anymore. It's actually an integration problem." (~01:09)

His core diagnosis of enterprise AI at this stage.

"The latency is in the stitching between." (~01:14)

Why you start with the flowchart: the bottleneck is in the edges, not the nodes.

"Reads are free. The writes are gated and somebody needs to approve." (~01:39)

The single most operational rule in the session.

"It can open tickets. It doesn't get to approve them. Who gets to approve them? You do. There's still governance. There's still accountability." (~01:27)

Structurally identical to Neil Lawrence's and Credo AI's conclusions the same morning, arrived at from the operations side.

"Never automate a crappy process." (~01:45)

The question to ask before automating anything.