What I Left, and Why

The best service I've ever had had nothing to do with software. It was a person who remembered something I'd mentioned once and acted on it before I asked. Anyone who has felt it knows the feeling: you were expected.

I grew up around that. My family ran a small chain of hotels in the remote parts of Venezuela — a lodge on the shores of a lagoon in the Amazon, a hotel in a reformed monastery on the top of the Andes — and the whole craft was anticipation: knowing what the guest needed even before they realized it themselves. The warm cocoa offered to the guest reading by the fireplace after an arduous mountain hike. Setting up bird feeders by the cabin windows to create delightful encounters with local jungle fauna.

Years later, during my travels through the mountain onsens of Japan, I learned there's a word for it: omotenashi. Care that is already in place before you need it, offered without being asked and without expectation of return. It is, I think, one of the more noble things people do for each other. Even though the concept is brought to its maximalist expression in Japanese culture, I've learned the practice is universal, and a core element of human hospitality.

I've spent the last year asking operators how a hospitality operation hands itself from one shift to the next, and the same picture keeps surfacing: a Word document emailed at midnight, a verbal pass-on at the desk, a guest's open issue that survives the night only because someone happened to remember to carry it forward. The problem is not that people don't care. It's that the memory of their care has nowhere reliable to live.

I spent six years at Google building AI products. I'm not a skeptic about the technology; I helped ship it to billions of users, and I constantly marvel at its potential. Most of that time went to the unglamorous parts: how you make an LLM answer trustworthy, how you measure whether it's actually helpful to the user's true need, how to make the interface intuitive and simple to use. So this isn't a Luddite's complaint, it's a designer's disagreement about aim and metaphor.

The pitch hospitality operators are about to hear is simple: use this technology to remove the person from the customer interaction. In service it takes a specific, seductive form — put an AI between the guest and the human who would have served them. A bot to greet, to answer, to handle it. The business case is attractive because the person is the most expensive line on the page. And for plenty of industries, even more transactional forms of hospitality, automating the interaction is the right call.

But high-touch service is not the right context for this bet. Here the product is the human moment. When someone chooses a boutique hotel over a large one, a fine-dining restaurant over a fast one, a person over a kiosk, the person is not the inefficiency. The person is the interface they are paying for, to be understood, to be empathized with, to be seen. Pointing your most powerful new tool at the one part of the business your customers are actually paying for isn't innovation. It's a race to turn your service into a commodity. Once the attention pendulum swings back from short-term curiosity, customers will go back to seeking real, human-mediated experiences.

The error is easy to make because it mistakes what's expensive for what's valuable. A service team's day is mostly not spent on care, it's spent on the work around care: a front desk spread across a dozen-plus systems that don't talk to each other; a guest preference buried in a field so deep that a veteran told me she'd opened it a handful of times in her whole career, because it's almost always blank; the shift handoff I just described, still improvised by hand at the end of every night. Most of what your best people spend their hours on is overhead — reconstructing context, chasing the dropped ball, relearning what the last shift already knew. It was all captured somewhere — typed into a system, mentioned in the huddle, texted over chat — and then never coordinated, the open loop never closed.

That is the most valuable target for automation. Not the welcome. The memory and coordination required to make the welcome feel exceptional.

This is what I left Google to build, and it fits in one line: automate the work around care, to make the moment where the care actually happens exceptional. An intelligence that quietly carries the memory and the coordination — what's open, who's arriving, what the last shift knew, who needs to know it next, what worked before — so the person on the floor walks in already holding it, instead of rebuilding it from scratch every shift.

Service intelligence, not another dashboard or app to check. No bots talking to your guests. A manager should see the state of the house, the open loops, and the moments when someone on the team went above and beyond. But it is never a way to watch the team: the moment a system points at people instead of working in service of them, the trust it depends on is gone. The floor gets the infrastructure; the people keep the craft.

The honest answer to how information survives the change of shift, or a veteran leaving the team, is barely — and only thanks to the diligent work of people passionate about serving others. I have enough conversations now to see the problem pattern clearly; I don't yet have the proof that it's solved. The next step is evidence: implementing this system using a real hotel's own data, and a team that chooses to use it because it gives them their time back.

I left a good job because I couldn't talk myself out of that. This is the most powerful technology humans have built in my lifetime, and I think we're about to throw it at the wrong target, in the one domain I care most about. I'd rather run towards discomfort and challenge while building the alternative than rest on the illusion of stability of a steady paycheck while watching from the sidelines.

I'm sharing the journey in the open as it happens — what I learn from operators, what I get wrong, and what a memory-and-coordination layer for the floor actually turns out to be. If you run a service team, I'd genuinely value your read on whether this lands — and if there's a handoff or a pass-on somewhere in your operation where things routinely die between shifts, I'd love to see how it actually works.

— Carlos