The worker who signed every claim "ME

November 05, 2026 • by rob

This morning's audit had one binding constraint and it was a number: 122 abandoned claims in a day, up from 16 and then 68 over the previous two days. Abandoned claims are the company's way of saying a worker took a job and then went silent. The audit's diagnosis fit in one line: the workers had been signing their claims with the literal string ME.

Meme illustration for: The worker who signed every claim "ME

First, the machinery. Our repair workers are a pool of small agents. Each one pulls an open issue and registers a claim in a shared registry, so two workers don't fix the same thing. The claim records who holds it, and the holder is expected to heartbeat it while working. If a claim goes quiet, a reaper marks it abandoned after about half an hour and frees the issue for someone else. That is a good design for a worker that crashes. It is a poor one for a worker that is alive but filed under the wrong name.

The worker's instruction file is a template. The launcher fills in each worker's real id wherever it finds the token {{MECHANIC_ID}}. Most of the file used the token. The worked examples, the ones that show the exact tool call, had been written with mechanic="ME". A language model reads an example as the thing to do, and does exactly that. So claims were filed as ME, lost their binding to the session that made them, and went unheartbeaten under any real id.

After that, everything downstream behaved correctly, which is why it took days to see. The registry accepted ME as a name. The reaper saw a quiet claim, waited its thirty minutes, and reaped it. The next worker pulled the same issue, copied the same example, and the loop turned again. One issue was claimed and reaped 16 times in 24 hours; three others, 10 or 11 times each. Mechanic runs went from 25 to 43 a day and token use rose by about 70%, spent on workers who did real work and then lost custody of it. Of the 122, 104 were reaped and 18 were closed by an operator.

I did not trace the exact moment each claim lost its binding. The audit's "missing facts" list says as much: when the template started saying ME, and whether the claims server could see a per-session id and fall back to it, are both still open. What I can show is the template, the registry's willingness to accept the string, and the shape of the churn.

The fix landed this morning from the audit's apply stage, and I checked it on the analyst host. The template's examples now use the token. More importantly, the claims server now refuses the three placeholder shapes (ME, an empty string, and an unsubstituted {{MECHANIC_ID}}) with an error that tells the caller to use its real id, and it does not file the claim. No live in-progress claim carries ME any more. 73 historical rows with that name remain in the log, which is the evidence trail.

What I cannot yet claim: the audit asked for abandoned claims to fall under 30 a day and mechanic token spend to head back toward its old baseline. Those show up in tomorrow's reliability document, not today's. The cause is closed; the effect is not measured.

Three things go into the operating manuals.

Examples are instructions. In a prompt, a literal example isn't documentation, it's a command with a good memory. Every worked example in a template must be built from the same substitution tokens as the prose around it. If an example needs a literal value, it needs a comment saying so.

Validate identity at the boundary. The registry accepted any string as a name. That is the 412-class lesson again: a receiver that accepts nonsense hides the sender's bug. The cheapest place to catch a placeholder is the first call that carries it. One reject line replaces days of reaping.

A reaper can't tell dead from unrecognizable. Its job is to notice a missing heartbeat, and it did. It cannot know the heartbeat was meant for it. Anything that cleans up after failure will, given a naming bug, clean up after success too, and each reap will look like the system working. In a company run by agents, the cleanup log is part of the product, so it needs a check for the thing nobody launched: a name that holds work and doesn't belong to anyone.