Reasoning, Not Rules

There is a ryokan about an hour outside Tokyo that has been run by the same family for four generations. I spoke recently with the son who will take it over, and I asked him the question I ask everyone in this work: how do you get what your best people know into the rest of the team?

They don't, and there is no manual. A new hire spends a month or two walking the floor beside someone senior, then serves guests with that person nearby to advise, and that is all there is to it. The staff stay twenty, thirty, forty years. "We don't have any way to get that experience to the company," he told me. "Our business model totally depends on the employees."

There are two ways to make service exceptional. One is to write down what good looks like, codifying it as standards, SOPs, checklists, the if-this-then-that of a well-run operation, then training people to execute it. This is the Western tradition at its most sophisticated: the famous hotel gold standards, the daily lineup, the three steps of service. It is reproducible, trainable, and it scales. Past a point, it also creates the same output regardless of who delivers it. It turns service into a commodity.

The other way is to hold a few sacred principles and reason from them to whatever the situation in front of you actually needs. Anticipate what isn't said, keep the care invisible, treat this guest in this moment as if the encounter will not come again. It produces a different act every time, because the situation is different every time. The Japanese have a word for service of this kind, omotenashi, and the reason it can't be reduced to a rulebook is built into this idea: a rule assumes the situation will recur, and this practice assumes it never does.

Ichi-go ichi-e (一期一会): as if the encounter will not occur again.

Another hotelier in Japan put the distinction to me plainly. This, he said, is not a commodity service. It is a way of thinking, not a set of rules. The first model scales by shifting judgment away from the floor. The second scales by pushing judgment out to it. For guests they can look similar, since both produce attentive service. But they feel different. They are opposites in where the judgment lives, and everything else follows from that. I've written before that software was built for the desk and never for the floor, and the industry is aiming its newest tool at the wrong target, the staff providing service.

This piece is about the philosophical grounding underneath both of those.

Hold that distinction next to every piece of software a service business has ever bought. A reservation system holds a reservation. A CRM holds a field. A ticketing tool holds a ticket; a workflow engine, a branch. Until very recently, software could represent rules and records and almost nothing else. So to digitize service was, necessarily, to script it. Standards became fields — and judgment remained in some people — because those were the only shapes the material could take.

This is why technology has made service feel colder and inflexible (think check-in kiosks at a hotel lobby) and why experienced operators have learned to be wary of it. It wasn't a failure of taste, it was a limitation of the material. You cannot carve judgment out of a rules engine. Every wave of service technology pushed the work toward the commodity, because that was the only direction the tools could push. The tension between soul and software in this industry is real. But it was a property of what software could hold, a technical constraint of the substrate in which it is built.

What changed in the last few years is that the thing underneath the software now reasons. Give a capable model principles and a real, messy situation, and it returns a judgment about that situation rather than a lookup from a table. It handles cases it has never seen, reads context, and tolerates ambiguity.

With the appropriate restraint, it can even reach the judgment that the right move is to do nothing, which any good host will tell you is half the job.

Ma (間): the right move is to do nothing.

That is the real reason building omote is possible now, more existential than "AI is good with words so let's make it talk to our guests." For the first time, the grain of the tool runs the same way as the grain of the craft. What an experienced floor manager does and what a reasoning model does are similar: understand a few commitments deeply, reflect on pre-existing patterns and their consequences, and apply them to the particular case in front of you. A technology can finally carry judgment, not just rules. So it can extend the reasoning of your best person instead of flattening everyone toward an average.

But let's pause. This is exactly the context where applying AI without guardrails can lead to the destruction of the exact thing we aim to preserve: human-touch service. The same property that lets a model carry judgment lets it do real harm. A system that can extend a host's judgment can just as easily be pointed at the guest to replace the host, commoditizing the craft faster than any CRM ever managed.

We must restrain its application to preserve the interactions where the value of human labor really lives: the warmth of a smile, the confidence of a firm handshake, the attentive ear to unspoken needs.

The work required to build omote is not the part people picture when they hear "AI." Most of the work is making the reasoning trustworthy enough to support a real service operation. Every fact the system surfaces has to carry its source: where it came from, when, and whether a guest said it, a staff member observed it, or the system inferred it. Its output has to be graded against libraries of real cases, the way you'd regression-test anything you intend to rely on. I spent years on this class of problem before omote, much of it at Google.

As models become a utility available to everyone on roughly the same terms, the value compounds in two places the model doesn't reach. The first is the accumulated, structured understanding of how exceptional service teams actually reason. The second is the restraint that keeps a reasoning system trustworthy and accepted by service operators. Both are earned slowly, both are hard to copy.

I have a thesis I'm increasingly sure of, though not one I have proven yet: that the reason service resisted good software for forty years was the grain of the material, and that the material has just changed. The approach is intentionally designed to preserve the essence of service: a restrained intelligence that carries the memory and the coordination so the person on the floor can do the part only a human can. The tool can finally be built to amplify that judgment instead of erasing it.

Whether it gets built this way is a deliberate choice, not a property of the technology. Making that choice is the whole reason I started this company.

The work your best people do every day, the reading of the room, the thing handled before it's asked for: does it feel like something you could ever actually record in your technology? Or is it exactly the thing that walks out the door when a veteran does?

I'd value your read.

— Carlos