Last time I wrote about KittenClaw, the teaching harness I built so a room full of beginners could get an agent running end-to-end on free tiers without losing the first forty minutes to setup. The harness solves the plumbing. It says nothing about the harder question, which is what you actually point it at.
That question matters more than the harness does. For a lot of the people in the room, the workshop is their first real contact with an agent. If that contact goes badly, if the task is confusing or fiddly or spits out pages of output nobody can read, they don’t just fail the exercise. They walk away with the quiet conclusion that this stuff is finicky and not for them, and I’ve probably delayed their next attempt by months. The first task is the make-or-break example, and I’ve come to treat it with far more suspicion than the code around it.
So here is the rubric I use to choose it. It is deliberately opinionated, because every one of these rules is scar tissue from a task that went sideways.
Form: remove every excuse not to start
The first job of the task is to have nothing standing between a person and their first result.
No programming background can be required. The moment a task assumes someone is willing to write two lines of python, I’ve cut my enrollable audience by ~80% and added friction for 80% of who’s left. Whatever the task is, it has to be legible to someone who has never opened a terminal. And if it rewards someone who can, that reward has to be optional.
It has to run on cheap or free tiers, and it has to be indifferent to which provider supplies them. I don’t want the exercise to break the day a free tier changes its terms, and I don’t want to be shilling for anyone. The same task should run on whatever model the room can get for nothing.
It has to run in the browser. Every local install is a fork in the road where a third of the room ends up somewhere I can’t help them from the front. And the whole interaction has to be visible, with no step happening on someone else’s server where we can’t watch it. This is the same instinct that made KittenClaw three readable files with its whole memory on disk: if a beginner can’t see it, they can’t learn from it, and they certainly can’t trust it. Finally, a human has to be in the loop. A task that runs to completion on its own is a demo, not an exercise.
Scope: a toy of a real thing
Get the form right and you’ve earned the room’s attention. Scope is how you keep it.
The interaction loop has to be short enough to feel immediate. Change the prompt, change a constraint, and see the outcome in seconds. That tight loop does the teaching. It’s what turns “I read that prompts matter” into “I felt that prompt change the answer.” Anything that puts minutes between a change and its consequence kills the intuition before it forms.
The knowledge base has to be small, fixed, and boring. No loading documents, no managing state mid-exercise, and absolutely nothing proprietary. Data management is friction and proprietary data is risk, and neither teaches anything about agents. The reasoning has to be shallow for the same reason the models are cheap: I don’t want thirty people debugging a subtle chain of logic on a free tier. Short steps, obvious failures.
And the task has to sit in a specific sweet spot. It should be a toy version of a real workflow, close enough that an attendee can see the analogy to a system that would actually earn its keep. But it can’t be so simple that a regex or a spreadsheet would do it. If a non-AI tool solves it cleanly, the exercise teaches that agents are pointless. The whole thing works only if success and failure are both obvious the instant they happen. No rubric, no “well, sort of.” It worked or it didn’t, and everyone can see which.
Two guardrails do a lot of work here. Avoid anything that’s already a solved product, like transcription, document Q&A, or deep-research-over-a-corpus, because the interesting engineering has been done and hidden, and there’s nothing left to feel. And avoid anything a five-line script would nail, for the opposite reason. The task has to live in the gap between “trivial” and “already a product,” which is exactly where the useful agentic work lives too.
Difficulty: one task, every skill level
The last problem is that the room is not uniform. In the same thirty people I’ll have someone who has never used a chatbot sitting next to someone who writes Python for a living, and the task has to land for both.
So the task has to be modular. There’s a version you solve by editing a prompt in plain English, and a version you solve by changing the tools underneath, and the same exercise has to admit both without either group feeling cheated. For the people who finish early (and someone always finishes early), the task needs room for adversarial constraints. A user who won’t commit to an answer, a requirement that the bot collect something it doesn’t obviously need, an edge case that turns a clean solution into a pile of blanks. Realistic difficulty, handed out on demand, so the fast solvers stay in the problem instead of getting bored and skeptical.
And there has to be a moment of wow. One beat that teases what comes after the workshop. The one I use is agent-driving-agent: a coding assistant driving KittenClaw, writing a prompt on its own, holding a whole conversation with the bot and then grading the transcript. The triage exercise I ship with KittenClaw is built to pay all of this off at once: a bot that has to gather information it doesn’t itself need because a second agent will. Modular and adversarial at once, in fifteen lines.
None of these rules are clever. They’re just expensive to learn the other way. The harness took a weekend; the rubric took years of teaching.