| name | reserve_table |
| description | Use this skill when the user wants to make a reservation at a specific restaurant or café. The skill drives a browser sub-agent through the reservation form. It STOPS before the final submit and registers a pending approval — the user must confirm in chat before the reservation is actually placed. Inputs include place_name, reservation_url, date (YYYY-MM-DD), time (HH:MM), party_size, contact_name, and optional contact_phone. |
| allowed-tools | ["browser_navigate","browser_click","browser_fill","browser_wait_for","browser_page_context","request_user_approval"] |
reserve_table
When to use
Invoke this skill when the user has expressed a clear intent to book a table or seat at a specific place, and you have (or can ask for) the required details:
- "Book me a table at Iva for tomorrow 8pm, 2 people."
- "Reserve at Koffein on Friday at 11am for 1."
- "Can you make a reservation at on ?"
If any required detail is missing (date, time, party size, contact name), ask the user before calling this skill. Reservations are irreversible — the skill is designed to surface a confirmation prompt before any submit happens, but it should not be invoked with partial information that would force the sub-agent to guess.
Do not invent the reservation page URL. Invoke this skill only when reservation_url is grounded in tool output or another deterministic discovery step. A venue homepage is not enough unless it is explicitly the booking page.
Inputs
place_name (str, required): human-readable place name.reservation_url (str, required): full URL of the place's reservation page.date (str, required): YYYY-MM-DD.time (str, required): HH:MM in 24-hour clock.party_size (int, required): number of people, ≥1.contact_name (str, required): name on the reservation.contact_phone (str, optional): contact phone number.
What this skill does internally
- If the host has a cached parser trace, replay it with the new arguments.
- Otherwise, spawn a browser sub-agent (ReAct loop) with browser tools:
- The sub-agent navigates to
reservation_url.
- It reads the rendered page via
browser_page_context and may retry page inspection briefly if the first view is only a shell.
- It uses
browser_wait_for only as a targeted hint for concrete selectors, not as a fatal gate.
- It fills date, time, party size, name, phone.
- When the form is ready, it calls
request_user_approval with a summary, the exact final submit selector, the place name, and the current booking URL.
- It STOPS — it does NOT click the final submit button.
- The trace is saved to the parser cache (per host).
- The skill returns
{"status": "pending_approval", "action_id": ..., "summary": ...}.
What happens after this skill returns
The orchestrator detects the pending approval and surfaces the summary to the user via chat. If the user replies "yes" / "confirm" / "go ahead", the orchestrator passes the deterministic confirm-gate and calls finalize_reservation, which clicks the submit button. If the user replies "no" / "cancel", the orchestrator discards the pending action.
The action guardrail (taste_agent.guardrails.action) enforces this — the final submit cannot run unless is_approved(action_id) is true. The check is non-LLM-based.
Output (pseudo-JSON)
status: "pending_approval" or "failed"action_id: 8-char hex (present only when status is "pending_approval")summary: human-readable reservation summary (present only when pending)source: "agentic" for a fresh sub-agent run, "cached" for a replayed traceerror: error message (present only when status is "failed")
