When AI agents place the order: getting your menu and APIs ready for agentic commerce

For most of digital ordering's history, the guest has been a person looking at a screen. You designed menus for thumbs, photos for appetite, and checkout flows for impatience. That assumption is starting to crack. AI assistants can now look for a place to eat, compare options, build a cart, and in some cases place the order, with the guest approving the result instead of tapping through every step.

It is early. But the requirements agents bring are not exotic. They are the same things good digital operations already need, held to a stricter standard. A person can squint past an ambiguous modifier or a stale photo. An agent either handles it correctly or gets it wrong at scale.

What changes when an agent is the customer

An agent does not browse. It reads structured data, calls interfaces, and follows rules. That shifts where the work sits.

• Discovery becomes a data question. An agent choosing between three nearby lunch options will lean on whatever it can parse reliably: items, prices, hours, availability, dietary attributes. If your data is incomplete or inconsistent, you are harder to recommend, no matter how good the food is.
• The cart gets built without your UI. Your upsell placement, combo prompts, and carefully ordered categories may never be seen. What the agent sees is your menu model and the rules that come with it.
• Errors compound. A person who hits a confusing screen abandons one order. An agent that misreads a modifier rule can repeat the same mistake for many guests before anyone notices.

The implication is simple. For this channel, your menu data and your ordering APIs are the storefront. Design them that way.

A menu a machine can read without guessing

Most restaurant menus carry meaning that lives only in the presentation layer. "Choose up to two sauces" is written in a description. A combo's price logic sits in a POS configuration nobody documented. Allergen information lives in a PDF. A person can read context. An agent needs it explicit.

A menu ready for agents has four properties:

1. Modifiers with real rules. Minimums, maximums, defaults, and dependencies expressed as data, not prose.
2. Allergens and dietary attributes as fields. Declared per item and, where it matters, per modifier. Include what you cannot guarantee, such as shared fryers or cross-contact, so an agent does not overstate safety.
3. Pricing that is fully stated. Base price, modifier upcharges, location-specific pricing, and any fees applied at checkout. Surprise fees annoy people. For agents they are a trust failure, because the guest approved one number and was charged another.
4. Stable identifiers. Items and modifiers should keep their IDs across menu updates, so an agent that remembers a guest's usual order can find it again next month.

{
  "id": "item_harvest_bowl",
  "name": "Harvest grain bowl",
  "price": { "amount": 1450, "currency": "USD", "priceBook": "storefront", "location": "loc_downtown" },
  "availability": { "status": "available", "dayparts": ["lunch", "dinner"] },
  "allergens": {
    "contains": ["sesame"],
    "mayContain": ["tree nuts"],
    "note": "Prepared on shared surfaces"
  },
  "modifierGroups": [
    {
      "id": "mg_protein",
      "name": "Protein",
      "min": 1,
      "max": 1,
      "default": "mod_chicken",
      "options": [
        { "id": "mod_chicken", "name": "Grilled chicken", "price": 0 },
        { "id": "mod_tofu", "name": "Crispy tofu", "price": 0 },
        { "id": "mod_salmon", "name": "Roasted salmon", "price": 350 }
      ]
    },
    {
      "id": "mg_sauce",
      "name": "Sauces",
      "min": 0,
      "max": 2,
      "options": [
        { "id": "mod_tahini", "name": "Lemon tahini", "price": 0 },
        { "id": "mod_chili", "name": "Chili crisp", "price": 75 }
      ]
    }
  ]
}

Every rule a person would infer from the screen is explicit: how many sauces, which protein is the default, what costs extra, and what the kitchen cannot guarantee.

This is the core argument for a canonical menu model: one structured source that publishes to every channel. Agents are simply the least forgiving channel you will ever publish to.

Availability and orders that survive retries

Two operational properties matter more for agents than for almost any other channel.

Real-time availability

An agent that recommends an item your kitchen ran out of an hour ago has created a bad experience for you, not for itself. Availability needs to reflect reality at the location level: 86'd items, paused stores, extended prep times, daypart menus. If your availability lags behind the kitchen, agents will expose the gap faster than people do, because they check more often and act immediately.

Idempotent order submission

Agents work over networks, and they retry when something times out. Without idempotency, a retry becomes a duplicate order: two bowls fired, one guest charged twice, a store team confused. Order APIs should accept a client-supplied idempotency key, so a repeated request returns the original result instead of creating a new order. The same principle applies to payment capture and loyalty redemption.

Pair that with clear, machine-readable errors: "item unavailable at this location" and "store closed for this pickup time" should be distinct, documented responses. An agent can recover from a specific error. It cannot recover from a generic failure.

POST /v1/orders
Idempotency-Key: 7c1e9b4a-8f2d-4c61-a0b3-5d9e2f1c8a47

HTTP/1.1 422 Unprocessable Content
{
  "error": "item_unavailable",
  "message": "Harvest grain bowl is unavailable at Downtown right now.",
  "item": "item_harvest_bowl",
  "location": "loc_downtown",
  "retryable": false,
  "alternatives": ["item_market_bowl"]
}

If your ordering path spans several providers, such as a POS for menus, a loyalty platform, and a payment processor, these guarantees have to hold across the whole chain.

Policies, identity, and consent

A person reads your policies once, or never. An agent needs them in a form it can apply every time.

• Ordering policies. Order minimums, catering lead times, substitution rules, cancellation and refund windows, large-order handling. Write them as explicit rules with clear boundaries.
• Identity handoff. An agent may act for a known guest. Decide how that guest's identity links to their account, loyalty balance, and order history, and what the agent is allowed to see.
• Payment and consent. The guest should approve the final cart and total, and that approval should be explicit and recorded. Payment belongs with your processor, such as Stripe, through tokenized flows. Raw card data should never pass through an agent.
• Scope of authority. "Reorder my usual" is not the same as "order whatever you think I'd like." Your systems should know which kind of authority an agent is acting under and cap it accordingly.

Consent is what keeps an agent-placed order from turning into a disputed charge.

The brand risk of being represented

When an agent recommends you, describes your food, or resolves a problem, it speaks for your brand without your voice. That creates risks worth naming plainly.

An agent might describe a dish from outdated data, promise a promotion that ended last week, or answer an allergen question with more certainty than your kitchen can support. That is the default outcome when any system summarizes thin source data.

An agent can only represent your brand as well as your data describes it. The gaps you tolerate today become the claims an agent makes tomorrow.

The mitigation is mostly unglamorous. Keep item descriptions accurate and specific. Retire promotions in the system, not just on the website. Mark allergen information with its limits. Publish a clear path for order issues, so agents route problems to your team instead of improvising a resolution.

Measuring agent-originated demand

If you cannot see agent traffic, you cannot decide how much to invest in it. Start instrumenting now, while volumes are still small.

• Tag the origin. Identify orders that arrive through agent-facing interfaces or known agent clients, and keep that attribution through fulfillment.
• Compare quality, not just volume. Look at error rates, cancellations, refunds, and support contacts for agent-placed orders against the rest of your digital mix.
• Watch the menu signal. Agents may favor items with clean data and clear pricing. If certain items are rarely chosen through agents, check whether the data is the reason.
• Keep it in one view. Agent orders should sit alongside every other channel with the same definitions, so comparisons are honest. A shared workspace like Techtris Console is where that cross-channel view belongs.

A practical first quarter

The takeaway

Agentic ordering does not call for a new strategy so much as a stricter version of the one you should already have: a canonical menu, accurate availability, reliable APIs, and explicit policies. Brands that do this work will be easy for agents to recommend and safe for agents to order from. The rest will be skipped quietly, without ever learning why.

If you want one interface for menus, carts, orders, and loyalty that holds up for people and agents alike, explore the Techtris API, or book a demo and we will walk through your menu with you.