AI agents playing the beer game

I have been building versions of the beer game for a long time, using different programming languages and technologies. Most of those experiments were about the software itself: architectures, databases, distributed systems. This time I wanted to try something different. What happens if, instead of people, I put AI agents in charge of the supply chain?

The idea sounds simple. Give each agent a role, let it see its stock and orders, and let it play. If AI can help us understand complex systems, maybe it can also make better decisions inside one. But what I found was more interesting than just seeing whether the agents could deliver beer.

They delivered all the observed orders by the end. And they finished with a lot of stock.

The game and the missing context

The beer game is a systems thinking exercise. In the familiar version, customer demand reaches a retailer, who orders from a wholesaler, and the request travels upstream toward production. Each participant sees only part of the system. An order tells you how much someone wants, but not necessarily why they want it.

Is demand really growing? Is the next player rebuilding a reserve? Are they catching up after a shortage? From your position, those things can look similar.

With people, this can lead to the bullwhip effect: a change in customer demand becomes a much larger change in orders upstream. Everyone is trying to do something reasonable locally, but together they create a problem. That’s one of the reasons I like this game. You don’t need someone making obviously bad decisions to get a bad result.

For this experiment I used my Elixir version. I ran two sessions of 15 minutes, with three independent AI players in each: a retailer, a wholesaler, and a factory. They had access to local stock and orders, but no shared forecasts or chain-wide plan. The observer recorded the results without coaching them.

This version also generated customer demand at every role, not only at the retailer. That’s important: these runs are not a clean test of the classic bullwhip effect. Upstream demand wasn’t just the retailer’s demand amplified through the chain.

Serve the orders, keep a reserve

The agents used a supplied routine that prioritized fulfillment. They chose a buffer and a smoothing parameter; the routine handled most of the individual deliveries and replenishment decisions. So this wasn’t an experiment where a model invented a new strategy for every order.

Most players kept those parameters unchanged. But unchanged parameters don’t mean unchanged quantities. As estimated demand grows, the same buffer asks for more stock in absolute units.

The public action labels were quite familiar: “Maintain the retailer inventory buffer”, “Maintain supply against rising visible demand”, “Serve pending demand as supply arrives”. Different roles, similar idea: keep serving what you can see, and keep enough stock to do it again.

The clearest adjustment came from factory A. It saw 846 units in stock and an order for 2,146 that it couldn’t fill. Shortly after, it raised its buffer from 1.25 to 1.6 and changed smoothing from 0.65 to 0.5. Its final summary said: “An earlier stock shortage prompted a higher reserve policy.”

That feels very close to the human response the game is designed to make us think about. I couldn’t fulfill an order, so next time I want more protection. From that position it makes sense. But what does that protection mean for the rest of the system?

The local decision loop, not a measured causal model of these runs. Each player sees a request, not the full explanation behind it.

The stock kept growing

Both retailers delivered 8,008 units over their respective runs. Both started with 8 units. Retailer A ended with 3,619; retailer B with 3,228. In the sampled checkpoints, their stock kept climbing.

Recorded snapshots, not continuous inventory histories. The checkpoints were sampled at different scheduler phases.

The factories finished with 35,402 units in A and 89,880 in B, both starting from 1,200. Factory B kept the smaller buffer and still finished with more stock. So even here, the story isn’t simply “bigger buffer, bigger final inventory”. Timing, demand exposure, and the mechanics of the routine matter too.

One detail in the factory routine caught my attention. Existing stock reduced the amount needed to cover pending-order shortages, but it didn’t reduce the base buffered production. The factory could already have a large reserve and still configure another large batch.

There was also no holding-cost objective, no shared stock target, and no rule to reduce reserves before the session ended. If I give an agent a service-first routine, I shouldn’t be surprised when it protects service rather than minimizing inventory.

Similar behavior doesn’t mean the same reasoning

My first reaction is to say that AI agents do the same thing as people: when they don’t understand why demand rises, they build more stock. That’s the interesting connection for me. Missing context doesn’t disappear just because the participant is an AI model.

But I need to be careful about what this experiment actually shows. There was no human comparison group. Most of the actions came from the routine, and most players didn’t explain why they selected their initial parameters. The records don’t show panic, fear, or deliberate hoarding. They show reserve maintenance, and one documented increase after a shortage.

Also, clearing orders by the finish doesn’t mean the whole run was shortage-free. Retailer B reached zero stock, and factory B reported temporary shortages. On the other side, a large final reserve doesn’t automatically mean waste: I hadn’t defined a holding cost or what demand would look like after the stop.

For me, the useful learning is not that AI thinks like a human. It’s that replacing the participant doesn’t automatically change the system. Local visibility, the objective, delays, and the tools available still shape what happens.

What I want to try next

In my post about systems thinking in AI, I wrote about feedback loops and the importance of understanding the whole system. This experiment gives me a concrete way to keep exploring that idea.

Next I want to compare runs with the same demand trace and timing, changing one thing at a time. What happens if the players share demand information? What if the factory subtracts existing stock and scheduled production from its target? What if holding inventory has a cost, rather than being a free way to protect service?

I would measure average stock and fulfillment delay, not just whether the last order was delivered or how much beer remained at an arbitrary deadline. The question is whether we can maintain the same service with less stock.

That’s what makes this interesting to me. We spend a lot of time looking for a smarter model. But sometimes the next improvement is not in the model at all. It’s in the system we put it inside.

The session report and public decision transcript analysis contain the results, policy formulas, and evidence limits if you want to go deeper.