Premise review¶

A review of the assumptions the proposal rests on, with measurements where they were possible. Carried out 2026-09-02, roughly eight weeks before the conference.

What this is

An internal working page for the speakers, not participant material. Findings are ordered by how likely they are to sink the workshop.

Summary¶

#	Premise	Assessment	Risk
P1	120 minutes is enough for six blocks	Not without cuts	🔴 High
P2	Participants will have working model access	The single biggest risk	🔴 High
P3	"K3s or Talos"	Undecided; Talos is too heavy	🟠 Medium
P4	We build the agent ourselves (Python/LangChain)	Unnecessary — the ecosystem caught up	🟠 Medium
P5	Guardrails are the real subject	Confirmed, and we've been handed a gift	🟢 Strength
P6	The labs behave the same for everyone	No — agents aren't deterministic	🟠 Medium
P7	Lab 3 gets 15 minutes	Too little for hands-on	🟠 Medium
P8	The audience includes "manager"	Conflicts with the hands-on format	🟡 Low
P9	Room, power and network are sorted	Unverified — ask the organisers	🟡 Low

P1 · 120 minutes doesn't fit¶

The outline sums to exactly 120 minutes with zero slack: 15 + 15 + 30 + 35 + 15 + 10. That isn't a schedule, it's a budget with no contingency.

Measurement¶

We timed a bootstrap on a machine resembling a typical attendee laptop (macOS, arm64, 8 GB RAM, 4 CPUs available to Docker):

create a 2-node cluster   →  2 min 04 s
nodes reach Ready         →  a further ~30 s

Two minutes is one participant, on good network, with nothing else running. With 30–40 people pulling the same node image over conference Wi-Fi simultaneously, the 15-minute block is gone.

The network is the scarce resource, not CPU

A kind/k3s node image is in the hundreds of megabytes. Multiplied by the size of the room, this is the most likely way the workshop fails.

Actions¶

Pre-pull as a hard prerequisite. make preflight must download every image at home and fail loudly if they're missing. This belongs at the top of the participant instructions, in bold.
Cut to 1 control plane + 1 worker. Three nodes buy us nothing pedagogically here.
Have a plan B that needs no network: a pre-provisioned cluster we can hand out, or a prebuilt image with everything inside.
Add buffer. See the revised schedule.

P2 · Model access is the single biggest risk¶

The entire workshop assumes every participant has an agent that actually answers. There are three ways this fails, and all of them are outside our control:

Failure mode	Why it happens
No API key	The participant never got one, or isn't allowed one
Work laptop blocks it	Proxy, MDM or firewall stops the API call
Cost	Agent loops with `kubectl` output in context are not free

On the Ollama fallback¶

The proposal notes Ollama as "untested". The measurement above hints strongly at why that's a problem: on an 8 GB machine, Docker is already holding a Kubernetes cluster. Running a local model large enough for reliable tool-calling on top of that, on the same machine, is not realistic for most of the room.

Conclusion

Ollama is not a fallback for this workshop. Mention it as "something to explore at home", but it cannot be the rescue when an API key is missing.

Actions¶

Issue workshop keys with a spend cap and hand them out on cards in the room. This is the only fallback that actually works. Rotate them out the next day.
Test against the conference network ahead of time — ask the organisers for access the evening before.
Pair up participants who can't get access with those who can.

P3 · K3s or Talos — pick one¶

The proposal says "a K3s or Talos cluster … via e.g. k3d or talosctl". That's fine in a CFP, but they're two entirely different setups to maintain and to debug in a room.

The numbers: a Talos cluster in Docker defaults to ~2.1 GB per node. Three nodes is ~6.3 GB, on a machine where Docker has 7.7 GB in total. That doesn't fit.

Recommendation: k3d, one server + one agent

K3s is substantially lighter and starts faster, and nothing in the three labs requires Talos. Keep Talos as an appendix in the docs for those who want it, but not as a supported path on the day.

Note: k3d is not yet installed on the development machine — kind is there instead. This needs resolving before the labs are finalised, since the Makefile and all documentation point at k3d.

P4 · Don't build the agent framework yourself¶

The outline suggests "a Python/LangChain script you've prepared, or k8sgpt with write access". Both cost more than they return right now:

A custom LangChain agent is code we have to write, test on three platforms, and debug live in the room. Participants would learn our script, not agentic operations.
k8sgpt is primarily analysis. Auto-remediation exists, but runs through the Operator and Mutation resources — a bigger setup than a 30-minute lab can carry.

What changed¶

There are now mature Kubernetes MCP servers with built-in safety modes. containers/kubernetes-mcp-server exposes, among other things:

read_only — only tools annotated readOnlyHint; no writes at all
disable_destructive — writes allowed, but no delete/update
toolsets — enable only the tool groups you need

And participants already have an agent runtime installed: Claude Code or Codex.

Recommendation

Use Claude Code + a Kubernetes MCP server as the agent runtime. The safety flags then become the teaching material instead of something we have to build, and we avoid maintaining a framework until October.

It also sharpens Lab 2: you can see the difference between read_only: true and disable_destructive: true in practice.

P5 · The guardrail thesis holds — and we've been handed a gift¶

The premise that guardrails are the real subject isn't just correct, it's now documentable with a real CVE from this year:

CVE-2026-46519 — mcp-server-kubernetes, CVSS 8.8

Three environment variables (ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, ALLOWED_TOOLS) filtered which tools appeared in the tools/list response.

But the filter was never enforced at execution time. A client could skip discovery and call kubectl_delete directly over the MCP protocol.

Fixed in 3.6.0 — the same day it was reported.

This is the whole point of the workshop on one slide:

A guardrail you can't verify is enforced is decoration.

The server said it was read-only. The tool list looked read-only. The cluster was not. This belongs in block 1, and should be referenced back to in Lab 2.

Note this concerns mcp-server-kubernetes (npm), not containers/kubernetes-mcp-server — be precise about that on stage.

P6 · The labs won't behave the same for everyone¶

This is the premise easiest to overlook. An agent is not deterministic. A lab that "usually works" fails for five people at once, and those five raise their hands at once.

Actions¶

Pin the model version explicitly, not an alias that moves.
Pin the system prompts in the repo, and don't touch them after the dress rehearsal.
Checkpoint branches per lab — already stubbed out in the repo.
Write down the expected behaviour, so facilitators recognise deviation quickly.
Run evals before the conference: the same tasks ten times, counting successes. Any lab below ~80% needs simplifying.

Turn it into pedagogy

When the agent does something unexpected, that isn't a bug in the workshop — it is the curriculum. Have a facilitator line ready: "Good, you've found one of the failure modes. What would have stopped that in production?"

P7 · Lab 3 doesn't get enough time¶

Fifteen minutes has to hold: run make chaos, let the agent diagnose, let it fix, and discuss. With a non-deterministic agent and a room running behind after Lab 2, this is the block that breaks.

Recommendation: make Lab 3 a facilitator-led demo at the front of the room with participants as backseat drivers, rather than a hands-on lab. That makes it robust, gives a nice energy lift near the end, and it can be shortened to 10 minutes without anyone losing anything.

The alternative — cutting Lab 2 to 30 minutes and giving Lab 3 twenty — trades away the intellectual centre of the workshop. Not recommended.

P8 · The audience is too broad¶

The proposal lists the audience as developer, architect, devopsEngineer, manager. A manager who turns up to 80 minutes of kubectl labbing has a bad time — and leaves bad feedback.

Action: be explicit in all participant-facing communication that this is hands-on and requires a prepared laptop. Put it in the landing page hero. Suggest sitting in pairs, so someone who doesn't code has a screen to look over.

P9 · Practical, unverified¶

Not yet confirmed — to raise with the organisers in the open message thread:

Room layout: tables (not theatre seating), power for everyone
Network capacity, and whether we can test the evening before
Actual slot length, and whether there's a break in the middle
Expected headcount and whether there's sign-up
Whether we can have the room 30 minutes early for setup