Loop
How it worksThe loopWhy LoopPricingDocs
use case hotel · hospitality · guest-facing agents

Hotel concierge agent.

A concierge agent is the clearest demo of why freshness matters. The guest asks once, expects a real answer — not a stale restaurant listing from six months ago. Loop gives the agent live search, a verify step before it commits, and a feedback channel after the guest returns. Every interaction improves the data.

flow search → verify → recommend → report
1
Guest states preferences
Agent receives natural language input: "outdoor terrace, vegetarian-friendly, not too loud, dinner"
2
search() — find matching restaurants
Agent calls search() with the preference as query and hotel neighborhood as location. Loop returns up to 8 ranked, typed results with confidence scores and observed_at timestamps.
3
get_details() — load the full record
When the guest picks a shortlist, the agent calls get_details() to retrieve opening_hours, phone, website, and the result_token needed for report().
4
verify() — confirm before committing
Before telling the guest 'yes, it's open tonight', the agent calls verify() with the claim. Loop re-checks the record live. Availability moves from inferred to observed.
5
Recommend with honest labeling
Agent presents the result with confidence score and observed_at. If verify() returns inferred: true, it says so. No fabricated certainty.
6
report() — guest returns, loop closes
After the guest returns, the agent asks for a quick outcome. A single report() call mutates the record's confidence score. Future concierge agents get better data.
code the three key calls

The agent calls these in sequence. search() narrows the field. verify() checks the winner before commitment. report() closes the loop after the guest returns.

1 — search by guest preference
// Guest: "I'd like a romantic outdoor dinner, vegetarian-friendly"
search({
  query: "romantic outdoor dinner vegetarian",
  location: "Kreuzberg, Berlin"
})

// Loop returns up to 8 ranked results:
// {
//   result_id: "m_1042",
//   name: "Café Morgenrot",
//   cuisine: ["vegetarian", "international"],
//   price_band: "$$",
//   outdoor_seating: true,
//   confidence: 0.91,
//   observed_at: "2026-06-11T20:14:00Z",
//   availability: { inferred: true, label: "likely_open_now" }
// }
2 — verify before confirming
// Before confirming to the guest:
verify({
  result_id: "m_1042",
  claim: "open for dinner tonight"
})

// Loop re-checks the record live:
// {
//   verified: true,
//   latest_observation: { open: true, observed_at: "2026-06-12T18:02:00Z" },
//   confidence: 0.94
// }
3 — report outcome after visit
// Guest returns after dinner:
// "The food was great — exactly as described"
report({
  result_token: "<token from get_details>",
  outcome: "correct"
})

// Loop mutates the record's confidence score.
// outcome options: correct · wrong · booked · closed · other
why freshness is load-bearing for concierge
Without LoopWith Loop
Static place data, no freshness timestampobserved_at on every record — agent knows how old the data is
Hours pulled from Google Places (stale at build time)verify() re-checks the specific record live before the guest goes
No way to know if the recommendation was correctreport() closes the loop — wrong info gets a lower confidence score
Each agent session is isolated — no shared learningEvery report() mutates the shared DB — all future agents benefit
availability: true — no label, no caveatavailability: { inferred: true, label: 'likely_open_now' } — honest
common questions

Can a hotel concierge agent search restaurants in real time?

Yes. The agent calls search()with the guest's preferences in natural language. Loop returns typed results with cuisine, price band, outdoor seating, vegan/vegetarian flags, confidence score, and an observed_at timestamp. No Overpass QL, no tag parsing.

How does Loop prevent recommending a closed restaurant?

Before the agent confirms a recommendation, it calls verify(result_id, claim). Loop re-checks the record live and returns a latest_observation with a freshness timestamp. Search results always label availability as inferred: true — verify() upgrades it to observed.

How does the agent collect guest feedback after the visit?

After the guest returns, the agent calls report(result_token, outcome) with correct, closed, wrong, booked, or other. This mutates the record's confidence score in Loop's DB — future agents get better data from every guest interaction.

Which agent platforms support this concierge pattern?

Any platform that supports MCP: Claude Desktop, Flowise, Langflow, n8n, Make, Zapier, Cursor, VS Code, and any OpenAI-compatible agent via the REST API at api.stayinloop.dev/v1. Add https://stayinloop.dev/mcp as the server URL — all four tools appear automatically.

Build the concierge agent

Add https://stayinloop.dev/mcp to your agent platform. All four Loop tools — search, get_details, verify, report — appear automatically. Free tier, no API key required.

Platform setup guides →Claude setup
← All use casesAI travel plannerRestaurant booking agent