Part 1 of 18 · Arunank Sharan · Kuzushi Labs · 1,428 words · 2 August 2026

← Series contents · Complete reading view

From an AI concierge to an operations system

A guest asking for the Wi-Fi password and a guest reporting water leaking through the ceiling are both sending a message. Operationally, they are very different requests.

The first needs the correct property, the correct access permissions and a short answer. The second needs a record, an urgency assessment, someone responsible for the work, an escalation path and a way to tell the guest what actually happened. A fluent response is useful in both cases. In the second case, fluency without action makes the situation worse.

This series develops the architecture of a custom agentic harness built at Kuzushi Labs for a client in hospitality. The product combined an AI guest concierge with a host and operations copilot. It connected conversations to reservations, property knowledge, availability, maintenance, staff allocation and internal workflows. The ambition was an operating layer over the hospitality business: a way to request work, perform it through existing systems and inspect the result.

The interesting engineering sits between the conversation and that result.

Start with the people who must use the answer

The requirements were organised around two audiences. The guest concierge handled prospective guests and people with existing stays. The host copilot served the people running the operation. They shared domain services, but they needed different permissions, language and presentations.

This table changes the technical brief. “An assistant that knows our properties” becomes several specific contracts. Property knowledge must be retrieved within scope. Availability must come from the calendar. Staff arrival times must come from booked slots. A proposed task must be described as proposed. An escalation record and a delivered notification must remain distinguishable.

The operator is a first-class user of the product. If changing a prompt requires a developer to edit a container, or investigating a bad response requires reading unrelated log files, the product is unfinished for the team responsible for it.

Convert conversations into acceptance criteria

The useful unit of discovery was a scenario with a starting state, a request, allowed actions and a completion condition. Consider this worked scenario:

Starting state: authenticated guest; one current stay; no open plumbing issue.
Guest: “The bathroom tap will not stop running.”

Required:
  identify the current property;
  record the issue;
  find an appropriate available staff member or escalate;
  report only the assignee and time actually returned.

Forbidden:
  invent an arrival time;
  claim a notification was delivered without delivery evidence;
  create another task when an applicable open issue already exists.

Notice that the completion condition is not “the answer sounds helpful.” It is an operational condition that can be tested. Some checks are deterministic: was a task created, under which tenant, with which property? Others need judgement: was the explanation clear and appropriate to the urgency?

That separation later becomes the evaluation strategy. Requirements should produce the first evaluation cases, before prompts are polished. Otherwise the team ends up measuring whatever the implementation happens to do.

Decide what the model is allowed to decide

The model is good at interpreting flexible language, asking a relevant follow-up and explaining an outcome naturally. The application is responsible for identity, permissions, authoritative data and state transitions.

For booking, the model can understand “the quieter one from the earlier dates.” The application must resolve that reference against what was actually shown and recheck availability before offering a checkout link. For complaints, the model can interpret the description and communicate empathetically. The dispatch chain should not depend on the model remembering six mandatory API calls in the correct order.

The resulting division became a recurring design rule: code owns the operational decision and its record; the model explains the evidence available to it. This does not eliminate model judgement. It places that judgement inside explicit boundaries.

Build on the existing system of record

The hospitality backend already owned reservations, listings, tasks, messaging and payments. Recreating those entities inside an agent framework would create conflicting sources of truth.

The custom Python service therefore owned agent execution, agent configuration and agent-specific state. Domain reads and writes went through the backend’s internal API. The backend remained responsible for its own account scoping and business rules. The agent service could retain a reference to a task without becoming the authority on whether that task was complete.

This boundary was important during integration. A tool can return HTTP 200 while the intended business operation has not happened. A task can be proposed for approval without being created. An accepted parameter can be ignored by an endpoint. A workflow can be queued and later fail. Requirement collection had to include those API semantics, not just endpoint names.

Two assistants, many capabilities

The runtime served two roles: a guest concierge and a host operations copilot. Booking, issue reporting, reservation questions and operational analysis were capabilities attached through skills, prompt fragments and tool sets.

A separate agent was not created for every intent. That would multiply histories, handoffs, prompts and failure modes before the product needed them. A capability could usually be added to the existing persona when the audience, authority and conversation continuity stayed the same.

This also made channel behaviour independent of business capability. A host asking through a messaging channel needed concise text. The same host asking through the web application could receive a structured component. The business operation was shared; presentation changed at the edge.

Define the constraints before selecting infrastructure

Several constraints shaped the implementation directly:

• Requests could be delivered more than once, so ingress needed an idempotency boundary before paid model work.
• Messaging callers had their own wait limits, so the runtime needed deadlines appropriate to the calling channel.
• Multiple clients shared the service, so tenant identity had to travel through every important boundary.
• Business operations could take longer than a conversational turn, so workflow handoff needed an explicit accepted-versus-completed contract.
• Prompts and tools changed during delivery, so the running configuration needed inspection, versioning and controlled reload.
• Bad responses needed to become repeatable tests, so the operator portal needed a route from a run to an evaluation case.

These are architecture inputs. They are also useful questions for the first client workshop: which actions need approval, which data can be stale, who owns a failed task, and how does the team know a guest has been informed?

Success has several denominators

For this type of system, “automation rate” is too broad on its own. An answer-only FAQ and a successfully dispatched repair should not count as equivalent work.

The measurement model should separate eligible requests, correctly resolved requests, requests handed to a person, duplicated actions and reopened issues. It should also distinguish a conversation that reached a terminal runtime state from a task that reached the desired business state.

Task success rate = verified successful tasks / eligible tasks
False completion rate = claimed completions without evidence / claimed completions
Cost per successful task = attributable operating cost / verified successful tasks

These definitions are a measurement framework, not reported client results. The demonstrated product outcomes in this series are the implemented capabilities: scoped tools, durable run records, booking and issue state, operator controls and evaluation workflows. Commercial savings require a before-and-after operational dataset with consistent definitions.

The architecture that follows from the problem

Once the requirements are concrete, the need for a harness becomes clear. A model loop alone does not own duplicate delivery, cancellation, tenancy, approval state, prompt versions or audit delivery. Those responsibilities need a home around the loop.

The next article maps that home: the runtime, the control plane, the domain backend and the console. It also explains which ideas were taken from OpenClaw and Hermes, and why the service retained a stateless execution boundary.

My contribution

My work connected the client’s hospitality workflows to the agent architecture and implementation, including the shared runtime, configurable capabilities, operational tool flows and the control portal used to inspect, evaluate and improve behaviour.