Dangerously Convenient: My Agents Learn to Order Breakfast

When I'm not cooking dinner for my family, I'll admit it: I lean on delivery services. Yes, it's lazy. I prefer the word convenient. There's a meaningful difference, and I will defend it right up until the receipt arrives.

So when I found out DoorDash had shipped an experimental CLI built for AI agents — a real command-line tool with an agent skill file, OAuth sign-in, and structured JSON output — I knew exactly what had to happen. The convenience had to move into my agentic tools.

This is probably dangerous. The distance between "Claude, what's open for breakfast?" and a drone of sausage croissants landing on my porch every morning is now measured in keystrokes. Pray for my grocery budget.

But it was also a perfect excuse for a real experiment. Early on a Sunday morning, I ran two full sessions against the same tool with two different agents: Claude Code and Google Antigravity running Gemini 3.7 Flash. Same house, same hunger, same CLI. Here's what I learned — about the tool, about the agents, and about where all of this is heading.

What DoorDash shipped

Credit where it's due: DoorDash is doing something interesting with doordash-cli. This isn't an API doc dump or a thin wrapper. It's a tool that was clearly designed to be operated by an agent:

• A bundled SKILL.md — a skill file that drops into your agent's project so it knows the tool exists and how to start navigating it.
• Agent guidance baked into --help — the help text doesn't just document flags. It tells the agent how to resolve "deliver it to my work address," warns it to check for existing carts before creating new ones, and explains which fields feed which downstream commands. The docs have two audiences, and the second one isn't human.
• A required --intent flag — every command requires a plain-language statement of why the agent is making the call, which DoorDash reviews for research. Think about that: the API contract now includes the agent's reasoning. It's the API equivalent of Jerry Maguire — help me help you. I've never seen anything like it, and I suspect we'll see a lot more of it.
• --json-output everywhere — structured envelopes for agents, rendered text for humans, one flag apart.

Is it all polished? No — it's clearly an experiment, and some seams show (more on that below). But DoorDash is running the experiment with us, in public, and that deserves a tip of the cap. This is how you learn what the agentic web needs: you ship something weird and see what agents do with it.

Session one: Claude Code

The Claude session started the way every good agent story should: with my own mess. The first thing the agent found when it listed my delivery addresses was twelve saved entries — years of accumulated beach rentals, an old workplace, and inexplicably, a Chipotle. None labeled. The CLI can list addresses and set a default, but it can't clean any of that up, so I did my chores on the website and watched the CLI reflect the changes instantly. (That gap became a feature request.)

Then the fun part. "Who delivers breakfast here?" got me a tidy table of ten nearby options with distances, ETAs, and ratings. But it was 7:30 on a Sunday morning, and "delivers breakfast" is not the same as "awake." The search results don't carry open/closed status — so the agent fanned out, checked each of the ten stores individually, and came back with the honest answer: two. Sheetz and Hardee's. Everything else was still asleep, like most sensible people on a Sunday.

That little sweep is worth pausing on. No single API call answered the question I asked. The agent had to notice the gap between my question and the data, then go make ten more calls to close it. That's the layer agents add on top of raw endpoints — and it's exactly the kind of judgment work where I found the model you're running really matters.

The $5 meal deal saga

Here's where it got interesting. Sheetz runs a $5 breakfast croissant meal deal — sausage croissant, mini hashbrowns, french toast sticks, coffee. I asked Claude to build a cart with three of them.

At this point I had dropped the session down to Sonnet to save some tokens, and Sonnet fell flat on its croissant. It pulled the store's menu — 150 items — found no croissant, no sausage, no breakfast anything, and folded: the deal must not be on DoorDash. I nudged it — "might just be called a meal deal" — and it searched the same menu again, came up empty again, and gave up again. Politely, confidently, and wrong.

So I bumped the model up to Fable and asked one more time. The very next turn, it questioned the tool choice instead of the data: convenience-store catalogs on DoorDash aren't enumerable like restaurant menus, they're searchable. A different command, find-items, surfaced "$5 Breakfast Croissant Meal Dealz!" on the first try. (I didn't test Opus, but I'd wager it finds the croissant too.)

Then the wall. The combo item carries a nested option tree — four required components, each with its own required sub-selections (the croissant alone has four mandatory "default topping" confirmations; the coffee needs a brew choice). The backend demanded those selections, then rejected every one of eight different payload structures the agent tried with the same error: "Option is nested at the wrong level." The first rule of Combo Club: you must select all four items. The second rule: every way you select them is wrong. No cart, no croissants.

That became a detailed bug report, along with a third issue suggesting a more prescriptive SKILL.md so agents don't have to burn tokens rediscovering the tool's conventions every session. Three issues filed from one breakfast that never arrived. That's the experiment working, for both sides.

Session two: Antigravity

The next morning's twist: same tool, different agent, different model tier. Antigravity running Gemini 3.7 Flash — a fast, inexpensive model, not a frontier reasoner.

First hurdle was discovery: Antigravity doesn't scan .claude/skills/, so we symlinked the folder to .agents/ and it picked the skill right up. (File that under "the agentic web has no standard for where skills live yet" — we'll come back to that.)

Flash was good at this. It resolved my address, checked for dangling carts unprompted, ran breakfast and coffee searches, and found the $5 meal deal via find-items on the first try — no menu detour, no giving up. When I asked what the deal would cost delivered, it did something clever: added a $2 soda to a cart purely to unlock the fee preview, pulled the full breakdown — $0 delivery fee (store promo), $3.00 in service fees, tax — then cleaned up its test cart. It price-checked a coupon code I had (ineligible, correctly reported), and when I asked about skipping the combo entirely, it priced the components individually and told me the meal deal saves about $2–2.50 over building it à la carte.

It also hit the exact same wall on the combo's nested options — which independently confirms the bug isn't one agent's payload quirk.

What the two sessions taught me about models

Here's the observation I keep chewing on. The plumbing — auth, search, lookups, previews, cleanup — worked everywhere, on every model I tried. The difference showed up in exactly two places:

1. Knowing when the answer isn't in the data. The "who's open right now?" question required noticing that search results don't answer it, and going wider. The analytical, multi-step judgment calls were consistently where the higher-reasoning models earned their keep.
2. Knowing when to distrust your own conclusion. Sonnet looked at a menu with no croissants and declared the hunt over — twice. Fable re-examined the tool selection instead of the data and found the item one turn later. The scary part is that Sonnet didn't fail loudly; it gave up politely, which is worse. A polite wrong answer sails right past you if you don't already know the truth.

But before anyone concludes "always buy the big model": Flash ran the happy paths beautifully, and cheaply, including some resourceful moves like the throwaway-item fee preview. The real lesson is the boring, durable one — match the model to the job. Navigation and structured workflows are a solved problem at every tier. Judgment under ambiguity is not.

There's a tooling lesson hiding in there too, and it's the one I put in the GitHub issue: a more prescriptive skill file — happy-path examples, decision tables, known gotchas — is effectively reasoning subsidized in advance. Every convention the SKILL.md spells out is a dead end a smaller model doesn't need the judgment to escape. If you're building for agents, your documentation is now part of your product's model-compatibility story. Write it for the least capable agent you want to succeed.

How will agents consume the internet?

Zoom out from the croissants for a second, because this is the part that keeps me up at night (in the fun way).

Right now, if you want your service to be consumable by agents, you have a pile of options and almost no consensus: a classic REST API and hope the agent reads your docs. An MCP server. A CLI wrapper like DoorDash built. Skill files — which themselves have no standard home yet, as my .claude → .agents symlink proves. On the content side, llms.txt and agent-readable pages (this very site serves /agent.md for exactly that reason). Every one of these is a different bet on the same question: what does the agent-facing surface of a business look like?

DoorDash's bet is fascinating because a CLI is a strange, wonderful middle ground. It's self-documenting (--help is right there), it composes with everything an agent already knows (pipes, jq, files), it works over plain terminal access with no protocol handshake — and its help text can carry agent-specific guidance that would feel bizarre in an OpenAPI spec. The --intent flag goes further and hints at something bigger: agent-facing services asking not just what you want, but why, as a first-class part of the contract. There are trust, telemetry, and abuse-prevention ideas buried in that one flag that whole standards bodies will eventually argue about.

I don't know which of these surfaces wins. Probably several do, for different jobs — the same way the human web settled on sites and apps and email. What I do know is that the companies experimenting in public right now, seams showing and all, are the ones writing the early chapters. DoorDash could have waited for a standard. Instead they shipped a weird, thoughtful thing and invited agents to bang on it. Three of my bug reports later, I'd call that a successful invitation.

The adventure part

I set out to test a CLI and ended up with a pretty good preview of the next few years: agents that can nearly complete real-world transactions, tools that are half-built for them, standards that don't exist yet, and model choice quietly determining whether your assistant perseveres or politely gives up.

No sausage croissants were successfully ordered in the making of this post. The $5 meal deal remains, for now, safely out of my agents' reach — which my wallet considers a feature, not a bug.

But the wall between "ask" and "delivered" is getting thinner every month, and I can't wait to see what's on the other side. Roads? Where we're going, we don't need roads. It's going to be a fun adventure. Dangerously convenient, indeed.

–Jeremy