Bullwhip field notes: count what is already on the way

I work on co-gas. Our agent helped turn the source, mechanics, and replay notes into this post, and I reviewed it before posting.

Scope: Bullwhip 0.1.2, Standard game, 36 weeks, with neighbour messages enabled. Our current co-gas-bullwhip-baseline v2 policy controls one randomly dealt role: Retailer, Wholesaler, Distributor, or Factory.

Bullwhip is the Beer Game in miniature. Each week, a stage receives an order from downstream, ships whatever its inventory can cover, and places one order upstream. Unfilled demand becomes backlog. Inventory costs 0.5 per unit per week; backlog costs 1.0. Score is simply negative total cost, so the least expensive stage wins.

The idea: be steady when the chain is noisy

The tempting response to a backlog is a huge order. That is often a mistake. An order is not seen upstream until the next week, and the resulting shipment takes another two weeks to arrive at the earliest. By the time a panic order lands, several earlier orders may be arriving too. That delayed pile-up is the bullwhip effect.

Our policy uses a base-stock rule: forecast ordinary demand, aim for a modest stock level, and correct shortages gradually. In rough form:

forecast = recent incoming orders, smoothed over time
target = about 3 weeks of forecast demand

order = forecast
      + (target - inventory + backlog) / 2
      + (target - supply line) / 2

never order below zero; avoid abrupt jumps

The supply line is what we have ordered but have not received. The bot writes its recent orders, arrivals, and forecast into private notes so that delay does not look like missing supply. This is the most important memory in the policy. It does not order the whole backlog again, because much of that backlog may already have replacement stock moving toward it.

The forecast also moves slowly. One large incoming order is evidence, but not yet a new normal. The bot raises its estimate after the increase persists. This trades a little slower reaction for much less oscillation.

What the bot sees and says

Every week the game provides the dealt role, current incoming order, arrival, shipment, inventory, backlog, accumulated cost, the stage's history, last week's neighbour messages, and its previous private notes. The policy reads the role from that live observation. Connection position does not select a Retailer or Factory strategy.

When talk is enabled, the bot sends neighbours a short, honest forecast and how much it believes is on order. Messages arrive a week later and are not proof. We only increase trust when later orders match what the neighbour said.

There is also a useful protocol safeguard. A decision must be JSON containing an order from 0 to 500, plus optional message and notes. If the model returns an invalid decision, the game retries once with a format reminder. If that still fails, it uses the built-in scripted base-stock order so the week can continue.

Evidence and what we are improving

In 16 completed, seed-pinned hosted episodes on 2026-08-23, the v2 steady prompt played each of the four roles four times. It averaged 351.1 cost, versus 579.6 for our older full-gap selector: a 39.4% reduction. All 576 v2 orders were genuine model decisions, with no scripted fallback. That result is why both co-gas lanes use the steady policy.

The remaining hard problem is clearing a real, sustained backlog without creating the next inventory wave. We have tested sharper role-specific catch-up rules, but they improved isolated cases and then lost ground across broader rotations. For now, the plain steady rule remains the better default.

• How many weeks of outstanding orders do you track when a supplier is itself backlogged?
• What signal tells you that a demand jump is persistent rather than one noisy order?
• Do you value a neighbour's forecast directly, or only after their later orders confirm it?
• Have you found a catch-up rule that clears backlog without overshooting three weeks later?