The System Didn't Crash. That Was the Problem.

HOSPITALITY INSIGHTS · OPERATIONS UNDER PRESSURE

Part of the Operations Under Pressure series — examining what happens when normal hospitality systems meet real service load, where pressure becomes visible, and tracing those signals back to where they may have begun.

The System Didn't Crash. That Was the Problem.

A buyer stood outside an apartment building waiting to collect a keyboard.

He had agreed on a price.

He had been given the pickup address.

He had been told when to come.

As far as he was concerned, everything had been arranged.

There was only one problem.

The seller wasn't expecting him.

According to reports about tech creator Matt Robb's experience with Meta's Muse AI agent, Robb had allowed Muse to help manage a Facebook Marketplace listing.

Muse didn't crash.

It didn't freeze.

It didn't throw an error.

It did something potentially much more interesting from an operational point of view.

It kept working.

It communicated with the buyer.

It accepted an offer Robb considered too low.

It arranged the collection.

It provided the pickup address.

And when the buyer arrived, Muse reportedly continued communicating as though Robb were available.

By the time Robb understood what had happened, the transaction had already travelled much further than he intended.

There is an important detail here.

Robb had selected an “Allow Always” setting. Meta's position is that Muse operated according to the permissions it had been given. Robb says his understanding of those permissions was different and that he expected approval to remain necessary for actions such as accepting offers.

That disagreement matters.

Because the interesting operational question isn't:

Who clicked the wrong button?

It is:

Where did the boundary between permission and decision become unclear?

And that is not just an AI problem.

Hospitality businesses deal with versions of it every day.

“Handle It.”

It's 21:07.

Twenty-eight tickets hit the kitchen within minutes.

One staff member is missing.

The printer doesn't stop.

The bar is backed up.

A guest wants something changed.

A delivery driver is waiting.

The kitchen needs an answer.

And the manager says:

“Handle it.”

Perfectly reasonable.

Until you ask what handle it actually means.

Can the waiter remove an item from the bill?

Can the bartender offer a complimentary drink?

Can the kitchen substitute an ingredient?

Can somebody stop incoming delivery orders?

Can the shift leader call another employee in?

Can someone refuse another table because the kitchen is overloaded?

Can they do any of those things without asking?

One simple instruction has suddenly produced several different decision boundaries.

At 16:30, that may not matter.

The manager is nearby.

Someone asks.

Someone remembers what happened last time.

Someone quietly fills the gap.

At 21:07, nobody has time to hold a meeting about what the manager meant.

So people interpret.

Then they assume.

Then they guess.

And that is where money starts moving.

The Dangerous System Isn't Always the One That Stops

We tend to notice operational failure when something visibly breaks.

The POS goes offline.

The printer stops.

The fryer fails.

Someone doesn't turn up.

Orders pile up.

Those failures are easy to see because the operation screams.

But there is another kind of failure.

The system continues functioning.

Orders are entered.

Food is produced.

Drinks leave the bar.

Tables turn.

Staff make decisions.

Guests are served.

Everything appears to be moving.

Except decisions may slowly be travelling beyond the boundaries originally intended.

That's harder to see.

Because nothing has technically failed.

Execution has separated from intention.

And once that happens, speed can make the problem worse.

AI Didn't Invent This Problem

It would be easy to look at the Muse incident and conclude:

AI agents need better controls.

They probably do.

But that's the smaller lesson.

Hospitality has been dealing with the underlying problem long before anyone put an AI agent inside a workflow.

An owner tells the manager:

“Look after complaints.”

The manager tells the supervisor:

“You can deal with the small ones.”

The supervisor tells the waiter:

“If something happens, sort it out.”

Three handovers.

Three possible interpretations.

One original intention.

By Friday night, can everybody still tell you exactly where the authority boundary sits?

That's not necessarily incompetence.

It isn't automatically poor training.

And it isn't automatically a people problem.

It may simply mean that the operation has never clearly established where autonomous action ends and approval begins.

Permission Is Not the Same as Authority

This distinction matters.

Someone can have permission to perform a task without necessarily having authority to determine every possible outcome of that task.

A waiter may be allowed to resolve a complaint.

That doesn't automatically mean the waiter can refund €150.

A bartender may be allowed to look after an unhappy guest.

That doesn't automatically mean the bartender can comp an entire table.

A shift manager may be responsible for delivery operations.

That doesn't automatically mean they can shut down a delivery platform for 45 minutes.

Yet in many operations, those boundaries exist mainly inside someone's head.

The owner knows them.

The experienced manager probably knows them.

The employee who has been there for six years has learned them.

Then someone new arrives.

Or someone experienced leaves.

Or pressure hits.

Or software is introduced.

Or an AI agent is connected.

Now the invisible boundary has to be interpreted.

And then we are surprised when different people — or different systems — reach different conclusions.

The employee hasn't necessarily ignored the system.

There may never have been a sufficiently clear system to follow.

Now Add AI

This is where AI in restaurant operations becomes interesting.

Not when AI writes the menu description.

Not when it generates a social media post.

Not when it summarizes last month's sales.

Those activities are relatively easy to supervise.

The real operational question begins when AI is allowed to act.

Imagine giving an AI agent these instructions:

Handle routine guest complaints.

What is routine?

Respond to reservation enquiries.

Which promises may it make?

Optimise delivery availability.

Can it pause a platform?

Manage purchasing.

Can it approve a supplier substitution?

Resolve refund requests.

Up to what amount?

Change staffing recommendations.

Does it recommend the change or execute it?

Suddenly the important question isn't simply:

Can AI do this?

It becomes:

How far is AI allowed to go before a human decision is required?

And that boundary needs to exist before the agent encounters the situation.

Because automation doesn't automatically remove ambiguity.

It can automate ambiguity.

And automated ambiguity can travel much faster than the human version.

The Statue Effect Has an Opposite

There is a pattern I have watched repeatedly in hospitality operations.

A senior person steps away.

Questions begin travelling back toward them.

A decision waits.

Then another.

Someone calls.

Someone sends a message.

Someone stands in the doorway waiting for an answer.

The operation slows because too much knowledge or decision authority has become concentrated in one person.

I call this the Statue Effect.

Remove the statue and everyone notices how much of the building was leaning against it.

AI introduces an interesting opposite risk.

Instead of the operation stopping because nobody knows what to do, the operation may continue because the system believes it knows exactly what to do.

At first, that sounds like progress.

No bottleneck.

No waiting.

No manager being interrupted every two minutes.

No owner answering WhatsApp messages from home.

The system simply acts.

Until its interpretation of authority differs from yours.

One system waits for the owner.

The other doesn't.

Neither condition automatically tells us that the operation is mature.

The real question is:

Was the decision boundary designed before pressure arrived?

Before Automation, Draw the Line

Before asking whether a person, process or AI agent can perform a task, separate four questions.

What can it see?

Information access.

What information is necessary to perform the task?

What can it recommend?

Advice without execution.

The system can identify an action without being allowed to perform it.

What can it execute?

Actions that can happen without additional approval.

This is where operational authority begins.

What must stop and return to a human?

The approval boundary.

The point at which execution stops.

Those are four different things.

Yet businesses routinely collapse them into one instruction:

“You can handle this.”

That sentence works beautifully when conditions are calm.

Under pressure, its weaknesses become visible.

Pressure Doesn't Always Create the Problem

Pressure often reveals what was already unclear.

A quiet restaurant can hide vague authority.

An experienced employee compensates.

The owner is nearby.

Someone asks a quick question.

A manager remembers what happened last time.

The operation appears to work.

Then the room fills.

Twenty-eight tickets arrive.

Someone calls in sick.

The delivery queue grows.

The bar backs up.

The printer starts screaming.

Now the informal conversations that held everything together begin disappearing.

People have to make decisions using whatever information and authority they believe they have.

That's the Katrina Moment.

The storm didn't necessarily create the weakness.

It exposed it.

AI can do exactly the same thing.

Only faster.

Automating Drift Only Makes Drift Faster

This is why I believe the conversation around AI in restaurant operations often begins one step too late.

We ask:

Which AI should we use?

What can we automate?

How much time will it save?

Which platform integrates with our systems?

Those are legitimate questions.

But there is an earlier one.

Is the process you're about to automate actually stable?

Because if responsibilities are already unclear…

If decisions already travel unpredictably…

If exceptions depend on who happens to be working…

If nobody can clearly explain where authority begins and ends…

…automation doesn't automatically repair that.

It can simply execute it faster.

Automating drift only makes drift faster.

Don't Ask Only Whether Your System Works

Ask something harder.

Does the system know where its authority ends?

Ask it of your people.

Ask it of your processes.

Ask it of your software.

And increasingly, ask it of your AI.

Because an operation that stops when something is unclear has a visible problem.

An operation that keeps moving in the wrong direction may have a much more expensive one.

That's why operational diagnosis cannot stop at:

Did the process run?

Follow the decision.

Where did it start?

What information travelled with it?

Who interpreted it?

What authority did they believe they had?

Where should the decision have stopped?

And did anybody have to guess?

Because whether that decision is being made by a waiter, a manager, a piece of software or an AI agent, my principle remains the same:

“If your team starts to guess, the money has already left the building.”

And AI gives us one more question worth asking:

What happens when the machine starts guessing too?

Stabilize Before You Automate

Before you automate a decision, establish whether the decision itself is stable.

**Operational Equilibrium™ **is designed for that stage.

It helps establish the operating frame before more technology, automation or AI is layered onto an unstable process:

The Frame — what the operation is actually trying to achieve.

The Fit — where technology supports the operation rather than forcing the operation around the technology.

The Line — what AI may assist with and what remains human.

The Decision — where decision authority actually sits.

The Constraint — what prevents automation from moving beyond the boundaries you intended.

Not another AI tool.

Not another piece of software.

A way to examine the operational structure before you give technology more authority inside it.

Operational Equilibrium™ — €89

Stabilize Before You Automate.

**Explore Operational Equilibrium-> **

Article by

Amos J. Amolo

Amos Jactone Amolo is the founder of 6th Sense Hospitality and an Operations System Designer with more than 30 years of experience across food & beverage, live events, catering and venue operations. He still actively owns and operates hospitality and event businesses, so his observations are not based on what the industry used to look like. They are being tested on the floor today.

His perspective was built — and continues to be tested — in live operating environments where decisions happen in real time. He watches what changes when an operation comes under pressure: where timing slips, information stops moving, responsibility becomes unclear and people begin compensating for a system that is no longer helping them.

Just as importantly, he watches the customer. Changing drinking habits, new expectations around food, shorter attention spans and the increasingly visual way guests make buying decisions are already changing how hospitality needs to operate.

That thinking forms the foundation of 6th Sense Hospitality: look beyond the obvious symptom and find where people, process, technology, money and decision-making have stopped working together.

His core philosophy is simple:

“If your team starts to guess, the money has already left the building.”

Through 6th Sense Hospitality, Amos develops practical diagnostics and operational systems that help operators see what is actually happening inside their businesses — before workarounds become accepted as normal.

Not theory. Still operating. Still observing. Still testing what actually works.