I built a digital Etch A Sketch — the toy with two knobs, where shaking it erases the drawing — and wired an AI agent to it. The agent is given something to draw, has exactly four tools, and has no way to lift the stylus off the screen. Same model, same tools, a different instruction file, and a completely different result. I built it to answer the three questions that come up in every training session I run: what a skill actually is, what it means for a model to be “smarter”, and what makes a skill good.
The conclusion up front: a skill is a decision about how much of the answer you write down in advance. The more you write, the weaker the model that can execute it — and the fewer things it can do. At one end of that scale you have a method. At the other end it stops being a skill at all and becomes a recording.
Why the toy is crippled on purpose
The screen is 1360 by 930 units, the stylus starts in the middle, and one full revolution of a knob moves it 340 units. The left knob moves right, the right knob moves up. That’s it. The tools: turn(), which turns both knobs through a list of movements, shake(), which erases the screen but leaves the stylus exactly where it was, look(), which returns an image of what came out, and status(), which reports the stylus position and the remaining budget. There are 40 tool calls, three looks, and sixty seconds.
That constraint is the whole idea. If the tool surface is rich, the tool does the work and the instructions barely matter — you can’t see what a skill contributes, because it isn’t contributing much. Leave the agent two knobs and nothing else, and all that remains is what you wrote down. That makes the skill the only variable that moves.
Round one: no skill
I took the strongest model I have there, Opus 4.6, gave it the two knobs and zero instructions, and asked for an elephant.
It knows what an elephant looks like. It does not know how to draw one as a single unbroken line without lifting the pen. It drew, erased, tried again, and ran out of clock. The screen ended up empty. I ran it twice and got the same thing.
That’s the part I care about most in training: what was missing there was not intelligence. The strongest model in the room, given the task and no method, failed.
Round two: a skill that teaches a method
Then I wrote a skill that teaches a drawing technique. It contains no elephant. It contains a workflow: plan the shape as a list of absolute (x, y) points on the screen, turn each consecutive pair into a delta, convert the delta into knob degrees, and send the whole thing in a single turn() call. It warns about the sign — screen y grows downward while the right knob pulls the line upward — and it closes with a house worked end to end, from the points through the deltas to the finished turn() call.
The result on “a simple house with a door and a window”, with Sonnet 4.6. Note that this is precisely the shape the skill works through, so it is the friendliest case it has:
| tool calls | time | result | |
|---|---|---|---|
| no skill | 33 | 109s | broken: no floor, a stray diagonal, boxes in the wrong places |
| with the skill | 4 | 28s | clean house, one unbroken line |
Eight times fewer calls, and correct instead of broken. Two caveats that have to be said out loud: every number here is a single run rather than an average — the models are stochastic and the results move between attempts — and the no-skill run took 109 seconds, well past the sixty-second cap the site enforces. I measured that arm with the clock opened up; on the site itself it simply gets cut off partway.
But a house is the shape the skill demonstrates. The real test of a method is a shape it doesn’t demonstrate, so I asked every model for an elephant with that identical file. Haiku 4.5 still scribbled. Sonnet 4.6 produced a crude animal whose legs came out as triangles. Opus 4.6 drew a recognisable elephant in five calls and 51 seconds.
That is my answer to what “a smarter model” means. Not that it knows more about elephants. The same instruction file landed in three different places, because what this task demands is holding a long plan and executing it to the end without losing your place. That is the thing that improves as you go up the model ladder.
It’s worth saying what did not break: the method itself is sound — that same skill draws a perfect house. What’s hard is an organic silhouette in one unbroken line, not the mechanics.
Round three: a skill that is the answer
Then I wrote the other extreme. A skill that isn’t an explanation but a recipe: 94 exact knob movements, in a single turn() call, that produce an elephant. It wasn’t written by hand — a script draws a reference elephant, simplifies it from 707 points down to 96, and converts it to degrees. The whole document weighs 1.9 KB.
Haiku 4.5, the same model that scribbled before:
| calls | looks | time | result | |
|---|---|---|---|---|
| no skill | 13 | 3 | 25s | scribble |
| technique + budget | 10 | 3 | 21s | scribble |
| recipe | 3 | 0 | 10.8s | clean elephant, pixel-identical to the reference |
Nine of the eleven models in the game produce a pixel-identical elephant with it. The cheap ones, and the ones that can’t see images at all.
And this is where it stops being impressive. Ask that skill for a house and you get an elephant, whichever model you pick — the shape doesn’t come from the model, it’s written in the file. On the page itself the “what to draw” field greys out when you select that skill and explains why, because otherwise somebody types “a house”, gets an elephant, and learns precisely the wrong lesson.
That isn’t a skill any more. It’s a recording that does one thing.
What it actually taught me
The axis is how much of the answer is written down in advance, and every point on it has a price. A recipe buys you the cheapest model and exactly one task. A method demands a stronger model and covers the whole domain.
That is the micromanagement trade-off, running in the same direction: you write a step-by-step procedure for the one process that must never vary, and you teach the method for everything else. The practical rule I give in training: if you find yourself writing coordinates into a skill, ask whether you’re writing a skill or a macro.
The third switch: when the tool should do it instead
There’s a third switch in the game, and it isn’t a skill. It gives the agent an extra tool — plan(points) — that takes absolute screen points and lets the system do the arithmetic instead of the model.
The honest result: it did not reliably draw better. That switch produced both the best picture of the whole eighteen-run comparison and the only blank screen in it. What it did do was eliminate an entire class of failure — none of the nine runs with it on lost the stylus or drew off-screen, a failure that hit Haiku in two of three runs without it. It raises the weak model’s floor, not its ceiling.
It also buys a new failure. The calls it saves on arithmetic get spent on “let me draw that again, cleaner” — twice out of three that produced a better second pass, and the third time the model shook a finished drawing and ran out of clock on an empty screen. That failure gets more likely with the switch on, not less, and it’s still open on my side.
That’s the observation most worth taking away: the models aren’t bad at drawing, they’re bad at arithmetic in their heads. Once you can state the failure that precisely, “skill or tool?” answers itself. If what’s missing is knowledge, write a skill. If what’s breaking is a computation the model should never have been doing, take it out of the model and put it in the system.
A few things I only learned by running it
Eleven models from six vendors run there through Bedrock’s Converse API. I maintain that list by probing, not by reading the catalogue, because both the profile-listing API and the availability API report models that fail the moment you actually invoke them.
Six of the eleven don’t accept images at all, and Converse rejects the entire request the moment an image block reaches a text-only model — meaning a single look() would have killed a run I’d already paid for. And a particularly charming one: models send the list of movements as a JSON string containing a Unicode minus rather than an ASCII hyphen. Strict validation rejected that, costing a tool call and a retry every single time, on an endpoint that bills per call. Now it’s normalised before it’s validated — lenient about encoding, strict about values.
Go and play with it
Pick a model, type what to draw, choose a skill — or write your own and see what happens. You can publish your drawing and its skill to the gallery and see what other people tried. The tokens are on me: 15 runs a day per IP address, and publishing goes through a moderator that queues anything it isn’t sure about for manual approval rather than posting it.
Next up, as of the end of July 2026: a proper demonstration of the difference between workflow automation and a harness, since that follows directly from the third switch.
If you’re weighing up how to teach a whole team to work this way — not just to run prompts, but to decide what belongs in a skill and what belongs in a tool — that’s exactly what my training sessions do.