I have been running restaurants for thirty years. I have also spent the last several years watching the technology industry try to build AI tools for restaurants. The gap between those two experiences is where Table & Ledger lives.
Here is the thing nobody in a product meeting seems to know: a restaurant line during a dinner rush is a distributed computing system. It has been one since the first brigade kitchen. We just never had the vocabulary for it.
The Architecture Nobody Named
Walk into any functioning kitchen at volume and look past the noise. What you are actually watching is message passing between autonomous nodes operating under shared state constraints with a hard real-time requirement.
The grill station is a node. It has a local queue, a processing capacity, and a thermal state that affects throughput. The saute station is a node. The cold side is a node. Each one receives messages (tickets), processes them according to its own logic, and emits outputs that must coordinate with the other nodes to produce a coherent result at the pass.
The expeditor is not a manager in the conventional sense. The expeditor is a load balancer and a message broker. Their entire job is monitoring queue depth across nodes, identifying backpressure, and routing work to maintain even throughput. When the grill is buried and the saute station has capacity, a good expeditor adjusts ticket routing in real time. That is literally what a load balancer does.
The 86 board is shared mutable state. When an item runs out, that is a state change that has to propagate to every node in the system simultaneously or you get errors: servers selling things that don't exist, tickets coming in for items that can't be produced, guests waiting while the system figures out it's broken.
Every experienced operator has a muscle memory for managing these systems. We just describe it differently. We say things like "the line got backed up" (downstream backpressure), "we were in the weeds" (queue overflow), "the kitchen was firing on all cylinders" (optimal throughput with full node utilization). Same principles. Different vocabulary.
Why This Matters for AI
The technology industry largely builds restaurant AI as if restaurants are retail stores with a kitchen printer attached. That assumption is the core reason Toast has eaten Square's lunch in the full-service restaurant segment for years.
Retail inventory is quantity-based: you have 47 units of SKU 10234, you sell one, you have 46. Restaurant inventory doesn't work that way. The 86 board is binary. An item is available or it isn't, and that state can change in minutes based on prep yield, unexpected volume, or a line cook calling in sick. Building AI tools that reason about restaurant inventory using retail inventory paradigms is like trying to run a distributed system with the wrong consensus algorithm. It will work until it doesn't, and when it fails it will fail in ways that are hard to diagnose.
The labor problem is the same. Restaurant scheduling is not shift assignment against a coverage target. It is capacity planning across a system with variable throughput requirements, constrained by human factors (skill level, station certification, interpersonal dynamics), legal requirements (break schedules, minor labor laws), and real-time demand signals (reservations, historical sales curves, weather). The AI tools that treat it as a simple optimization problem miss most of the actual complexity.
What an Actual Operator Brings
I am not a software engineer. I have never written production code. What I have done is run this system under real conditions for thirty years, and I have spent the last several years systematically mapping restaurant operations concepts onto AI architecture to understand where the tools break and why.
When I walk a large language model through a restaurant scenario, I am not testing whether it knows what an 86 board is. I am watching how it reasons about state propagation, queue management, and constraint satisfaction under conditions it was not explicitly trained to handle. The model reveals its assumptions. Those assumptions are almost always retail assumptions applied to a restaurant context.
That gap, between what the tools assume and what the operation actually requires, is the entire job. Not hype. Not theory. Thirty years of operational reality applied to the question of where AI actually helps and where it confidently gets it wrong.
That is what this blog is about.