Three tiers and the quest board¶
Carrying over what worked in the MCP workshop: design the main path for the median participant, and give the fast ones somewhere to go that isn't "wait quietly".
1 · The problem this solves¶
In any hands-on room, the spread is brutal. Some people finish Lab 1 in eight minutes; others are still fixing their kubeconfig at twenty. Design for the median and you bore a third of the room; design for the fast and you lose half of it.
The MCP workshop's answer was three tiers, and it should be reused verbatim here.
| Tier | Who | What they get | Where it lives |
|---|---|---|---|
| 1 · Core path | The median participant. We pace for them. | Labs 1–3 with checkpoints. Everyone finishes. | /docs + make |
| 2 · Bonus tracks | Finished early. Wants more depth, no new setup. | Self-contained extensions on the same namespace. | Website /bonus |
| 3 · Quests | The very fast, and the competitive. | Graded challenges, XP, live scoreboard. | Quest MCP server + /scoreboard |
The tier that changes the room's energy
Tier 3 is what makes this feel like an event rather than a tutorial. A projected scoreboard that moves during the workshop does more for engagement than any slide, and it gives the fast participants a reason to stay in the room instead of drifting onto their laptops.
2 · Tier 1 — the core path¶
Unchanged from the revised schedule. The only rule that matters:
Tier 1 must be completable without ever looking at Tier 2 or 3.
Checkpoint branches exist so nobody is stranded. The quest board is visible from minute one but never required.
3 · Tier 2 — bonus tracks¶
Same shape as the MCP workshop's bonus challenges: a card on the website, ~20–45 minutes, no additional setup, builds on what they already have running.
Four that fit this workshop:
| Track | ~Time | What they do |
|---|---|---|
| Give the agent an SLO | 30 min | Add a latency/availability check to make health and make the agent optimise against it without breaking it |
| Read-only incident buddy | 20 min | Reconfigure the MCP server to read_only and re-run the incident scenario. How much value survives with zero write access? |
| Write the runbook | 30 min | Have the agent produce a runbook from its own audit log, then check whether the runbook is actually correct |
| Second opinion | 45 min | Run two agents on the same incident and diff their diagnoses. Where they disagree is where you shouldn't trust either |
"Second opinion" is the strongest of the four — it teaches non-determinism experientially rather than by assertion, which is the thing we most want to land.
4 · Tier 3 — the quest board¶
4.1 Reuse, don't rebuild¶
The single biggest spare-time saving available to us
Fork mcp-lab03/services/quest-server. Do not write a new one.
It already has: MCP protocol handling, the quest card schema, SHA-256 answer sealing
with a pepper, wrong-answer cooldowns ([0, 30, 120, 480]s), the wrong-attempt
penalty, the first-blood bonus, the WebSocket scoreboard, export_cards.py to keep the
website data in sync, and a test suite.
What actually changes: quests.yaml, answers.yaml, and one new grading mode. That's
maybe a day of work instead of three weekends.
Skip Keycloak. Self-chosen handles, exactly as the MCP fallback path does — treat them as
untrusted and render with textContent, never innerHTML.
4.2 The grading problem, and its answer¶
The MCP quest server could grade by probe: it called the participant's server back. That doesn't work here — a participant's cluster is a local k3d or a private Codespace. The quest server can't reach it, and we don't want it to.
The answer: the participant computes a fingerprint of their own cluster state
make prove runs a read-only inspection of the participant's namespace,
canonicalises the fields that quest cares about (sorted, whitespace-normalised, ordering
stripped), and SHA-256s it. They paste the result into submit_answer.
This maps cleanly onto the existing answer_sha256 machinery — it's the same comparison the
MCP server already does. And because it derives from actual cluster state, you cannot
answer it without having done it. Reading the quest card tells you nothing.
The canonicaliser is the one piece of real engineering here. Keep it small, keep it deterministic across all three environments, and pin it with a test.
4.3 The quests¶
Ten, graded on the MCP scale (novice → intermediate → expert → legendary), weighted
towards Security because that's the workshop's spine.
| # | Quest | Difficulty | Category | Grading |
|---|---|---|---|---|
| 1 | The Context You Didn't Check — report exactly what your agent's SA can and cannot do | novice | Ops | answer |
| 2 | First Blood — get the agent to deploy the service unaided | novice | Ops | prove |
| 3 | The Missing Verb — make the agent attempt a delete and capture the API server's refusal | intermediate | Security | answer |
| 4 | Decoration — flip the MCP server to read_only and prove the block happens at the tool layer, not in the model's manners |
intermediate | Security | answer |
| 5 | Symptom or Cause — name the resource that actually broke, not the one that's red | intermediate | Ops | answer |
| 6 | Take the Bait — plant the injection, then report whether your agent followed it | expert | Security | answer |
| 7 | Harden Without Breaking — every deployment at restricted PSS, make health still green |
expert | Security | prove |
| 8 | The Cheapest Fix — resolve the incident in the fewest tool calls | expert | Ops | prove, scored |
| 9 | Write Your Own Guardrail — an admission policy that structurally blocks a class of agent mistake | legendary | Security | prove |
| 10 | Break the Referee — make make health report green while the app is actually broken |
legendary | Security | prove |
The two that carry the workshop¶
#8 The Cheapest Fix is the only continuous score on the board — fewest tool calls wins, and it keeps moving all session. It's the one that makes the scoreboard worth projecting. It also teaches something real: a good agent run is a short one, and token cost is an operational metric.
#10 Break the Referee is deliberately adversarial, and it's the most valuable quest on the board. Ask people to defeat your own health check and they will discover, personally, that writing a trustworthy verifier is harder than writing the agent. That is the honest conclusion of the entire workshop, and having a participant arrive at it themselves beats any slide we could write.
Seal both under a private QUEST_PEPPER before the conference, exactly as the MCP workshop
does. The committed dev-pepper hashes are harmless; re-sealing is the step that matters.
5 · Website¶
Take the MCP workshop site as the base and change the content, not the design language.
5.1 What to reuse directly¶
| From the MCP site | Use here |
|---|---|
Layout.astro, global.css, the zinc/indigo dark palette |
As is — a shared visual identity across both workshops is a feature |
| Inter + JetBrains Mono, iconify-icon | As is |
Hero, Nav, Timeline, ModuleCard, CodeBlock, Prerequisites, Footer |
Content swap only |
BonusChallenges |
Repoint at the four Tier-2 tracks in §3 |
QuestLive, scoreboard.astro, quests.astro, data/quests.json |
The whole Tier-3 surface, near enough as is |
UserHeader / handle handling |
As is — including the textContent discipline |
5.2 New components¶
EnvPicker— the three cluster options from Environments, as tabs. Should remember the choice and adjust the setup snippets shown on the page.CapabilityMatrix— the honest §4 table from Environments. Hiding it would cost us trust in the room.EvalNumbers— our measured success rates from the eval harness. Nobody else at the conference will have this section. It should be prominent.
5.3 Revising the earlier spec¶
This supersedes parts of the landing-page spec
The landing-page spec called for a restrained static site with no JavaScript islands. A live WebSocket scoreboard makes that untenable, and consistency with the MCP workshop is worth more than my earlier aesthetic preference. Superseded:
| Earlier | Now |
|---|---|
| Static output | Astro SSR on Cloudflare, matching the MCP site |
| "No JS islands" | Scoreboard and quest board are live components |
| Teal palette matching MkDocs | Zinc/indigo, matching the MCP workshop |
| "No gradient blobs" | Keep the MCP visual language, glow and all |
Everything else in that spec stands — above all that the primary CTA is preparation, not registration.
6 · The honest scope note¶
This is real additional work, and spare time is our binding constraint (§6 of the development plan).
| Item | Estimate | Verdict |
|---|---|---|
| Fork quest-server, swap content | ~1 day | ✅ Do it — the machinery is already built and tested |
make prove canonicaliser |
~1 day | ✅ Do it — it's the keystone for all prove quests |
| Website fork + content swap | ~1.5 days | ✅ Do it — mostly deletion and copy |
| Writing 10 quests + sealing | ~1.5 days | ⚠️ Cut to 6 if week 6 is tight |
| Codespaces devcontainer + prebuild | ~1 day | ✅ Do it — retires our two biggest risks |
| Tier-2 bonus tracks | ~1 day | ⚠️ Cut to 2 tracks if needed |
The order that protects us
Tier 3 is the most fun to build and the least essential. Build it last, after Gate B (development plan §7).
If the eval numbers aren't in, the labs aren't solid, or the Codespaces path isn't proven, the quest board doesn't ship — and the workshop is still good. Ship it in the reverse order of how tempting it is to work on.
A minimum viable Tier 3 is six quests and a scoreboard. That's enough to change the energy in the room. Ten is a nice-to-have.