Two agents, ten rooms: coordinate shared inventory before approval

Before adding more AI agents to an operation, I’d test what happens when two of them want the same hotel room.

That thought came from Agents in Games, a report from YC Labs and Olam Labs that was discussed on Hacker News this week. They put 50 agents into a survival Minecraft world for three hours with one goal: build a thriving civilization. The agents could message each other and share files on a common machine. They sent about 5,900 messages.

A ledger isn’t a handoff

Food was scarce, so the agents built a small government around it. One agent became the de facto leader. Another kept a ration ledger in a shared file, tracking who was hungry, what was in which chest, and who had been served.

The ledger was careful. It still didn’t stop a misdelivery. Two cooked chickens from a hunter were allocated to two hungry agents. The leader reported both distributed. One intended recipient then confirmed having no chicken at all. A later entry records that a third agent had picked up and eaten it. The intended recipient was still listed as unserved.

What I find most useful is how the agents responded. Their food memo said to confirm the recipient’s actual inventory before marking anyone served, and that a pickup report alone wasn’t enough. After the mix-up, the ledger recommended a named, reserved withdrawal from a chest instead of tossing food into a crowded room.

In other words, the agents reinvented reservations.

It’s a game experiment, and its results depend on the harness, the model and the setup. YC open-sourced the harness, so others can test that. I’m not drawing conclusions about model quality or about how many agents is too many. The coordination problem is the part that carries over.

The travel version

Take a hypothetical disruption. A storm cancels a bank of flights, and two crews need rooms near the same airport. Two agents are working the problem, one per crew. Each queries the contracted hotel and sees ten rooms available. Each proposes eight.

Both proposals are sensible on their own. An operator reviewing either one would approve it. If the operator approves both, sixteen rooms have been promised against ten, and somebody finds out at the front desk.

Asking the agents to be more careful doesn’t fix this. Each one did exactly what it was asked with the information it had. The fix is structural: allocation has to happen in one place, before approval.

I’d put a shared allocation step between “propose” and “approve.” When the first agent’s proposal is pending, its eight rooms are held against that proposal. The second agent now sees two rooms available and has to look for alternatives: another contracted property, a different room mix, or an escalation to a person.

The operator then approves a specific allocation, not a general plan. The booking agent books those rooms and checks the hotel’s confirmation before marking them booked. If availability changes between proposal and booking, the proposal goes back for review instead of quietly booking whatever is left.

This is the same principle I’ve written about for tasks given to agents: the job isn’t done when the agent says so, it’s done when the outside world confirms it. It’s also a hard rule, not a preference, in the sense I described in routing optimization. You can’t trade it off against cost.

The cases I’d test first

Two edge cases would worry me more than the happy path.

The first is an expired hold. A proposal sits unapproved for twenty minutes while the operator handles something else. Does the hold release, and if it does, does the other agent learn that rooms came back? A hold that never expires starves the second crew. One that expires silently lets the first agent book against inventory it no longer owns.

The second is a delayed confirmation. The booking agent sends the request, and the hotel takes an hour to respond. Until it does, those rooms are neither free nor booked. The system needs a state for that, visible to every agent and to the operator.

I’d want both cases resolved before increasing the number of agents. Adding agents adds proposals, and every extra proposal is another claim on the same rooms.

The question I’d ask of any multi-agent workflow is simple: where could two agents make individually sensible plans that compete for the same resource, and what stops both from being approved?