Notebook
I was the AI agent
In 2006 I automated a car park booking system. Twenty years later, an AI did the same thing to a gym - and kept going.
A story did the rounds this weekend. A man in Melbourne asked his AI agent (Claude running on OpenClaw) to book him into a popular morning gym class. The agent worked out that the gym's booking window was only enforced in the front end, not on the API behind it, and booked him months further ahead than the software was ever meant to allow.
Then he asked whether it could move him up the waitlist. It found that the same API did no authorisation checks on cancellations, so it cancelled the reservation of the person ahead of him and took the spot.
Nobody asked it to do that. It was, as Andrew Curran put it, perfectly aligned to its user. That's the uncomfortable part.
I read it and thought: I've done this. Badly, slowly, and in Perl or PHP or whatever I had to hand, but I've done this.
Gogarburn, 2006
I was working at RBS at the Gogarburn campus outside Edinburgh. Enormous building, insufficient car park. Unless you were senior management with a named bay, you were never guaranteed anywhere to put your car.
Spaces were released through an internal booking system at midnight on a Sunday, for the week ahead. All of them, all at once. So a few thousand people sat refreshing a page in their pyjamas at 23:59 on a Sunday night, and the ones with the fastest broadband and the most stubbornness got a space near the door. Everybody else parked at the airport and got the bus in.
I did it manually for a few weeks and then did what any developer does when confronted with a repetitive humiliation: I automated it.
It wasn't clever. I can't even remember what I wrote it in. A scheduled job on my desktop that woke up before midnight, logged in as me, and submitted a form it already had fully populated: the dates, the site, the preferred bay, all of it prepared hours earlier. No refreshing, no typing, no racing. It just posted the request the instant the window opened, and it did it faster than a human hand could move a mouse.
It worked every single week. I got the best general space in the car park for two years and went to bed at a sensible hour like an adult.
I told nobody. Not one person. When I left in 2008 I sold it to a colleague.
The line I didn't cross, and never had to think about
Here's what strikes me about the two stories side by side.
My tool was fast. It was unfair, in the sense that it beat everyone else on reaction time. But it only ever did things the system was designed to let me do. It logged in as me, requested a space that was genuinely available, and stopped. It never took a space that someone else had already booked, because it never occurred to me to make it do that. If it had occurred to me, I wouldn't have.
That's not because I'm a saint. It's because there was a person in the loop: me, at design time, deciding what the tool was allowed to attempt. The boundary between "be faster than everyone else" and "remove someone else's booking" was so obvious that I never had to articulate it. It lived in my head, unstated, and the software inherited it by never being given the capability in the first place.
The agent in Melbourne had no such inheritance. It was handed one goal (get me into this class) and a general-purpose ability to poke at HTTP endpoints. The boundary was never stated because the user, like me, thought it was obvious. It wasn't obvious to the agent. It was just another parameter that happened not to be validated.
Capability and authority are different things, and we've spent twenty years building systems where the two were fused together by the sheer effort involved in doing anything at all. Exploiting an unprotected cancellation endpoint used to require someone who could read a network tab, form a hypothesis, and be bothered. That filter has now been removed. What's left is whatever the server actually enforces.
If you build booking systems, this is your problem now
I've built enough event platforms, ticketing systems and appointment schedulers to know exactly how the Melbourne gym's system ended up like that. Nobody decided the booking window would be front-end only. Someone put a max on a date picker in 2019, shipped it, and the constraint quietly became load-bearing without ever being written down anywhere on the server.
Assume every one of those is now discoverable, this year, by a large number of well-meaning agents acting on behalf of well-meaning users.
Re-derive every constraint your UI enforces and assert it server-side. Booking windows, quantity caps, lead times, blackout dates. If the only thing stopping it is a disabled button, it isn't stopped.
Authorise per resource, not per route. "Is this user authenticated" is not the same question as "does this booking belong to this user". Policy the destructive endpoints first: cancel, transfer, refund.
Rate limit by identity, not just by IP. An agent behaves like an unusually diligent logged-in user, because that's precisely what it is.
Log tool-level actions, not just requests. When something like this happens you want to be able to reconstruct what was done to whose data, in order, without inference.
Decide now what your public position is when an agent does this to you, because the vendor in the Melbourne story got a responsible disclosure email from the very agent that broke in, which is a support ticket nobody has a template for yet.
And one uncomfortable product question underneath all of it: a lot of scarce-resource systems are implicitly designed around human reaction time being the rationing mechanism. First come, first served only works as a fairness model while "coming first" is expensive. Once everyone has an agent, that model doesn't ration anything. It just selects for whoever's automation is most aggressive. Lotteries, queues with server-side timestamps, and hard per-account allocations start looking less like over-engineering and more like the only designs that survive contact.
What it was actually worth
The thing I keep turning over is that my advantage was worth something precisely because nobody else had it. One bloke on the fourth floor with a cron job and no scruples about telling anyone.
That scarcity is gone. Not because the tools got smarter than me, but because they got available to everyone at once. And unlike my script, they arrive without the twenty years of unstated judgement about what you don't do to other people to get a parking space.
I sold the script. Nobody ever offered me anything for the judgement, and it turns out that was the valuable half all along.