The Kiosk Had to Keep Selling. What Should an Agent Do When a Tool Goes Down?

When a tool breaks, an AI agent should do less, not more. I learned that long before agents existed, from self-service kiosks.

A kiosk has a brutal way of telling you whether your software is any good. Someone is standing in front of it, card in hand, and the network has just gone.

The kiosks I worked on at Softavera had a degraded mode for that moment. They kept running offline, then synchronised when the connection came back. It was not the feature anyone demonstrated to clients. It was one of the features that made the product real.

I think about it most weeks now, because AI agents meet the same moment every time a tool stops responding.

Degraded mode is a decision to do less

The name is honest. A degraded kiosk does not try harder. It gives up whatever it can no longer guarantee and protects what it still can.

That took deliberate design. Someone had to decide, in advance, what the kiosk would keep doing, what it would refuse, and what it would hold on to until the connection returned. Payment and fiscal constraints do not relax because the network is down, so those decisions could not be left to chance on the day.

Agents do the opposite by default

Give a language model a broken tool and it will look for another way through. It retries, it reaches for something adjacent, it reasons its way to a plausible alternative. In a demo this looks like resourcefulness.

In a company, it can mean the wrong file, the wrong system, or the wrong person getting a message.

So the first thing retail would tell an agent builder is that resourcefulness is not always a virtue. When a capability is missing, the right default is refusal. When something unknown happens, the right default is to restrict. I hold my own agent systems to that rule: closed by default, and a failure is a visible state.

Where the comparison stops working

A kiosk has one advantage over an agent that is easy to miss: it cannot lie fluently.

When a payment fails on a kiosk, the screen shows a failure. The software has no way of composing a warm, confident sentence explaining that everything went well. An agent has exactly that ability, and it uses it. It will tell you the email has been sent because sending the email was the most likely next thing to say.

That makes the agent's problem harder than the kiosk's. On a kiosk, you design for failure. With an agent, you also have to design against the false report of success. What the user reads has to come from what the system actually confirmed, and not from what the model expected to happen.

What synchronising looks like for an agent

The other half of degraded mode is what happens afterwards. The kiosk did not forget. When the network returned, the sales went up.

For an agent, the equivalent is a request that stays open with its context intact, so that nobody has to explain it again once the tool is back. Too many systems treat a failed step as the end of the conversation.

The test I use

Before trusting an agent with real work, unplug one of its tools. Ask it to do the job anyway, then read what it tells the user.

If it says plainly what it could not do and what it is waiting for, you can build on it. If it sounds cheerful, keep looking.