The watch shouldn't be in a ready room: illegal states in agentic systems

You check out of a hotel. The front desk marks your room “empty, ready for the next guest”. Then the next guest opens the door and finds your watch on the bedside table.

Nobody was careless. The desk wrote “empty” without anyone looking in the room. I hit the same problem this week in a system where AI agents do the work, and it changed how I think about fixing it.

Why agents make this worse

I’m building a system where several agents work on software tasks. One writes code. One reviews it. One retries when something fails. Another tidies up in the background. They act in any order, and sometimes one crashes halfway.

Every agent writes to one shared record of what happened. That record is the system’s memory. But the agents also change real things: folders on a disk, branches in a code repository. The record says what we believe. The disk shows what is true. Sometimes the two disagree.

When they do, the next decision rests on a wrong picture. An agent reads “folder removed” and moves on, while the folder is still there. My question was simple. How do I keep this safe when it has to stay fast and nobody watches every step?

The hotel rule

Hotels already solved this. Guests forget watches, wallets and chargers, and no hotel can stop that. But a hotel never marks a room “ready” while something is still in it. Housekeeping checks the room first. Anything found goes to lost and found, gets written down, and the guest is contacted. Nothing is thrown away in silence.

So the bad state is not “something was left behind”. The bad state is “the record says empty, but the room is not empty”. That is the one to rule out.

An old idea from programming

Programmers have a name for this. Yaron Minsky wrote a heading for it in 2011: “Make illegal states unrepresentable”. In 2019 Alexis King wrote that you should parse, not validate. Her point: check input once, at the door, and turn it into a shape that can only hold valid values.

Here is what that looks like for the hotel’s own booking system. The loose way gives every room a status, a guest name and a list of things found in it:

status:     "ready", "checked in" or "checked out"
guest:      a name, or nothing
itemsFound: a list, maybe empty

Nothing stops a room from being “ready” while the list still holds a watch, or “checked in” with no guest. So you add checks everywhere, and one day someone forgets one.

The strict way names the three states a room can be in, and gives each one only what it needs:

Room = Ready                 // empty, inspected, can be let
     | CheckedIn(guest)      // someone is staying
     | CheckedOut(guest)     // they left; not inspected yet

Then it allows only three moves between them, one after another in a loop:

check in:   Ready             -> CheckedIn(guest)
check out:  CheckedIn(guest)  -> CheckedOut(guest)
inspect:    CheckedOut(guest) -> Ready
            (anything found goes to lost and found, under that guest's name)

There is no move from CheckedOut straight to Ready. The only road to Ready runs through the inspection. Now “ready, with a watch inside” cannot be written down, and neither can “checked in, with no guest”. There is no check to forget.

There is a limit. The booking system owns the room’s status, but not the room. A guest can come back for a forgotten coat, or a cleaner can leave a trolley behind, after the inspection. So the strict shape protects the record, and the hotel rule protects the moment of writing: one door into the record, and the door looks at the room before it writes. That look is true only at that moment, so anything that shows up later gets reported, not quietly fixed. My system has the same edge. Its record is mine. The folders on the disk are not.

Where I hit it

In my system, each task gets its own working folder, and every setup, reset and cleanup is recorded. A new rule said: never delete a folder unless the record shows it is the current one.

The reviewing agent found a conflict with an older fix. Once, a folder had been left on the disk after the record said “removed”. The old fix told cleanup to delete such a leftover anyway. The new rule said cleanup should refuse. An existing test caught it.

The first suggestion was the hotel picture, used the wrong way. The guest checked out, the watch is still there, so work out whose it is and clear the room quietly. I didn’t like that. A room marked ready should never have a watch in it. A careful cleanup for a bad state still accepts the bad state.

So I asked who writes “removed”. Two places did: the main cleanup step, and a background sweep. Both deleted first and recorded second, which is the right order. But neither checked that the folder was really gone before writing “removed”. My best guess is that this is how the leftover happened. I haven’t proven it.

So I asked for four changes. Each one is the hotel rule, applied to folders:

• Look before you write. The system writes “removed” only after it has checked that the folder is really gone. Housekeeping looks in the room before it marks it ready.
• If something is still there, say so. The system stops, reports which folder it found, and leaves the record as it was. The watch goes to lost and found. It is never thrown away.
• One door. Only the main cleanup step may write “removed”. The background sweep no longer deletes folders at all. One housekeeper signs off a room, not two.
• Test the door, not the repair. The old test checked that cleanup could tidy up a leftover. The new test checks that a wrong “removed” can’t be written in the first place.

Where things stand: both changes are done. The background sweep no longer deletes folders, and the main cleanup step now looks before it writes “removed”.

The last review of that work found one more way in. Each folder carries a small tag that says who owns it, and a damaged tag was read as no tag at all. That let a delete go ahead without knowing whose folder it was. In the hotel, it’s a lost-and-found label with the name smudged off: you don’t throw the watch away, you hold it until you know whose it is. Same lesson, one level down. A small follow-up, running now, makes a damaged tag its own state, and that state blocks any delete.

What I learned

• Ask who can write the bad state before you write the repair. A repair path makes a broken state normal. Close the door instead.
• Make the record wait for the world. If a record describes something outside the system, write it only after you have looked at the outside thing.
• Use types where you own the data, and a checked door where you don’t.
• Report what you can’t prevent. People and tools will still leave things behind. Show them. Don’t hide them.
• A good picture can point the wrong way. The hotel story made a cleanup rule sound fine, until I asked how a room marked ready still had a watch in it.

Two questions I’m still asking:

Where else does my system mark a room “ready” without looking inside?

When it finds a watch it won’t touch, how should it tell me?

If you’re building something similar, I’d like to hear about your own watch in a ready room.