Agentcard
← Blog

How to Build an AI Agent That Orders Groceries

Grocery delivery is one of the most useful things an AI agent can do on someone's behalf, and it is a genuinely different engineering problem from ordering off a marketplace. Like any agent checkout it splits in two: driving the store — accounts, search, cart, address, and delivery windows — and paying safely. This post covers the first half, using Good Eggs as the running example because it is the kind of cooperative, single-catalog grocer the approach fits best. The payment half is in how AI agents pay for grocery orders safely.

If you would rather not build it: Agentcard ships grocery checkout as an MCP server your users connect to over OAuth, with the payment side fully handled. What follows is what the build itself involves.

A grocer is friendlier than a marketplace

Unlike a bot-defended food marketplace, a typical online grocer is a single store with one catalog and far lighter automation defenses. That changes the cheapest reliable identity strategy. Rather than borrowing a human's logged-in session, you can give the agent its own account at the store — which is cleaner, more stable, and keeps the agent's activity separate from the user's personal account.

Identity: give the agent its own account

An agent-owned account is a store account created specifically for the agent, tied to an email inbox the agent can actually read. To stand one up you need two things most people forget:

  • A programmatic mailbox. Grocers send verification links and order confirmations by email, so the agent needs a real inbox it can read — not a human's personal email. Provision a dedicated address per agent.
  • Generated credentials. Create the store account with a strong generated password and store the whole identity (email, password, and the contact details the store requires) as the agent's profile, scoped per user and per connecting app.

This gives the agent a durable identity — saved addresses, order history, delivery preferences — without a human ever sharing personal credentials, and it cleanly attributes the account's activity to the agent's operator.

Driving the store with captured endpoint specs

A grocery site is a normal web app backed by a handful of API calls. Rather than automate the visible page — which is brittle, because layouts and selectors change constantly — the durable approach is to capture the underlying calls once and replay them.

Endpoint-spec replay: you run a real session through the store's flow, record the API calls it makes, and turn each into a typed template — the request shape, the headers, and which values are dynamic (the search term, an item ID, the session cookie). At run time the agent fills the template with current values and issues the request directly. No browser rendering, no selector scraping. Two things make this robust in practice: carry the session cookies forward across calls, and re-authenticate automatically when the store returns an unauthenticated response, so an expired session self-heals instead of failing.

The grocery order flow

With identity and replay in place, the sequence is straightforward, with a couple of grocery-specific wrinkles:

  • Search. Be aware the store's search can be narrower than you expect — some match on product name only, not brand or description — so an agent searching for a brand should query by product type and filter the results.
  • Add to cart, view cart. Standard, but watch the order minimum: many grocers reject checkout below a threshold, so the agent has to know the minimum and surface it before trying to pay.
  • Set the delivery address on the basket, including whether it is okay to leave at the door.
  • Fetch and select a delivery window. The store returns available time slots, each with a fee and a status; the agent picks one and submits it.
  • Tip, optionally, before placing the order.

The signed-window gotcha

Here is the detail that wastes an afternoon if you do not know it. The delivery slots a grocer hands back often carry a server-signed token — a value the store generated and signed to prove the offer is genuine and unexpired. When you select a window, you have to echo that token back exactly as received. Reconstruct the slot from your own cached values and the order is rejected with a validation error, because the signature no longer matches. The rule: treat the delivery offer as opaque, store it whole, and pass it through verbatim. And because these tokens expire, re-fetch the windows if the user takes a while to confirm rather than reusing a stale one.

What breaks in production

  • Account provisioning. No readable inbox means no verification and no order email; the mailbox is load-bearing, not an afterthought.
  • Spec drift. The store changes its payloads on its own schedule. Validate the fields you depend on and fail loudly when one disappears.
  • Expired delivery windows. Signed offers time out. Re-fetch before submitting if any time has passed.
  • Order minimums. Surface them early; a cart that cannot check out is a worse experience than a clear "add $6 more to reach the minimum."

How does an AI agent order groceries without using the website UI?

It drives the store's underlying API directly using captured endpoint specs: a real session is recorded once, each call becomes a typed template with the dynamic values marked, and the agent fills and replays those templates at run time. This avoids the fragility of automating a rendered page and keeps working as the visual layout changes.

What is an agent-owned account for grocery ordering?

It is a store account created for the agent itself, tied to a mailbox the agent can read, with generated credentials stored as the agent's profile. It gives the agent a persistent identity — saved address, preferences, history — without a human sharing personal account credentials, and it attributes activity to the agent's operator.

What is the signed-window gotcha?

Many grocers attach a server-signed token to each delivery slot to prove the offer is real and current. You must pass that token back verbatim when selecting the window; rebuilding the slot from cached values fails signature validation. Store the offer whole, send it through unchanged, and re-fetch it if it may have expired.

Or skip the build: connect Agentcard

Standing up an agent-owned account with a real inbox, capturing and maintaining endpoint specs, handling the order minimum and the signed-window dance — that is the grocery build, and it shifts every time the store does. Agentcard exposes grocery checkout as an MCP server your users authenticate to over OAuth, with a single conversational buy tool that runs the flow server-side. And you never solve the payment part: card issuance, tokenization, spend limits, settlement, and refunds are all handled. The Model Context Protocol makes it a drop-in for any compliant agent.

Next steps