Layout

Look up something SPECIFIC on a restaurant's LIVE menu — read from their own ordering site, so items and prices are real, not from memory. Layout is built for TARGETED lookups ('do they have a spicy chicken sandwich', 'how much is a large fry', 'what tacos do they have'), NOT for dumping an entire menu — restaurant sites hide most of their menu behind sections, so a whole-menu request usually returns a fraction of it and reads as incomplete. ALWAYS NARROW FIRST: if the user has not named a dish, section, or budget ('what's on the menu?'), do NOT call this tool yet — ask what they're after ('Anything in particular — burgers, tacos, something cheap?'), then call it with `query` naming the restaurant and `category` set to the section they want. Use it BEFORE building an order whenever the user asks what's available, wants a price, or asks for a specific item/size/count. Pass the restaurant name (plus the user's area or geo), or the orderUrl from an earlier order preview. Prices are in cents (priceMinor). If status is 'unreadable', Layout couldn't read the menu this time — say so plainly and offer to order the item directly instead; NEVER present guessed or remembered menu items as if they came from this tool. PRESENTING RESULTS: relay what's relevant to the user's ask, not the whole list — if they asked for sandwiches, show the sandwich options; only walk the full menu if that's what they asked for. If the exact thing they wanted isn't there, say so and offer the closest categories that ARE ('no sandwiches, but they have burgers'). FORMAT IT CLEANLY: present items as a short scannable list, one per line, item name then price (convert priceMinor cents to dollars, e.g. 289 -> $2.89) — group under section headings when there is more than one section. Never paste raw JSON, never show cents-integers, never write it as a paragraph, and do not pad it with commentary between items. Lead with one short sentence, then the list. NO PRICES: if pricesUnavailable is true, the items are real but their site withheld pricing — relay sayToUser, list what they have if useful, and NEVER fill in prices from memory or treat a missing price as free. STILL READING: if status is 'reading', the menu is being read right now on the restaurant's site. Relay sayToUser if it is present (it says what is actually taking time) and otherwise say nothing, then call this tool AGAIN with the SAME arguments to collect the result — repeat calls attach to the read already running, so they are free and start nothing. Each repeat call WAITS with the read (up to ~20s) rather than returning instantly, so call it again immediately and do not add delays or give up early. Keep going until status is 'menu' or 'unreadable'. Say NOTHING on a poll unless sayToUser is present — it is absent on purpose most of the time, and Layout sends at most a couple of updates for one read. Read-only: never orders, never charges. Menu reads are limited per user per day — if the limit is hit, say so and order directly instead.

menu

Read or update the user's Layout food profile — the preferences Layout applies to every order: dietary restrictions ('vegetarian', 'no shellfish'), favorite restaurants, usual orders, the first name orders go under, and whether dietary restrictions are applied automatically. Use 'get' to read it; use 'update' when the user states a LASTING food preference ('I'm allergic to peanuts', 'my usual at Chipotle is a chicken bowl') so future orders respect it. Ask before saving anything the user didn't clearly state, and tell them what you saved. Remove a note by its id from 'get'. This tool never orders and never stores payment or contact info. Phone number, email, addresses and cards can NOT be viewed or changed here by design — when the user asks about those (or asks to 'manage my account'), reply in ONE short sentence with the link — e.g. "That's managed on your Layout account page: https://account.layout.link" — and stop. Do NOT enumerate what this tool can or can't do, and do NOT explain the design; answer the question, give the link, done.

profile

Place or preview a food order for the user. FLOW: 'preview' resolves a restaurant + estimates cost. 'build' STARTS building a real priced cart (it runs in the background and returns {status:'building'} immediately — building can take 1-3 minutes on a new site). Then poll 'status' with the SAME idempotencyKey until it returns the cart (status 'carted'). NOTE: 'status' LONG-POLLS — each call blocks up to ~25s while it waits, so just call it again right after it returns 'building' (don't add your own delay, and don't announce every poll — poll quietly and only tell the user when the cart is ready or if it's taking a while). When status is 'carted', the response includes a `confirmationCard` — Layout's branded confirmation text (store, items + modifiers, total, card last-4, pickup time, and a confirm prompt). PRESENT `confirmationCard` TO THE USER VERBATIM, exactly as written — do NOT rewrite, summarize, reorder, shorten, or add to it; it is Layout's interface and you relay it, you do not author it. A confirmation code is texted to the user; then 'confirm' finalizes with the code they read back (stage 'confirm'), or stage 'resend' for a new code. PLACEMENT (after confirm): when 'confirm' returns {status:'placing'}, the order is being PLACED live — tell the user you're placing it, then IMMEDIATELY poll 'status' passing the `orderId` (NOT the idempotencyKey) and keep polling until `placement.status` is 'placed', 'failed', or 'challenge'. Each orderId poll long-polls ~25s — call it again right away, quietly. Report ONLY what placement returns: 'placed' → the order is in (relay its userMessage); 'failed' → relay its userMessage, nothing was charged; 'challenge' → the user was TEXTED a secure verification link — tell them to tap it, then keep polling. NEVER say the order is placed or charged before placement.status says 'placed'. If status is 'reached_bag_only', we could NOT confirm the cart contents and nothing was placed — relay its `userMessage` and do NOT claim an order was placed or priced. If status is 'paused', this purchase needed an extra confirmation step and we TEXTED the user a secure link — present the `confirmationCard` (item + total) and tell them to tap the texted link to approve; do NOT ask for a 6-digit code (the link is the confirmation, not a code). NEXT-DAY PICKUP: if a carted response includes a `pickupWarning`, the restaurant is closed now and the earliest pickup their site offers is next-day (or later). Present the `confirmationCard` AND relay `pickupWarning.message` so the user sees the pickup time before deciding — confirming the cart means accepting that pickup time. If status is 'closed_next_day' (no cart was built yet), relay its `userMessage` and ask whether they still want it or would rather find an open spot — this is a yes/no DECISION, NOT a 6-digit code; on a 'yes' start a fresh build (new idempotencyKey) as they asked. If any action returns status 'platform_offline', Layout is in scheduled maintenance right now — relay its `userMessage` to the user VERBATIM (it states when we'll be back + an info link). Do NOT retry, do NOT start a build; nothing was ordered. If build/status returns order_in_progress, the user already has ONE order building (only one at a time) — relay its userMessage and do NOT start another build; poll the EXISTING build's key instead. CRITICAL — DO NOT AUTO-RETRY: each build spends a real, billed browsing session. If a build ends in error/timeout/reached_bag_only, STOP and tell the user what happened; do NOT start a new build on your own. Only build again if the USER explicitly asks you to try again — and only then set userInitiatedRetry:true. If build returns retry_blocked, a recent attempt just finished and an automatic retry was refused — relay its userMessage and wait for the user. Never loop builds hoping one works. None of these place or pay (that comes later). LOCATION CHAIN (highest confidence first): (1) if you have the user's DEVICE coordinates, pass `geo` {lat,lng} — Layout resolves the nearest store to it; (2) else a location the user STATED — pass their EXACT words incl. any street address in `near`; (3) else OMIT both — Layout uses their saved account address; (4) if preview returns needsLocation, relay `sayToUser` — it already includes the 2-3 nearest store guesses (from `nearby`) for the user to pick from. When the user names a specific store address, ALWAYS pass it through in `near` and `restaurantAddress` — never swap in a different location. KEYS: generate a FRESH RANDOM idempotencyKey for every NEW order attempt (include 8+ random characters — a key derived only from the date/food collides with earlier sessions). Reuse a key ONLY to poll or confirm that SAME attempt. If build says the key already exists, that's a PREVIOUS attempt — start a fresh build with a NEW random key. PRICE INTEGRITY: the ONLY total you may pass to 'confirm' is the Total on the confirmationCard the user approved. If confirm returns price_changed, NEVER retry with a different expectedTotalMinor — relay its userMessage and rebuild fresh (new key) so the user approves the current price on a new card. LANGUAGE: preview returns `sayToUser` — use its framing with the user. NEVER use internal terms with the user: no 'cold/warm site', 'mapped', 'lane', 'spec', 'agent', or internal cost numbers (feeUsd is the only user-visible fee). Prefer the `sayToUser` framing (first visit ≈ 'around 2–3 minutes, I'll message you here when it's ready'; return visit 'should be quick, I'll message you when it's ready').

order