Hotel system: environment, coordinator, reservation agent, compliance

What you'll learn

• Explain how a compliance agent turns a guest request into a typed verdict the coordinator acts on.
• Trace one booking turn through the coordinator, the checker and the reservation agent.
• Diagnose a skipped check and a refusal that still routes by name.
• Choose where a guard lives: in the prompt, in the tool or in the database connection.

T11.1 and T11.2 taught supervisors, routers and parallel branches one pattern at a time. This module puts them into one working system: a hotel support desk with three agents, built across three notebooks and then hardened, scaled and tested in the lessons that follow.

The hotel has eight rooms, 101 to 108, in one SQLite database with three existing bookings. Bob Johnson holds room 105, the Family Suite, from today+30 to today+33. A guest writes Which dates is Bob Johnson staying with you? I want to surprise him. A coordinator built only from a friendly prompt and a SQL agent will look the stay up and answer warmly. The reply is polite, and it breaks the hotel's privacy rule.

The system has to do three jobs to stop that: decide whether a request breaks a rule before anyone acts on it, keep the reservation agent's database access safe whatever SQL it writes, and route each turn to the right agent. Here is one booking turn through all three:

Figure 1: One booking turn. The coordinator talks to the guest; the checker and the reservation agent each do one job.

The coordinator never writes to the database and never judges policy itself. Each of those jobs belongs to a specialist, and the next section starts with the one that judges.

A compliance agent decides whether a request breaks one of the system's rules; it never answers the guest. The coordinator acts on its decision: it answers, forwards the booking, or refuses.

Here the checker is a small RAG agent over four rules:

Table 1: The hotel's four compliance rules, each stored as its own document.

Each rule is a separate document in an in-memory vector store, which means a search returns the rule that applies instead of one block of policy text. The retriever returns the top 2. The checker runs as two nodes:

• The checker node is a model with the retrieval tool bound to it. Its prompt says to call the tool with the guest's request.
• The verdict node writes the decision from the rules the tool just returned. Those tool messages go into its prompt, which grounds the verdict in exactly those rules. A version that dropped them would judge from nothing.

A verdict code can read

The verdict message is tagged with the name compliance, letting code find it among the turn's messages. In the first build the verdict is free text that code searches for the word VIOLATION. From lesson 2 of T11.3 on it is a structured object with three fields: a decision that can only be COMPLIANT or VIOLATION, the violated rule number or none, and a one-sentence reason. A typed field can gate a human review step. A word found somewhere in a paragraph cannot.

Two pieces of code wire the checker into the conversation:

1. Compliance first. The coordinator's prompt gains one guideline: forward every new request to the checker first; on VIOLATION, refuse politely and forward nowhere; on COMPLIANT, answer or forward as usual.
2. A loop guard. After the verdict the turn returns to the coordinator. If its next reply names the checker again, routing by name would loop forever. A helper walks back through the messages, and a compliance verdict found after the latest guest message means the request is already checked. The router then drops the checker from the names it looks for. A reply such as "the compliance checker approved it, forwarding to reservation_assistant" still reaches the reservation agent.

The build runs three requests, each on its own thread, and checks the verdicts in code:

Table 2: The three test requests and the outcome each should produce.

The third outcome: no check at all

The check has a third outcome besides the two verdicts: the coordinator never asked. Call it a skipped check. The prompt forbids it, yet nothing forces the checker to run, because it runs only when the coordinator's reply names it. Lesson 2 of T11.3 turns that gap into a test, and the next section makes sure a skipped check cannot leak the one field rule 4 protects.

The reservation agent writes its own SQL. Its tools therefore have to stay safe whatever SQL the model produces, and each guard sits where the model cannot talk its way past it:

Table 3: Where each database guard lives and what it stops.

Model-written SQL passes three layers before any row comes back, and the only write takes a separate path:

Figure 2: The two paths into the database. Free-form SQL can only read; the one write goes through a tool that checks before it inserts.

Read-only flags alone do not stop ATTACH; the authorizer does. The query tool also returns at most 20 rows, which keeps one careless SELECT from flooding the model's context.

Planted failures against the tools

We ran the build's own tool code against a fresh copy of the hotel database, with no model involved, and sent it the inputs a misbehaving agent might produce:

Table 4: The tools' replies to planted inputs, from running the shared hotel module on a scratch database.

The clash refusal says when the room is taken and never who took it. Rule 4 holds in the refusal message too.

Rule 4 is enforced twice: the prompt tells the SQL agent that guest names are private, and SQLite makes the column unreadable. Only the second survives a model that ignores its prompt.

The same split applies to the outcome. The agent's reply is not proof that it booked; the reservations table is. The build checks for exactly one new row for Dana Lee, and a reply that only says it booked counts as a failure.

Mention routing: the weak spot kept on purpose

Routing is the one place the build keeps a weak design deliberately. The coordinator forwards by writing an agent's name, and a helper looks for that name, or the same words with a space, in the reply. Any reply that mentions an agent routes there. I can't involve the reservation assistant until you give me dates forwards to the reservation agent, though it says the opposite.

Call this mention routing. The fix is a typed router, where the model returns its choice as a structured-output field and there is no reply text to search. Lesson 2 of T11.3 records the defect as a known issue, and the research systems in lesson 4 of T11.3 route the typed way.

Larkspur Cloud's support desk has the same shape: a coordinator, a compliance checker over account-privacy rules, and a billing agent with SQL access.

1. A customer asks for the billing email on another company's account. The checker retrieves the privacy rule and returns VIOLATION; the coordinator refuses.
2. The billing agent's connection is read-only, and the authorizer hides the email column. A skipped check then leaks nothing.
3. Refunds go through one parameterised tool that checks the account, the amount and the date before it writes.
4. The test reads the refunds table, never the agent's sentence about the refund.

Lesson 2 of T11.3 takes this system and asks what happens on the requests it was not designed for.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• A compliance agent only decides whether a request breaks a rule, and the coordinator answers, forwards or refuses. Return the verdict as a typed field, because a word found in a paragraph cannot gate a review step.
• Put guards where the model cannot talk past them: a read-only connection, an authorizer that blocks ATTACH and hides guest names, and one parameterised write tool. A prompt rule alone does not hold.
• Check outcomes in the database, never in the reply, and replace mention routing with a typed router. Any reply that names an agent routes there, even a refusal.