A reasoning layer for the floor. Honest about what’s hard.
This page is for engineers. If you build systems that have to be right, not just impressive, the problem underneath Omote is one of the more interesting ones in applied AI right now. It is also genuinely unsolved in places. Here is the honest shape of it: what we build, what is hard, where we actually are, and what a founding engineer would own.
A service operation already knows almost everything it needs. The knowledge is just unstructured, scattered, and contradictory.
Read the unstructured
The signal lives in radio calls, WhatsApp threads, shift notes, and email. No schema, no labels, half of it shorthand. The first job is to read it the way an experienced operator would, and never to make the team file tickets to feed a database.
Ground it in messy records
A guest, a room, a reservation, a past complaint: the same entity is spelled five ways across a PMS, a CRM, a spreadsheet, and someone’s memory. Resolving it, and grounding every statement in a real record, is most of the work. If it can’t be traced, it isn’t said.
Reason, don’t rule
Great service is judgment, not a script. The system reasons from a few of the house’s commitments to the situation in front of it, and it shows its work. Guardrails are a handful of plain principles, not two hundred rules and not a black box.
Write back, with a person in the loop
Nothing is sent on its own. The system drafts, a person approves, and the result is written back to the tools the house already runs. Every action is attributable to a decision someone made.
Naming the difficulty is the most credible thing we can do.
Grounding without hallucination, at service speed
A brief that is 95% right is worse than no brief, because the team stops trusting it after the first miss. Getting to the bar where a manager will rely on it on a Saturday night is the whole game, and we are not done.
Entity resolution across systems that never meant to talk
There is no clean key. We reason over noisy, partial, and conflicting records, and we have to be honest about confidence instead of guessing with a straight face.
Capturing judgment without flattening it
Encode too little and it is generic. Encode too much and it is a rulebook that breaks on the first real situation. Finding that line is an open design problem, not a solved one.
Earning trust from people software has burned
The floor has to believe the system serves them, not the people watching them. That constrains what we build as much as any technical limit, and we think it should.
We are deliberate about what is proven and what isn’t. The pain is validated by operators. The quality bar and the economics are being tested in the field right now. We would rather show you a real result built from real traffic than a roadmap.
Design-partner stage. We build inside real properties across New York, California, and Spain, with a small founding team. Early enough that the architecture is still yours to shape, not a corner of someone else’s design.
Real surface, end to end: the ingestion and grounding pipeline, the reasoning and guardrail layer, or the human-in-the-loop write path. The exact shape depends on you. We would rather talk than pretend the org chart is already fixed.
The principles we build against live on the About page, and we write the field notes as we go in the Journal. A good place to start is Built for Desks, Built for the Floor.
If this is the kind of problem you want to spend years on.
The fastest way in is a conversation. Book a time with Carlos, or send a note about what you’ve built and what pulls you to this. A person reads every one.