A customer wants a table for four at seven in the evening. They should not need to know which service checks availability or who is allowed to confirm the booking. They should have one clear conversation and receive a reliable answer.
Our system handles the work behind that answer. In the AIP Bistro case, it turned one request into a simple sequence: understand what the customer needs, check the real booking system, approve the action and confirm what actually happened.
That sequence is the important part of the story. The restaurant is only one example of a wider problem: how do several specialised agents work on the same customer request without losing context, acting too early or leaving the customer to make sense of the handoffs?
First, the system makes the request complete.
Customers rarely provide every detail at once. They might begin with “Can you book dinner?” and add the date, time, party size and contact details over the next few messages. The system keeps those details together as one request instead of treating every message as a new task.
The restaurant and its local time are already part of the business setup, so the customer is not asked for information the restaurant already knows. But the system does need the details that can change: which day, what time, how many people and who the booking is for. It asks for those details naturally as the conversation continues.
In the case we ran, an incomplete request produced a helpful question—not a guessed reservation. Even after the customer supplied only their name, nothing was booked. The system waited until the request contained enough information to act with confidence. At the same time, it remembered what had already been provided, so the customer did not have to start again with every reply.
The customer experiences one conversation. The system keeps every responsibility behind it clear.
Several modules work behind one simple confirmation.
Once the request was ready, the work moved through six distinct parts. Three of them are Hermes agents with different responsibilities. The others keep the process together and connect it to the restaurant’s booking system. Each part does a limited, understandable job.
- Hermes ConciergeSpeaks with the customer, understands the request and gathers the missing details.
- Restaurant CoordinatorKeeps the conversation and the work behind it connected as one tracked request.
- AIPMoves the work between responsible roles and holds the action until the required checks are complete.
- Hermes Booking ManagerChecks the requested slot and prepares the reservation for review.
- Cal.diy connectorLinks the workflow to the real booking system, where availability and reservations live.
- Hermes SupervisorChecks the proposed reservation independently before the system can create it.
The Concierge is the only part that needs to speak like a host. The Booking Manager can focus on the calendar, and the Supervisor can focus on the decision. The Coordinator keeps the request intact while AIP makes sure each role receives the right work at the right moment. The connector is simply the bridge to Cal.diy—it does not decide whether a booking should happen.
This separation matters because being good at conversation is not the same as being responsible for a business action. The customer still sees one smooth interaction, while the restaurant keeps clear ownership behind it.
Nothing is booked until the decision is checked.
Finding a free table is not the same as booking it. The Booking Manager first used the connector to check the requested slot in Cal.diy and prepared a proposal. That proposal contained the same date, time and party size that the customer had agreed to, but it had not changed the calendar yet.
AIP paused the work at that boundary and sent the proposal to the Supervisor. The Supervisor checked the slot independently and compared it with the original request. If a detail was missing, the time no longer matched or the table was unavailable, the process could stop before creating the wrong reservation. Only an approved proposal was allowed to continue through the connector into Cal.diy.
- Understand. Make sure the customer’s request is complete.
- Check. Read availability from the real source.
- Approve. Let another responsible role verify the action.
- Act. Create only the reservation that passed those checks.
For the restaurant, this creates a useful line between an agent suggesting an action and the business accepting it. It also makes failures easier to understand: the team can see whether a request was still being completed, a slot was unavailable or an approval did not pass.
Finally, the system confirms the result—and remembers it.
Approval is not the end of the job. After the booking was created, the Coordinator used the connector to read it back from Cal.diy and match it to the original request. Only then did the Concierge send the customer a confirmation. The customer saw the useful facts—the restaurant, date, time and party size—not the internal process used to get there.
We also repeated the same completed request. The system recognised that the work was already done and returned the existing reservation instead of creating another one. That small detail is important in real conversations, where a customer may repeat a message or a service may try again after a slow response. A retry should provide certainty, not put two tables in the guest’s name.
Restaurant booking is a familiar example, but the pattern is broader. A customer request becomes one piece of work; specialist agents handle the parts they understand; the business keeps control of the important decision; and the final result is checked before anyone calls the job complete. That is what AIP adds between a helpful conversation and a dependable outcome.
Understand. Coordinate. Verify. Confirm.