My agents built 16 wallpapers overnight, and none of them ever saw one run

On 17 September a chain of Opus 5 agents spent eight and a half hours building 16 animated Wallpaper Engine scenes of Jefrie and BloodTailor for me. Not one agent ever saw a wallpaper running. Wallpaper Engine crashed while the third scene was being applied, and the next thirteen were built, “done”, against a program that was sitting on its crash dialog the whole time.

An agent that can’t see its output isn’t building the thing you asked for. It’s building something that passes whatever check it can run. Here, the only check was “did it crash”. So this week I started building my own wallpaper app, and the first line of its design doc is that Claude must be able to see everything it makes.

What I asked for

I had four Jefrie images from Nano Banana, and I’d just got SAM (a segmentation model that cuts things out of a picture) working in ComfyUI. At 4:10 in the morning I asked for four scenes per image, each built by its own Opus 5 sub-agent, with a “housekeeper” agent after each one to tidy up and write down what worked. I told it the run was exploratory, “there are no wrong answers”, and that each scene should take 20 to 40 minutes.

These are the four images, as Wallpaper Engine shows them in its list. The previews are the only part of the run I can show you as it was: the motion is what never got checked.

The agents were inventive. One made the cage a bell: a lightning bolt every 8.6 seconds sends a shock ring across the bars that reaches her grip 1.02 seconds later. One hung 16 soul-wisps over the reading scene’s ruins and made them a 16-band music visualiser. One gave Jefrie a blink by having Flux.1 Fill repaint her glowing eye slits dark and flashing that patch for 95 ms. Every one of these was described, measured and logged in a shared notes file that grew to 400 KB.

None of it had been looked at.

The night, from the files

The times below come from the scene folders, the crash dumps Wallpaper Engine wrote, and the prompts I typed. Central time, 17 September.

1. 04:10

   I ask for 16 scenes, one Opus 5 agent each, a housekeeper after each.

2. 04:38

   Scene 1 (climbing, "Storm Ascent") is finished.

3. 05:39

   Crash dump. The process sits on Wallpaper Engine has crashed … Access violation at 0% CPU.

4. 06:02

   Scene 3 is marked done (built + installed; NOT verified on screen — it crashed WE).

5. 07:34 – 12:48

   Scenes 4 to 16 are each marked done (built + installed; NEVER APPLIED — WE still down).

6. 12:21 – 12:51

   A probe script launches each scene, waits 14 seconds and checks for a new crash dump. 19 more dumps.

7. 12:23

   I can't launch wallpaper engine. Looks like there is an error.

8. 12:41

   the flail arc scene crashes everything when I try to load it … Are you unable to do it through computer use?

The crash had two causes, found later. The script that wrote Wallpaper Engine’s texture files used an old container version (TEXB0003 where the program wanted TEXB0004), and after that was fixed, 9 of the 16 scenes still crashed on one particle setting written as the wrong type. Wallpaper Engine’s scene format isn’t documented, so the agents copied it out of Workshop wallpapers they had unpacked. Everything visual was a guess checked only for whether it loaded.

The agents weren’t blind by choice, exactly. Two of them wrote in the notes that they had no way to spawn an agent to judge images, and one that it had no screenshot tool either. One wrote, “I haven’t looked at this scene — only confirmed it loads.” When I asked about computer use, the session chose the crash test instead.

What it looked like when I did look

That afternoon I went through the scenes by hand and dictated notes. Some of it was good. The swings on the tail “really makes it feel like a living thing”, the lightning lit only the background, and I loved the cage vibrating to music. But the effects were unnamed (“I had 9 different swings and I had to check them individually”), the strengths were turned down too far to see, and the sky effects bent the cage, because the cage had never been cut out of the sky.

So that night I cut it out myself. This is the climbing scene’s background: the one the agent shipped on the left, the one I made on the right. Drag the line.

And the layers the cage needed, which the September scenes didn’t have: the bars in front of her, the bars behind her, and Jefrie on her own.

In my words to Claude afterwards: “I went ahead and made the masks by hand and generated all the occluded areas … It took me like 5 hours.” The whole session, from the first upscale workflow to the 16 scenes, cost $373 at API list prices.

Asking the question properly

On 27 September I asked Claude whether the problem was real and how bad it was, and told it I wanted an answer I could trust without doing my own research. It sent three agents: one into Wallpaper Engine’s internals, one comparing Lively, Rainmeter and the rest, and one to audit my old sessions. The audit is where most of the facts above come from.

It also measured something I had filed as “web wallpapers are slow”. My earlier HTML wallpaper had felt like 2 fps. Wallpaper Engine’s own settings file said "fps" : 15, and every daily backup of it since 14 September said the same. The browser it tested in fell back to the Intel graphics even when the page asked for the RTX 4070. The effect code itself took about 16 ms a frame on that chip, across three monitors. Three separate causes, none of them “HTML is slow”.

Its recommendation was to keep Wallpaper Engine and build web wallpapers Claude could open in a browser and screenshot. I thought about it overnight and went further. What I actually want is one folder per wallpaper where every cutout, mask and version is an ordinary file I can open, compare and replace, and buttons on the wallpaper that run my own scripts. That isn’t how Wallpaper Engine works, so on 28 September I asked for a new app, and gave it a working name: Wallpaper Breaker.

What exists a day later

I said “go do it” at 6 pm. By 9 am the repo had about 80,000 lines of tracked code (around 22,000 of it tests): a .NET engine that puts web pages behind the desktop icons on all three monitors, a WebGL player, and a render tool Claude uses to turn any moment of any wallpaper into an image, a contact sheet or a clip. The build ran as a workflow of 96 Opus 5.5 agents, and the whole session so far is about 2 billion tokens, most of them cache reads.

The check I care about is in its test notes: with Wallpaper Engine stopped and restored, the engine played two demo wallpapers on the real desktop, and the frame the engine drew at 1.5 seconds matched the render tool’s frame exactly, a maximum pixel difference of 0. What Claude looks at and what I’d see are the same picture.

It isn’t a clean win yet. One of those two demos has a rain effect nobody can see: the fixture gives the rain’s area in pixels where the effect expects fractions of the screen, so the rain is spread over roughly 90,000 times the canvas. The integration agent found it and wrote down the two-number fix, and the fix is waiting on my OK because the agent wasn’t allowed to change the shared file.

The first real wallpaper

The pilot is Jefrie cooking in the ruins. This time the agents’ job was only the assets, and they made a review image for nearly every step. The source is a 1239×848 Nano Banana picture. Qwen-Image 2.1 outpainted it to 16:9, and the new edges had to be aligned and colour matched back to the original, because Qwen shrinks the picture by 1 to 3% and comes back a little bluer.

Then SAM 3.1 and a stack of other methods cut it into 25 layers, back to front: sky, far ruins, ground, the flail, the back half of her tail, the scythe, the cape, her body, the pot, the stirring arm, the spoon, the fire, the head, the ear points, the steam, the front half of the tail, a foreground rock.

The test for a stack like this is to put it back together and compare it to the plate. If the layers are right, you can’t tell them apart.

And the difference between them, multiplied by eight so there’s anything to see at all:

The pilot’s file list has 2,206 entries, every one marked chosen, candidate or rejected, with how it was made. There are 319 review images, and it is on its sixth round of fixes. It isn’t a wallpaper yet: nothing in it moves until the effects go on.

Update, 7 October: the effects went on. Claude made four moods from these layers, and this is one of them, “Weight and Momentum”, for one whole 60-second loop. Her stir, head, ears and cape move every 6 seconds, the flail every 10, and a wet sheen runs round the tail coil. It comes from the app’s render tool, the one whose frame matched the engine’s exactly, so these are the frames the engine draws, not a recording of a screen.

The rejected column is the useful part. Asking Qwen to “keep only the tail” redrew the tail or broke it apart, three tries out of three. Asking SAM for “red spike” found the ear point. oneObsession left hard seams outpainting a painterly image. In September, failures like these shipped inside the scenes: a spear Flux invented behind Jefrie in the reading plate, a scythe mask that erased the bar she was holding. Now they land in the rejected column, with a note on why.

What I keep coming back to is how reasonable each September agent was. Each one read the notes, did careful work and wrote honestly about what it hadn’t checked. The notes said “never applied” thirteen times in a row, and the plan had no step where anyone had to stop because of it.